Mark
Interestingly in section 9.4.2.2 SSID Element reads:
“The SSID element indicates the identity of an ESS or IBSS.”
Not sure if this normative or what.
Luther
From: G Smith <gsmith@xxxxxxxxxxxxxxxxxxx>
Sent: Tuesday, August 22, 2023 2:47 PM
To: STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBH] TGbh CID 104
Hi Mark,.
“All APs shall set this field to the same value as the other APs in an ESS, to operate correctly within the ESS.”
I think this is a reasonable statement. Maybe turn it around?
“For device ID mechanism to operate correctly in an ESS, all APs in that ESS shall set this field to the same value.”
Just a suggestion
Graham
All,
Here are my thoughts on TGbh CID 104, to follow-up on my other action item from today’s call.
I made a claim on the call today that there is (somewhere in the baseline) a requirement that all APs in an ESS have the same SSID. As I have researched this, I can not find any such requirement clearly stated
in a normative statement. There are these statements in clause 4, “An ESS is the union of the infrastructure BSSs with the same SSID connected by a single DS. All BSSs in an ESS have the same SSID.”
But, whether this is a normative requirement is a bit unclear.
With that in mind, consider CID 104’s claim that our amendment cannot enforce a normative requirement on a configuration of an ESS. A couple questions to the group:
-
Where does it say that we (802.11) cannot enforce such a normative requirement? Or, perhaps some would argue that even if we _can_ have such a normative requirement we _should not_ and they don’t want this text in the draft? Any comments/thoughts?
-
An alternative way to look at this (and what the text in our draft actually says, in my opinion), is that we are not putting a requirement on the ESS configuration, but a requirement on the configuration of any AP that is/wants to be part of the ESS. Is that
okay to do? (Our current text says this, by the way, “All APs in a given ESS shall set this field [Device ID Active field, or IRM Active field, appropriately]
to the same value.” ) If this were changed to “All APs shall set this field to the same value as the other APs in an ESS, to operate correctly within the ESS.” does that help?
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
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