Thanks Eric for the detailed review, raised PR https://github.com/tireddy2/ikev2-pqc-auth/pull/42 to address them.
-Tiru On Tue, 7 Jul 2026 at 19:35, Eric Vyncke (evyncke) <evyncke= [email protected]> wrote: > # É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] >
_______________________________________________ IPsec mailing list -- [email protected] To unsubscribe send an email to [email protected]
