Hello Tiru and other authors,

Thanks for the PR, I have reviewed it and it addresses all of the points in my 
AD review.

Please submit via email to [email protected] with the XML and with me in copy. I 
will then approve the publication as this I-D is now within the IESG and won't 
be presented at the IPSEC WG session in Vienna, i.e., the cut-off date is not 
really relevant in this case. (Tero and Yoav, please let me know if this draft 
is on the agenda).

Regards,

-éric


From: tirumal reddy <[email protected]>
Date: Friday, 10 July 2026 at 07:25
To: Eric Vyncke (evyncke) <[email protected]>
Cc: [email protected] <[email protected]>
Subject: Re: [IPsec] AD review for draft-ietf-ipsecme-ikev2-pqc-auth-08

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) 
<[email protected]<mailto:[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]<mailto:[email protected]>
To unsubscribe send an email to 
[email protected]<mailto:[email protected]>
_______________________________________________
IPsec mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to