Hello Youhan,
Yes, I think non-HT PPDUs are irrelevant.
I see your point re the various other flavours of PPDU.
However, since the cross-reference is specifically to "as described in 10.12.6 (A-MPDU padding for VHT, HE, EHT or S1G PPDU(#11be))"
I think the current proposal in the database to:
Delete "in a (#11be)VHT, HE or EHT PPDU" at the cited location.
is OK, because we'll end up with:
Set to 1 in an A-MPDU subframe that has 0 in the MPDU Length field and that is used to pad the A-MPDU as described in 10.12.6 (A-MPDU padding
for VHT, HE, EHT or S1G PPDU(#11be)).
and that's fine because 10.12.6 does not allow for padding of DMG
or whatever PPDUs.
We still have some risk of spec rot because of 10.12.6 itself, but it's
smaller (headlines are more easily caught for updating than text buried
somewhere) so there's been an improvement.
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: Youhan Kim <youhank@xxxxxxxxxxxxxxxx>
Sent: Thursday, 15 October 2026 22:35
To: Mark Rison <m.rison@xxxxxxxxxxx>; STDS-802-11-TGM@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGM] TGmf teleconference reminder - 16 Oct 2026
Thanks, Mark.
I am not opposed to that general direction, but some questions.
- What about Non-HT PPDU?
- I presume leaving out Non-HT PPDU is fine as it does not support A-MPDU, but bringing it up here in case others have different opinion
- What about DMG, EDMG, CMMG, NGV, etc. PPDUs?
- I really don't know the answer for these PPDUs. What is clear is that the current text does not seem to apply to these PPDUs, while the potential new direction
probably includes these PPDUs as well, and hence would be a technical change?
Regards,
Youhan
From: Mark Rison <m.rison@xxxxxxxxxxx>
Sent: Thursday, October 15, 2026 2:29 PM
To: Youhan Kim <youhank@xxxxxxxxxxxxxxxx>;
STDS-802-11-TGM@xxxxxxxxxxxxxxxxx <STDS-802-11-TGM@xxxxxxxxxxxxxxxxx>
Subject: RE: [STDS-802-11-TGM] TGmf teleconference reminder - 16 Oct 2026
WARNING:
This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.
Hello Youhan,
I think the point here was to avoid spec rot, e.g. TGbn/TGbx forgetting
to add UHR/WIN PPDUs to the list.
So how about "… in a PPDU that is not an HT PPDU"?
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: Youhan Kim <00002b3ff331b292-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Thursday, 15 October 2026 22:23
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 ---
Hi, Mike.
Sorry but one more.
I would suggest the following alternate resolution to CID 2160.
|
REVISED At REVmf D3.1 P2208L48, change "pad the A-MPDU in a VHT, HE or EHT PPDU" to "pad the A-MPDU in a VHT, HE, S1G or EHT PPDU" |
(Or ACCEPTED is also fine if the Editor is fine with the instruction from the commenter.)
Reason:
S-MPDU is not allowed in HT PPDUs.
However, the current proposed resolution (delete "in a VHT, HE or EHT PPDU") could be confused to mean that S-MPDU is allowed in HT PPDUs.
Thanks,
Youhan
From: Youhan Kim <youhank@xxxxxxxxxxxxxxxx>
Sent: Thursday, October 15, 2026 1:09 PM
To: STDS-802-11-TGM@xxxxxxxxxxxxxxxxx <STDS-802-11-TGM@xxxxxxxxxxxxxxxxx>; M Montemurro <montemurro.michael@xxxxxxxxx>
Subject: Re: [STDS-802-11-TGM] TGmf teleconference reminder - 16 Oct 2026
Thank you, Mike and Mark.
Mike,
Sorry for the typo. The CIDs missing resolution are 2441, 2442, 2443, 2444, 2445,
4664
2447.
And thanks for reassigning 2485 and 2486 to me.
Mark,
Yes, I saw the sentence in
9.3.19.1 (D3.0 p790), but it is pretty far away from the individual NDPA frame format subsections - for example, the EHT NDPA is on D3.0 p798. So, it's just easier for the readers to be able to get the info right there, at least a pointer.
Thanks,
Youhan
From: M Montemurro <montemurro.michael@xxxxxxxxx>
Sent: Thursday, October 15, 2026 12:50 PM
To: STDS-802-11-TGM@xxxxxxxxxxxxxxxxx <STDS-802-11-TGM@xxxxxxxxxxxxxxxxx>
Subject: Re: [STDS-802-11-TGM] TGmf teleconference reminder - 16 Oct 2026
WARNING:
This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.
--- This message came from the IEEE 802.11 Task Group M Technical Reflector ---
Sorry. Hit send too soon. We will discuss tomorrow during the meeting, but we will assign CIDs 2485 and 2486 to you.
Cheers,
Mike
On Thu, Oct 15, 2026 at 3:32 PM M Montemurro <montemurro.michael@xxxxxxxxx> wrote:
Hi Youhan,
Thanks for your review, I will adjust the motions accordingly.
By the way, when you mentioned CID 4664? What did you mean?
Cheers,
Mike
On Thu, Oct 15, 2026 at 3:24 PM Youhan Kim <youhank@xxxxxxxxxxxxxxxx> wrote:
Thank you very much Mike.
Sorry but I have a few requests/feedback on the motion.
First, I would like to propose an alternate resolution to CIDs 2581 and 2417 (under Motion Oct A).
REVISED
At REVmf D3.1 P792L11, change
"The NDP Announcement Variant subfield is set to 2 to identify the frame as an HE NDP Announcement
frame."to
"The NDP Announcement Variant subfield is set as defined in Table 9-48 (NDP Announcement frame variant encoding)."
At REVmf D3.1 P795L24, change
"The NDP Announcement Variant subfield is set to 1 to identify the frame as an Ranging NDP
Announcement frame."to
"The NDP Announcement Variant subfield is set as defined in Table 9-48 (NDP Announcement frame variant encoding)."
At REVmf D3.1 P798L1, change
"The NDP Announcement Variant subfield is set to 3 to identify the frame as an EHT NDP Announcement
frame."to
"The NDP Announcement Variant subfield is set as defined in Table 9-48 (NDP Announcement frame variant encoding)."
Reason: It is still helpful for the readers to know what value should be populated in the NDP Announcement Variant subfield within the respective NDPA variant subsections. If writing the exact value is the concern (because it is duplicative of Table 9-48), then I believe a more proper fix is to refer to the table rather than deleting the entire sentence.
Second, I would like to request to defer motion on CIDs 2485 and 2486 (Motion Oct A) as I would like to investigate the history on why we specifically called out Trigger frames that are not MU-RTS in the cited locations.
Lastly, CIDs 2441, 2442, 2443, 2444, 2445, 4664 (Motion Oct A) seem to lack resolution (Accept/Revised/Reject) in https://mentor.ieee.org/802.11/dcn/26/11-26-2018-00-000m-revmf-motion-comments-16oct26.xlsx
Thanks,
Youhan
From: M Montemurro <montemurro.michael@xxxxxxxxx>
Sent: Thursday, October 15, 2026 11:04 AM
To: STDS-802-11-TGM@xxxxxxxxxxxxxxxxx <STDS-802-11-TGM@xxxxxxxxxxxxxxxxx>
Subject: [STDS-802-11-TGM] TGmf teleconference reminder - 16 Oct 2026
WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.
--- 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