Hi Jay,
May I suggest that at P30.54, you insert a new sentence, something like:
“The non-AP STA should store the newly provided Device ID
in the dot11DeviceID MIB attribute as an identifier for use with that AP/ESS.”
Then leave it at that?
Furthermore, Mark is correct that it is an array, but not sure what to do about that. Should the MIB change?
Graham
From: Jay Yang <yang.zhijie@xxxxxxxxxx>
Sent: Tuesday, October 10, 2023 2:14 AM
To: STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBH] defered CID159 and CID 276 in 1369r2
Hi Mark, Graham,
Thanks for your response.
Based on Mark's comment, I think we can only have the following change to incroprate MIB attribute dot11DeviceID
in subclause 12.2.11.1. "
A non-AP STA that is associating or using PASN with any AP in an ESS, when Device ID is active for both the non-AP STA and the AP， and the non-AP STA has a saved device ID
in dot11DeviceID for
the ESS, shall send the most recently received dot11DeviceID value for that ESS in the frame containing device ID. "
Any further thought on this?
Original
Subject: Re: [STDS-802-11-TGBH] defered CID159 and CID 276 in 1369r2
All,
(Sorry, I’m traveling today/at the moment, so I can’t be very complete – I’ll work on this a bit tonight.)
My thoughts:
- I agree with Graham, keep it simple. I would just mention somewhere in clause 12 that when a non-AP STA receives a device ID (during any of the frame exchanges we are adding) then it shall save it in the dot11DeviceID MIB
attribute. And, when a non-AP STA is connecting to a network for which it has a stored device ID, then it provides the dot11DeviceID value in the appropriate frame. (I think this mostly what Jay suggested with a couple of his sentences below, but I think
the wording Jay has suggested is a little odd.)
- I don’t we say anything about the AP side. That is, in particular, I don’t think the AP has a dot11DeviceID MIB attribute at all, and we should state that clearly. Note that otherwise, the AP’s MIB would need to store every
still valid device ID that it had ever allocated, along with some sort of connection to the “local state” that goes with it – and I really don’t want to try to explain within the MIB what that latter part would look like.
- A question to the group, though (did we discuss this already?): Should the non-AP STA have an array of stored device IDs, mapped to the SSID of the network that provided each? That is, in the MIB, dot11DeviceID should be
an array, and our description above about non-AP STA behavior is all with reference to the particular entry that corresponds to the SSID of the network being connected to?
Mark
I think that changing to dot11DeviceID makes sense, and I would support it.
Fix typo
|
If dot11DeviceIDActivated is true and dot11FILSActivated is true,
|
Kurt
Hi all,
CID 159 and CID276 in 1369r2 are defered from last call. Let's have some discussion in this mail loop and make the decision to address them.
CID276:
As the commenter said, we define dot11DeviceID in Annex C but never use it in the normative text.
To address the commenter's concern,one approach is to remove the defination of dot11DeviceID from Annex C.
Another approach is to have some text change in subclause 9 and And in subclause 12.2.11.1(in
red font) as bellow, I would like to know our group's preference.
" The Device ID field contains a device ID dot11DeviceID or
an opaque identifier (see Annex AD.1)."
"Assign a new device ID value dot11DeviceID in
Device ID field, and set Device ID Status field of Device ID KDE or Device ID element to 0 to indicate that AP recognizes the non-AP STA in the appropriate frame."
"When an AP with dot11DeviceIDActivated equal to true receives a first PASN frame containing a device ID which is recognized,the AP shall assign a new device ID value dot11DeviceID to
the non-AP STA,via setting a new device ID in Device ID field with the Device ID Status field of Device ID element set to 0 to indicate that the AP recognizes the non-AP STA in the second PASN frame."
|
276
|
27/61
|
dot11DeviceID is not referenced in body text
|
Either add that the Device ID field contains the ID from dot11DeviceID here and add behavioral text (probably in clause 12) that sets the attribute when a Device ID is received
at a non-AP STA, or remove the MIB attribute from Annex C.
|
Revised--
|
CID 159:
Based on the commenter's suggestion, I think we need change to description in the note as bellow(in red font):
9.3.3.5 Association Request frame format/9.3.3.6
Association Response frame format/9.3.3.7
Reassociation Request frame format/9.3.3.8
Reassociation Response frame format
|
Order
|
Information
|
Notes
|
|
|
Device ID
|
If dot11DeviceIDctivated is true and dot11FILSActivated is true,the Device ID element is optionally present when using FILS
authentication; otherwise, it is not present.
|
|
63
|
IRM
|
If dot11IRMActivated is true and dot11FILSActivated is true, the IRM element
is optionally present when using FILS authentication;
otherwise, it is not present.
|
|
159
|
|
Doesn't the presence of the Device ID element need to depend on dot11DeviceIDActivated and dot11FILSsomethingorother being true, and the presence of the IRM element need to depend
on dot11IRMActivated and dot11FILSsomethingorother being true?
|
As it says in the comment
|
Revised--
|
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
|