Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [802SEC] what is an interpretation?




David,

Hey, a new Standards Companion! This is the first I've heard of it. 
Strange that this wasn't announced, even in the "Standards Bearer".

Roger


>Hi Roger,
>
>I was surprised by your comment that the Standards Companion is outdated since
>the copyright statement date on the version on the web is 2003. I therefore
>called Mary Lynne Nielsen at the IEEE who maintains the Standards 
>Companion and
>she said that the current edition was published just over a month 
>ago. She also
>pointed me to an Annex of the Standards Companion which provides example
>responses [ http://standards.ieee.org/guides/companion/annexb-c.html#partc ].
>
>As for your example below I think what you are proposing is to use what is
>called 'the defect situation' described in the Annex I refernce above and as
>such I agree that it is an legitimate interpretation - however as you also say
>it hasn't "fixed" the error.
>
>Best regards,
>   David Law
>
>
>>  From owner-stds-802-sec@majordomo.ieee.org Thu Feb 20 17:29 GMT 2003
>>  Mime-Version: 1.0
>>  X-Sender: rogermarks@mail.4dv.net
>>  Date: Thu, 20 Feb 2003 10:25:05 -0700
>>  To: David Law <davel@pdd.3com.com>
>>  From: "Roger B. Marks" <r.b.marks@ieee.org>
>>  Subject: [802SEC] what is an interpretation?
>>  Cc: stds-802-sec@ieee.org
>>  X-Resent-To: Multiple Recipients <stds-802-sec@majordomo.ieee.org>
>>  X-Listname: stds-802-sec
>>  X-Info: [Un]Subscribe requests to  majordomo@majordomo.ieee.org
>>  X-Moderator-Address: stds-802-sec-approval@majordomo.ieee.org
>>
>>
>>  [I've changed the subject line, which was getting stale.]
>>
>>  David,
>>
>>  OK; I admit that I don't know what an interpretation is.
>>
>>  Your quote from the Standards Companion (which I don't consult
>>  anymore because it is so outdated) helps to tell us what it isn't.
>>  The description on the interpretation page:
>>	http://standards.ieee.org/reading/ieee/interp
>>
>>  is, I think, a slight bit looser. It is also dominated by negatives:
>>  *"not intended to constitute an alteration to the original standard"
>>  *"cannot make new rules to fit situations not yet covered in the
>>  standard, even if the investigations of the subgroup lead it to
>>  conclude that the requirement is incomplete or in error"
>>  *"Changes to the standard are made only through revisions or
>>  supplements to the standard"
>>
>>  On the other hand, it does say "Interpretations are issued to explain
>>  and clarify the intent of the standard."
>>
>>  Within the language, I still think that interpretations could address
>>  some kinds of errors. Consider, for example, inconsistencies. Let's
>>  imagine an interpretation basically said: "The standard says in 10
>>  places that X shall be 2. It is very clear from the context, and we
>>  can establish by careful analysis, that any choice but 2 would break
>>  it. However, in a table of parameters, X is said to be 3. It is our
>>  interpretation that this line of the table is in error." Of course,
>>  this doesn't really "fix" the error, but it does provide a useful
>>  point of reference.
>>
>>  Again, I am not an expert in interpretations, but I do believe I see
>>  some wiggle room here.
>>
>>  Do you think my example is a legitimate interpretation?
>>
>>  Roger
>>
>>
>>  >Hi Roger,
>>  >
>>  >Just a point of clarification, but I note that you say 'Also, 
>>don't forget the
>>  >option of an interpretation, which is suitable for fixing some 
>>kinds of errors
>>  >and can be done very quickly by the Working Group alone.' Now I 
>>maybe missing
>>  >your point here but I don't believe that an interpretation can be 
>>used to fix
>>  >an error.
>>  >
>>  >Reading from the Interpretations clause of the IEEE Standards Companion
>>  >[http://standards.ieee.org/guides/companion/part2.html#interpret] it states
>>  >in the third paragraph:
>>  >
>>  >'Interpretations are a unique form of commentary on the standard.
>>  >They are not explanations of what the standard should have done or
>  > >meant to say. Interpretations cannot change the meaning of a
>>  >standard as it currently stands. Even if the request points out an
>  > >error in the standard, the interpretation cannot fix that error. The
>>  >interpretation can suggest that this will be brought up for
>>  >consideration in a revision or amendment (or, depending on the
>>  >nature of the error, an errata sheet might be issued). However, an
>>  >interpretation has no authority to do any of this. It can only
>>  >discuss, address, and clarify what the standard currently says. The
>>  >challenge for the interpreters is to distinguish between their
>>  >expertise on what "should be," their interests in what they "would
>>  >like the standard to be," and what the standard says.
>>  >Interpretations are often valuable, though, because the request will
>>  >point out problems that might otherwise have gone unaddressed.'
>>  >
>>  >I therefore don't think an interpretation can ever be used to fix an error.
>>  >
>>  >Best regards,
>>  >   David Law
>>  >
>>  >|=========================================|
>>  >| David Law                               |
>>  >| Vice-Chair IEEE 802.3                   |
>>  >| 3Com                                    |
>>  >| Princes Exchange                        |
>>  >| 1 Earl Grey Street                      |
>>  >| Edinburgh                               |
>>  >| EH3 9BN                                 |
>>  >| Scotland                                |
>>  >| Phone: +44 131 659 8218                 |
>>  >| Fax:   +44 131 659 8001                 |
>>  >| E-Mail: David_Law@3com.com              |
>>  >|=========================================|
>>  >
>>  >
>>  >
>>  >>  From owner-stds-802-sec@majordomo.ieee.org Tue Feb 18 14:55 GMT 2003
>>  >>  Mime-Version: 1.0
>>  >>  X-Sender: rogermarks@mail.4dv.net
>>  >>  Date: Tue, 18 Feb 2003 07:54:07 -0700
>>  >>  To: <mjsherman@research.att.com>
>>  >  > From: "Roger B. Marks" <r.b.marks@ieee.org>
>>  >>  Subject: RE: [802SEC] Bad press Re: pre-std "g" equipment
>>  >>  Cc: <stds-802-sec@ieee.org>
>>  >>  X-Resent-To: Multiple Recipients <stds-802-sec@majordomo.ieee.org>
>>  >>  X-Listname: stds-802-sec
>>  >>  X-Info: [Un]Subscribe requests to  majordomo@majordomo.ieee.org
>>  >>  X-Moderator-Address: stds-802-sec-approval@majordomo.ieee.org
>>  >>
>>  >>
>>  >>  Mat,
>>  >>
>>  >>  I don't think that the 802 process makes it too hard or
>>  >>  time-consuming to correct errors.
>>  >>
>>  >>  Let me take an example: 802.16c. We submitted a PAR in February; it
>>  >>  was approved by the SEC in March, and we issued a Call for
>>  >>  Contributions. In May, we released a draft and opened a Working Group
>>  >>  Letter Ballot. We opened Sponsor Ballot on August 5. The final draft
>>  >>  (Draft 4) was issued on October 4 and approved in December.
>>  >>
>>  >>  802.16c included a lot more than maintenance; it was 92 pages long,
>>  >>  and maintenance was just a tag-along to the primary content. If we
>>  >>  were doing maintenance alone, it would have been a lot easier (though
>>  >>  probably not much faster).
>>  >>
>>  >>  If you look at the process as having taken nearly a year, then it
>>  >>  sounds a bit long. However, the final draft was finished less than
>>  >>  eight months after the PAR was submitted. And most of the corrections
>>  >>  were in the draft issued less than four months after the PAR
>>  >  > submittal. Overall, I think that the time frame was short enough.
>>  >>
>>  >>  I understand that a larger group, or more contention, could lead to
>>  >>  slower progress. However, I don't think that the process of
>>  >>  developing corrections in 802 in inherently too slow.
>>  >>
>>  >>  Also, don't forget the option of an interpretation, which is suitable
>>  >>  for fixing some kinds of errors and can be done very quickly by the
>>  >>  Working Group alone.
>>  >>
>>  >>  Roger
>>  >>
>>  >>
>>  >>
>>  >>  At 10:57 PM -0500 03/02/17, <mjsherman@research.att.com> wrote:
>>  >>  >Bob,
>>  >>  >
>>  >>  >Well you got me on this one.  Somehow I glossed over it when I was
>>  >>  >writing my response to Geoff (I did catch it when you first sent it
>>  >>  >out).  But I should note that it was a quote of a rather disgruntled
>>  >>  >sounding individual, and I did not think it represented the author's
>  > >>  >opinion.  The author ended the article clearly coming down 
>on Wi-Fi, not
>  > >>  >IEEE.  The real question is what are we going to do about it?
>>  >>  >
>>  >>  >If we feel that IEEE is being misrepresented, then it is up to us to
>>  >>  >respond in some way to ensure that these perceptions are not 
>>propagated.
>>  >>  >However, when they are presented as one person's opinion I'm not sure
>>  >>  >what we can do.
>>  >>  >
>>  >>  >As for your further comments, there are some parts of the process I'd
>>  >>  >like to see changed.  My feeling is that when something in the standard
>>  >>  >is clearly broken, there needs to be a "fast track" to fix it.  You had
>>  >>  >suggested opening a PAR the other day in the 802.11 interim, and I
>>  >>  >misinterpreted your meaning as to create a standing PAR for corrections
>>  >>  >to the standard.  In my mind, a lot of the process is just 
>>getting a PAR
>>  >>  >approved.  I'd almost rather that once a project exists, corrections to
>>  >>  >standards the project produced are possible without getting a new PAR.
>>  >>  >I know that goes against the current process, but to me this is one
>>  >>  >possible way to improve the current process.
>>  >>  >
>>  >>  >Also, about your comment on the IETF and interoperable prototypes, I
>>  >>  >like that idea a lot.  However, when we (AT&T) have tried to bring in
>>  >>  >hardware demos of a proposed standard in the past we were 
>>told that such
>>  >>  >things aren't allowed in our meeting.  We had to do the demo 
>>"off site".
>>  >>  >So I guess my question is what could be done to permit more of the IETF
>>  >>  >approach which requires demonstration of hardware and interoperability
>>  >>  >during the standards development process?
>>  >>  >
>>  >>  >Best Regards,
>>  >>  >
>>  >>  >Mat
>>  >>  >
>>  >>  >Matthew Sherman
>>  >>  >Vice Chair, IEEE 802
>>  >>  >Technology Consultant
>>  >>  >Communications Technology Research
>>  >>  >AT&T Labs - Shannon Laboratory
>>  >>  >Room B255, Building 103
>>  >>  >180 Park Avenue
>>  >>  >P.O. Box 971
>>  >>  >Florham Park, NJ 07932-0971
>>  >>  >Phone: +1 (973) 236-6925
>>  >>  >Fax: +1 (973) 360-5877
>>  >>  >EMAIL: mjsherman@att.com
>>  >>  >
>>  >>  >
>>  >>  >-----Original Message-----
>>  >  > >From: Bob O'Hara [mailto:bob@airespace.com]
>>  >>  >Sent: Monday, February 17, 2003 8:05 PM
>>  >>  >To: Sherman,Matthew J (Matthew); gthompso@nortelnetworks.com
>>  >>  >Cc: stds-802-sec@ieee.org
>>  >>  >Subject: RE: [802SEC] Bad press Re: pre-std "g" equipment
>>  >>  >
>>  >>  >Mat,
>>  >>  >
>>  >>  >I'm not sure how you can say this article "didn't come down on IEEE at
>>  >>  >all" with a straight face.  I quote from the article below:
>>  >>  >
>>  >>  >"Within the IEEE, former home of engineering, but now merely court
>>  >>  >jester to
>>  >>  >vested interest, standard seems to mean 'I'm already shipping it -
>>  >>  >look how big my wallet is,' or something very similar." "
>>  >>  >
>>  >>  >Regarding your point about the turn-around time in the IEEE process, I
>>  >>  >agree.  It takes a relatively long time to modify the standard.  I have
>>  >>  >not found any parts of the process that I would like to see changed,
>>  >>  >though.  It is really up to the working groups to determine how they
>>  >>  >produce their draft to send to Sponsor Ballot.  Currently, 802.11 is
>>  >>  >mostly in "invent, then standardize" mode, which takes quite 
>>a long time
>>  >>  >and results is a high probability of problems discovered only after
>>  >>  >deployment.  An alternative method is one used in the IETF; 
>>"show me two
>>  >>  >different and interoperable implementations, then I might standardize
>>  >>  >it".  This takes longer up front, but seems to result in fewer
>>  >  > >interoperability problems after deployment.
>>  >>  >
>>  >>  >Seems like a "pay me now or pay me later" situation.
>>  >>  >
>>  >>  >  -Bob
>>  >>  >
>>  >>  >
>>  >>  >-----Original Message-----
>>  >>  >From: mjsherman@research.att.com [mailto:mjsherman@research.att.com]
>>  >>  >Sent: Monday, February 17, 2003 3:58 PM
>>  >>  >To: gthompso@nortelnetworks.com; Bob O'Hara
>>  >>  >Cc: stds-802-sec@ieee.org
>>  >>  >Subject: RE: [802SEC] Bad press Re: pre-std "g" equipment
>>  >>  >
>>  >>  >
>  > >>  >Geoff,
>>  >>  >
>>  >>  >Given that the standard isn't even released yet, I don't see how there
>  > >>  >can be a question about 802.11g quality, or our due diligence on that
>>  >>  >standard yet.  I think this is an issue of how we interface with the
>>  >>  >outside world, what we do to defend our name, and how we deal with
>>  >>  >industry pressure to release products before they are done.
>>  >>  >
>>  >>  >
>>  >>  >My own read of this particular g-bashing is that it didn't come down on
>>  >>  >IEEE at all - rather it attacked Wi-Fi.  I have seen some other similar
>>  >>  >pieces that Bashed IEEE / 802 as well.  Honestly I don't see that we've
>>  >>  >done anything wrong yet - at least not procedurally.
>>  >>  >
>>  >>  >Also, being on the board to me means that we ensure "due diligence" on
>>  >>  >procedural issues.  Those procedures may not be sufficient today to
>>  >>  >guarantee issues such as compatibility from the get go.  My impression
>>  >>  >is that all our standards are becoming more complex, and there are
>>  >>  >increased possibilities for interactions (coexistence, backwards
>>  >>  >compatibility, etc.).  The real question to me is not whether "new
>>  >>  >projects" in our own or other groups are up to snuff, but 
>>rather are the
>>  >>  >procedures / rules we follow up to snuff, and properly enforced.  This
>>  >>  >to me is where we need to focus our due diligence.
>>  >>  >
>>  >>  >One thing that has greatly bothered me is the turn around time to fix a
>>  >>  >problem in a standard.  Compatibility problems are (in my opinion) more
>>  >>  >likely to be found in the field than on the drawing board.  Fixes might
>>  >>  >be quickly developed, but for even a simple fix to be reviewed and
>>  >>  >accepted by the standards body could (in my opinion) take a year or
>>  >>  >more.  This is a long time when vendors are chomping at the bit to get
>>  >>  >devices to the market (and the standard has already been formally
>>  >>  >released.
>>  >>  >
>>  >>  >In other industry organizations I have participated in, a number of
>>  >>  >procedures were followed that allowed greater certainly of the
>>  >>  >performance of a specification, and shorter time to fix it when a
>>  >>  >problem arose.  These included requiring a hardware brass board (which
>>  >>  >becomes the gold standard for compatibility) prior to release of the
>>  >>  >specification, and a revision notice procedure that allowed fixes to an
>>  >>  >existing specification to be quickly evaluated and accepted/rejected.
>>  >>  >While these bodies were not "standards bodies", it would be nice if
>>  >  > >there were analogous processes which could be followed in 
>>developing our
>>  >>  >standards.
>>  >>  >
>>  >>  >Just my two cents.
>>  >>  >
>>  >>  >Mat
>>  >>  >
>>  >>  >Matthew Sherman
>>  >>  >Vice Chair, IEEE 802
>>  >>  >Technology Consultant
>>  >>  >Communications Technology Research
>>  >>  >AT&T Labs - Shannon Laboratory
>>  >>  >Room B255, Building 103
>>  >>  >180 Park Avenue
>>  >>  >P.O. Box 971
>>  >>  >Florham Park, NJ 07932-0971
>>  >>  >Phone: +1 (973) 236-6925
>>  >>  >Fax: +1 (973) 360-5877
>>  >>  >EMAIL: mjsherman@att.com
>>  >>  >
>>  >>  >
>>  >>  >-----Original Message-----
>>  >>  >From: Geoff Thompson [mailto:gthompso@nortelnetworks.com]
>>  >>  >Sent: Sunday, February 16, 2003 3:31 PM
>>  >>  >To: Bob O'Hara
>>  >>  >Cc: stds-802-sec@ieee.org
>>  >>  >Subject: Re: [802SEC] Bad press Re: pre-std "g" equipment
>>  >>  >
>>  >>  >
>>  >>  >Bob-
>>  >>  >
>>  >>  >This only emphasizes that all members of the SEC have real
>>  >>  >responsibility
>>  >>  >to see that new projects in other groups, as well as their own, uphold
>>  >>  >the
>>  >>  >established quality of 802 Standards.
>>  >>  >
>>  >>  >Being on a "board" is a due diligence job, whether it is the 
>>finances of
>>  >>  >
>>  >>  >Enron or the quality of 802 Standards.
>>  >>  >
>>  >>  >Sigh,
>>  >>  >
>>  >>  >Geoff
>>  >>  >
>>  >>  >
>>  >>  >At 10:46 AM 2/13/2003 -0800, Bob O'Hara wrote:
>>  >>  >
>>  >>  >>IEEE, and by association 802, is getting tarred with the same brush
>>  >>  >from
>>  >>  >>this 802.11g fiasco.
>>  >>  >>
>>  >>  >>   -Bob
>>  >>  >>
>>  >>  >>
>>  >>  >>-----Original Message-----
>>  >  > >>
>>  >>  >>  >
>  > >>  >>  > New wireless 11g 'standard' ends in tears
>>  >>  >>  > By Guy Kewney, Newswireless.net
>>  >>  >>  > Posted: 10/02/2003 at 08:43 GMT
>  > >>  >>  > <http://www.theregister.co.uk/content/59/29250.html>
>>  >>  >>  >
>>  >>  >>  > It is nearly a year since NewsWireless Net warned of the disasters
>>  >>  >>  > looming if American wireless manufacturers went ahead 
>>with 802.11g -
>>  >>  >>  > the go-faster WiFi standard. Now, we hear of incompatibility
>>  >>  >problems
>>  >>  >>  > between rival 11g products - discovered in "secret" testing
>>  >>  >sessions.
>>  >>  >>  > Are we really supposed to be surprised?
>>  >>  >>  >
>>  >>  >>  > You can, today, buy an 802.11g (pre-standard) device. 
>>This story was
>>  >>  >>  > written on a PC connected over a Linksys WRT54G "Wireless-G"
>>  >>  >>  > broadband router. It really is running at 54 megabits a second,
>>  >>  >>  > giving a pretty good working approximation of 20 
>>megabits per second
>>  >>  >>  > throughput. And, the good news: it will work fine with my old WiFi
>>  >>  >>  > cards on the 11b standard too, even though it slows down to 11
>>  >>  >>  > megabits (5 megabits throughput) to do so.
>>  >>  >>  >
>>  >>  >>  > So why is this bad news? The answer is that since it works, in a
>>  >>  >>  > one-off situation like this, people will, quite naturally, buy it.
>>  >>  >>  > And then, the fun will begin; because there's no guarantee of
>>  >>  >>  > compatibility with other 11 "pre-g" standards.
>>  >>  >>  >
>>  >>  >  > > It was Nick Hunn, managing director of TDK Grey Cell, who first
>>  >>  >>  > pointed out that there were serious problems with the idea of
>>  >>  >rolling
>>  >>  >>  > out a 50 megabit version of the normal WiFi LAN 
>>technology, back in
>>  >>  >>  > May last year.
>>  >>  >>  >
>>  >>  >>  > Now, the WiFi Alliance has been forced to act as rival 50 megabit
>>  >>  >>  > wireless systems have been launched on the market - 
>>without even the
>>  >>  >  > > benefit of a finally agreed IEEE standard to conform 
>>to, and with no
>>  >>  >>  > compatibility testing between the rivals, either.
>>  >>  >>  >
>>  >>  >>  > As predicted, the result is a monumental cockup.
>>  >>  >>  >
>>  >>  >>  > A scale of the disaster is the giveaway quote by Broadcom's Jeff
>>  >>  >>  > Abramowitz, senior director of wireless LAN marketing:
>>  >>  >"Manufacturers
>>  >>  >>  > understand what interoperability means to them, and they 
>>are moving
>>  >>  >>  > in that direction."
>>  >>  >>  >
>>  >>  >>  > This statement says, as honestly as you could ask for from a man
>>  >>  >>  > speaking under NDA, that we aren't there yet.
>>  >>  >>  >
>>  >>  >>  > Abramowitz can't say "they don't interwork" even though 
>>he may know
>>  >>  >>  > for sure which ones cause the problems. He's not allowed 
>>to, because
>>  >>  >>  > the tests where this bad news was established are secret. WiFi
>>  >>  >>  > specialist site, Unstrung, reports: "Fueling industry 
>>anxiety is the
>>  >>  >>  > fact that the results of the first interoperability trials,
>>  >>  >sponsored
>>  >>  >>  > by the University of New Hampshire Interoperability Lab, won't be
>>  >  > >>  > made public." Not only will they not be made public, 
>>but the people
>>  >>  >>  > who attended them have actually been obliged to sign a
>>  >>  >non-disclosure
>>  >>  >>  > agreement saying that they may not discuss them.
>>  >>  >>  >
>>  >>  >>  > There would be no need to make the results secret if 
>>they all showed
>>  >>  >>  > interworking.
>>  >>  >>  >
>>  >>  >  > > Today, Nick Hunn responded angrily: "In my belief, 
>>'standard' means
>>  >>  >  > > something that everyone adheres to for the common good. 
>>Within the
>>  >>  >  > > IEEE, former home of engineering, but now merely court jester to
>>  >>  >>  > vested interest, standard seems to mean 'I'm already shipping it -
>>  >>  >>  > look how big my wallet is,' or something very similar."
>>  >>  >>  >
>>  >>  >>  > Hunn believes that the 11g concept is redundant, and should never
>>  >>  >>  > have been developed. "I've already said that .11g is a bastard
>>  >>  >>  > concept - it should have been put down eighteen months 
>>ago, but the
>>  >>  >>  > chip vendors can't take the medicine of having to throw away their
>  > >>  >>  > competing development," he commented. "As regards 
>interoperability,
>>  >>  >  > > at least the standard has taken a leaf out of the 
>>Hitchhiker's Guide
>  > >>  >>  > to the Galaxy and comes with the comforting phrase "These are
>>  >>  >working
>>  >>  >>  > drafts. Do not build product" on the front cover."
>>  >  > >>  >
>>  >>  >>  > Our own tests here at NewsWireless Net have been 
>>hampered by samples
>>  >>  >>  > which worked poorly. One vendor shipped faulty 54g equipment for
>>  >>  >>  > review, and we found that not only was the signal 
>>indecipherable by
>>  >>  >>  > an 802.11b adapter, but it was also jumbled when the mobile units
>>  >>  >>  > moved more than 20 feet away. A replacement unit shipped two weeks
>>  >>  >>  > later works correctly.
>>  >>  >>  >
>>  >>  >>  > However, from reports leaking out of the New Hampshire University
>>  >>  >>  > tests, it's clear that there have indeed been 54g and rival chip
>>  >>  >sets
>>  >>  >>  > which did not work correctly with 11b "legacy" network equipment.
>>  >>  >>  >
>>  >>  >>  > It isn't a trivial matter. To some, it will seem 
>>trivial, of course.
>>  >>  >>  > They have PC notebooks with plug-in PC card adapters. 
>>Throw away the
>>  >>  >>  > old 11b adapter, plug in the new 54g or alternative, and 
>>you're back
>>  >>  >>  > online, four times faster - where's the downside, apart from the
>>  >>  >>  > upgrade price?
>>  >>  >>  >
>>  >>  >>  > But to many, there is a different problem; they have notebooks or
>>  >>  >>  > pocket PCs or other devices which have the WiFi wireless built in.
>>  >>  >>  > Many PC makers have already started shipping dual 
>>standard PCs, with
>>  >>  >>  > 11b and 11a, not 11g, built in. They will perhaps be 
>>able to plug a
>>  >>  >>  > new adapter card in, but the support costs for a corporate user of
>>  >>  >>  > wireless are going to be substantial.
>>  >>  >>  >
>>  >>  >>  > The other problem is that while 11b and 11g are supposed to be
>>  >>  >>  > compatible, that comes at a cost. The cost is speed. As long as
>>  >>  >there
>>  >>  >>  > is an old legacy 11b unit broadcasting packets, the 11g 
>>devices will
>>  >>  >>  > have to switch mode to 11b, and run at a maximum of 11 megabits.
>>  >>  >>  >
>>  >>  >>  > Some fear that manufacturers will deal with this the 
>>cruel way; they
>>  >>  >>  > will simply make 11g units that go diplomatically deaf when an 11b
>>  >>  >>  > card walks into the room, and ignore it. Hints from the test
>>  >>  >>  > laboratory suggest this has already happened.
>>  >>  >>  >
>>  >>  >>  > Back in May last year, we quoted Gartner analyst Martin Reynolds
>>  >>  >>  > saying: "Think of the wireless spectrum as a three-lane highway in
>>  >>  >>  > which all drivers are required to change lanes every 10 seconds -
>>  >>  >not
>>  >>  >>  > so bad when the roads are empty, but a probable disaster when
>>  >>  >traffic
>>  >>  >>  > mounts. The ruling makes life easier for designers of devices
>>  >>  >>  > supporting multiple protocols."
>>  >>  >>  >
>>  >>  >>  > The biggest loser, here, is almost certainly the WiFi Alliance,
>>  >>  >which
>>  >>  >>  > was the watchdog that ran away in the night when it saw 
>>the burglar.
>>  >>  >>  >
>>  >>  >>  > The Alliance made its reputation by insisting that only compatible
>>  >>  >>  > equipment could carry the WiFi logo. It organised tests where
>>  >>  >>  > compatbility was assured, and issued accreditation, and the result
>>  >  > >>  > was a wireless industry where wireless adapters became 
>>commodities,
>>  >>  >>  > and you could pick the cheapest.
>>  >>  >>  >
>>  >>  >>  > This didn't suit the manufacturers. They like the idea of "winning
>>  >>  >>  > big" - of being the guy who sets the standard. They want 
>>to be first
>>  >>  >>  > out the door, forcing everybody else to follow in their footsteps,
>>  >>  >>  > and maybe, even, pay a licence fee for doing so. They hate
>>  >>  >>  > commoditisation; so why they praise the standard in 
>>public, they try
>>  >>  >>  > their hardest to undermine it and create their own statute in the
>>  >>  >>  > background.
>>  >>  >>  >
>>  >>  >>  > If this standard is rescued, it will take time; and by the time it
>>  >>  >is
>>  >>  >>  > sorted out, many dismayed buyers will find themselves 
>>with obsolete
>  > >>  >>  > gear. The WiFi Alliance turned out to be helpless to 
>intervene, and
>>  >>  >>  > its credibility will be hard to re-establish.
>  > >>  >>  >
>>  >>  >>  >
>>  >>  >>  >
>>  >>
>>  >>
>>
>>