Hi Luis, thank you for your review.
> -----Original Message----- > From: Luis Contreras via Datatracker <nore...@ietf.org> > Sent: Wednesday, April 2, 2025 12:02 AM > To: ops-...@ietf.org > Cc: draft-ietf-ipsecme-ikev2-qr-alt....@ietf.org; ipsec@ietf.org; > last-c...@ietf.org > Subject: Opsdir last call review of draft-ietf-ipsecme-ikev2-qr-alt-07 > > Reviewer: Luis Contreras > Review result: Has Nits > > I have reviewed this document as part of the Operational Directorate's ongoing > effort to review all IETF documents being processed by the IESG. These > comments were written to improve the operational aspects of the IETF drafts. > Comments that are not addressed in the last call may be included in AD reviews > during the IESG review. Document editors and WG chairs should treat these > comments just like any other last-call comments. > > ## Minor > > - Appendix A, bullet 4. I guess AUTH should be IKE_AUTH, right? No. In IKEv2 we have exchanges, and messages that are sent in these exchanges have payloads. IKE_AUTH is the name of exchange, while AUTH here is the name of one of payloads. > - I would recommend to use <TBA-1 by IANA> for USE_PPK_INT in the text, and > similarly <TBA-2 by IANA> for PPK_IDENTITY_KEY, and later on reference to > <TBA-1 by IANA> and <TBA-2 by IANA> in section 5 for clarity. Done. > - RFC9370 is listed > as Informative reference, but I think should be Normative (it is an Standard > track > RFC). I disagree.. Implementers need not to read RFC 9370 to implement this draft. > ## Nits > > - The acronym for Security Association (SA) is expanded in the abstract after > first > occurrence. Please, expand it the first time SA is used. Done. > - In Intro: s/that it is the IPsec traffic that mostly needs protecting/that > it is the IPsec traffic > the one that mostly needs to be protected Done. > - I would recommend to expand the > forms like doesn't (does not), wouldn't (would not), etc. Done. > - In Intro: s/and for rekey of IKE and IPsec SAs/and for rekeying of IKE and > IPsec SAs, > or alternatively /and for the rekey of IKE and IPsec SAs Done. > - Section 2: s/reffered/referred Fixed. > - Not all the message illustrations are numbered (for instance, > those in Section 3.2). Please, follow the same criteria in all of them, and if > numbered, please, be sure that all are numbered. While I agree with you in general, there is a long practice in the IPSECME WG that short pictures describing single IKEv2 exchanges are inlined in the text with no captions. Larger pictures have captions and are numbered. For now I'd leave numbering as is. > - Appendix A title: Comparison of this Specification with RFC8784. Fixed. > - Appendix A. s/replacement for use PPKs/replacement for using PPKs Fixed. > - Appendix A. s/where use PPKs in IKE_AUTH suffices/where using PPKs in > IKE_AUTH suffices Fixed. Thank you again for careful review. Regards, Valery. > Thanks, best reagards, > > Luis > _______________________________________________ IPsec mailing list -- ipsec@ietf.org To unsubscribe send an email to ipsec-le...@ietf.org
