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