Hi Sarah, I see no more issues, thus I approve the publication.
Thank you for your work. Regards, Valery. > Hi Valery, > > My apologies! Thank you for catching that. > > 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 24, 2025, at 9:40 AM, Valery Smyslov <[email protected]> wrote: > > > > Hi Sarah, > > > > thank you for the update. > > > >> Hi Valery, > >> > >> Thank you for your reply. All 3 of your updates have been incorporated, as > >> they were all quite reasonable and > >> correct. Articles are quite tricky! > > > > Oh, indeed... > > > > > > The last (hopefully) remaining issue - while addressing the first update > > from the last message > > you accidentally deleted the sentence "This specification does not define > > any data that this notification > > may contain, so the Notification Data is left empty." (Section 3.1): > > > > CURRENT: > > 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. > > However, future extensions of this specification may make use of it. > > Implementations MUST ignore any data in the notification that they do > > not understand. > > > > Please, get it back :-) > > > > NEW (also partially OLD :-)): > > 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. > > This specification does not define any data that this notification > > may contain, so the Notification Data is left empty. > > However, future extensions of this specification may make use of it. > > Implementations MUST ignore any data in the notification that they do > > not understand. > > > > 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 24, 2025, at 2:53 AM, Valery Smyslov <[email protected]> wrote: > >>> > >>> 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]
