Re: [802SEC] Proposed action on 802.15.3a PAR withdrawal
Personally I favor a PAR split over reduced consensus.
Once again, the real problem is that the process allows market gain
through blocking the progress of others. It is very difficult (and I
would argue unreasonable) for us (802) to decide which technology is a
better choice for the market. Generally those who are turned away just
go off and do a standard elsewhere anyway. Powerline carrier comes to
mind.
My feeling is that if any sufficiently large enough group of people want
to establish a standard, it should not be possible for an equally large
group of people (or even a larger group of people) to prevent them -
even if it splits the industry.
Again, just my view...
Mat
Matthew Sherman, Ph.D.
Senior Member Technical Staff
BAE SYSTEMS, CNIR
Office: +1 973.633.6344
email: matthew.sherman@baesystems.com
-----Original Message-----
From: Geoff Thompson [mailto:gthompso@NORTEL.COM]
Sent: Friday, January 27, 2006 12:43 PM
To: STDS-802-SEC@listserv.ieee.org
Subject: Re: [802SEC] Proposed action on 802.15.3a PAR withdrawal
Steve-
The basic flaw in your arguments rests in the brand identity of 802 and
the
assumption that participants, especially new participants, have that an
approved standard equals success. We are perfectly capable of generating
standards that are market failures.
I assert that if we reduce the approval ratio, we reduce the market
support
for the approved output. On the other hand, if we (are forced to) split
the
PAR and have two distinct standards the result is at least a crispened
choice in the market. It will take time and too much money but the
market
will, in time, decide. In the meantime we have. at least, provided a
crisp
choice.
Geoff
At 08:58 AM 1/27/2006 , Wood, Stephen R wrote:
>Geoff,
>
>I spent a great deal of time attempting to unravel the situation in
>.15.3a from the inside. Let me offer some further detail.
>
>66% approval - There is a fundamental parlimentry question here. As
the
>approval rate goes up, it clearly indicates a greater unanimity of the
>body. But, if the body is divided, it makes it easier for the minority
>to control the forward progress of the body. In theory at least, if
>committees are showing evidence of frequent jamming, it is probable
that
>the approval level has been set too high and it has now become
>profitable for groups to force a split standard rather than attempting
>to compromise.
>
>I believe that you are correct that the problem is not only present at
>the task group level. If the task group level is set to 66%, the
>problem may well work its way up the decision chain. Another possible
>outcome is that people find the strategy to stalemate too tenuous and
>become more willing to compromise. Your choices are: a) let the
>situation continue b) reset all technical decisions to 66%
b)experiment
>by altering the task group position and evaluating the effect on the
>process.
>
>Entity balloting - The ideal of a democratic organization is
>commendable. In the trenches, this is a level of idealism that is
>fairly disconnected from practice. In practice, company members vote
>together.
>
>If a company has a significant vested interest in the process, it is
>simply too attractive for them not to send a body of voters in an
effort
>to obtain a favorable outcome in the voting. This is the reality.
>
>While I fully recognize that this suggests that a fix may well require
a
>fundamental reconsideration of the organization's founding principals
>and/or a whole lot of effort to find other paths, this is a key factor
>in much of the trouble that exists.
>
>Let me give a simple example. If a startup has produced first
prototype
>silicon and is almost through round A funding at the time that
proposals
>are considered, it is extremely critical for their business to have
>their approach largely if not entirely accepted. Millions of dollars
>and entrepeneurial dreams are on the line. Would it be suprising to
>find that sending a contengient of 20 or more people who have been
>encouraged to vote positively (and who have stock options riding on the
>outcome)is considered acceptable and sufficiently ethical?
>
>
>Forced division of the PAR
>
>Personally, I take the concept of a STANDARD rather literally. To me
it
>generally means that there is one approach that is recognized by the
>body. Split standards, while in many cases expedient, are not really
>beneficial to the market. They cause unnecessary confusion and in
cases
>of radio systems, interference.
>
>I think that we should be working toward a process that reliably and
>consistently generates single solution standards.
>
>I would further argue that if we are experiencing the frequent use of
>split standards to solve or avoid excessive delays, it is probably
>another indication that your approval percentage is set too high. If a
>group is in a minority position, it is an attractive option for them to
>hold out for the split standard. They get a second bite at the apple
in
>the open market.
>
>If the rules essentially force a split PAR approach, we would have
>created an incentive. Getting to #2 is the same as a win. No further
>compromise would be needed. This type of approach would seem to
>severely diminish the likelihood of single solution standards.
>
>
>
>
>-----Original Message-----
>From: Geoff Thompson [mailto:gthompso@NORTEL.COM]
>Sent: Thursday, January 26, 2006 9:28 PM
>To: STDS-802-SEC@listserv.ieee.org
>Subject: Re: [802SEC] Proposed action on 802.15.3a PAR withdrawal
>
>Mat-
>(2nd try, the list server rejected my 1st attempt)
>At 09:38 AM 1/26/2006 , Sherman, Matthew J. (US SSA) wrote:
> > Bob / All,
> >
> >
> >
> > For the sake of brainstorming here are some possible resolutions:
> >
> >
> >
> >1) Reduce consensus level to 66%
>
>Ultimately will not work and just delays the problem. If you can't get
>75%
>at WG ballot what makes you think you can get 75% at Sponsor Ballot.
>
>
> > 2) Entity balloting
>
>Possibility but probably takes it out of 802 under current rules. In
any
>
>case it would require a PAR modification along with the attendant
>approvals.
>
>
> > 4) Task Group membership
> >
> > 4) Mandatory PAR split if predefined stalemate conditions occur
>
>I don't quite understand how these allege to solve the problem,
although
>a
>negotiated split has resolved some problems in the past.
>
>Geoff
>
>
> >
> >
> > I don't advocate one particular route or another,
> > but all of these have been suggested as potential parts of a
>solution.
> >
> >
> >
> > Another issue is cross task group / cross working group / sponsor
>level
> > influence. If you have two Task Groups working on potentially
>competing
> > technologies can they block each other? Also, people seem more apt
>to
> > cross working groups lately if they see activities in that other
>group
> > as competing with their own. In the past they were willing to live
>and
> > let live. This seems less true today. Also, even if you get a
>standard
> > through at the WG level, there is still the sponsor ballot. Any
> > interested party can participate there and kill something if they
>feel
> > it competes with a different solution that they advocate.
> >
> >
> >
> > Personally I advocate a process which is more procedural and less
> > judgmental. We have set ourselves up through the PAR / 5 criteria
>and
> > WG processes as judge and jury as to whether a project has merit,
and
> > which sets of technologies should be allowed to proliferate. I'd
>rather
> > see us merely be an instrument and forum for the development and
> > documentation of solid specifications, and let the market decide.
>The
> > specifications that succeed in the market will be come the
standards
> > that further generations of specifications are based on. We need a
> > process that reduces the potential gains available (or ability) to
>block
> > work on a basis of market addressed, or technology used.
> >
> >
> >
> > At least that's my view.
> >
> >
> >
> > Regards,
> >
> >
> >
> > Mat
> >
> >
> >
> > Matthew Sherman, Ph.D.
> >
> > Senior Member Technical Staff
> >
> > BAE SYSTEMS, CNIR
> >
> > Office: +1 973.633.6344
> >
> > email: matthew.sherman@baesystems.com
> >
>-----Original Message-----
>From: Bob Heile [mailto:bheile@ieee.org]
>Sent: Thursday, January 26, 2006 11:46 AM
>To: STDS-802-SEC@listserv.ieee.org
>Subject: [802SEC] Proposed action on 802.15.3a PAR withdrawal
>
>
>
>Dear EC Members
>
>
>
>As you have all probably seen in the press, Task Group 3a in 802.15
>voted
>
>to recommend the withdrawal of its PAR. The action was unanimously
>
>affirmed by the full Working Group. The PAR was due to expire in
>December
>
>of this year anyway and given that one of the parties in the stalemate
>
>adamantly refused to compromise, this is a sensible action. I will be
>pre
>
>submitting this recommendation for conditional inclusion on the NesCom
>
>March meeting agenda subject to approval by the EC in Denver in a few
>
>weeks. Just wanted to give everyone a heads up.
>
>
>
>Press has been generally neutral to slightly positive regarding the
>
>action. The IEEE has not been blamed. That is the good news.
>Something
>
>we may want to discuss though is the fact that this collision of
>factions
>
>is happening more and more. We seem stymied on how to deal with blocks
>and
>
>voter influence through economic pressure. Proving this stuff is
>difficult
>
>and the level of proof required is unclear. Does taking action expose
us
>to
>
>lawsuits? Our 75% consensus requirement makes it relatively easy to
>block
>
>an action. These are topics we should perhaps discuss in Denver.
>
>
>
>Bob
>
>
>
>
>
>
>
>Bob Heile, Ph.D
>
>Chairman, ZigBee Alliance
>
>Chair, IEEE 802.15 Working Group on Wireless Personal Area Networks
>
>11 Louis Road
>
>Attleboro, MA 02703 USA
>
>Mobile: +1-781-929-4832
>
>email: bheile@ieee.org
>
>
>
>----------
>
>This email is sent from the 802 Executive Committee email reflector.
>This list is maintained by Listserv.
>
>
>----------
>This email is sent from the 802 Executive Committee email reflector.
>This
>list is maintained by Listserv.
>
>----------
>This email is sent from the 802 Executive Committee email reflector.
>This list is maintained by Listserv.
----------
This email is sent from the 802 Executive Committee email reflector.
This list is maintained by Listserv.
----------
This email is sent from the 802 Executive Committee email reflector. This list is maintained by Listserv.