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

Re: [STDS-802-11-EDITORS] 11bc MDR report updated

--- This message came from the IEEE 802.11 Editors' Reflector ---

Hello everyone,

 

I have taken Mark’s r5 and added my comments to make an r6 which is now posted to Mentor.  Please let me know if you have any comments on my markups.  TGbc will also take a quick look at this tomorrow in AM1.

 

Regards,

Carol

 

From: *** IEEE stds-802-11-editors List *** <STDS-802-11-EDITORS@xxxxxxxxxxxxxxxxx> on behalf of Mark Hamilton <mark.hamilton2152@xxxxxxxxx>
Date: Tuesday, July 12, 2022 at 9:58 AM
To: STDS-802-11-EDITORS@xxxxxxxxxxxxxxxxx <STDS-802-11-EDITORS@xxxxxxxxxxxxxxxxx>
Subject: Re: [STDS-802-11-EDITORS] 11bc MDR report updated

--- This message came from the IEEE 802.11 Editors' Reflector ---

All,

 

Again, my apologies for being slow/late.  I have now uploaded 11-22/0699r5, which adds my comments in section 2.1.19.4 “SAP interfaces (Clause 6)”: https://mentor.ieee.org/802.11/dcn/22/11-22-0699-05-0000-tgbc-mdr-report.docx

 

I would appreciate review/comments from the EDITORS group.  For your convenience, the comments are reproduced in the text of this email, just below (if you don’t want to download the document).

 

Thanks.  Mark

--

Mark Hamilton

 

[01] N/A is not a very useful information/reference for the Valid range column.  Replace N/A with a “As defined in xx.yy.zz”, with a reference to a clause 9 or 12 description of what is valid in these sequences.  Make these changes:

  • MLME-EBSINFO.request, PrivateKey row should be “As defined in 12.14.1”
  • MLME-EBCSINFO.request Certificate row, replace “N/A” with “As defined in 9.6.7.54”.
  • MLME-EBCSUL.request HLPPayload row, replace “N/A” with “As defined in 9.6.7.53”.
  • MLME-EBCSUL.request “STA Certificate row, replace “N/A” with “As defined in 9.6.7.53”.
  • MLME-EBCSUL.request PrivateKey row should be “As defined in 12.14.1”
  • MLME-EBCSUL.indication HLPPayload row, replace “N/A” with “As defined in 9.6.7.53”.

 

[02] Recommend that each subclause of 6.3 contain just one named MLME service, and its primitives (request, confirm, etc.), to make it easier to understand the scope of that service and its primitives pattern.  Specifically, separate into distinct 6.3.XXX subclauses for MLME-EBCSINFO, MLME-EBCSTERMINATIONNOTICE, and MLME-EBCACONTENT, rather than combining all these into 6.3.126.

 

[03] If any parameters to primitives are not always present, the presence conditions should be specified:

  • MLME-EBCSINFO.request, in the Certificate row, add a new sentence, “Present if the EBCS Info Authentication Algorithm subfield indicates that a certificate is present”.
  • MLME-EBCSUL.request, for the STACertificate, FrameTxTime, FrameCount and PrivateKey rows, 11.55.4.3 is rather vague about when these parameters (and resulting fields in the protocol) will be included and seems that it could be a bit more explicit than just a list of “should”s, but that is a technical comment out of scope of the MDR.  Based on the 11.55.4.3 language, it seems these fields are simply optional.  So, add “This parameters is optionally present and” to start of each of the Description entries on these rows.
  • In the MLME-EBSUL.indication, since this primitive is generated when a frame is received, the FrameTxTime and FrameCount parameters are present in the primitive when they are present in the frame.  In those rows, change the Description from “When present, specifies …” to “Present when the Frame Tx Time was present in the received EBCS UL frame.  Specifies …” and “Present when the Frame Count was present in the received EBCS UL frame.  Specifies …”, respectively.

 

[04] When comparing the SAP primitive parameters to the frame fields, an inconsistency is found in the MLME-EBCSCONTENT primitives.  The request and indication both contain the PeerSTAAddress, and also a DialogToken.  However, the response includes a PeerSTAAddress and DialogToken but the confirm has only the DialogToken and no PeerSTAAddress.  It seems it could be argued that the PeerSTAAddress can be determined based on saved information attached to the DialogToken at the requester, and thus is not needed in the confirm.  However, by that logic, then the PeerSTAAddress should not be needed in the response.  So, either delete PeerSTAAddress from the response, per the above logic, or add PeerSTAAddress to the confirm if that logic is not sufficient/desired logic.

 

 

 

From: *** IEEE stds-802-11-editors List *** <STDS-802-11-EDITORS@xxxxxxxxxxxxxxxxx> On Behalf Of Stacey, Robert
Sent: Monday, July 11, 2022 7:46 AM
To: STDS-802-11-EDITORS@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-EDITORS] 11bc MDR report updated

 

--- This message came from the IEEE 802.11 Editors' Reflector ---

Hello All,

 

I’ve updated the 11bc MDR (r3) with findings from

Edward,

Yongho,

Emily

Myself (ANA)

MEC response

 

r3 had Jonathan’s and Peter’s findings.

 

https://mentor.ieee.org/802.11/dcn/22/11-22-0699-04-0000-tgbc-mdr-report.docx

 

-Robert

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

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

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