Charles Eckel has entered the following ballot position for draft-ietf-ipsecme-ikev2-mlkem-08: Discuss
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-mlkem/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I would like to DISCUSS a couple concerns I have with respect to normative language. Section 1.2, reads, "ML-KEM-768 and ML-KEM-1024 public key and ciphertext sizes can exceed the path MTU; these key exchanges could require more than one IP packet from both the initiator and the responder." Section 2.1 says, "Thus, implementation transporting IKE over UDP and not performing Path MTU (PMTU) discovery SHOULD NOT use ML-KEM-768 or ML-KEM-1024 in the IKE_SA_INIT exchange on networks where the PMTU is unknown or restricted." Why is this not a MUST? How does receiver handle if sender ignores the SHOULD? I suppose the latter depends on whether reassembly of the fragments succeeds or not. Is it worth saying something about this? I also support the DISCUSS by Mahesh on section 2.2. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks to Scott Fluhrer, the document shepherd, for his very helpful write-up, particularly the insights on IPR claims. Nits - Abstract, expand "SA" in "Child SA". - Section 2.1, s/fields inside it has meaning/fields inside it have meanings _______________________________________________ IPsec mailing list -- [email protected] To unsubscribe send an email to [email protected]
