Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [STDS-802-11] "Present if <condition>" so what about not <condition>?

--- This message came from the IEEE 802.11 Working Group Reflector ---
Hi Mark, all
I am not familiar with the specific instances in the standard, as "newly back" to diving into 802.11 I wasn't there when those requirements were written and so have no idea what is meant.  I can offer a perspective of one reading it as written, though. As for example a voter in SA ballot might read.

In general, negative requirements are a red flag. When I review a statement of requirement, I try to read it as if I were developing a validation test.  In this case my eye goes to the word "otherwise".  Can we define with precision a sufficiently bounded "otherwise"?  If we can't do that then it's not a verifiable statement and IMO should not be stated as a normative requirement. A strong recommendation is helpful in such cases.   "Should not be included otherwise" makes the point not to waste effort or bandwidth without creating a validation headache.

The next question is will including the element under "otherwise" conditions cause undefined behavior in the recipient? In other words, a negative requirement is appropriate only when the occurrence of something out of context will cause bad things to happen. If no, then there is no need to grapple with the problem of testing the negative conditions.  If the inclusion of unneeded elements causes only inefficiency, the strong recommendation is sufficient. 

It is easier to validate that a recipient doesn't do something bad upon reception of an unexpected (or malformed) element.  So stating when it is valid to process and act upon an element is more correct and effective IMO. We often see "shall be ignored" in this case.  One (ok I) could argue "ignored" is an internal behavior not directly visible, but I've lost that argument most times and concede that absence of action (or smoke) is sufficient evidence the errant element was properly ignored.   In this case defining a positive action by the recipient is generally better than a negative requirement on the sender.  It also good to consider consequences of reception of a malformed message from an errant or malicious sender.  It would not be a good design if sending something when not expected caused bad things to happen.  

 Again, not fully understanding the issues I may be off in the weeds again, but hope this helps!

Ben


From: Mark Hamilton <mark.hamilton2152@xxxxxxxxx>
Sent: Tuesday, February 1, 2022 1:22 PM
To: STDS-802-11@xxxxxxxxxxxxxxxxx <STDS-802-11@xxxxxxxxxxxxxxxxx>
Subject: [STDS-802-11] "Present if <condition>" so what about not <condition>?
 
--- This message came from the IEEE 802.11 Working Group Reflector ---

All,

 

REVme is looking for feedback on current implementation behavior/assumptions on a wide-ranging technical point:

 

REVme is discussing a comment on D1.0 (CID 1622) that requests, in effect, to add a statement to clause 9 that wherever we currently have a requirement such as “the xxx element is present if condition yyy is true”, then there is an implicit _requirement_ (to be made explicit by this comment) that if “condition yyy” is not true then “xxx” is _not_ present.  Specifically, the added sentence(s) would be:

“If an element is indicated as present when certain conditions are met, this is to be understood as meaning that the element is not included if these conditions are not met.”

 

Some considerations, and where we would like feedback:

  • In many places in the current spec, we explicitly say “and not present otherwise” (or something similar)
  • However, there are also many places in the spec where this is not stated.
    • Some of these unstated locations can be read as implying or only making sense if we take this to mean “is not included if these conditions are not met”
    • Other places are not clear.  In those places, are there implementations that may include the element, as an “allowed extension” (since it is not currently prohibited), and thus those implementations would become non-compliant if add this sentence?
    • Or, in those places, is the general assumption and implementation practice already to not include the element, so adding the statement above would be a proper clarification of existing interpretation?

 

Feedback to this reflector, or to the REVme reflector, is appreciated.

 

Thanks!  Mark

 

To unsubscribe from the STDS-802-11 list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11&A=1

To unsubscribe from the STDS-802-11 list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11&A=1