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.
> > >> >> >
>> >> >> >
>> >> >> >
>> >>
>> >>
>>
>>