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? - 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. - RFC9370 is listed as Informative reference, but I think should be Normative (it is an Standard track RFC). ## Nits - The acronym for Security Association (SA) is expanded in the abstract after first occurrence. Please, expand it the first time SA is used. - 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 - I would recommend to expand the forms like doesn't (does not), wouldn't (would not), etc. - 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 - Section 2: s/reffered/referred - 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. - Appendix A title: Comparison of this Specification with RFC8784. - Appendix A. s/replacement for use PPKs/replacement for using PPKs - Appendix A. s/where use PPKs in IKE_AUTH suffices/where using PPKs in IKE_AUTH suffices Thanks, best reagards, Luis _______________________________________________ IPsec mailing list -- ipsec@ietf.org To unsubscribe send an email to ipsec-le...@ietf.org
