Thanks for the valuable comments in the reflector.
See my comments and the corresponding change on all detable CIDs as below:
My thoughts in green.
CID 75: There is no much different on the words of "function" and "mechansim", see some instances in "10.3.2.1 CS mechanism", I propose to pick up one of them.
"Physical and virtual CS functions are used to determine the state of the medium", "A physical CS mechanism shall be provided by the PHY"
the proposal change: Globally change
“Device ID indication” to
“Device ID mechansim”
CID123:
change "of Device ID" to "of
the device ID mechansim" in all occurences,
e.g. "...indicates activiation of
the device ID mechansim..."
[typo]
CID244: in order to keep the original ideas of all APs in the same ESS have the same capability of 11bh identifier,
delete "for a particular ESS", and add "sent to any AP in the ESS"
at the end of the sentence.
"
A non-AP STA or a STA affiliated with a non-AP MLD indicates activation of device ID for a particular ESS by setting the Device ID Active field to 1 in the Extended RSN Capabilities field in
(Re)Association Request frames sent to any AP in the ESS."
What does "the ESS" mean here?
Is there a reference to an ESS earlier in the text where this sentence appears?
If not, "in the ESS" doesn't work.
CID 104/170: change back to "shall", which will be aligned with the resolution in CID244.
CID106: The proposal of positive _expression_ may cause inconsistence in other place, I will change it back to double negative _expression_:
"
A STA or a STA affiliated with an MLD shall not send a frame with device
ID to any STA or any STA affiliated with an MLD that
doesn't indicate dot11DeviceIDActivated equal to true
"
You can avoid a double negative with "unless":
A STA or a STA affiliated with an
MLD shall not send a frame with device
ID to any STA or any STA affiliated
with an MLD unless the receiving STA indicates dot11DeviceIDActivated equal to true
Note however, that a STA doesn't indicate MIB attributes to another STA.
It would be better to refer to a specific field transmitted by the receiving STA that indicates DID is activated.
Welcome further comments, and it's appreciated if we can reach some consensus and move forward before next call.
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
Original
From: LutherSmith <000025945f3926b3-dmarc-request@xxxxxxxxxxxxxxxxx>
Date: 2023年08月24日
21:44
Subject: Re: [STDS-802-11-TGBH] Off-line discussion action items from today's TGbh call
Mark,
Thank you for your comments – I was simply pointing out the previous use of sub-field (and was not sure why it was referred to as sub-field versus just field) greatly appreciated.
As to the others I will continue thoughts and opinions on the new thread.
Sincerely,
Luther
From: mark.hamilton2152@xxxxxxxxx <mark.hamilton2152@xxxxxxxxx>
Sent: Wednesday, August 23, 2023 2:07 PM
To: Luther Smith <l.smith@xxxxxxxxxxxxx>;
STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-11-TGBH] Off-line discussion action items from today's TGbh call
Luther,
First, thanks for the research, and thoughts/suggestion from there.
Another “gotcha” item, though, for those new(er) to IEEE 802.11: The direction from REVme is largely toward stopping with the distinction between fields and subfields. 1) Everyone
gets it wrong all the time, and it’s just busy work fixing them all the time. 2) The distinction really doesn’t matter in any practical real-world sense. 3) Which is correct is sometimes context dependent, and relies on context that may not be knowable at
the point of the particular sentence being written.
So, we’re giving up, and (slowly – because it’s just way too painful) getting rid of the “subfield” usage, and just saying “field” for all components of a larger protocol structure.
I’ll leave the discussion about “DID” versus “Device ID [<something>]” I’ll leave to another thread. (Note that I responded to Stephen, also, already.)
And, likewise, whether we need/want a distinction between “Device ID function” and “Device ID mechanism” (and what about “Device ID feature”?) I’ll leave to a separate thread.
I’m not convinced there is any consistent semantic difference between these in the current 802.11 baseline (REVme, etc.) though.
Mark
From: Luther Smith <000025945f3926b3-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Wednesday, August 23, 2023 8:42 AM
To:
STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBH] Off-line discussion action items from today's TGbh call
All,
After some research to how elements and fields are referred to in the base document the following is my interpretation.
The element is the part of the messaging that continues information about the topic/item. In this case the length, extension, status, and value used for identifying the device,
“Device ID”, thus the element is named “Device ID element”. This is consistent with the definition of other elements.
The “items” or fields within the elements that contain values seem to be referred to as “subfields” such example is within the
Link Info field of the Basic Multi-Link element
“The Link ID subfield is as defined in 9.4.1.71 (Link ID Info field)
and specifies a value that uniquely identifies the link where the reported STA is operating on (see 35.3.3.2 (Link ID)).”
Hence the actual value used for the Device ID should be referred to as “The Device ID subfield…”.
Since this is focused on just the ID of the device (Device ID) that using “Device” or “Device Information” this seems are more generic or broader terms and could be seen as including
things such as the Device MAC address or the IRMA (using Mark’ term) versus just the device’s ID that is used by the AP and STA.
To the use of “DID”, the term is not very descriptive and could be confused with the verb “did”. That the fill use or spelling of “Device ID mechanism” defines it as a mechanism
involving the Device ID. While the use of mechanism and function seem closely related based on my evaluation, a mechanism is the action of fulfilling a function. Such as the Device ID function is preformed using the following mechanism. Thus there may be room
for both Device ID function (and IRM function) to indicate that something is being done (ie the function) and Device ID mechanism (and IRM mechanism) to define what is done or to be done to execution the function.
Respectfully submitted,
Luther
From: Stephen McCann <mccann.stephen@xxxxxxxxx>
Sent: Wednesday, August 23, 2023 3:35 AM
To:
STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBH] Off-line discussion action items from today's TGbh call
Mark,
thanks for capturing these items.
It's definitely going in the right direction, although I would prefer Device ID field and Device ID element to be named differently, as these terms cause a lot of confusion when
reading the text. Something like Device element or Device Information element may work, leaving Device ID field as it is.
Kind regards
Stephen
On Tue, 22 Aug 2023 at 18:42, Mark Hamilton <mark.hamilton2152@xxxxxxxxx> wrote:
All,
I’ll throw in a thought on CIDs 75 and 123, also, and in particular the concern about terms (like “device ID”) meaning both the device ID mechanism, and the logical/conceptual identifier that is shared between a particular non-AP STA and a particular ESS.
How about if we use these terms for Device ID (I had started to put some of this in the Chat today, in case it looks familiar):
· Mechanism: “DID mechanism” (as was suggested by someone).
§ Example: An AP shall set the Device ID Active field to 1 when the DID mechanism is activated.
· Identifier concept shared by a particular pair: “device ID”.
§ Example: A device ID is provided by the network to identify this particular non-AP STA when it returns to the ESS in the future.”
· Field: “Device ID field”
§ Example: The Device ID field contains a device ID, when dot11DeviceIDActivated is true.
· Element: “Device ID element”
· KDE: “Device ID KDE”
§ Example: … the most recently received Device ID element or Device ID KDE …
Similarly, extending to IRM:
· Mechanism: “IRM mechanism”.
§ Example: An AP shall set the IRM Active field to 1 when the IRM mechanism is activated.
· Identifier concept shared by a particular pair: “IRMA”. (Define this to be the acronym for “identifiable random MAC address” and create a definition so that “IRM” is only used for references to the mechanism.)
§ Example: An IRMA is provided by the non-AP STA to identify this particular non-AP STA when it returns to the ESS in the future.”
· Field: “IRM field”
§ Example: The IRM field contains an IRMA, when dot11IRMActivated is true.
· Element: “IRM element”
· KDE: “IRM KDE”
§ Example: … the most recently received IRM element or IRM KDE …
Thoughts/comments?
Mark
From: mark.hamilton2152@xxxxxxxxx <mark.hamilton2152@xxxxxxxxx>
Sent: Tuesday, August 22, 2023 9:52 AM
To: STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx
Subject: Off-line discussion action items from today's TGbh call
All,
This is, I believe, the CIDs in 11-23/1316r4 that need off line (reflector) discussion, and the status as I recorded it after today’s TGbh call:
· CID 75: Generally, the TG is okay with the new wording, although there were comments about the multiple use of “device ID” as both the (shorthand) name for the mechanism, and the name for the particular identifier that is conceptually shared/agreed between the AP and non-AP STA. This also related to CID 123 (below).
· CID 244: There was one comment (from me, and a promise to work off-line) that we are losing the idea that an identifier can be used later with any AP in the ESS (not necessary the same AP that exchanged the protocol previously).
· CID 123: This discussion about when we need an article, and also on when we are referencing the mechanism, the identifier, or some element or field, led to the request to consider this off-line and review if we have all these usage situations correct. Also, there was a suggestion to name the mechanism something different from the logical identifier itself (“DID” was suggested in the chat, for the mechanism), to remove the multiple use. (Chair note: We’ll need to do the same with IRM, for consistency, I assume.)
· CID 104/170: There was one comment (from me, and a promise to work off-line) that we have a similar requirement for all APs in an ESS to use the same SSID. How is that requirement phrased, and can we use something similar here (instead of just saying “should”)?
· CID 106: Do we need these “negative requirements”, and if so, how do we word them? The last changes in 11-23/1316r4 had inconsistent wording, with changing the first “shall not” (under a specific situation) to a “may” (under the reverse of the situation), while the second and third “shall not”s were changed from “shall not send a device ID” to “shall not send a frame with device ID”.
Reminder, we stopped at CID 133. This CID and some following ones are overlapping in the re-write of the bullet lists in this subclause, and everyone is encouraged to review the re-write off-line before next week’s call.
Thanks. Mark
To unsubscribe from the STDS-802-11-TGBH list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBH&A=1
To unsubscribe from the STDS-802-11-TGBH list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBH&A=1
To unsubscribe from the STDS-802-11-TGBH list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBH&A=1
To unsubscribe from the STDS-802-11-TGBH list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBH&A=1
To unsubscribe from the STDS-802-11-TGBH list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBH&A=1
To unsubscribe from the STDS-802-11-TGBH list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBH&A=1