Hi Hyung-Nam,
Thanks for the careful check. I have fixed them and revised the document to r2 on Mentor.
Hi Dan,
Thanks for your comments, see my response below.
Best Regards,
Bo Cao
Original
From: Harkins,Dan <daniel.harkins@xxxxxxx>
To: Hyung-Nam Choi5 <hchoi5@xxxxxxxxxx>;STDS-802-11-TGBT@xxxxxxxxxxxxxxxxx <STDS-802-11-TGBT@xxxxxxxxxxxxxxxxx>;曹博10345817;
Date: 2026年09月17日 09:48
Subject: Re: [STDS-802-11-TGBT] LB297 CR for 4WHS-Review and Editorial CIDs
Hi Bo,
If you’re updating this presentation then can you also do the following please?
- In 12.7.6.2.4 the changed text goes under the heading “Key Data = "" and so what the dashed entries should start with is the thing there followed by the condition. For instance, there is an existing line that says “An OCI KDE, if dot11RSNAOperatingChannelValidationActivated is true on the Supplicant”. That’s the right order. So please change your new text to “A PQC Parameter element for PTK rekeying if the AKM is AKM 00-0F-AC:31 or AKM 00-0F-AC:32”. This change should also be made to 12.7.6.3.4, page 9 line 4 of your submission.
The condition-first order in my submission comes from CID 653, which explicitly asked to move the condition to the front, citing the latest REVmf draft.
I checked the baseline, and both orders actually exist. For example, there is a condition-first entry:
"(#421) If dot11MultibandImplemented is true and ... , the RSNE and Multi-band element(s) for generating a different PTK for each involved band."
as well as the item-first entry you quoted:
"(#421) An OCI KDE, if dot11RSNAOperatingChannelValidationActivated is true on the Supplicant."
I have no preference on the order itself — I will follow the group's opinion.
Given that the baseline itself is inconsistent, I think it would be better to first unify the overall style within REVmf, then TGbt can simply align with it.
- On page 8 line 7-8 of your submission it says to “…include the ephemeral public key in the PQC Parameter element.” That is ambiguous as the method of “inclusion” is not mentioned. If you look at the baseline where similar public key operations are made you will see language about how this key gets encoded. So can you change your text to say, “…derive the corresponding ephemeral public key from the private key, and encode the public key in the PQC Parameter element according to the element to octet string conversion rules in 12.4.7.2.4.” This change should also be done on page 8 line 35 of your submission where the response is generated. Encode that public key according to the appropriate conversion rules.
- Similar to #2 it says, “…and include the ephemeral encapsulation key in the PQC Parameter element.” That is also ambiguous but given that the encapsulation key should not require explicit encoding rules the way an ECC public key does I think it might be better to just say “…and copy the ephemeral encapsulation key into the PQC Parameter element.” This change should also be made to page 8 lines 37 and 38 of your submission where you “include” the ciphertext. Just say you “Copy the ciphertext into the PQC Parameter element.”
I understand your concern that "include" does not say how the key is carried in the PQC Parameter element.
However, this is beyond the CIDs in this CR document. As there are many such places in the draft, changing only the ones in this CR would make the Draft inconsistent. I suggest use a new comment to update this style across the whole draft. I'm happy to follow the group's opinion and help prepare the new CR.
Thanks,
Dan.
--
“the object of life is not to be on the side of the majority, but to
escape finding oneself in the ranks of the insane.” – Marcus Aurelius
Dear Bo,
I want to come back to your revised 1863r1. Before it will go to Motion today, can you please fix the following two editorial issues for consistency reasons:
1. 12.7.6.2, page 8: comma should be deleted and word “General” should be set in brackets.
2. 12.7.6.3, page 9: term “AKM” should be added for 00-0F-AC:32.
BR
Hyung-Nam / Lenovo
From: Bo Cao <cao.bo4@xxxxxxxxxx>
Sent: Wednesday, September 16, 2026 3:32 AM
To: STDS-802-11-TGBT@xxxxxxxxxxxxxxxxx
Subject: [External] [STDS-802-11-TGBT] LB297 CR for 4WHS-Review and Editorial CIDs
Sent: Wednesday, September 16, 2026 3:32 AM
To: STDS-802-11-TGBT@xxxxxxxxxxxxxxxxx
Subject: [External] [STDS-802-11-TGBT] LB297 CR for 4WHS-Review and Editorial CIDs
Hi All,
The 4WHS-Review and Editorial CIDs assigned to me (19 CIDs) have been addressed in https://mentor.ieee.org/802.11/dcn/26/11-26-1863-00-00bt-lb297-cr-4whs-review-and-editorial-part.docx. Comments are welcome.
Hi Stephen,
Could you please add this submission to the agenda of the Wednesday or Thursday session?
Thank you!
Best Regards,
Bo Cao (ZTE)
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