Thread Links | Date Links | ||||
---|---|---|---|---|---|
Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
--- This message came from the IEEE 802.11 Task Group M Technical Reflector ---
Hi Joe, Abhi, Mark, and all, I would prefer language that deletes the word “undefined” everywhere. What exactly are we trying to achieve by including this word? In particular, just how far do we think the “undefined” behavior can go? For example, suppose a receiver encounters a reserved value that triggers “undefined” behavior
in a PPDU that is not addressed to it, and interprets that as “treat the current PPDU as noise, and revert to backoff counter countdown”. Is that permissible? There is precedent for this exact interpretation. In some ways, adding a statement that the behavior is undefined makes matters worse than saying nothing at all, because it might be taken to imply that the standard is authorizing any receiver behavior. There must be some limits on what a receiver can do. It would be better to define those limits and leave it at that. Regards, Sean From: Joseph Levy <000019588066c6b7-dmarc-request@xxxxxxxxxxxxxxxxx>
--- This message came from the IEEE 802.11 Task Group M Technical Reflector ---
HI Abhi, Mark, and All – Abhi – thanks for digging through the standard to find the text you provided. Unfortunately, I believe the text only applies to the case it addresses – the requirement is that a STA when receiving a GAS frame process the whole frame even
if it finds an unknown or reserved value, if the frame is received without error. This is critical for GAS as it is possible that a STA may not know all the values sent in a GAS frame and receiving such a value should not stop the STA from receiving the rest
of the values in the GAS frame. The general case we are dealing with is the reception of a reserved value in any field or subfield, the general case. Therefore: I would favor a more direct wording in the transmission requirement: “Reserved values for a field or subfield shall not be used in a transmitted field or subfield.” And I support Mark’s proposal to include “unless otherwise specified”, but suggest the following text: "A STA’s behavior when a reserved value is received in a field or subfield is undefined, unless otherwise specified." Regard, Joseph From: Abhishek Patil <appatil@xxxxxxxxxxxxxxxx>
--- This message came from the IEEE 802.11 Task Group M Technical Reflector ---
There was an error when I sent the email below to the REVme reflector yesterday. Retrying again. From: Abhishek Patil <appatil@xxxxxxxxxxxxxxxx>
--- This message came from the IEEE 802.11 Task Group M Technical Reflector ---
Hi Mark,
I am fine with the additional text you suggested. >> [What are examples of "the behavior at the receiver is clearly defined (i.e., to ignore the reserved value)"? >> Are there any outside Clause 12?] Yes, I found some instances in other clause (see P1891 L01, L31, L50 in D2.1) where there is a behavior associated when a certain (reserved) value is received.
Take for example the following instance in clause 11 (P2642): There are many other such instances (outside clause 12). Therefore, we can’t say the behavior is undefined at the receiver.
Your proposed addition (“unless otherwise specified”) will address it. Regards, From: Mark Rison <m.rison@xxxxxxxxxxx>
WARNING:
This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros. [Restricting to TGm reflector to avoid spamming the world.] The group came-up with the following text for the receive side [second sentence on line 36 page 574]: "Upon reception of a reserved value in a field or subfield, the behavior is undefined." However, there is a debate on whether or not we need to specify anything for the receive side. For instance, there are occasions where the behavior at the receiver is clearly defined (i.e., to ignore the reserved value) and therefore, it
is incorrect to say the receive side behavior is undefined. Personally, I feel, we should delete the sentence and leave the behavioral aspects to the pertinent clauses (which is already the case at several instances in the spec). I do think we need to make it clear that using reserved values in non-reserved fields will in general have unpredictable effects. Note that the scope of all this is just Clause 9, so anything in say Clause 12 about needing to ignore reserved values is not affected. However, we could make this clear like this: "Upon reception of a reserved value in a field or subfield, the behavior is, unless otherwise specified, undefined." [What are examples of "the behavior at the receiver is clearly defined (i.e., to ignore the reserved value)"? Are there any outside Clause 12?] Thanks, Mark --
Mark RISON, Standards Architect, WLAN English/Esperanto/Français Samsung Cambridge Solution Centre Tel: +44 1223 434600 Innovation Park, Cambridge CB4 0DS Fax: +44 1223 434601 ROYAUME UNI WWW:
http://www.samsung.com/uk From: Abhishek Patil <appatil@xxxxxxxxxxxxxxxx>
--- This message came from the IEEE 802.11 Working Group Reflector ---
Hi All, Thank you for the discussion during today's REVme call. We made some more progress on the topic but could not reach consensus on a mutually agreeable text. After a few iterations between different members, the group seemed to have stabilized on the following text for the transmit side [replacement to line 36 page 574 in REVme D2.0]:
"In a field or subfield, values that are reserved for that field or subfield are not used for transmission."
The group came-up with the following text for the receive side [second sentence on line 36 page 574]: "Upon reception of a reserved value in a field or subfield, the behavior is undefined." However, there is a debate on whether or not we need to specify anything for the receive side. For instance, there are occasions where the behavior at the receiver is clearly defined (i.e., to ignore the reserved value) and therefore, it
is incorrect to say the receive side behavior is undefined. Personally, I feel, we should delete the sentence and leave the behavioral aspects to the pertinent clauses (which is already the case at several instances in the spec). I'd like to hear if there any further suggestions for the text on the transmit side and opinions on deleting the text for the receive side. Regards, Abhi From: Stephen McCann <mccann.stephen@xxxxxxxxx>
WARNING:
This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros. Abhi, thanks. I think your
proposed text is good. Kind regards Stephen On Mon, 13 Feb 2023 at 04:16, Abhishek Patil <appatil@xxxxxxxxxxxxxxxx> wrote:
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-TGM list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGM&A=1 To unsubscribe from the STDS-802-11-TGM list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGM&A=1 To unsubscribe from the STDS-802-11-TGM list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGM&A=1
To unsubscribe from the STDS-802-11-TGM list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGM&A=1 |