# Éric Vyncke, INT AD, AD review for draft-ietf-ipsecme-ikev2-pqc-auth-08 CC @evyncke
Thank you for the work put into this well-written and easy-to-read document; even as INT AD, IPsec was always close to my mind and I am happy to take over the responsibility of this draft to relieve Deb Cooley's workload. Please find below my AD review. As the new responsible AD, I expect all the points below to be addressed, either by a revised I-D, or an email reply. Of course, authors and WG can reject my points, but this needs to be justified. Once all the points are addressed, I will proceed with the publication process, i.e., IETF Last Call. Special thanks to Tero Kivinen for the shepherd's write-up including the WG consensus *and* the justification of the intended status. I have read it and have no comment about it. I hope that this review helps to improve the document, Regards, -éric Note: this AD reviews follows the Markdown syntax of https://github.com/mnot/ietf-comments/tree/main, i.e., they can be processed by a tool to create github issues. ### Abstract and section 8: NIST Please use "US NIST" rather than "NIST" (as "national" is ambiguous without a country association). Like done in section 1. ### Abstract IKEv2 expansion Please expand IKEv2 at first use (and not at the 2nd one). ### draft-ietf-pquip-pqc-engineers is now RFC 9958 Please update the reference draft-ietf-pquip-pqc-engineers to use the published RFC 9958. ### Section 3.1 and RNG The acronym RNG is never used in the rest of the draft, so, remove it. ### Section 3.2.1 and SHOULD Suggest using a BCP14 "MUST" in `this specification SHOULD implement` as it is followed by "unless" restricting the scope of the SHOULD/MUST. ### Section 3.2.1 and IANA Please add an informational reference (URL) to `defined in the IANA "IKEv2 Hash Algorithms" registry` ### Section 3.2.1 No need to reply as it is a mere compliment to rightfully talk about MTU (after all, I am a INT AD). ### Section 3.3 Unsure why, but the TXT and HTML renderings have a weird formatting for `Certificate Request Payload: One method to ascertain that the key pair type the initiator wants` ### Section 3.3: PQC PQC acronym has already been expanded in `post-quantum cryptographic (PQC)`, no need to re-expand it here ;-) ### Section 4: MLWE As the `MLWE` acronym is never used, there is no need to introduce it. ### Section 4: FS schemes Please explain (or add an informational reference) to `FS schemes`. ### Section 4: table 2 in Section 10 Please double check whether the reference to `table 2 in Section 10` is still correct or change `security categories` into "PQ Security Level" to be consistent with RFC 9958. ### Section 5; XMSS and HSS/LMS Yes, I do not like unexpanded acronyms... so please expand XMSS and HSS/LMS. ### Section 5: at the time of writing this document s/at the time of writing this document/2026/ ### Normative reference Please prefix "NIST" with "US" per my previous comment. ## Non-critical / cosmetic issues Note: these points must also be addressed. ### Section 3.1 Using singular "is" in `If protection against side-channel attacks *are* required`
_______________________________________________ IPsec mailing list -- [email protected] To unsubscribe send an email to [email protected]
