Re: [802SEC] what is an interpretation?
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.
> >> >> >
> >> >> >
> >> >> >
> >>
> >>
>
>