Hi Mike,
No problem. I have uploaded r12 to change resolution for CID 2399 as suggested.
https://mentor.ieee.org/802.11/dcn/26/11-26-1633-12-000m-cr-for-control-frame-protection.docx
Best,
Po-Kai
From: M Montemurro <montemurro.michael@xxxxxxxxx>
Sent: Thursday, October 15, 2026 3:24 PM
To: Huang, Po-kai <po-kai.huang@xxxxxxxxx>
Cc: STDS-802-11-TGM@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGM] TGmf teleconference reminder - 16 Oct 2026
For the note in 2399, could you make the fix and post an 11-26/1633r7?
Thanks,
Mike
On Thu, Oct 15, 2026 at 6:05 PM Huang, Po-kai <po-kai.huang@xxxxxxxxx> wrote:
--- This message came from the IEEE 802.11 Task Group M Technical Reflector ---
Hi Mark,
For 2368, I think there is indeed an error. In my original 1633, the instructions is to implement 2368 for CID 2368 as well.
For 2333, the suggestion is not related to the change, but we can make a note to change the font size.
For 2399, I can do below to move forward.
Best,
Po-Kai
From: Mark Rison <m.rison@xxxxxxxxxxx>
Sent: Thursday, October 15, 2026 2:46 PM
To: STDS-802-11-TGM@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGM] TGmf teleconference reminder - 16 Oct 2026
--- This message came from the IEEE 802.11 Task Group M Technical Reflector ---
I would like the following to be pulled for the reasons given,
please, unless we can patch them up in time.
Motion Sept B:
CID
Commenter
Clause
Page
Comment
Proposed Change
Resolution
mgr comment
2279
Atsushi Shirakawa
9.3.1.19.3
792.58
If this description is for Figure9-92, "Disabled Subchannel Bitmap" should be "Disallowed Subchannel Bitmap"
As in comment
REVISED
Change "Disabled Subchannel Bitmap" to "Disallowed Subchannel Bitmap" at P792.58 and P793.1.There are about 71 instances of "disabled subchannel bitmap" (and in fact only 25 of "disallowed subchannel bitmap") so I'm not clear this resolution is correct or complete
2368
Po-Kai Huang
35.3.5.2
5526.18
Beacon frame protection is always enabled for MLO. See "An EHT non-AP STA and EHT AP shall have dot11BeaconProtectionEnabled set to 1 when using RSN." management frame protection is also always negotiated because of "If dot11RSNAProtectedManagementFramesActivated is false, dot11BeaconProtectionEnabled shall be set to false."
Remove "if beacon protection is enabled" after BIGTKSA. Remove "if management frame protection is enabled" after IGTKSA. Add a note to calrify this fact. Similar instances in line 24 and line 28.
REVISED
Incorporate the changes in https://mentor.ieee.org/802.11/dcn/26/11-26-1633-06-000m-cr-for-control-frame-protection.docx for CID 2347.Shouldn't that be "… for CID 2368"?
2399
Alfred Asterjadhi
9.3.1.22.3
814.61
What about the User Info fields that are addressed to other STAs?
Add language that mentions that User Info fields addressed to STAs that have not negotiated protected control frames may appear before or after the Trigger And MIC field.
REVISED
Incorporate the changes in https://mentor.ieee.org/802.11/dcn/26/11-26-1633-05-000m-cr-for-control-frame-protection.docx for CID 2399The proposed NOTE is confusing. Suggest "NOTE - The Trigger Control MIC field might precede a User Info field in the Trigger frame that is addressed to a STA that does not negotiate control frame protection.(#2399)"
Motion Oct A:
CID
Commenter
Clause
Page
Comment
Proposed Change
Resolution
mgr comment
2073
Arik Klein
4.3.25
0.00
Page 352, lines 8 through 45, is a self-contained approximately 38-line normative description of DMG STA PHY/MAC capabilities, but every line in that span is tagged under subclause 4.3.25 (Subscription service provider network (SSPN) interface). There is no '4.3.26 DMG STA' (or equivalent) heading anywhere in this span; the next actual subclause heading after this block is '4.3.26 DMG relay' (page 352, line 47). The DMG STA description is therefore missing its own subclause heading and number, and is misattributed in its entirety to 4.3.25.
Insert a new subclause heading and number (e.g., '4.3.26 DMG STA', renumbering the existing 4.3.26 DMG relay and subsequent subclauses accordingly) immediately before the DMG STA description at page 352 line 8, so the description is no longer misattributed to 4.3.25.
ACCEPTED
Also need to delete the "DMG STA" at the end of the NOTE on line 5
2333
Liwen Chu
12.5.5.7
3538.33
This paragraph clarifies that the protected Management/data frame and the A-MPDU subframe following it can't be the padding of the protected control frame. It is not clear whether the MPDU delimiter of A-MPDU subframe carrying the protected management/data frame can be used as the padding of the protected control frame. It is not clear whether the same protected control frame (as 2nd frame) and its follwing A-MPDU subframes used for the protected control frame befire it (as 1st frame). If this is the case the 2nd frame being the padding of 1st frame doesn't need to be mentioned since once 2nd frame's padding is satisfied, 1st frame's padding requirement is aumitically satisfied. If this is not the case, the clarification test should be added.
As in comment.
REVISED
Revised. Incorporate the changes in https://mentor.ieee.org/802.11/dcn/26/11-26-1633-10-000m-cr-for-control-frame-protection.docx for CID 2332.BTW, the font size is wrong for the paras at 3538.33/51
2355
Po-Kai Huang
13.7.1
3718.48
The sentence says that the target FTR may delete the PTKSA, but in 13.5.3 and 13.5.2 for over the air and over the DS, we have the shall requriement to delete the PTKSA. "The FTO and the target (#11be)FTR compute the PTK and PTKName using the PMK-R1, PMKR1Name,
ANonce, and SNonce, as specified in 12.7.1.6.5 (PTK). The PTKSA shall be deleted by the target FTR if it
does not receive a Reassociation Request frame from the FTO within the reassociation deadline timeout
value."change the may requirement to shall when the FTR does not recevie reassociation reqeust within the deadline.
REVISED
At 3718.48, change "the target FTR may delete" to "the target FTR shall delete"At P3707 L49, P3710 L17, P3715 L37, P3718 L28, change "The PTKSA shall be deleted by the target FTR if it does not receive a Reassociation Request frame from the FTO within the reassociation deadline timeout value." to "The target FTR deletes the PTKSA if it does not receive a Reassociation Request frame from the FTO within the reassociation deadline timeout value."the second set of changes has lost the "shall". Should be "The target FTE shall delete the PTKSA if…"
2406
John Coffey
9.4.1.81.2.2
1047.23
"The number of receive chains is indicated by N_RX and the number of transmit chains is indicated by N_TX." Why is this text in 9.4.1.81.2.2? Neither N_RX nor N_TX is used in this subclause. (They're used in 9.4.1.81.4.) The text looks as if it belongs in the previous subclause.
Move "The number of receive chains is indicated by N_RX and the number of transmit chains is indicated by N_TX" to the end of subclause 9.4.1.81.2.1.
REVISED
At the start of 9.4.1.81.2.2, add "The CSI is encoded for transmission as follows:"Move the sentence currently at the start of 9.4.1.81.2.2 to the end of the sentence at P1050.64, adding a ", where the".the moved sentence needs to start with a lowercase letter, obviously. Also need to reletter the items in the subclause
2499
Jeongki Kim
35.11.2
5643.53
Change 35.11.2 to 35.11.1.7 because the SPATIAL_REUSE is one of the TXVECTOR parameters. Update the corresponding texts globally.
As per comment
ACCEPTED
what does "Update the corresponding texts globally" mean?
2500
Jeongki Kim
35.11.5
5647.54
Change 35.11.5 to 35.11.1.8 because the INACTIVE_SUBCHANNELS is one of the TXVECTOR parameters. Update the corresponding texts globally.
As per comment
ACCEPTED
what does "Update the corresponding texts globally" mean?
2587
Mark RISON
9.4.2.72
1352.08
The Multiple BSSID-Index element potentially contains DTIM period and count fields but they are in the opposite order to in the TIM element! This should be NOTEd to avoid interop issues
At the end of the NOTE at 1352.31 add "Note that the DTIM Period and DTIM Count fields are in the opposite order in the TIM element."
ACCEPTED
Actually the NOTE is about a third instance of a DTIM Count field, so instead the resolution should be to add another "NOTE 2---The DTIM Period and DTIM Count fields are in the opposite order in the Multiple BSSID-Index element compared with the TIM element and the Per-STA Profile subelement of the Basic Multi-Link element."
2694
Mark Hamilton
12.7.6.3
3608.19
"For MLO, if the non-AP MLD includes requested link(s) in the Basic Multi-Link element in the (Re)Association Request frame and the message 2 is used for the initial 4-way handshake, validates that the affiliated STA MAC addresses are the same for each link included in the Multi-Link element in the (Re)Association Request frame." This sentence needs an actor noun (like the previous two sentences). Same thing in the next sentence.
Insert "the Authenticator" before "validates". Same thing in the next sentence.
ACCEPTED
Note to Editor: The two locations are 3608.19 and 3608.24.shouldn't this MLO text be a new list item 3)?
Motion CID 2076:
CID
Commenter
Clause
Page
Comment
Proposed Change
Resolution
mgr comment
2076
Arik Klein
4.5.12.3.2
0.00
NOTE 3 in 4.5.12.3.2 (EBCS proxy operation) states, using mandatory language, that 'the EBCS relaying STAs will not beacon or establish an infrastructure BSS' in a deployment scenario where an operator installs EBCS relaying STAs intended only to provide relaying service. Per IEEE style NOTEs are informative only, so this normative-sounding restriction currently has no corresponding statement in the main body text.
Restate the 'will not beacon or establish an infrastructure BSS' restriction as normative body text (e.g., a 'shall not' statement scoped to the relaying-only deployment case) in 4.5.12.3.2, rather than leaving it only in an informative NOTE.
REVISED
Change “that 'the EBCS relaying STAs will not beacon or establish an infrastructure BSS'” to “that 'the EBCS relaying STAs do not transmit beacons and do not establish an infrastructure BSS'spurious apostrophes before "the"
Motion CID 2371:
CID
Commenter
Clause
Page
Comment
Proposed Change
Resolution
Edit Notes
2371
Po-Kai Huang
12.11.2.5.3
3653.22
The value here does not even match the value in 3653.54. Also, there are 3 values, but line 54 has 4 values.
There seems to be error here and there on the number of bits. There must be a better way to write these bits.
REJECTED
The commenter has withdrawn the comment.I think that the mismatch and the missing value are clearly bugs that need to be fixed
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: M Montemurro <montemurro.michael@xxxxxxxxx>
Sent: Thursday, 15 October 2026 19:04
To: STDS-802-11-TGM@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGM] TGmf teleconference reminder - 16 Oct 2026
--- This message came from the IEEE 802.11 Task Group M Technical Reflector ---
Hello everyone,
Just wanted to send out a reminder that we will be holding a teleconference tomorrow from 10am - noon.
As announced earlier this month, we plan to run motions during the call on comment resolutions marked "Ready for Motion" between the last meeting of the September interim and the TGmf adhoc.
The agenda can be found here:
Cheers,
Mike
To unsubscribe from the STDS-802-11-TGM list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGM&A=1
To unsubscribe from the STDS-802-11-TGM list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGM&A=1
To unsubscribe from the STDS-802-11-TGM list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGM&A=1
To unsubscribe from the STDS-802-11-TGM list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGM&A=1