All, We have now received all necessary approvals and consider AUTH48 complete: https://www.rfc-editor.org/auth48/rfc9867
Thank you for your attention and guidance during the AUTH48 process. We will move this document forward in the publication process at this time (with RFC-to-be 9838: draft-ietf-ipsecme-g-ikev2-23). Sincerely, Sarah Tarrant RFC Production Center > On Sep 24, 2025, at 10:23 AM, Valery Smyslov <[email protected]> wrote: > > 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]
