Fwd: Re: [802-11WG] untestable PICS items
X-Sieve: CMU Sieve 2.3
X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0
X-NIST-MailScanner: Found to be clean, Found to be clean
X-Originating-IP: [129.6.16.226]
X-Bayes-Prob: 0.0001 (Score 0)
X-Spam-Score: 0.50 () [Hold at 10.00]
HTML_MESSAGE,PORN_RP_PICS,SPF(none,0)
X-IEEE-UCE-Filter-Settings: 80_DEFAULT (inherits from default)
X-IEEE-UCE-Stats-ID: Bayes signature not available
X-Scanned-By: IEEE UCE Filtering Service (uce . ieee . org) on
140.98.193.233
Date: Mon, 24 Mar 2008
08:54:42 -0400
Reply-To: David Cypher <david.cypher@nist.gov>
Sender: ***** IEEE stds-802-11 List *****
<STDS-802-11@LISTSERV.IEEE.ORG>
From: David Cypher <david.cypher@nist.gov>
Subject: Re: [802-11WG] untestable PICS items
X-To:
STD-802-21@LISTSERV.IEEE.ORG
To: STDS-802-11@LISTSERV.IEEE.ORG
List-Help:
<
http://listserv.ieee.org/cgi-bin/wa?LIST=STDS-802-11>,
<
mailto:LISTSERV@LISTSERV.IEEE.ORG?body=INFO%20STDS-802-11>
List-Unsubscribe:
<
mailto:STDS-802-11-unsubscribe-request@LISTSERV.IEEE.ORG>
List-Subscribe:
<
mailto:STDS-802-11-subscribe-request@LISTSERV.IEEE.ORG>
List-Owner:
<
mailto:STDS-802-11-request@LISTSERV.IEEE.ORG>
X-Proofpoint-Virus-Version: vendor=fsecure
engine=4.65.7111:2.4.4,1.2.40,4.0.164
definitions=2008-03-24_02:2008-03-21,2008-03-24,2008-03-24
signatures=0
X-PP-SpamDetails: rule=spampolicy2_notspam policy=spampolicy2 score=0
spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0
classifier=spam adjust=0 reason=mlx engine=3.1.0-0803050000
definitions=main-0803240029
X-PP-SpamScore: 0
X-NIST-MailScanner-From: owner-stds-802-11@listserv.ieee.org
X-NIST-MailScanner-Information:
--- This message came from the IEEE 802.11 Working Group Reflector ---
PICS - Protocol Implementation Conformance Statement
The "I" stands for implementation. The "I" dose
not stand for interoperability.
So if you think that an IEEE 802 standard is written for interoperability
and not as an implementation, then there should never be a PICS Proforma
contained, since that is not its purpose.
Conformance and interoperability are two different items.
- Things that are conformant may not be interoperable.
- Things that are interoperable may not be conformant.
Stop mixing the two. They are different.
Please educate yourself by reading the ISO 9646 or ITU-T X.296. It
will go a long way.
David Cypher
================================
Again
At 12:35 AM 3/24/2008, Richard Roy wrote:
--- This message came from the
IEEE 802.11 Working Group Reflector ---
Bob,
Thanks for your thoughts. Some comments below …
From: Bob O'Hara [
mailto:bohara@wysiwyg104.com]
Sent: Saturday, March 22, 2008 9:26 AM
To: dickroy@alum.mit.edu; STDS-802-11@LISTSERV.IEEE.ORG
Subject: RE: [802-11WG] untestable PICS items
The PICS is not a
statement of testability. It is a statement of
implementation.
[RR] I think we need to be
careful here. Standards should specify required functionality for
interoperability. Properly written, they do not specify
implementation. The example I gave, carefully crafted to expose this
difference, is what I believe to be an improperly written standard.
It essentially specifies an implementation which it should not be
doing. The point is that in the large, implementation details are
not testable from an input-output perspective, while interoperable
functionality by definition is testable. Standards specify the later, not
the former. If a PICS statement ultimately results in a requirement
for “compliance” to an implementation, it should not be in the
PICS.
The box is
checked “yes” if the item is implemented and “no” or “n/a” if it is not
implemented.
[RR] If the PICS item relates
to a functionality required for interoperability, no problem. If
the PICS item is designed to constrain a design to a particular
implementation, problem. Furthermore, if it is not testable, then
the manufacturer can simply say YES as in the example below with no
consequences. He can’t be proven wrong. If the manufacturer tells
the truth, then he loses the sale. Why would he do that?
Furthermore, you could ask why was that untestable, and clearly
technically unsupportable, feature in the PICS in the first place.
Some might claim that it was the result of improper standards design
perhaps related to IPR or other self-aggrandizing considerations.
The purpose of
a PICS, though it seems to be rarely used, is for a customer to get a
completed PICS from their equipment supplier. If you have ever
tried to do that, you would find, as I have, that it is nearly impossible
to obtain.
[RR] I have not tried and I
sympathize with you. However, it could be that the PICS contain
some items related to implementation details, and rather than telling a
lie or the truth, the manufacturer simply declines to incriminate himself
or lose the sale. Seems like a reasonable response to me.
RR
-Bob
From: ***** IEEE stds-802-11
List ***** [
mailto:STDS-802-11@LISTSERV.IEEE.ORG] On Behalf Of Richard
Roy
Sent: Saturday, March 22, 2008 5:56 AM
To: STDS-802-11@LISTSERV.IEEE.ORG
Subject: [802-11WG] untestable PICS items
--- This message came from the IEEE 802.11 Working Group Reflector ---
1) Can/should Annex A contain untestable items?
2) If a PICS item is untestable, what is the appropriate box for someone
filling out a compliance statement to check: YES or NO?
Consider a statement in the base document such as “The STA shall discard
the packet.” Normally such a statement would generate a PICS item stating
that to be compliant, a STA must discard the packet. This is
clearly not testable without access to the machine code and every storage
area in the STA. Assume a manufacturer of a device chooses not to
discard the packet, and instead uses that packet in some innovative
manner by which the efficiency of his implementation is increased over
that of other implementations. His STAs now outperform those from
others manufacturers. Should that manufacturer state his device is
non-compliant and check NO in the compliance statement? Is there
anything preventing that manufacturer from claiming his device is
compliant by checking YES?
Any thoughts?
RR
_______________________________________________________________________________
IF YOU WISH to be Removed from this
reflector, PLEASE DO NOT send your request to this CLOSED reflector. We
use this valuable tool to communicate on the issues at hand.
SELF SERVICE OPTION: Point your
Browser to -
http://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11 and then amend
your subscription on the form provided. If you require removal from the
reflector press the LEAVE button.
Further information can be found at:
http://www.ieee802.org/11/Email_Subscribe.html
_______________________________________________________________________________
_______________________________________________________________________________
IF YOU WISH to be Removed from this reflector, PLEASE DO NOT send your
request to this CLOSED reflector. We use this valuable tool to
communicate on the issues at hand.
SELF SERVICE OPTION: Point your Browser to -
http://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11 and then amend
your subscription on the form provided. If you require removal from the
reflector press the LEAVE button.
Further information can be found at:
http://www.ieee802.org/11/Email_Subscribe.html
_______________________________________________________________________________
_______________________________________________________________________________
IF YOU WISH to be Removed from this reflector, PLEASE DO NOT send your
request to this CLOSED reflector. We use this valuable tool to
communicate on the issues at hand.
SELF SERVICE OPTION: Point your Browser to -
http://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11 and then amend
your subscription on the form provided. If you require removal from the
reflector press the LEAVE button.
Further information can be found at:
http://www.ieee802.org/11/Email_Subscribe.html
_______________________________________________________________________________