--- This message came from the IEEE 802.11 Task Group M Technical Reflector ---I think that at least in:
The Quiet element is optionally present if
dot11SpectrumManagementRequired is true or
dot11RadioMeasurementActivated is true.
it's clearly 2, because a Quiet element is not always present in
Beacon frames, even when those MIB attributes are true.
I think that for 1 we use "is present if", e.g.:
The Country element is present if dot11MultiDomainCapabilityActivated
is true or dot11SpectrumManagementRequired is true or
dot11RadioMeasurementActivated is true.
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: Joseph Levy <Joseph.Levy@xxxxxxxxxxxxxxxx>
Sent: Thursday, 3 February 2022 22:30
To: STDS-802-11-TGM@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGM] [STDS-802-11] "Present if <condition>" so what about not <condition>?
--- This message came from the IEEE 802.11 Task Group M Technical Reflector ---
I have a question regarding the text being discussed:
What is the meaning of “is optionally present”?
Does it mean:
1. The optional field is present.
or
2. The field may be present.
As Mark points out if it is 2) then the requirement in not really saying anything and the text should probably be removed.
But if it is 1) then there is a requirement that is being specified and we should probably clarify the text to eliminate any confusion.
Either way I share Thomas’s concern about a global change.
Joseph
From: Mark Hamilton <mark.hamilton2152@xxxxxxxxx>
Sent: Thursday, February 3, 2022 11:43 AM
To: STDS-802-11-TGM@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGM] [STDS-802-11] "Present if <condition>" so what about not <condition>?
--- This message came from the IEEE 802.11 Task Group M Technical Reflector ---
Mark R,
My view/concern is that this might be a case-by-case problem. I don’t actually know, but I can imagine that in some places where the behavior is unstated, it is just fine to (optionally) include the element and even perhaps that some implementations do so. However, in other places, it is probably equally likely that it either doesn’t make any sense, or worse in fact causes interop problems to include the element, and we need to give messaging to assure implementations do not do so.
So, I’m having a problem with any blanket statement, no matter which direction such a statement may take. Hence, my concern that we need to actually review these situations individually, and make specific and thought-out changes in each case. And, as usual, that turns into a very painful and lengthy effort. Perhaps we can/should identify some of the more blatant situations, and address those specifically, and make this one of those items that we work to clean up over time.
Mark
From: Mark Rison <m.rison@xxxxxxxxxxx>
Sent: Thursday, February 3, 2022 6:24 AM
To: STDS-802-11-TGM@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGM] [STDS-802-11] "Present if <condition>" so what about not <condition>?
--- This message came from the IEEE 802.11 Task Group M Technical Reflector ---
[Narrowing to TGme]
I think the argument I've heard for not having a global statement is
"it does no harm to include an 'unnecessary' element, because the
receiver can just ignore it". That's a plausible argument, and if
we accept it, then maybe all we need to do is to change the instances
of "X is optionally present if dot11foo is true" to just
"X is optionally present".
But I don't think we can simultaneously assert that
"we don't need to spell out that otherwise it's optional [, because it's always fine to include]"
and
"we can't spell out that otherwise it's optional [, because sometimes it's not fine to include]".
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: Thomas Derham <00000ad2eabc2931-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Wednesday, 2 February 2022 18:41
To: STDS-802-11@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11] "Present if <condition>" so what about not <condition>?
--- This message came from the IEEE 802.11 Working Group Reflector ---
>> we could add that otherwise it is optional
If we were to make such change globally, I think we’d need to be careful there are no cases where a peer infers a device supports a feature based on its transmission of the element.
I get the desire to dot i’s and cross t’s here, but if there’s going to be significant work to make sure we avoid unintended consequences, we should consider whether it’s a productive use of time (imho).
Thanks
Thomas
On Feb 2, 2022, at 10:34 AM, Mark Hamilton <mark.hamilton2152@xxxxxxxxx> wrote:
--- This message came from the IEEE 802.11 Working Group Reflector ---
Mark,
I would say, “In this case, you’re right, because it was optionally present in the first place. However, in other cases where if either of those MIB attributes are true, then it is required to be present (not optional), we could add that otherwise it is optional.”
Not sure if I am confusing your point though – and maybe you were only referring to the places where it is already “optionally present if …” ?
Mark
From: Mark Rison <m.rison@xxxxxxxxxxx>
Sent: Wednesday, February 2, 2022 8:15 AM
To: mark.hamilton2152@xxxxxxxxx; STDS-802-11@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-11] "Present if <condition>" so what about not <condition>?
I think an additional point is that although one can make the argument
that while it might sometimes be harmless to include a "spurious" element,
this then makes the "optionally present" statements confusing. To pick
one at random, in Beacon frames:
The Quiet element is optionally present if
dot11SpectrumManagementRequired is true or
dot11RadioMeasurementActivated is true.
… but if the Quiet element can also be present if neither of these MIB
attributes is true, then why are they mentioned? Just say it is optionally
present full stop.
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: Mark Hamilton <mark.hamilton2152@xxxxxxxxx>
Sent: Tuesday, 1 February 2022 21:23
To: 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
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