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

Re: [STDS-802-11-TGM] TGmf teleconference reminder - 16 Oct 2026



--- This message came from the IEEE 802.11 Task Group M Technical Reflector ---
HI Mark and all, 

Here are my updates:
CID 2279 - Will run as a separate motion
CID 2368 - Resolution has been updated in 11-26/2018r2 with the correct CID number
CID 2399 - Resolution has been updated to point to 11-26/1633r12  with the updated note.
CID 2073 - During the discussion, it was clear that a LF was missing and the editor understood the change
CID 2333 - As long as the Editor notes the font change. No reason to pull
CID 2355 - Resolution has been updated in 11-26/2018r2 with the proposed updated text.
CID 2406 - Resolution has been updated in 11-26/2018r2 with a note to editor.
CID 2499, 2500 - No change. When the resolution was discussed when the CID was reviewed, it was clear that the commenter identified the global change with individual comments.
CID 2587 - Resolution has been updated in 11-26/2018r2 with the suggested changes
CID 2694 - The comment does not ask to add another list item, just a subject of the phrase.
CID 2076 - Resolution has been updated in 11-26/2018r2 as suggested
CID 2371 - It's a separate motion on a withdrawn comment

CID 2160 - Separate motion with Youhan's suggested resolution.

Cheers,

Mike



On Thu, Oct 15, 2026 at 5:46 PM Mark Rison <m.rison@xxxxxxxxxxx> wrote:

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 2399

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
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