| 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 ---
Mark (H.), all, I’ll take the liberty of responding mainly to the last phrase in your poll (“or is there another suggestion?”). I suggest that we should start with the issue of whether it is desirable to have the language in the current draft (at the end of the cited text) saying that “the behavior is undefined”. I further suggest that the answer to this is “no”, and that we should change that to something else. Historically, setting the reserved bit to 1 in the 11a/11g OFDM L-SIG led to “undefined” behavior, in the sense that some deployed chipsets simply didn’t defer for the full signaled duration, in some circumstances. Without rehashing the
rights and wrongs of this (“wrongs”, if you ask me, but there is disagreement on this point to this day), I think we should not have a situation where unexpected use of reserved fields voids any and all normative statements in the spec. If “the behavior is undefined” means “there are no *new*, extra requirements (but all the old ones still hold good)”, that would be fine. But does it? The requirement to defer for the full signaled duration contained no exception
“except when the L-SIG reserved bit is set to 1”, but that’s the way it was read by some. I was not able to find any other instance of “the behavior is undefined”, or anything like it, anywhere in the draft. I suggest we should decide this issue first. As an initial suggestion, I would prefer to change “the behavior is undefined” to “the field is ignored”. Regards, Sean From: Mark Hamilton <mark.hamilton2152@xxxxxxxxx> --- This message came from the IEEE 802.11 Task Group M Technical Reflector ---
All, We’re looking for opinions… On yesterday’s REVme call, we considered CID 1218: "Reserved fields and subfields defined in this clause are set to 0 upon transmission and are ignored upon reception.
NOTE 2--This applies to reserved fields and subfields in MAC headers. Reserved fields and subfields in PHY headers might be set to a nonzero value upon transmission, and might not be ignored upon reception.
Reserved field and subfield values are not used upon transmission. Upon reception of a reserved field or subfield value, the behavior is undefined." This is all very confusing. The last two sentences seem to contradict the first sentence. The middle throws in a contrast to PHY headers that does not seem to be supported anywhere else in the draft. In our discussion, we determined that this text was expanded (to its current form, per above) in REVmd. It is believed this was to address some confusion that prior to the REVmd expansion (at least the addition of the NOTE), that there
was some confusion that use of the term “reserved” in the PHY clauses might be interpreted as “tx as 0, ignore on rx” when actually it meant something different in the PHY. Also, during our discussion, it was noted that the last two sentences are trying to talk about _values_ that are reserved (within a given field/element/etc., for example if 255 should never be used, etc.), in contrast to the first
sentence which is talking about entire (sub)fields that are reserved. One suggestion was to reword the last two sentences to make the distinction more clear.
So, the questions to the group:
Replies to this (REVme) reflector, please. Thanks. Mark 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 |