Re: [STDS-802-11-TGM] 11mf/D3.0 comment resolutions

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

Hi Mark,

In every editor report, we advertise members to use the latest RTF to prepare their resolution to avoid conflict and implementation confusion from the editor.

I think the resolution should at least note which issue is still relevant and which issue is not.

At this point, majority of the proposed resolution is not even relevant anymore.

Best,

Po-Kai

From: Mark RISON <m.rison@xxxxxxxxxxx>
Sent: Wednesday, November 11, 2026 5:40 PM
To: STDS-802-11-TGM@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGM] 11mf/D3.0 comment resolutions

--- This message came from the IEEE 802.11 Task Group M Technical Reflector ---

Hello Po-Kai,

By definition all comments are against D3.0, and by implication and

explicit notification (see end of submission) all resolutions are against

D3.0 too, unless specified otherwise.

Here is one of the instances in D3.0:

I'm happy to add "Note to the Editor: this was fixed in D3.1; no

additional changes necessary".

Actually scratch that -- one of the instances has not been fixed in D3.1:

Thanks,

Mark

Mark RISON, Standards Architect, WLAN English/Esperanto/Français

Samsung Cambridge Solution Centre Tel: +44 1223 434600

1 Cambridge Square, Cambridge CB4 0AE Fax: +44 1223 434601

ROYAUME UNI WWW: http://www.samsung.com/uk

From: Huang, Po-kai <po-kai.huang@xxxxxxxxx>
Sent: Thursday, 12 November 2026 07:34
To: Mark RISON <m.rison@xxxxxxxxxxx>; STDS-802-11-TGM@xxxxxxxxxxxxxxxxx
Subject: RE: 11mf/D3.0 comment resolutions

Caution: External Emails May Contain Spoofed Addresses, Malicious Links, or Attachments – Verify Before Engaging.

Hi Mark,

On the following instruction for CID 2755, I search D3.1. Can not find any instance of “STA_”, “PPDU_”, or “PCP_” in clause 3.2 in D3.1. As a result, I have to request you to provide the spec page number and line on where is the instance you want to fix. Otherwise, I currently conclude that the resolution can not be implemented by Editor.

In Subclause 3.2 in “(STA_”, “(PPDU_”, “(PCP_” and “(BSSID_” change the underscore to a closing parenthesis.

Best,

Po-Kai

From: Mark RISON <m.rison@xxxxxxxxxxx>
Sent: Wednesday, November 11, 2026 11:08 AM
To: STDS-802-11-TGM@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGM] 11mf/D3.0 comment resolutions

--- This message came from the IEEE 802.11 Task Group M Technical Reflector ---

Hello,

I have uploaded https://mentor.ieee.org/802.11/dcn/26/11-26-1978-04-000m-resolutions-for-some-comments-on-11mf-d3-0-lb295.docx ,

which contains resolutions for the comments below (note the Proposed

Change below is the change proposed by the commenter, not necessarily

the change proposed to resolve the comment).

Please take a look and tell me before AM2 if you have any concerns,

since we have a lot of things to get through in TGmf today! Note that

comments whose resolution is highlighted in green are already ready

for motion and those in a table with red highlight are not being

proposed for resolution today.

CID	Page	Clause	Comment	Proposed Change
2008	1758.06	9.4.2.300	"The P2P Ranging Availability subelement is included in the IFTMR and IFTM frames for non-TB FTM session negotiation with a non-AP RSTA." - I believe the term is "non-TB ranging", also a link would be nice.	Replace with "The P2P Ranging Availability subelement is included in the IFTMR and IFTM frames for non-TB ranging FTM session negotiation with a non-AP RSTA, see 11.21.6.4.4.4."
2514	1283.39	9.4.2.46	In the description of the FTE, it says "R1KH-ID indicates the identity of the R1KH", which is not clear. Is the body of the R1KD-IH subelement just an identifier? How big is it supposed to be? Similarly it's not clear what's in the R0KH-ID subelement	Other locations indicate this is actually a MAC address. This should be specified
2532		11	Why both 11.10.14 Multiple BSSID set and 11.1.3.8 Multiple BSSID procedure?	Merge into one subclause by making 11.10.14 a new last subclause of 11.1.3.8
2539	2413.36	10.23.3.5.1	"A TXOP obtained by receiving a QoS (+)CF-Poll" -- the TXOP is obtained by the transmitter of the CF-Poll, not by the receiver	Reword (not sure exactly what the sentence is trying to say)
2547		13	The spec is inconsistent as to which FT messages the RSNXE is included in. Table 9-87--Presence of fields and elements in Authentication frames says it can only be present in message 1. Figure 13-5--Over-the-air FT protocol in an RSN and 13.7.1 FT reassociation in an RSN say it can only be present in messages 3 and 4. Table 13-1--FT authentication elements says it can be in messages 1, 3 and 4	Agree which messages the RSNXE can be present in for FT, then make sure the spec consistently says so and does not mention the RSNXE in other messages
2556	2896.33	11.2.3.14	"The insertion of an element means that the element was not present in the previous Beacon frame, is present in the current Beacon frame, and will be carried in the next Beacon frame. " -- the receiver has no way to know for sure whether the element will be included in the next frame (maybe CSA, but even there there could be weird corner cases where the AP immediately advertises a CSA on the new channel). Also, should there be something about the removal of an element (e.g. no more Quiet)?	Change to "The insertion of an element means that the element was not present in the previous Beacon frame, is present in the current Beacon frame, and (for an AP) will be carried in the next Beacon frame, or that it was present in the previous Beacon frame and is not present in the current Beacon frame. "
2567		9	"element is included in" is duplication and spec rot, but the following seem to be behaviour not just format/encoding: The EDMG Specific Parameters subelement is included in the IFTMR frame, as described in 9.6.7.32 (FTM Request frame format), and the IFTM frame, as described in 9.6.7.33 (FTM frame format), if the Secure RTT Measurement subfield of the FTM Parameters field of these frames is equal to 1. The EDMG Wide Bandwidth Channel Switch element is included in DMG Beacon frames, Announce frames, or Information Response frames, as defined in 11.8.8.7 (Selecting and advertising new channels in an EDMG BSS). If the initiator and the responder successfully negotiate an FTM session, and the negotiated ranging protocol is non-TB, then the Non-TB Specific subelement is included in both the IFTMR frame, to describe the requested set of parameters that the initiator proposes to use, and in the IFTM frame. If the initiator and the responder successfully negotiate an FTM session where the negotiated ranging protocol is TB, then the TB Specific subelement is included in both the IFTMR frame, to describe the requested set of parameters that the initiator proposes to use, and in the IFTM frame. The P2P Ranging Availability subelement is included in the IFTMR and IFTM frames for non-TB FTM session negotiation with a non-AP RSTA.	Delete the cited sentences and move the behaviour to Clauses 10 and later
2573	867.19	9.3.3.1	The allowed settings of A1 and A3 in probe requests is unclear: whether you can have A1 = unicast A3 = broadcast, or A1 = broadcast A3 = broadcast, and whether there are any additional subtleties with MBSSID (e.g. A1 and/or A3 has to be the txBSSID or something) and/or 6G scanning	As a strawman: at the referenced location add "In Probe Request frames, if the Address 3 field is the wildcard BSSID, the Address 1 field shall be the broadcast address."
2575	4734.38	26.17.2.3.3	"-- Otherwise, if the channel is a PSC and the STA has determined the medium to be idle for a continuous period of at least dot11MinPSCProbeDelay from the start of the scan on the channel, then the STA may, subject to other rules in this subclause, send a Probe Request frame to the broadcast address in that channel, with the SSID field set to the SSID that corresponds to an AP or with the Short SSID field of the Short SSID List element set to the short SSID that corresponds to an AP, and/or with the Address 3 field set to the BSSID of an AP, after invoking the backoff procedure, described in 10.23.2.2 (EDCA backoff procedure), starting from step c) of 11.1.4.3.2 (Active scanning procedure for a non-DMG STA)." seems to suggest you can have Addr1 = broadcast but Addr3 = BSSID. Is this valid, and if so what is the difference with Addr1 = Addr3 = BSSID? In general terms the latter seems better since it allows early rx termination	Clarify
2578	1283.39	9.4.2.45	"R1KH-ID indicates the identity of the R1KH, which is used by the S0KH and the R0KH for deriving the PMK-R1s." is not clear as to the actual contents of subelement, and how the identity of the R1KH is actually encoded in the subement. Similarly for R0KH-ID.	Change to "The Data field of the R1KH-ID subelement contains the identity of the R1KH, which ...". On page 1284 change "the R0KH-ID indicates the R0KH" to "the Data field of the R0KH-ID subelement contains the identify of the R0KH" (2x)
2579	3706.33	13.5.2	Shouldn't Figure 13-5--Over-the-air FT protocol in an RSN(#11be)(#199) include RSNXEs in the Auth frames, at least in some cases, per Table 9-87--Presence of fields and elements in Authentication frames? Conversely the table does not mention RSNXEs in anything but message 1	As it says in the comment
2582			"roaming" is used about 10 times outside the context of "SP" or "consortium", but not defined	Define the term, or change each instance to "BSS transition"
2614	2325.47	10.6.6.5	There are references to "alternate rate"s but it's not clear how you can have two rates that give the same airtime, unless this is something implausible like switching between 80M 2SS and 40M 4SS or something	Add a NOTE to give an example of two alternate rates
2616			Canonicalise "2s complement signed integer" "2s complement integer" "2s complement number" "2s complement value" "2s complement format" "2s complement 8-bit number"	I will provide the list of changes needed
2617			"unsigned 2s complement" makes no sense!	I will provide the list of changes needed
2626		12.7	Stuff like "-- The Key Data descriptions specify what shall or may be included; nothing else shall be included except that one or more vendor specific KDEs and/or Vendor Specific elements may be included." in 12.7.6.1 General also applies to the GKH (12.7.7)	Either duplicate the statements or have a subclause that applies to both 12.7.6 and 12.7.7
2635	3249.54	11.24.2.2	Things like "The QMFReconfigurationActivated subfield shall be set to 0 in the Extended Capabilities element when dot11QMFReconfigurationActivated is false." force the transmission of the octet containing the bit, even if it's the last octet and there are no bits set in it	Change to "... shall not be set to 1 ..."
2651		12.7	12.7.4 notation is EAPOL-Key(S, M, A, I, K, Reserved, RSC, ANonce/SNonce, MIC, {Key Data}) 12.7.7.1 says G1: EAPOL-Key(1, 1, 1, 0, G, 0, RSC, 0, MIC, ... G2: EAPOL-Key(1, 1, 0, 0, G, 0, 0, 0, MIC ... so the Key MIC Present (second argument to EAPOL-Key()) is shown as 1, but it is 0 when an AEAD cipher is used. This is incorrect duplication of the next two subclauses. Ditto for 12.7.6.1	Delete lines 2 to 8 inclusive on page 3617, and from line 63.5 on page 3603 to line 14 on the next page. Note: this is a very detailed and specific statement of the changes that would satisfy the commenter
2657		3.1	It would be useful to have something in 3.1 to say that a wrapped key is a key (or other sensitive material) that is encrypted and authenticated using a KEK. Note cf. CID 481 rejection that this concept appears in the form "wrapped <something>K" not "wrapped key"	Add a definition in 3.1: wrapped key: A key (or other sensitive material) that is encrypted and authenticated using a key encapsulation key (KEK). Notes from previous discussions: The Group did not like the generic definition of "wrapped key". Concern in the wrapped data expanding the use of "wrapped" and if it needed a better definition or usage.June 23: 12.7.3 text on wrapping could be moved to a new clause in 12.7 about the Key Wrap Algorithms for use in the standard. The Title should include the word "Wrapped" maybe at 12.7.2
2755	273.35	3.2	"(STA_" should be "(STA)". There are other typo instances of "_" used instead of ")" in this subclause.	As suggested.