Re: [STDS-802-11-TGBN] LB291 - CR for 9.4.2.355 MAPC element

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

Hi Jay, Abhi, Chaoming, Giovanni, Xiangxin, all

Thanks for the comments and suggestions.

Let me clarify and summarize the issue raised by Jay:

The cited sentence is added as a response for CID7797 which clearly ask to add a description for the Fragment subelement format that is used as part of MAPC element.
The added paragraph (pointed by Jay) is fully aligned with the main concept described in 35.3.3.7 (Subelement fragmentation in the Link Info field of a Multi-Link element): “If the length of the contents of a Per-STA Profile subelement for a reported STA exceeds 255 octets, the transmitting STA shall fragment the contents across a series of subelements consisting of the Per-STA Profile subelement, immediately followed by one or more Fragment subelements as illustrated in Figure 35-3 (Per-STA Profile subelement fragmentation) “.
Please note that the cited sentence exactly follow this guideline, specifying : “One or more Fragment subelements are present if the contents of a subelement exceed 255 octets. “
The cited paragraph is not aiming (as the CID 7797 is not asking it) to describe the entire method of Per-Scheme Profile subelement fragmentation (whereas CID11989, submitted by Abhi does) – therefore such normative behavior rules are expected in the submission to be provided by Mahmoud Hasabelnaby (currently assigned for this CID), not in this CR doc.
I also agree with Abhi’s argument that even if the MAPC security subelement is taken out from the MAPC element (as done in Mike’s proposal – 26/424), we still may face the need for Per-Scheme Profile subelement fragmentation in some specific cases (such as: Co-RTWT agreement in MBSSID set), so the problem needs to be resolved, but not in 26/410.
As such, I do not see any need to make any changes in the resolution of 7797.

Your further comments (if any) is highly appreciated.

Regards,

Arik

From: Abhishek Patil <appatil@xxxxxxxxxxxxxxxx>
Sent: שבת 28 פברואר 2026 01:06
To: yang.zhijie@xxxxxxxxxx; luochaoming@xxxxxxxx
Cc: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx; Arik Klein <arik.klein@xxxxxxxxxx>
Subject: RE: [STDS-802-11-TGBN] LB291 - CR for 9.4.2.355 MAPC element

Hi Jay,

Please sync up with Mike. He has prepared a document on MAPC security, which has been shared with you. In that document, he removed the security profile from the MAPC element. However, the MAPC element contains other subelements that may need to be fragmented if its total size exceeds 254 bytes. Therefore, removing the security profile subelement from MAPC element does not mean that we no longer need the procedure in 35.3.3.7.

Regards,

Abhi

From: yang.zhijie@xxxxxxxxxx <yang.zhijie@xxxxxxxxxx>
Sent: Thursday, February 26, 2026 7:45 PM
To: luochaoming@xxxxxxxx
Cc: Abhishek Patil <appatil@xxxxxxxxxxxxxxxx>; STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx; arik.klein@xxxxxxxxxx
Subject: Re: [STDS-802-11-TGBN] LB291 - CR for 9.4.2.355 MAPC element

WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.

Hi Chaoming,

Good point. Following your suggestion, I will make it in 25/1860, otherwise, we need to define three levels MAPC fragments.

Once it's done, I will share it to the group.

But two level MAPC fragments is still needed as Per-scheme Profile may exceed 255 octets.

Thanks

Best Regards

Jay Yang (杨志杰)

Original

From: 罗朝明(ChaomingLuo) <luochaoming@xxxxxxxx>

To: Abhishek Patil <appatil@xxxxxxxxxxxxxxxx>;STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx <STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx>;杨志杰10343608;arik.klein@xxxxxxxxxx <arik.klein@xxxxxxxxxx>;

Date: 2026年02月27日 11:24

Subject: RE: [STDS-802-11-TGBN] LB291 - CR for 9.4.2.355 MAPC element

Hi Guys,

Why not take the Security Profile out of the MAPC element and put it as a new element directly in the frame body? So that we don’t bother have multiple levels of fragmentation.

BR,

Chaoming

From: Abhishek Patil <0000297b717f2a04-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: 2026年2月27日 11:13
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBN] LB291 - CR for 9.4.2.355 MAPC element

Hi Jay, Arik,

I have a comment on this topic. Perhaps you could use that to provide guidance on the second level fragmentation (similar to MLE):

11989

Abhishek Patil

9.4.2.aa3.2.1

132.27

Provide the rules for fragmentation - see 35.3.3.7 as an example

As in comment

Regards,

Abhi

From: Jay Yang <yang.zhijie@xxxxxxxxxx>
Sent: Thursday, February 26, 2026 6:07 AM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBN] LB291 - CR for 9.4.2.355 MAPC element

WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.

Hi Arik,

Thanks for your contribution.

Regarding the following proposed text in your contribution. I don't believe it work at all.

(#7797) One or more Fragment subelements are present if the contents of a subelement exceed 255 octets. The format of Fragment subelement is the same as that of Fragment element (see 9.4.2.187) except that Element ID field is replaced with Subelement ID field.

In general, we need two levels fragments, one is MPAC element level, the second level is per-scheme profile. You can refer to prepare the text following the similar design in baseline 35.3.3.7 Subelement fragmentation in the Link Info field of a Multi-Link element

Thanks

Best Regards

Jay Yang (杨志杰)

Original

From: ArikKlein <0000177967a59511-dmarc-request@xxxxxxxxxxxxxxxxx>

To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx <STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx>;

Date: 2026年02月23日 07:09

Subject: [STDS-802-11-TGBN] LB291 - CR for 9.4.2.355 MAPC element

Hi all / MAPC TTTs

I’ve uploaded 11-26/0410r0 (29 CIDs) on the mentor.

Your review and comments are highly appreciated.

Regards,

Arik

To unsubscribe from the STDS-802-11-TGBN list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBN&A=1