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

[802SEC] Regarding conditional approval for 802.11bh D6.0 to be forwarded to RevCom

Hello 802 LMSC,

The 2nd recirculation ballot for 802.11bh on D6.0 was completed on August 15, 2024. The CRG has met and resolved the comments received. Additional MBS comments were submitted by one of the Disapprove voters. I have notified that voter that no further recircs are planned (see attached).

The results are: 
Approve: 128
Disapprove with MBS: 3
Abstains: 5
Approval rate: 97%
Return rate: 88%

There are no new DISAPPROVE votes. 

There are no new valid DISAPPROVE comments on new issues that are not resolved to the satisfaction of the submitter from existing DISAPPROVE voters.

No technical changes were made to the draft as a result of the recirculation ballot.

Here is a link to the TGbh comment spreadsheet: https://mentor.ieee.org/802.11/dcn/24/11-24-1415-01-00bh-p802-11bh-sa-recirc2-comments.xlsx

The conditions for forwarding to RevCom are met.  Since the project is already on the RevCom agenda I will let them know that we are done.

Regards,
Robert Stacey
IEEE 802.11 WG Chair,
robert.stacey@intel.com
rjstacey@gmail.com
Mobile phone: +1-503-724-0893


To unsubscribe from the STDS-802-SEC list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-SEC&A=1

--- Begin Message ---
Hello Mark,

I have uploaded the comment resolutions to MyProject. This is to let you know that no further recirculations are planned.

The resolution to your comment is as follows:
CID Name Category Page Subclause Line Comment Must be Satisfied Proposed Change Resolution Type Resolution Text
5000
 RISON, Mark
Editorial
30
 9.4.2.319 29 "Robust" font size too small Yes Make font size match surrounding text REJECTED The draft will be professionally edited prior to publication.  This concern will be passed along to the IEEE Editor.
5001
 RISON, Mark Technical 29 9.4.2.319 47 I don't understand why everything has been made into elements.  In the baseline we use subelements, not elements, inside elements.  They're clearly not elements, because ID 0 would otherwise be SSID, not Robust Device ID Yes Reword to be about subelements (9.4.3) REJECTED The comment seems to ask a question, and fails to identify changes in sufficient detail so that the specific wording of the changes that will satisfy the commenter can be determined.  
5002
 RISON, Mark Technical 36 12.2.13 59 In 12.2.13.1/2 it's always "An AP that has dot11DeviceIDActivated equal to true <does something>" but "A non-AP STA that has dot11MACPrivacyActivated and dot11DeviceIDActivated equal to true <does something>".  It's not clear why for the AP it's not conditional on dot11MACPrivacyActivated too Yes Make conditional on dot11MACPrivacyActivated for APs too (4x) REJECTED Per 12.2.11 (in baseline text), "MAC privacy enhancements are enabled on a non-AP STA when dot11MACPrivacyActivated is(M118) true."  There is no discussion of the meaning of this attriute on an AP.  Similarly, the MIB Description for this attribute only mentions non-AP STA behavior.  The CRG finds no justification for checking this MIB attribute for the AP operation of the P802.11bh features.
5003
 RISON, Mark
Editorial
62
 AG.2 12 "in association request" should be "in the association request" Yes As it says in the comment REJECTED The draft will be professionally edited prior to publication.  This concern will be passed along to the IEEE Editor.
5004
 RISON, Mark
Editorial
18
 4.5.4.10 26 "allow the network to connect transactional information obtained preassociation or in a prior association" should be "allow the network to connect transactional information obtained in preassociation or in a prior association" Yes As it says in the comment REJECTED The draft will be professionally edited prior to publication.  This concern will be passed along to the IEEE Editor.
5005
 RISON, Mark
Technical
37
 12.2.13.1 3 "The RSNXE with the Device ID Support field equal to 1 is present in either (Re)Association Request frames or the first PASN frame that is sent to an AP that advertises support for the device ID mechanism. " -- Table "Association Request frame body" in the baseline already specifies that " The RSNXE is present if any subfield of the Extended RSN Capabilities field in this element is nonzero, except the Field
Length subfield." and there's also " Including the constructed RSNE." for the first PASN frame, so this is duplication.  The previous sentence "A non-AP STA that has dot11MACPrivacyActivated and dot11DeviceIDActivated equal to true sets the Device ID Support field to 1 in the Extended RSN Capabilities field in the RSNXE to indicate that the device ID mechanism is supported." has the new material		 Yes Delete "The RSNXE with the Device ID Support field equal to 1 is present in either (Re)Association Request frames or the first PASN frame that is sent to an AP that advertises support for the device ID mechanism. " REJECTED The comment is out-of-scope: The cited sentence is unchanged.  Yes, the prior sentence had a change, but the change added an additional MIB attriute check to the existing requirement.  The CRG does not believe the cited concern with the sentence was affected by the change in the prior sentence (or other changes in the draft) as required for a valid comment per the IEEE SASB Operations Manual (comments "shall be based only on the changed portions of the balloted proposed standand [or] portions of the balloted proposed standard affected by the changes").

Also, the CRG disagrees with the Comment and the Proposed Change.  In response to the commenter, the CRG agrees that the frame formats require that the RSNXE is included in the respective frames (when the bit is set to 1).  However, the cited sentence is only an informative statement to help the reader understand that these two different situations are both possible and part of the specified behavior of the device ID feature, as part of understanding the overall device ID feature operation.  As a non-normative sentence, this is not a requirement duplication, it is an explanation.


Regards,
-Robert

--- End Message ---