So, picking up one of my action items, here are thoughts/comments on TGbh CID 244:
In 11-23/1316r4, CID 244 is resolved together with CID 103, with a complete re-write of the paragraph that used to include “A non-AP STA indicates activation of device ID for a particular ESS by setting … in … frames sent to any AP in the ESS.” (The underlined part is what CID 244 suggested to delete, and those are deleted in the re-write.)
The proposal is to remove this text in the subclauses for the Device ID and IRM specific usage behavior (as the comment requests), AND ALSO removes a similar discussion in the 12.2.11 introduction (which used to say “to allow any AP in the AP’s ESS to recognize the non-AP STA when it returns to that ESS”, but this text is also removed in 11-23/1316r4).
I am concerned that removing this text causes the reader to miss the concept that the device ID and/or IRM settings and identifiers are “per-ESS” and that any/all APs within the ESS will have the information so the non-AP STA can connect anywhere in the ESS for its next association.
I therefore propose to add text in the introduction section of the 11-23/1316r4 re-write, as shown below:
To mitigate tracking and traffic analysis, a non-AP STA may randomly change its MAC address (see 4.5.4.10 (MAC privacy enhancements)).
This presents a problem for the network in that it is unable to identify a non-AP STA that had previously associated and is not able to apply cached information from that previous association to the current association. The two mechanisms defined in 12.2.11 alleviate this problem. Both the mechanisms provide for an identifier that is shared between the network and the non-AP STA, but is not trackable by third-party observation. The identifier is optionally used, per-ESS, and the identifier is related to that ESS, with a different identifier generally used with other ESSs.
I am not very happy with this wording, and would be very welcoming of any wordsmithing to help this out. But, I hope the concept I’m trying to convey is clear, and I’d like to see if other members of the TG agree this is needed/desired to be added to our text.
Thanks. 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