| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
| --- This message came from the IEEE 802.11 Working Group Reflector ---
An observation: If you specify upon reception of a reserved value or field that the behavior is undefined, you have no hope of backwards compatibility with legacy devices that implement undefined behavior should the reserved value be defined in a future version
of the standard. What we have done in the past (and currently do in other standards) is specify the behavior to ignore a reserved value and/or reserved field upon reception. This way the behavior of a legacy device is well defined and it is possible to use
a reserved value or field later so long as the new use is defined such that the predictable legacy behavior is acceptable - nothing bad happens to the legacy device or the network if it does not process a field that contains a reserved value and never processes
a reserved field.
There's been some debates in the past as to what "ignored" means and a precise definition is possible, e.g. the field is not processed and no other action is taken based upon the field value.
As for the transmission, if this applies to an over the air field, I don't know what it means - "not used for transmission" could me not included in a transmitted frame, which would seem problematic.
Not having the context of discussion, I am going only by how someone without context of the discussion (e.g. an new reader of the standard) might interpret the words. Maybe I'm missing the point...but hoping this helps (feel free to ignore if it doesn't).
Typically we specify something predictable for reserved fields such as "shall be set to zero upon transmission" but if the RX behavior is defined so that the field is not processed, the TX value is irrelevant. However it's been handy for sniffer implementations
to have a predictable value as it can help find problems (i.e. when you see something other than zero in a reserved field it's a clue).
FWIW again hope it helps. Still getting reacquainted with 802.11!
Ben
From: Abhishek Patil <appatil@xxxxxxxxxxxxxxxx>
Sent: Friday, February 17, 2023 8:34 AM To: STDS-802-11@xxxxxxxxxxxxxxxxx <STDS-802-11@xxxxxxxxxxxxxxxxx> Subject: Re: [STDS-802-11] REVme: resolution for CID 3000 --- 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 list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11&A=1 |