Stephen/all, How about “Device Identification element” and “Device ID field”? (I kind of agree with Luther that “Device Information”, or just “Device”, are too broad in implication.) Mark From: Stephen McCann <mccann.stephen@xxxxxxxxx>
Sent: Wednesday, August 23, 2023 3:35 AM
To: mark.hamilton2152@xxxxxxxxx
Cc: STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBH] Off-line discussion action items from today's TGbh call 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. 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.”
- 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.”
- 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 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 |