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

Re: [STDS-802-11-TGBH] defered CID159 and CID 276 in 1369r2



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?

 

 

Best Regards

 

Jay Yang (杨志杰)

 

Wi-Fi  Standard Research Engineer

 

ZTE Corporation

R&D Building I, No.899 Bibo, Pudong District, Shanghai, P. R. China

T: +86 15021324431 

E: yang.zhijie@xxxxxxxxxx

www.zte.com.cn

Original

From: MarkHamilton <mark.hamilton2152@xxxxxxxxx>

Date: 20231010 04:31

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:

  1. 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.)
  2. 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.
  3. 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

 

From: Kurt Lumbatis <kurt.lumbatis@xxxxxxxxxxxxxx>
Sent: Monday, October 9, 2023 10:18 AM
To: STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBH] defered CID159 and CID 276 in 1369r2

 

I think that changing to dot11DeviceID makes sense, and I would support it.

Fix typo 


If dot11DeviceIDActivated is true  and dot11FILSActivated  is true
,

 

Kurt

 

On Sun, Oct 8, 2023 at 6:32 AM Jay Yang <yang.zhijie@xxxxxxxxxx> wrote:

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--

 

 

 

 

Best Regards

 

Jay Yang (杨志杰)

 

Wi-Fi  Standard Research Engineer

 

ZTE Corporation

R&D Building I, No.899 Bibo, Pudong District, Shanghai, P. R. China

T: +86 15021324431 

E: yang.zhijie@xxxxxxxxxx

www.zte.com.cn


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