Re: [STDS-802-11-TGBH] TGbh CID 104

Thread Links	Date Links
Thread Prev	Thread Next	Thread Index	Date Prev	Date Next	Date Index

Luther,

You’ve run into an oddity that catches everyone the first time… Clause 9 is somewhat unique. At the start of clause 9, there is this sentence,

A STA shall properly construct a subset of the frames specified in this clause for transmission and decode a (potentially different) subset of the frames specified in this clause upon validation following reception.

The idea is that _all_ of clause 9 is effectively normative, because of this statement. When clause 9 body text says something “is” such-and-such (or other equivalent existential verb), then that sentence at top says that all STAs _shall_ properly construct frames per that specification. Thus, all such text becomes normative, albeit indirectly.

Mark

From: Luther Smith <000025945f3926b3-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Wednesday, August 23, 2023 9:11 AM
To: STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBH] TGbh CID 104

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

From: Mark Hamilton <mark.hamilton2152@xxxxxxxxx>
Sent: Tuesday, August 22, 2023 1:17 PM
To: STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBH] TGbh CID 104

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

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