Hi Sarah, > Hi Valery, > > The double "with" doesn't ring any editorial alarm bells for me, so I updated > to "If the responder is configured with a > PPK with an ID".
Fine! > And we will make a note about this draft and draft-ietf-ipsecme-g-ikev2-23 > being published together, with each > others' RFC numbers. That shouldn't need a cluster construction. Excellent, thank you! > Please review the document carefully to ensure satisfaction as we do not make > changes once it has been > published as an RFC. Contact us with any further updates or with your > approval of the document in its current > form. I re-read the document and I found a couple of issues. 1) You expanded "SPI" on first use in the following text (Section 3.1). CURRENT: The USE_PPK_INT is a Status Type IKEv2 notification. Its Notify Message Type is 16445; the Protocol ID and Security Parameter Index (SPI) Size are both set to 0. The problem with this is that "SPI Size" is the name of the field in the Notify payload (defined in Section 3.10 of RFC 7296), thus this expansion makes the text incorrect. I propose the following change: NEW: The USE_PPK_INT is a Status Type IKEv2 notification. Its Notify Message Type is 16445; the Protocol ID is set to 0; the Security Parameter Index (SPI) is absent, so the SPI Size is set to 0 too. 2) Later in the same section (3.1). CURRENT: The PPK_IDENTITY_KEY is a Status Type IKEv2 notification. Its Notify Message Type is 16446; the Protocol ID and SPI Size fields are both set to 0. Since SPI Size is the name of the field, should not it be prepended with "the"? Please disregard if this is not needed. NEW (perhaps): The PPK_IDENTITY_KEY is a Status Type IKEv2 notification. Its Notify Message Type is 16446; the Protocol ID and the SPI Size fields are both set to 0. 3) Very minor issue (or perhaps not an issue at all). Comparing the following pieces of text: 1. If the responder is configured with a PPK with an ID that is... If the responder does not support (or is not configured for) using PPKs in the CREATE_CHILD_SA exchange or does not have a PPK with an ID that matches... If using PPKs in CREATE_CHILD_SA is mandatory for the responder, and the initiator does not include any PPK_IDENTITY_KEY notifications in the request, or if the responder does not have a PPK with an ID that matches... with this piece of text: 2. If the responder does not have a PPK with ID that matches... I noticed that the former three use "a PPK with an ID" and the latter uses "a PPK with ID" (no article in front of ID). Is this distinction correct? Should not all the instances be the same (either with or without "an")? Sorry, using articles has been always a bit of problem for me :-). Regards, Valery. > The updated files have been posted here (please refresh): > https://www.rfc-editor.org/authors/rfc9867.txt > https://www.rfc-editor.org/authors/rfc9867.pdf > https://www.rfc-editor.org/authors/rfc9867.html > https://www.rfc-editor.org/authors/rfc9867.xml > > The relevant diff files have been posted here (please refresh): > https://www.rfc-editor.org/authors/rfc9867-diff.html (comprehensive diff) > https://www.rfc-editor.org/authors/rfc9867-auth48diff.html (AUTH48 changes > only) > > Note that it may be necessary for you to refresh your browser to view the > most recent version. > > For the AUTH48 status of this document, please see: > https://www.rfc-editor.org/auth48/rfc9867 > > Thank you, > Sarah Tarrant > RFC Production Center > > > On Sep 23, 2025, at 9:27 AM, Valery Smyslov <[email protected]> wrote: > > > >> If the responder is configured with a PPK -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
