Re: [STDS-802-11-TGBT] [STDS-802-11-TBGT] 11-26/1265r4 - text for Extended Length Element proposal

["Anirban Karmakar (akarmaka)" <00005e809b46533a-dmarc-request@xxxxxxxxxxxxxxxxx>]

Hi All,

Thank you for the comments and discussion.

I’ve uploaded r10 and after discussion with Jouni, the capability part has been left as it was in previous version (r8/r9).

The change that r10 bring is the removal of the fragmentable column from "Table 9-ZZZ”.

Hi Stephen,

Please consider 1265r10  for motion.

Regards

Anirban

From: Huang, Po-kai <po-kai.huang@xxxxxxxxx>
Date: Wednesday, 15 July 2026 at 07:49
To: Anirban Karmakar (akarmaka) <akarmaka@xxxxxxxxx>; STDS-802-11-TGBT@xxxxxxxxxxxxxxxxx <STDS-802-11-TGBT@xxxxxxxxxxxxxxxxx>
Subject: RE: [STDS-802-11-TGBT] [STDS-802-11-TBGT] 11-26/1265r4 - text for Extended Length Element proposal

Hi Anirban,

 

                Thanks. Looks good.

 

Only one more observation. The element is still listed as Fragmentable in the table, but in the normative texts we say it is not fragmentable. Hence, I think we need to change the fragmentable in the table to No. Beyond that, I think the document is good, and I will support.

 

 

 

Best,

Po-Kai

From: Anirban Karmakar (akarmaka) <akarmaka@xxxxxxxxx>
Sent: Wednesday, July 15, 2026 4:15 AM
To: Huang, Po-kai <po-kai.huang@xxxxxxxxx>; STDS-802-11-TGBT@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBT] [STDS-802-11-TBGT] 11-26/1265r4 - text for Extended Length Element proposal

 

Hi Po-Kai,

 

Yes, I’ve incorporated it. It was missed from r7. Please see r8.

 

thanks

Anirban

 

 

From: Huang, Po-kai <po-kai.huang@xxxxxxxxx>
Date: Wednesday, 15 July 2026 at 07:04
To: Anirban Karmakar (akarmaka) <akarmaka@xxxxxxxxx>; STDS-802-11-TGBT@xxxxxxxxxxxxxxxxx <STDS-802-11-TGBT@xxxxxxxxxxxxxxxxx>
Subject: RE: [STDS-802-11-TGBT] [STDS-802-11-TBGT] 11-26/1265r4 - text for Extended Length Element proposal

Hi Anirban,

 

                I sent you suggested edit last night, but I do not see it is incorporated, so I sent it here.

 

                I suggest to delete the following sentence as highlighted. It is not clear what it means for only in a context that is permitted. Say we have 100 management frame, does STA need to specifically add code to drop frame when the element is not permitted or doing parsing per frame? That does seem to introduce significant works.

 

 

Best,

Po-Kai

 

From: Anirban Karmakar (akarmaka) <00005e809b46533a-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Wednesday, July 15, 2026 3:54 AM
To: STDS-802-11-TGBT@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBT] [STDS-802-11-TBGT] 11-26/1265r4 - text for Extended Length Element proposal

 

Hi All,

1265r7 is uploaded addressing the comments listed in the thread below.

 

regards

Anirban

 

From: Anirban Karmakar (akarmaka) <00005e809b46533a-dmarc-request@xxxxxxxxxxxxxxxxx>
Date: Wednesday, 15 July 2026 at 06:50
To: STDS-802-11-TGBT@xxxxxxxxxxxxxxxxx <STDS-802-11-TGBT@xxxxxxxxxxxxxxxxx>
Subject: Re: [STDS-802-11-TGBT] [STDS-802-11-TBGT] 11-26/1265r4 - text for Extended Length Element proposal

HI All,

 

The extended capabilities and this line in added in 10.28.X.X stating

"Such a STA shall set the Extended Length Element Support field to 1 in any Extended Capabilities element that it transmits. “

 

The requirement to set the Extended Length Element Support field to 1 in any Extended Capabilities element that the STA transmits is for general capability advertisement in contexts where the Extended Capabilities element is present. It is not intended to be the gating mechanism for the PQC Authentication frame itself. 

 

regards

Anirban

 

From: Huang, Po-kai <po-kai.huang@xxxxxxxxx>
Date: Wednesday, 15 July 2026 at 06:32
To: STDS-802-11-TGBT@xxxxxxxxxxxxxxxxx <STDS-802-11-TGBT@xxxxxxxxxxxxxxxxx>
Subject: Re: [STDS-802-11-TGBT] [STDS-802-11-TBGT] 11-26/1265r4 - text for Extended Length Element proposal

Hi all,

        On the capability, my understanding is that text mandates all STA that use the PQC security profile/AKM to support this two byte length parsing. As a result, the capability is not really needed for PQC in the sense that if AP sees PQC AKM is selected in authentication frame, then AP knows that the client supports this new parsing. Similar, if client sees AP advertise PQC profile in Beacon or Probe Response, then client knows that the new parsing is supported. Hence, I think we do not need to include extended capabilities element in the authentication frame.

        The indicated capability maybe useful for other cases in the future since we define this as a generic mechanism. Hence, I can be ok to keep the capability bit.

Best,
Po-Kai

-----Original Message-----
From: Jouni Malinen <jkmalinen@xxxxxxxxx>
Sent: Tuesday, July 14, 2026 4:56 PM
To: STDS-802-11-TGBT@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBT] [STDS-802-11-TBGT] 11-26/1265r4 - text for Extended Length Element proposal

There is a mismatch in the temporary subclause number: 10.28.X.X in the reference vs. 10.28.XX in the title.

"an one or more" --> "one or more"

Redline in 12.7.2 has some unexpected deleted (strikethrough) "Extended Length" strings.

Is an Extended Length Element an instance of "an element"? I thought it would be, but this text seems to disagree: "An Extended Length Element is parsed according to 10.28.X.X (Extended Length Element
element) and is not interpreted as an element or as a KDE." I would delete the "and is not interpreted ... KDE" part.

"A STA that receives an Extended Length Element element in the Key Data field where it is not explicitly permitted by the corresponding EAPOL-Key PDU description shall silently discard the EAPOL-Key PDU."
feels like a requirement that would apply to all STAs, including ones that do not support Extended Length Elements. That feels wrong. Such shall discard requirement should be conditional on the STA supporting this mechanism.

Why the Extended Length Element ID 0 is reserved?

Table 9-ZZZ should be extended to include an "Extensible" column similarly to Table 9-164.

How can an AP send an Extended Length Element element in an Authentication frame when an Authentication frame does not include an Extended Capabilities element? The AP would not know whether the STA sending an Authentication frame supports this capability since the need capability indication is not present in that frame.. In other words, this would need the Authentication frame format be extended at least for the PQC cases, but ideally, for all cases, to optionally allow an Extended Capabilities element.

- Jouni

On Tue, Jul 14, 2026 at 1:39 PM Anirban Karmakar (akarmaka) <00005e809b46533a-dmarc-request@xxxxxxxxxxxxxxxxx> wrote:
>
> Dear All,
>
> I’ve posted the updated version of the Extended Length element, normative text document.
> Please let me know your feedback.
>
> regards
> Anirban
> ________________________________
>
> To unsubscribe from the STDS-802-11-TGBT list, click the following
> link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBT&A=1

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

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

---

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

---

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

---

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