Post-quantum Key Exchange with ML-KEM in the Internet Key Exchange Protocol Version 2 (IKEv2)
draft-ietf-ipsecme-ikev2-mlkem-09

Thank you for addressing my comments. 
As for my DISCUSS, I found your more detailed explanation very helpful and believe others reading this document would as well, but perhaps the WG already debated this point and the current text was viewed as being sufficiently clear without being unnecessarily prescriptive.

The draft already provides justification for the SHOULD NOT. I will clear my DISCUSS and leave it to you to decide whether or not adding the more detailed justification is helpful.

Thanks to Scott F. for the nice shepherd's write up.

Thanks for the concise draft; it's also appreciated that it adds PQC into a flexible framework, that's easier!!

I just have one comment and it should be a simple (trivial even) fix:

* It would be really helpful if at the end of the opening paragraph of section 1, something like the following was added: “The following terms KEi, KEr, … are used as defined in RFC7296”

Thanks for addressing my previous blocking DISCUSS position: https://mailarchive.ietf.org/arch/msg/ipsec/ZSZfRgeweHS7J5oxIkUSDSmUbNA/

All is good now and thanks for the work done.

Thanks for submitting this document to the IESG, I do not see transport protocol concerns.

Please see the transport area review by Kyle Rose, I encourage the editors to address the issues raised:
review-ietf-ipsecme-ikev2-mlkem-05-tsvart-lc-rose-2026-06-08-00

Gorry

Thanks to the authors and the WG for their work on this document.

I have one question and one comment that I would like to share for your consideration.

1) section 1.1 - the following two statements seem somewhat contradicting?

".. or in some rare cases a distinguished error value."
"Note that ML-KEM's Decaps routine uses implicit rejection and will not return a distinguished error value."

2) IANA Considerations - This is a minor thing; I believe these values are already allocated by IANA and only this document references needs to be update to RFC-TBD? If so, please consider updating the text that way.

Thanks for addressing my DISCUSS and COMMENTs.

# IESG review of draft-ietf-ipsecme-ikev2-mlkem-07

CC @MikeBishop

## Comments

### "Abstract", paragraph 1
```
     specifies how to use ML-KEM by itself or as an additional key
     exchange in IKEv2 along with a traditional key exchange.  These
```
Given that both options are "in IKEv2", this could be reworded for clarity.
Perhaps "specifies how to use ML-KEM as a key exchange in IKEv2, either by
itself or alongside a traditional key exchange."?

### Section 2, paragraph 1

It might be worth being more explicit here that [RFC9370] already
defines arbitrary "hybrid" key exchanges, so all that's needed is to have the PQ
algorithm assigned a codepoint.

### Section 3, paragraph 7
```
     out-of-band that a responder supports ML-KEM, it SHOULD only include
     proposals for ML-KEM or abort the negotiation if the responder
```
This could be read as recommending only non-hybrid proposals, which I think is
not the intent.

### Inclusive language

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

 * Term `man`; alternatives might be `individual`, `people`, `person`

## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### Typos

#### Section 1, paragraph 1
```
-    communications in the future after a CRQC became available to them
-    which is also known as a 'harvest-now-decrypt-later' attack.  Such
-   --------------
+    communications in the future after a CRQC became available to them,
+                                                                      +
```

#### Section 1, paragraph 3
```
-    algorithms, another use of a PQ/T Hybrid key exchanges in IKEv2 is to
-                              --
```

### Section 2.1, paragraph 8
```
     ciphertext size for this ML-KEM parameter may not push the UDP packet
```
Is this to be understood as "might not (but also might)" or as "cannot" / "do not"?

### Section 3, paragraph 6

Consider "IKEv2 downgrades are" or "IKEv2's vulnerability to downgrades is"

### Grammar/style

#### Section 1.1, paragraph 3
```
turn a distinguished error value. Instead it will always produce an ss value
                                  ^^^^^^^
```
A comma may be missing after the conjunctive/linking adverb "Instead".

#### Section 3, paragraph 7
```
t an IKE_INTERMEDIATE exchange. Subsequently the peers can rekey the initial 
                                ^^^^^^^^^^^^
```
A comma may be missing after the conjunctive/linking adverb "Subsequently".

Thank you to Paul Kyzivat for the GENART review.

I support Charles' DISCUSS on the existing SHOULD leaving an interop ambiguity. Otherwise I have no additional concerns.