RE: stds-802-16: RE: Invitation to Co-Sign Letter to IEEE Election Candidates regarding ISTO
I strongly concur with Geoff and Pat's comments, and it seems to me that this
is the nub of the IEEE-ISTO / BWIF issue. I would have thought that over the
past twenty years IEEE and IEEE-SA would have clearly understood the
distinction between a Standard and a Specification, especially when defining
the roles / rules of ISTO. Or were they asleep at the switch ? From my
perception as a mere member of an 802.16 working group, it seems so far to have
been left with IEEE802 and IEEE-ISTO to try and resolve what is an IEEE and
IEEE-SA issue, in spite of clear directions to the contrary by the voting
members. When will we see a clear "policy" statement from IEEE and IEEE-SA on
the topic. So far we have been deafened by silence and fudge. I'm sure that the
instigators of the BWIF (who probably drafted the infamous Press Release) know
the distinctions and knew exactly what they were doing. Unfortunately ISTO
didn't seem smart enough to spot the difference between a Standard and a
Specification.
David Trinkwon
e-mail : trinkwon@compuserve.com
Telephone : UK (+44) (0) 7802 538315 USA (+1) 972 345 5226
Fax : UK (+44) (0) 20 7681 1695 USA (+1) 602 532 7013
----------
From: pat_thaler@agilent.com[SMTP:pat_thaler@agilent.com]
Sent: Friday, October 13, 2000 00:58
To: mark@uwtc.washington.edu; gthompso@nortelnetworks.com
Cc: stds-802-sec@ieee.org; stds-802-16@ieee.org
Subject: stds-802-16: RE: Invitation to Co-Sign Letter to IEEE Election
Candidates rega rding ISTO
Mark,
I totally agree with Geoff Thompson's statements. There are two
ways to make a document that specifies rules for something:
1) Follow an open process that allows for public review such
as governs standards developing organizations. The document
produced by this process is called a standard.
2) Form a consortium of some sort with rules agreed upon by the
parties forming the consortium. The degree of openness of the
consortium is up to the parties to decide. The document produced
by this process is called a specification.
This naming convention is widely understood and followed. It has
been used for many years. Twenty years ago when the first Ethernet blue book
was published by DEC, Intel and Xerox, it was called a specification.
When IEEE 802.3 defined a CSMA/CD MAC based upon that work, it was
a standard.
Pat
-----Original Message-----
From: Prof. Mark P. Haselkorn [mailto:mark@uwtc.washington.edu]
Sent: Thursday, October 12, 2000 9:09 AM
To: Geoff Thompson
Cc: stds-802-sec@ieee.org; stds-802-16@ieee.org
Subject: Re: Invitation to Co-Sign Letter to IEEE Election Candidates
regarding ISTO
Geof,
My definition of "one end of the spectrum" was that all the interested
parties were at the table.
The following exchange with Roger may be helpful.
Hope this helps.
Mark
Roger,
(1) Only an entity with IEEE's interests and perspectives can decide if an
issue is appropriate for ISTO (i.e. no, it cannot be left to the standards
developers). (2) They can't. The two need to be distinguished.
I don't have enough information to know how best to implement these two
items, but they need to be addressed.
Hope this helps. I suspect we're pretty much in agreement.
Mark
At 12:19 PM 10/11/00 -0600, you wrote:
>Mark,
>
>Thank you for your comments. I appreciate the seriousness with which you
>have taken the issue, and I particularly appreciate the point you made in
>your "pajama" example.
>
>Since you asked "Am I making my position clear?", I'll mention that I see
>a few problems. The main ones:
>
>(1) Who decides which side of the spectrum the topic falls on? Can you
>leave it to the standards developers? Pajama manufacturers might find more
>convenient to declare an "IEEE" "standard" through ISTO, even if you or I
>found this to be inappropriate.
>
>I would also ask: if an IEEE Standards project already exists, would this
>provide evidence that the project does not belong at the ISTO end of the
>spectrum and that ISTO should be prohibited from developing a competitive
>project?
>
>(2) How is the average EE (let alone the average citizen) going to
>distinguish a "standard" that has been through the IEEE Standards
>consensus process from one that hasn't?
>
>My own opinion is that ISTO should be prohibited from using the term
>"standard" to describe their output; I think "industry specification"
>would describe their outputs perfectly. And, unless ISTO were
>appropriately accountable, I would go further and prohibit ISTO from using
>the IEEE name and logo.
>
>I'm not trying to get into a debate with you on this, but, since you
>asked, I thought I owed you an answer.
>
>Since I won't actually ask for your comments until October 15, you have
>time to refine your position if you like.
>
>Regards,
>
>Roger
Mark
At 02:35 PM 10/11/00 -0700, Geoff Thompson wrote:
>Mark:
>
>I believe that your reply misses the point. What ISTO is doing (in your
>terms) is:
>"On one end of the spectrum would be a standard that was purely an issue
>of achieving consensus as quickly as possible among a clearly defined
>group of industrial partners with no issues of correctness or impact
>outside the agreeing participants"
>without consensus of "all interested parties". They limit the parties and
>they don't achieve consensus. How to provide access to "all interested
>parties" and the minimum requirements to achieve "consensus" are rooted in
>the procedures of the IEEE-SA and are derived from the accreditation
>requirements from ANSI.
>
>Folks who wish to cut an agreement, any sort of an agreement can do so,
>but that is not a standard in the sense above. It is a "specification",
>more properly in standards terms it is a "Publicly Available
>Specification" (PAS).
>
>The issue here is IF an organization produces accredited standards
>AND
>If the same organization produces "Publicly Available Specifications"
>
>Under the same logo/banner/brand mark
>AND
>Does not sufficiently distinguish between the two
>
>Then the result will be:
> 1) Loss of respect for standards produced under the traditional
> method due to destruction of the brand integrity.
> 2) The danger of loss of accreditation to the formulating
> organization for failure to adequately distinguish between the two.
>
>There is a simple way out.
>Don't call them "standards", call them "specifications".
>Some of the world's great standards started out as publicly available
>specifications. Examples: HP-IB became IEEE-488 and (DEC-Intel-Xerox)
>Ethernet became IEEE 802.3.
>
>Geoff Thompson
>
>
>At 10:48 AM 10/11/00 -0700, Prof. Mark P. Haselkorn wrote:
>
>>Roger,
>>I believe there are different types of standards that require different
>>types of handling. On one end of the spectrum would be a standard that
>>was purely an issue of achieving consensus as quickly as possible among a
>>clearly defined group of industrial partners with no issues of
>>correctness or impact outside the agreeing participants (I'm not sure
>>such a pure standard exists, but I'm laying out the extremes). On the
>>other end of the spectrum is a standard that has to conform with reality
>>and consider impacts beyond the participants. For example, it would be
>>very wrong for a group of pajama manufacturers to declare a standard for
>>"inflammable" that had nothing to do with whether or not the garment
>>could catch fire. The more a standard is on the first side of the
>>spectrum, the greater role I believe ISTO can play. The more it is on
>>the second side of the spectrum, the more IEEE needs to guard that ISTO
>>does not make standards for the convenience and profit of industrial
>>partners without regard to the greater realities of the situation and the
>>impact on non-participating parties. If this were allowed to happen,
>>IEEE would be failing in its central mission of benefiting society.
>>Am I making my position clear?
>>Mark
>>
>>**************************************************************************
***
>>Mark P. Haselkorn
>>Professor and Founding Chair
>>Department of Technical Communication
>>Principle Investigator, National Research Council Project on
>> Lessons from Y2K for Strategic Management of IT
>>IEEE Technical Activities Strategic Planning Committee
>>Box 352195
>>University of Washington
>>Seattle, WA 98195
>>(206) 543-2577; (206) 543-8858 (fax)
****************************************************************************
*
Mark P. Haselkorn
Professor and Founding Chair
Department of Technical Communication
Principle Investigator, National Research Council Project on
Lessons from Y2K for Strategic Management of IT
IEEE Technical Activities Strategic Planning Committee
Box 352195
University of Washington
Seattle, WA 98195
(206) 543-2577; (206) 543-8858 (fax)