Mark, all,
You ask what is the non-AP STA, or receiver, or AP supposed to do in any of these cases.
The universal answer is: anything at all, provided all requirements of the spec are met.
An implementation is a compliant portion if and only if it satisfies all (applicable) requirements in the spec. If the spec contains no normative statements for receivers w.r.t. reserved fields, then all the receiver needs to do is to comply
with all the other applicable requirements: there are no new requirements that arise as a result of the reserved field values.
If the non-AP STA, or receiver, or AP doing “anything at all” is a problem in any given case, then we should solve it by adding suitably worded normative statements.
What we should not do is include text that says that behavior is “undefined”. Historically, that term has been used within IEEE 802.11 discussions (even if not perhaps in the spec itself) to refer to behavior in which receivers treat *other*
requirements as not applicable (defer for the full duration signaled).
Regards,
Sean
From: Mark Rison <m.rison@xxxxxxxxxxx>
Sent: Saturday, February 5, 2022 5:03 AM
To: Sean Coffey <coffey@xxxxxxxxxxx>; STDS-802-11-TGM@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-11-TGM] CID 1218 "poll" for opinions
>
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”.
That doesn't work. Here are some examples:
- Channel Switch Announcement element with Channel Switch Mode 2 -- what
is the non-AP STA supposed to do in the course of ignoring this?
Ignore the channel switch? Honour it but continue transmitting until
the channel switch (as if it were 0)? Honour it but stop transmitting
until then (as if it were 1)?
- Authentication frame with Status Code 222 -- what is the receiver
supposed to do when ignoring this? Treat it as fatal failure (like most
non-zero status codes)? Or as soft failure (as for e.g. status codes
ANTI_CLOGGING_TOKEN_REQUIRED, 76 and 126)?
- HT Capabilities element in assoc req with SM Power Save 2 -- what is
the AP supposed to do when ignoring this? Does the AP need to expect
the STA to require a 1-chain transmission before multi-chain transmissions
or not?
I think we need to stick to the basic tenet that (IEEE Std 802.11)
conformant implementations only transmit things defined by the standard,
and so if something else is transmitted, all bets are off -> the
behaviour is undefined at the receiver. We could add some words about
the receiver not crashing or whatever, but beyond that I don't think
we should be saying anything (with the exception of security-related
things, where we might need to specify explicitly the behaviour in
response to nonconformant transmissions, to avoid vulnerabilities).
> I was not able to find any other instance of “the behavior is undefined”, or anything like it, anywhere in the draft.
I'd be OK with "the behaviour is outside the scope of the standard",
which we have in many places.
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: Sean Coffey <coffey@xxxxxxxxxxx>
Sent: Friday, 4 February 2022 22:27
To: STDS-802-11-TGM@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGM] CID 1218 "poll" for opinions
--- 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>
Sent: Tuesday, February 1, 2022 1:40 PM
To: STDS-802-11-TGM@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGM] CID 1218 "poll" for opinions
--- 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:
- Is NOTE 2 clear, and useful/needed? We note that the first sentence clearly says “in this clause” (and this text is in clause 9), so that means the sentence does not apply to the PHY clauses. But, is it
correct/necessary to exclude the PHY clauses? Is the sentence by itself (without the NOTE) clear enough in doing so?
- Would the last sentences (after the NOTE) be more clear with wording such as, “Reserved values in non-reserved fields and subfields defined in this clause...” or is there another suggestion?
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
------Please consider the environment before printing this e-mail.
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