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 ---
Hello Xiaofei,
I would be happy to be listed as co-author; that way you can deflect blame :-o
-Robert
From: Xiaofei Wang <Xiaofei.Wang@xxxxxxxxxxxxxxxx>
Sent: Tuesday, April 30, 2024 8:56 AM To: Stacey, Robert <robert.stacey@xxxxxxxxx>; STDS-802-11-TGM@xxxxxxxxxxxxxxxxx <STDS-802-11-TGM@xxxxxxxxxxxxxxxxx> Cc: M Montemurro <montemurro.michael@xxxxxxxxx>; Mark Hamilton <mark.hamilton2152@xxxxxxxxx>; Rui Yang <Rui.Yang@xxxxxxxxxxxxxxxx> Subject: RE: request for comments: proposed REvME changes to 26.1 Hi Robert,
Thank you for your feedback. I am ok with your proposed text. There are other places of “supports” in the spec, but we can address those at a different time since the CID only covers this part of the text.
Do you want to be listed as an co-author for this CR?
Xiaofei Clement Wang Principal Engineer | InterDigital T: (631) 622.4028
From: Stacey, Robert <robert.stacey@xxxxxxxxx>
Hello Xiaofei,
I think we are tying ourselves in knots here. The rewording implies that the features have a mandatory-ness (or optional-ness) that is independent of the HE STA. But that is not the case; an HE STA is defined by this collection of mandatory and optional features. Also, I find it problematic to use the normative verbs at two levels: at the feature definition level and at the "HE STA supports" level.
For example, one of the first features in Clause 26 is something called "TXOP duration-based RTS/CTS". The HE AP uses it by setting the "TXOP Duration RTS Threshold subfield" a certain way. If the HE AP sets it one way it's in use, if it sets it another way it's not in use. But can we say that the feature itself is an optional feature? Or mandatory feature? I don't think so.
So... getting back to the intent of the statement.
The intent of the statement is to define the MAC and MLME of an HE STA as a bunch of features defined in Clause 26 plus a bunch of features defined in Clauses 10, 11, etc. and to give precedence to Clause 26 definitions.
If using the word "supports" implies mandatory implementation, then we need a different word or a different phrasing.
How about...
The MAC and MLME of an HE STA comprises the functions defined in Clause 26 as well as the functions defined in Clause 10, the MLME functions defined in Clause 11 and the security functions defined in Clause 12, except when the functions defined in Clause 26 supersede the functions defined in Clause 10 or Clause 11.
-Robert
From: Xiaofei Wang <00001995ce968e76-dmarc-request@xxxxxxxxxxxxxxxxx>
--- This message came from the IEEE 802.11 Task Group M Technical Reflector --- Dear all,
For RevME, there is a comment 7024 for 26.1 regarding the word “supports”.
The proposed CR is to change Subclause 26.1 as follows (as shown below and in 11-24/718r1). It is mostly editorial changes. Please let me know if you have any comments/changes. There are also a number other sentences that may need to be changed regarding the word “supports”.
26. High-efficiency (HE) MAC specification(11ax) 26.1 Introduction An HE STA supports the mandatory MAC and MLME functions and may support the optional MAC and MLME functions:
A frame successfully transmitted by a non-AP STA in response to a Basic Trigger frame is a successful frame exchange sequence(#109) initiated by the STA as referred to in Clause 11 (MLME) and Clause 12 (Security).
Xiaofei Clement Wang Principal Engineer | InterDigital T: (631) 622.4028 E: Xiaofei.wang@xxxxxxxxxxxxxxxx
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 |