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 |
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 |
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 |
The 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 |
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, |
change the may requirement to shall when the FTR does not recevie reassociation reqeust within the deadline. |
REVISED |
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 |
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 |
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 |
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 |
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