Re: [auth48] AUTH48: RFC-to-be 9370 <draft-ietf-ipsecme-ikev2-multiple-ke-12> for your review

[Valery Smyslov <[e-mail]>]

Hi Megan,

thank you, I have no more niggles to the text of the document 😊

However. while doing a final sanity check of the xml file, I failed to find
any keyword that we asked to add there at the very beginning of AUTH48 process.
Perhaps they get lost in the editing loop. Or am I missing something?

For convenience, the following keywords were asked to be added:

post-quantum
PQC
hybrid

(message from 28 February)

hybridization
hybrid key exchange
key encapsulation
quantum
quantum-safe
KEM
PQ

(message from 9 March)

Can we please get them back in the xml? 😊

Regards,
Valery.


> -----Original Message-----
> From: Megan Ferguson <[e-mail]>
> Sent: 17 мая 2023 г. 22:12
> To: Valery Smyslov <[e-mail]>
> Cc: Scott Fluhrer (sfluhrer) <[e-mail]>; [e-mail];
> Roman Danyliw <[e-mail]>; Garcia Morchon O, Oscar <oscar.garcia-
> [e-mail]>; [e-mail]; Tero Kivinen
> <[e-mail]>; [e-mail]; [e-mail]; Graham
> Bartlett <[e-mail]>; [e-mail]; cjt@post-
> quantum.com; [e-mail]
> Subject: Re: AUTH48: RFC-to-be 9370 <draft-ietf-ipsecme-ikev2-multiple-ke-12>
> for your review
> 
> Hi Valery,
> 
> Got it!
> 
> The files have been posted here:
>  https://www.rfc-editor.org/authors/rfc9370.txt
>  https://www.rfc-editor.org/authors/rfc9370.pdf
>  https://www.rfc-editor.org/authors/rfc9370.html
>  https://www.rfc-editor.org/authors/rfc9370.xml
> 
> The relevant diff files have been posted here:
>  https://www.rfc-editor.org/authors/rfc9370-diff.html (comprehensive diff)
>  https://www.rfc-editor.org/authors/rfc9370-rfcdiff.html (comprehensive
> rfcdiff)
>  https://www.rfc-editor.org/authors/rfc9370-auth48diff.html (all AUTH48
> changes)
>  https://www.rfc-editor.org/authors/rfc9370-lastdiff.html (last version to this)
>  https://www.rfc-editor.org/authors/rfc9370-lastrfcdiff.html (last version to this
> rfcdiff)
> 
> The AUTH48 status page is viewable here:
>  http://www.rfc-editor.org/auth48/rfc9370
> 
> Thank you for your time and attention during AUTH48!
> 
> RFC Editor/mf
> 
> 
> 
> > On May 17, 2023, at 9:57 AM, Valery Smyslov <[e-mail]> wrote:
> >
> > Hi Megan,
> >
> > thank you for the update - it's almost there! Just one minor typo:
> >
> > CURRENT:
> >   *  Replaced the Note on what was the "Transform Type 4 - Diffie-
> >      Hellman Group Transform IDs" registry with the following two
> >      notes:
> >
> > in fact there are three notes listed below, so either:
> >
> > NEW1:
> >   *  Replaced the Note on what was the "Transform Type 4 - Diffie-
> >      Hellman Group Transform IDs" registry with the following three
> >      notes:
> >
> > or:
> >
> > NEW2:
> >   *  Replaced the Note on what was the "Transform Type 4 - Diffie-
> >      Hellman Group Transform IDs" registry with the following
> >      notes:
> >
> > Regards,
> > Valery.
> >
> >
> >
> >> -----Original Message-----
> >> From: Megan Ferguson [mailto:[e-mail]]
> >> Sent: Wednesday, May 17, 2023 4:34 PM
> >> To: Valery Smyslov
> >> Cc: Scott Fluhrer (sfluhrer); [e-mail]; Roman Danyliw; Garcia
> Morchon O, Oscar;
> >> [e-mail]; Tero Kivinen; [e-mail]; ipsecme-
> [e-mail]; Graham Bartlett;
> >> [e-mail]; [e-mail]; auth48archive@rfc-
> editor.org
> >> Subject: Re: Re: AUTH48: RFC-to-be 9370 <draft-ietf-ipsecme-ikev2-multiple-
> ke-12> for your review
> >>
> >> Hi Valery,
> >>
> >> [Note I’ve cut IANA from the CC field as their actions are complete.]
> >>
> >> Not nerdy at all - thanks for suggesting these changes!  Moving the text as
> you have helps clarify some of
> >> the questions I had on my initial read, making this text easier for the reader
> to digest.
> >>
> >> Again, once we have the go ahead on this version, we will move forward in
> the publication process.
> >>
> >> The files have been posted here:
> >>  https://www.rfc-editor.org/authors/rfc9370.txt
> >>  https://www.rfc-editor.org/authors/rfc9370.pdf
> >>  https://www.rfc-editor.org/authors/rfc9370.html
> >>  https://www.rfc-editor.org/authors/rfc9370.xml
> >>
> >> The relevant diff files have been posted here:
> >>  https://www.rfc-editor.org/authors/rfc9370-diff.html (comprehensive diff)
> >>  https://www.rfc-editor.org/authors/rfc9370-rfcdiff.html (comprehensive
> rfcdiff)
> >>  https://www.rfc-editor.org/authors/rfc9370-auth48diff.html (all AUTH48
> changes)
> >>  https://www.rfc-editor.org/authors/rfc9370-lastdiff.html (last version to
> this)
> >>  https://www.rfc-editor.org/authors/rfc9370-lastrfcdiff.html (last version to
> this rfcdiff)
> >>
> >> The AUTH48 status page is viewable here:
> >>  http://www.rfc-editor.org/auth48/rfc9370
> >>
> >> Thank you for your time and attention during AUTH48!
> >>
> >> RFC Editor/mf
> >>
> >>> On May 16, 2023, at 4:01 AM, Valery Smyslov <[e-mail]> wrote:
> >>>
> >>> Hi Megan,
> >>>
> >>> thank you for this update. The text now is correct, but may I propose the
> final
> >>> polishing change (sorry for being nerd :-)):
> >>>
> >>> CURRENT:
> >>>  IANA has also completed the following changes.  It is assumed that
> >>>  [RFC9370] refers to this specification.
> >>>
> >>>  *  Added a reference to [RFC9370] in what was the "Transform Type 4 -
> >>>     Diffie-Hellman Group Transform IDs" registry.
> >>>
> >>>  *  Replaced the Note on what was the "Transform Type 4 - Diffie-
> >>>     Hellman Group Transform IDs" registry with the following two
> >>>     notes:
> >>>
> >>>     This registry was originally named "Transform Type 4 - Diffie-
> >>>     Hellman Group Transform IDs" and was referenced using that name in
> >>>     a number of RFCs published prior to [RFC9370], which gave it the
> >>>     current title.
> >>>
> >>>     To find out requirement levels for Key Exchange Methods for IKEv2,
> >>>     see [RFC8247].
> >>>
> >>>  *  Added these notes to the "Transform Type Values" registry:
> >>>
> >>>     "Key Exchange Method (KE)" transform type was originally named
> >>>     "Diffie-Hellman Group (D-H)" and was referenced by that name in a
> >>>     number of RFCs published prior to [RFC9370], which gave it the
> >>>     current title.
> >>>
> >>>     All "Additional Key Exchange (ADDKE)" entries use the same
> >>>     "Transform Type 4 - Key Exchange Method Transform IDs" registry as
> >>>     the "Key Exchange Method (KE)" entry.
> >>>
> >>>  *  Appended [RFC9370] to the Reference column of Transform Type 4 in
> >>>     the "Transform Type Values" registry.
> >>>
> >>>  *  Appended this Note to what was the "Transform Type 4 - Diffie-
> >>>     Hellman Group Transform IDs" registry:
> >>>
> >>>     This registry is used by the "Key Exchange Method (KE)" transform
> >>>     type and by all "Additional Key Exchange (ADDKE)" transform types.
> >>>
> >>> PROPOSED:
> >>>  IANA has also completed the following changes.  It is assumed that
> >>>  [RFC9370] refers to this specification.
> >>>
> >>>  *  Added a reference to [RFC9370] in what was the "Transform Type 4 -
> >>>     Diffie-Hellman Group Transform IDs" registry.
> >>>
> >>>  *  Replaced the Note on what was the "Transform Type 4 - Diffie-
> >>>     Hellman Group Transform IDs" registry with the following three
> >>>     notes:
> >>>
> >>>     This registry was originally named "Transform Type 4 - Diffie-
> >>>     Hellman Group Transform IDs" and was referenced using that name in
> >>>     a number of RFCs published prior to [RFC9370], which gave it the
> >>>     current title.
> >>>
> >>>     This registry is used by the "Key Exchange Method (KE)" transform
> >>>     type and by all "Additional Key Exchange (ADDKE)" transform types.
> >>>
> >>>     To find out requirement levels for Key Exchange Methods for IKEv2,
> >>>     see [RFC8247].
> >>>
> >>>  *  Appended [RFC9370] to the Reference column of Transform Type 4 in
> >>>     the "Transform Type Values" registry.
> >>>
> >>>  *  Added these notes to the "Transform Type Values" registry:
> >>>
> >>>     "Key Exchange Method (KE)" transform type was originally named
> >>>     "Diffie-Hellman Group (D-H)" and was referenced by that name in a
> >>>     number of RFCs published prior to [RFC9370], which gave it the
> >>>     current title.
> >>>
> >>>     All "Additional Key Exchange (ADDKE)" entries use the same
> >>>     "Transform Type 4 - Key Exchange Method Transform IDs" registry as
> >>>     the "Key Exchange Method (KE)" entry.
> >>>
> >>>
> >>>
> >>> Just to list all the changes in Notes for each registry in a single clause
> >>> and reorder the change requests so that first IANA is asked for
> >>> adding a reference to RFC9370 to a registry and then is asked
> >>> for changing Notes.
> >>>
> >>> Regards,
> >>> Valery.
> >>>
> >>>> -----Original Message-----
> >>>> From: Megan Ferguson [mailto:[e-mail]]
> >>>> Sent: Monday, May 15, 2023 11:33 PM
> >>>> To: Valery Smyslov
> >>>> Cc: Scott Fluhrer (sfluhrer); [e-mail]; Roman Danyliw;
> Garcia Morchon O, Oscar; iana-
> >>>> [e-mail]; [e-mail]; Tero Kivinen; ipsecme-
> [e-mail]; ipsecme-
> >> [e-mail];
> >>>> Graham Bartlett; [e-mail]; [e-mail];
> [e-mail]
> >>>> Subject: Re: [IANA #1271735] [IANA] Re: AUTH48: RFC-to-be 9370 <draft-
> ietf-ipsecme-ikev2-multiple-
> >> ke-
> >>>> 12> for your review
> >>>>
> >>>> Hi Valery,
> >>>>
> >>>> Please take a look at the updates we made to the document and let us
> know if these changes address
> >>>> your concerns.  We have updated the introductory text to these notes
> and added a blank space
> >> between
> >>>> to show the note separation.
> >>>>
> >>>> Once we have your approval, we will move this document forward in the
> publication process.
> >>>>
> >>>> The files have been posted here:
> >>>>  https://www.rfc-editor.org/authors/rfc9370.txt
> >>>>  https://www.rfc-editor.org/authors/rfc9370.pdf
> >>>>  https://www.rfc-editor.org/authors/rfc9370.html
> >>>>  https://www.rfc-editor.org/authors/rfc9370.xml
> >>>>
> >>>> The relevant diff files have been posted here:
> >>>>  https://www.rfc-editor.org/authors/rfc9370-diff.html (comprehensive
> diff)
> >>>>  https://www.rfc-editor.org/authors/rfc9370-rfcdiff.html (comprehensive
> rfcdiff)
> >>>>  https://www.rfc-editor.org/authors/rfc9370-auth48diff.html (all AUTH48
> changes)
> >>>>  https://www.rfc-editor.org/authors/rfc9370-lastdiff.html (last version to
> this)
> >>>>  https://www.rfc-editor.org/authors/rfc9370-lastrfcdiff.html (last version
> to this rfcdiff)
> >>>>
> >>>> The AUTH48 status page is viewable here:
> >>>>  http://www.rfc-editor.org/auth48/rfc9370
> >>>>
> >>>> Thank you.
> >>>>
> >>>> RFC Editor/mf
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>> On May 15, 2023, at 9:36 AM, Valery Smyslov <[e-mail]> wrote:
> >>>>>
> >>>>> A short follow-up - just my personal opinion.
> >>>>> If to change, then perhaps it is better to correct
> >>>>> the text in the document to reflect the current IANA text
> >>>>> (where all new notes are shown as separate "Notes".)
> >>>>> This way there will be more "Notes", each concerned
> >>>>> with a separate consideration. But I don't insist.
> >>>>>
> >>>>> Regards,
> >>>>> Valery.
> >>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: Valery Smyslov [mailto:[e-mail]]
> >>>>>> Sent: Monday, May 15, 2023 4:27 PM
> >>>>>> To: 'Megan Ferguson'
> >>>>>> Cc: 'Scott Fluhrer (sfluhrer)'; [e-mail]; 'Roman Danyliw';
> 'Garcia Morchon O, Oscar';
> >>>> iana-
> >>>>>> [e-mail]; [e-mail]; 'Tero Kivinen'; ipsecme-
> [e-mail]; ipsecme-
> >>>>>> [e-mail]; 'Graham Bartlett'; [e-mail]; cjt@post-
> quantum.com;
> >>>>>> [e-mail]
> >>>>>> Subject: RE: [IANA #1271735] [IANA] Re: AUTH48: RFC-to-be 9370
> <draft-ietf-ipsecme-ikev2-
> >> multiple-
> >>>> ke-
> >>>>>> 12> for your review
> >>>>>>
> >>>>>> Hi Megan,
> >>>>>>
> >>>>>> thank you for the update. I think that currently all the notes are correct
> and
> >>>>>> the IANA page and the document are mostly in sync. I only found two
> minor
> >>>>>> issues with the splitting text into Notes.
> >>>>>>
> >>>>>> First issue:
> >>>>>>
> >>>>>> CURRENT DOCUMENT:
> >>>>>> *  Added this note to the "Transform Type Values" registry:
> >>>>>>
> >>>>>>    "Key Exchange Method (KE)" transform type was originally named
> >>>>>>    "Diffie-Hellman Group (D-H)" and was referenced by that name in a
> >>>>>>    number of RFCs published prior to [RFC9370], which gave it the
> >>>>>>    current title.  All "Additional Key Exchange (ADDKE)" entries use
> >>>>>>    the same "Transform Type 4 - Key Exchange Method Transform IDs"
> >>>>>>    registry as the "Key Exchange Method (KE)" entry.
> >>>>>>
> >>>>>> the IANA has the same text, but as two separate Notes:
> >>>>>>
> >>>>>> CURRENT IANA:
> >>>>>> Note
> >>>>>> 	"Key Exchange Method (KE)" transform type was originally
> >>>>>> 	named "Diffie-Hellman Group (D-H)" and was referenced by
> >>>>>> 	that name in a number of RFCs published prior
> >>>>>> 	to [RFC-ietf-ipsecme-ikev2-multiple-ke-12], which
> >>>>>> 	gave it the current title.
> >>>>>>
> >>>>>> Note
> >>>>>> 	All "Additional Key Exchange (ADDKE)" entries use the same
> >>>>>> 	"Transform Type 4 - Key Exchange Method Transform IDs"
> >>>>>> 	registry as the "Key Exchange Method (KE)" entry.
> >>>>>>
> >>>>>>
> >>>>>> Second issue:
> >>>>>>
> >>>>>> CURRENT DOCUMENT:
> >>>>>> *  Replaced the Note on what was the "Transform Type 4 - Diffie-
> >>>>>>    Hellman Group Transform IDs" registry with:
> >>>>>>
> >>>>>>    This registry was originally named "Transform Type 4 - Diffie-
> >>>>>>    Hellman Group Transform IDs" and was referenced using that name in
> >>>>>>    a number of RFCs published prior to [RFC9370], which gave it the
> >>>>>>    current title.  To find out requirement levels for Key Exchange
> >>>>>>    Methods for IKEv2, see [RFC8247].
> >>>>>>
> >>>>>> and the IANA contains the same text, but as two distinct Notes (with
> another Note in between):
> >>>>>>
> >>>>>> CURRENT IANA:
> >>>>>> Note
> >>>>>> 	This registry was originally named "Transform Type 4 -
> >>>>>> 	Diffie-Hellman Group Transform IDs" and was referenced
> >>>>>> 	using that name in a number of RFCs published prior to
> >>>>>> 	[RFC-ietf-ipsecme-ikev2-multiple-ke-12], which gave
> >>>>>> 	it its current title.
> >>>>>>
> >>>>>> [another Note here]
> >>>>>>
> >>>>>> Note
> >>>>>> 	To find out requirement levels for key exchange methods
> >>>>>> 	for IKEv2, see [RFC8247].
> >>>>>>
> >>>>>> I don't know whether it is important and whether this should be
> corrected
> >>>>>> (since these are only formatting issues) and if it should, then what
> >>>>>> should be corrected, document or IANA page, I only noted the
> difference :-)
> >>>>>>
> >>>>>> Regards,
> >>>>>> Valery.
> >>>>>>
> >>>>>>
> >>>>>>> -----Original Message-----
> >>>>>>> From: Megan Ferguson [mailto:[e-mail]]
> >>>>>>> Sent: Friday, May 12, 2023 8:22 PM
> >>>>>>> To: Valery Smyslov
> >>>>>>> Cc: Scott Fluhrer (sfluhrer); [e-mail]; Roman Danyliw;
> Garcia Morchon O, Oscar;
> >>>> iana-
> >>>>>>> [e-mail]; [e-mail]; Tero Kivinen; ipsecme-
> [e-mail]; ipsecme-
> >>>>>> [e-mail];
> >>>>>>> Graham Bartlett; [e-mail]; [e-mail];
> auth48archive@rfc-
> >> editor.org
> >>>>>>> Subject: Re: [IANA #1271735] [IANA] Re: AUTH48: RFC-to-be 9370
> <draft-ietf-ipsecme-ikev2-
> >>>> multiple-
> >>>>>> ke-
> >>>>>>> 12> for your review
> >>>>>>>
> >>>>>>> Sabrina and Valery,
> >>>>>>>
> >>>>>>> Thank you for your replies and clarifications.
> >>>>>>>
> >>>>>>> We have updated the file as requested below and marked IANA as
> “Approved” on the AUTH48
> >>>> status
> >>>>>>> page (see below).  We request review and approval of these changes
> to the document from one
> >> of
> >>>> the
> >>>>>>> authors.  Once we have received confirmation of the document in its
> current form, it will be ready
> >> to
> >>>>>>> move forward in the publication process.
> >>>>>>>
> >>>>>>> The files have been posted here:
> >>>>>>> https://www.rfc-editor.org/authors/rfc9370.txt
> >>>>>>> https://www.rfc-editor.org/authors/rfc9370.pdf
> >>>>>>> https://www.rfc-editor.org/authors/rfc9370.html
> >>>>>>> https://www.rfc-editor.org/authors/rfc9370.xml
> >>>>>>>
> >>>>>>> The relevant diff files have been posted here:
> >>>>>>> https://www.rfc-editor.org/authors/rfc9370-diff.html (comprehensive)
> >>>>>>> https://www.rfc-editor.org/authors/rfc9370-rfcdiff.html
> (comprehensive rfcdiff)
> >>>>>>> https://www.rfc-editor.org/authors/rfc9370-auth48diff.html (all
> AUTH48 changes)
> >>>>>>> https://www.rfc-editor.org/authors/rfc9370-lastdiff.html (last version
> to this)
> >>>>>>> https://www.rfc-editor.org/authors/rfc9370-lastrfcdiff.html (last
> version to this rfcdiff)
> >>>>>>>
> >>>>>>> The AUTH48 status page is viewable here:
> >>>>>>> http://www.rfc-editor.org/auth48/rfc9370
> >>>>>>>
> >>>>>>> Thank you.
> >>>>>>>
> >>>>>>> RFC Editor/mf
> >>>>>>>
> >>>>>>>
> >>>>>>>> On May 8, 2023, at 5:34 PM, Sabrina Tanamal via RT <iana-
> [e-mail]> wrote:
> >>>>>>>>
> >>>>>>>> Hi Valery, Megan, all,
> >>>>>>>>
> >>>>>>>> We've updated the notes in the registry according to the text
> proposed by Valery below. Please
> >> see
> >>>>>>>>
> >>>>>>>> https://www.iana.org/assignments/ikev2-parameters
> >>>>>>>>
> >>>>>>>> If any other changes are required, just let us know.
> >>>>>>>>
> >>>>>>>> Thanks,
> >>>>>>>>
> >>>>>>>> Sabrina Tanamal
> >>>>>>>> Lead IANA Services Specialist
> >>>>>>>>
> >>>>>>>> On Thu May 04 07:55:41 2023, [e-mail] wrote:
> >>>>>>>>> Hi Sabrina, Megan, all,
> >>>>>>>>>
> >>>>>>>>> since I'm at fault for the changes #4, #6, and #6, let me clarify.
> >>>>>>>>>
> >>>>>>>>> The change #4:
> >>>>>>>>>
> >>>>>>>>> It appears that the current text in the document is wrong and the
> >>>>>>>>> current text in the registry is correct.
> >>>>>>>>> This is an oversight (copy-paste of the similar text for another
> >>>>>>>>> registry), sorry for it, and thanks to Sabrina for catching it.
> >>>>>>>>>
> >>>>>>>>> The correct text in the document should be (slightly modified the
> >>>>>>>>> current registry text to match change #2)
> >>>>>>>>>
> >>>>>>>>> CURRENT DOCUMENT:
> >>>>>>>>>
> >>>>>>>>> *  Added this note to the "Transform Type Values" registry:
> >>>>>>>>>
> >>>>>>>>> "Transform Type 4 - Key Exchange Method Transform IDs" was
> >>>>>>>>> originally named "Transform Type 4 - Diffie-Hellman Group
> >>>>>>>>> Transform IDs" and was referenced by that name in a number of
> RFCs
> >>>>>>>>> published prior to [RFC9370], which gave it the current title.
> >>>>>>>>>
> >>>>>>>>> NEW:
> >>>>>>>>>
> >>>>>>>>> *  Added this note to the "Transform Type Values" registry:
> >>>>>>>>>
> >>>>>>>>> "Key Exchange Method (KE)" transform type was originally
> >>>>>>>>> named "Diffie-Hellman Group (D-H)" and was referenced by that
> name in
> >>>>>>>>> a number of RFCs
> >>>>>>>>> published prior to [RFC9370], which gave it the current title.
> >>>>>>>>>
> >>>>>>>>> The change #5:
> >>>>>>>>>
> >>>>>>>>> It seems to me that the current text in the document, while being
> >>>>>>>>> correct, is less clear,
> >>>>>>>>> than the current text in the registry.
> >>>>>>>>>
> >>>>>>>>> Perhaps it is possible to combine the two:
> >>>>>>>>>
> >>>>>>>>> CURRENT DOCUMENT:
> >>>>>>>>>
> >>>>>>>>> All "Additional Key Exchange" entries use the same "Transform Type
> >>>>>>>>> 4 - Key Exchange Method Transform IDs" as the "Key Exchange
> Method
> >>>>>>>>> (KE)".
> >>>>>>>>>
> >>>>>>>>> NEW:
> >>>>>>>>>
> >>>>>>>>> All "Additional Key Exchange (ADDKE)" entries use the same
> >>>>>>>>> "Transform Type 4 - Key Exchange Method Transform IDs"
> >>>>>>>>> registry as the "Key Exchange Method (KE)" entry.
> >>>>>>>>>
> >>>>>>>>> (I removed an asterisk, hope this won't cause any confusion?)
> >>>>>>>>>
> >>>>>>>>> The change #6:
> >>>>>>>>>
> >>>>>>>>> The same as above - the text in the document seems to be not
> >>>>>>>>> incorrect, but it seems that
> >>>>>>>>> we can make it more clear:
> >>>>>>>>>
> >>>>>>>>> CURRENT DOCUMENT:
> >>>>>>>>>
> >>>>>>>>> All "Additional Key Exchange" entries use these values as the "Key
> >>>>>>>>> Exchange Method (KE)".
> >>>>>>>>>
> >>>>>>>>> NEW:
> >>>>>>>>>
> >>>>>>>>> This registry is used by the "Key  Exchange Method (KE)" transform
> >>>>>>>>> type
> >>>>>>>>> and by all "Additional Key Exchange (ADDKE)" transform types.
> >>>>>>>>>
> >>>>>>>>> (again, no asterisk, hope it won't cause any confusion)
> >>>>>>>>>
> >>>>>>>>> I apologize for these oversights...
> >>>>>>>>>
> >>>>>>>>> Regards,
> >>>>>>>>> Valery.
> >>>>>>>>>
> >>>>>>>>>> -----Original Message-----
> >>>>>>>>>> From: Sabrina Tanamal via RT [mailto:[e-mail]]
> >>>>>>>>>> Sent: Wednesday, May 03, 2023 8:14 PM
> >>>>>>>>>> To: [e-mail]
> >>>>>>>>>> Cc: [e-mail]; [e-mail]; [e-mail];
> >>>>>>>>>> [e-mail]; oscar.garcia-
> >>>>>>>>>> [e-mail]; [e-mail]; [e-mail];
> ipsecme-
> >>>>>>>>>> [e-mail]; ipsecme-
> >>>>>>>>>> [e-mail]; [e-mail];
> [e-mail];
> >>>>>>>>>> [e-mail];
> >>>>>>>>>> [e-mail]
> >>>>>>>>>> Subject: [IANA #1271735] [IANA] Re: AUTH48: RFC-to-be 9370
> <draft-
> >>>>>>>>>> ietf-ipsecme-ikev2-multiple-ke-12>
> >>>>>>>>>> for your review
> >>>>>>>>>>
> >>>>>>>>>> Hi Megan, all,
> >>>>>>>>>>
> >>>>>>>>>> Please see [ST] inline.
> >>>>>>>>>>
> >>>>>>>>>> On Mon May 01 17:26:54 2023, [e-mail] wrote:
> >>>>>>>>>>> IANA,
> >>>>>>>>>>>
> >>>>>>>>>>> Each of the following updates or requests for review pertain to
> >>>>>>>>>>> https://www.iana.org/assignments/ikev2-parameters.
> >>>>>>>>>>>
> >>>>>>>>>>> Note that all authors have approved, and once IANA confirms
> these
> >>>>>>>>>>> changes and/or provides guidance on these issues, the document
> will
> >>>>>>>>>>> be
> >>>>>>>>>>> ready to move forward in the publication process.
> >>>>>>>>>>>
> >>>>>>>>>>> 1) In the “Transform Type Values” registry, please update the
> >>>>>>>>>>> Descriptions of values 6 - 12 to include the abbreviation.
> >>>>>>>>>>>
> >>>>>>>>>>> Old:
> >>>>>>>>>>>
> >>>>>>>>>>> 6       Additional Key Exchange 1       (optional in IKE, AH, ESP)
> >>>>>>>>>>> [RFC-ietf-ipsecme-ikev2-multiple-ke-12]
> >>>>>>>>>>> 7       Additional Key Exchange 2       (optional in IKE, AH, ESP)
> >>>>>>>>>>> [RFC-ietf-ipsecme-ikev2-multiple-ke-12]
> >>>>>>>>>>> 8       Additional Key Exchange 3       (optional in IKE, AH, ESP)
> >>>>>>>>>>> [RFC-ietf-ipsecme-ikev2-multiple-ke-12]
> >>>>>>>>>>> 9       Additional Key Exchange 4       (optional in IKE, AH, ESP)
> >>>>>>>>>>> [RFC-ietf-ipsecme-ikev2-multiple-ke-12]
> >>>>>>>>>>> 10      Additional Key Exchange 5       (optional in IKE, AH, ESP)
> >>>>>>>>>>> [RFC-ietf-ipsecme-ikev2-multiple-ke-12]
> >>>>>>>>>>> 11      Additional Key Exchange 6       (optional in IKE, AH, ESP)
> >>>>>>>>>>> [RFC-ietf-ipsecme-ikev2-multiple-ke-12]
> >>>>>>>>>>> 12      Additional Key Exchange 7       (optional in IKE, AH, ESP)
> >>>>>>>>>>> [RFC-ietf-ipsecme-ikev2-multiple-ke-12]
> >>>>>>>>>>>
> >>>>>>>>>>> New:
> >>>>>>>>>>>
> >>>>>>>>>>> 6       Additional Key Exchange 1 (ADDKE1)      (optional in IKE,
> >>>>>>>>>>> AH,
> >>>>>>>>>>> ESP)      [RFC-ietf-ipsecme-ikev2-multiple-ke-12]
> >>>>>>>>>>> 7       Additional Key Exchange 2 (ADDKE2)      (optional in IKE,
> >>>>>>>>>>> AH,
> >>>>>>>>>>> ESP)      [RFC-ietf-ipsecme-ikev2-multiple-ke-12]
> >>>>>>>>>>> 8       Additional Key Exchange 3 (ADDKE3)      (optional in IKE,
> >>>>>>>>>>> AH,
> >>>>>>>>>>> ESP)      [RFC-ietf-ipsecme-ikev2-multiple-ke-12]
> >>>>>>>>>>> 9       Additional Key Exchange 4 (ADDKE4)      (optional in IKE,
> >>>>>>>>>>> AH,
> >>>>>>>>>>> ESP)      [RFC-ietf-ipsecme-ikev2-multiple-ke-12]
> >>>>>>>>>>> 10      Additional Key Exchange 5 (ADDKE5)      (optional in IKE,
> >>>>>>>>>>> AH,
> >>>>>>>>>>> ESP)      [RFC-ietf-ipsecme-ikev2-multiple-ke-12]
> >>>>>>>>>>> 11      Additional Key Exchange 6 (ADDKE6)      (optional in IKE,
> >>>>>>>>>>> AH,
> >>>>>>>>>>> ESP)      [RFC-ietf-ipsecme-ikev2-multiple-ke-12]
> >>>>>>>>>>> 12      Additional Key Exchange 7 (ADDKE7)      (optional in IKE,
> >>>>>>>>>>> AH,
> >>>>>>>>>>> ESP)      [RFC-ietf-ipsecme-ikev2-multiple-ke-12]
> >>>>>>>>>>
> >>>>>>>>>> [ST] Done: https://www.iana.org/assignments/ikev2-parameters.
> >>>>>>>>>>
> >>>>>>>>>>> 2) Please update the first Note in the “Transform Type 4 - Key
> >>>>>>>>>>> Exchange Method Transform IDs” registry as follows:
> >>>>>>>>>>>
> >>>>>>>>>>> Old:
> >>>>>>>>>>> Note
> >>>>>>>>>>> This registry was originally named "Transform Type 4 -
> >>>>>>>>>>> Diffie-Hellman Group Transform IDs" and was renamed to
> >>>>>>>>>>> its current name by [RFC-ietf-ipsecme-ikev2-multiple-ke-12].
> >>>>>>>>>>> It has been referenced in its original name in a number
> >>>>>>>>>>> of RFCs published prior to the publication of
> >>>>>>>>>>> [RFC-ietf-ipsecme-ikev2-multiple-ke-12].
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> New:
> >>>>>>>>>>> This registry was originally named "Transform Type 4 -
> >>>>>>>>>>> Diffie-Hellman Group Transform IDs" and was referenced using
> that
> >>>>>>>>>>> name
> >>>>>>>>>>> in a number of RFCs published prior to [RFC-ietf-ipsecme-ikev2-
> >>>>>>>>>>> multiple-ke-12], which gave it its current title.
> >>>>>>>>>>
> >>>>>>>>>> [ST] Done: https://www.iana.org/assignments/ikev2-parameters.
> >>>>>>>>>>
> >>>>>>>>>>> 3) Please update the last Note in the “Transform Type 4 - Key
> >>>>>>>>>>> Exchange
> >>>>>>>>>>> Method Transform IDs” registry as follows (cap and add
> >>>>>>>>>>> abbreviation):
> >>>>>>>>>>>
> >>>>>>>>>>> Old:
> >>>>>>>>>>> Note
> >>>>>>>>>>> The instructions for the designated experts are described
> >>>>>>>>>>> in [RFC-ietf-ipsecme-ikev2-multiple-ke-12]. While adding new
> >>>>>>>>>>> key exchange methods, the following considerations must be
> >>>>>>>>>>> applied.
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> New:
> >>>>>>>>>>> Note
> >>>>>>>>>>> The instructions for the designated experts are described
> >>>>>>>>>>> in [RFC-ietf-ipsecme-ikev2-multiple-ke-12].  While adding new
> >>>>>>>>>>> Key Exchange (KE) methods, the following considerations must
> be
> >>>>>>>>>>> applied.
> >>>>>>>>>>
> >>>>>>>>>> [ST] This is also done: https://www.iana.org/assignments/ikev2-
> >>>>>>>>>> parameters.
> >>>>>>>>>>
> >>>>>>>>>>> 4) Please review the differences in the first note of the
> >>>>>>>>>>> “Transform
> >>>>>>>>>>> Type Values” registry with what is listed in the document:
> >>>>>>>>>>>
> >>>>>>>>>>> Current registry:
> >>>>>>>>>>> Note
> >>>>>>>>>>> "Key Exchange Method (KE)" transform type was originally
> >>>>>>>>>>> named "Diffie-Hellman Group (D-H)" and was renamed to its
> >>>>>>>>>>> current name by [RFC-ietf-ipsecme-ikev2-multiple-ke-12].
> >>>>>>>>>>> It has been referenced in its original name in a number of RFCs
> >>>>>>>>>>> published prior to the publication of [RFC-ietf-ipsecme-ikev2-
> >>>>>>>>>>> multiple-ke-12].
> >>>>>>>>>>>
> >>>>>>>>>>> Current document:
> >>>>>>>>>>> Note
> >>>>>>>>>>> “Transform Type 4 - Key Exchange Method Transform IDs” was
> >>>>>>>>>>> originally
> >>>>>>>>>>> named “Transform Type 4 - Diffie-Hellman Group Transform IDs”
> and
> >>>>>>>>>>> was
> >>>>>>>>>>> referenced by that name in a number of RFCs published prior to
> >>>>>>>>>>> [RFC-
> >>>>>>>>>>> ietf-ipsecme-ikev2-multiple-ke-12], which gave it its current
> >>>>>>>>>>> title.
> >>>>>>>>>>> It has been referenced in its original name in a number of RFCs
> >>>>>>>>>>> published prior to the publication of [RFC-ietf-ipsecme-ikev2-
> >>>>>>>>>>> multiple-ke-12].
> >>>>>>>>>>
> >>>>>>>>>> [ST] For #4, 5, and 6, these changes were requested by the author
> >>>>>>>>>> during the IANA review process; see
> >>>>>>>>>> the thread below (apologies for the long thread). Just let us know
> if
> >>>>>>>>>> these need to be updated in the
> >>>>>>>>>> registry.
> >>>>>>>>>>
> >>>>>>>>>> Thanks,
> >>>>>>>>>> Sabrina
> >>>>>>>>>>
> >>>>>>>>>> Note changes per author:
> >>>>>>>>>>
> >>>>>>>>>>> Hi Valery,
> >>>>>>>>>>>
> >>>>>>>>>>> Please see [ST] below.
> >>>>>>>>>>>
> >>>>>>>>>>> On Tue Dec 27 07:05:56 2022, [e-mail] wrote:
> >>>>>>>>>>> Hi Sabrina,
> >>>>>>>>>>>
> >>>>>>>>>>> please, see below.
> >>>>>>>>>>>
> >>>>>>>>>>>> -----Original Message-----
> >>>>>>>>>>>> From: Sabrina Tanamal via RT [mailto:drafts-approval-
> >>>>>>>>>>>> [e-mail]]
> >>>>>>>>>>>> Sent: Monday, December 26, 2022 10:24 PM
> >>>>>>>>>>>> Cc: [e-mail]; mt@post-
> quantum.com;
> >>>>>>>>>>>> [e-mail];
> >>>>>>>>>>>> [e-mail]; [e-mail]; [e-mail];
> >>>>>>>>>>>> [e-mail]; [e-mail];
> >>>>>>>>>>>> [e-mail]; [e-mail]; [e-mail]
> >>>>>>>>>>>> Subject: [IANA #1262332] Protocol Action: 'Multiple Key
> Exchanges
> >>>>>>>>>>>> in
> >>>>>>>>>>>> IKEv2' to Proposed Standard (draft-
> >>>>>>>>>>>> ietf-ipsecme-ikev2-multiple-ke-12.txt)
> >>>>>>>>>>>>
> >>>>>>>>>>>> Hi Valery, all,
> >>>>>>>>>>>>
> >>>>>>>>>>>> See [ST] inline.
> >>>>>>>>>>>>
> >>>>>>>>>>>> On Mon Dec 26 08:54:56 2022, [e-mail] wrote:
> >>>>>>>>>>>>> Hi Amanda,
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> please see inline.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> -----Original Message-----
> >>>>>>>>>>>>>> From: Amanda Baber via RT [mailto:drafts-
> [e-mail]]
> >>>>>>>>>>>>>> Sent: Saturday, December 24, 2022 2:10 AM
> >>>>>>>>>>>>>> Cc: [e-mail]; [e-mail]; [e-mail];
> >>>>>>>>>>>>>> [e-mail]; [e-mail];
> >>>>>>>>>>>>>> [e-mail]; [e-mail];
> >>>>>>>>>>>>>> [e-mail]; [e-mail];
> >>>>>>>>>>>>>> [e-mail]; [e-mail]
> >>>>>>>>>>>>>> Subject: [***SPAM***] [IANA #1262332] Protocol Action:
> >>>>>>>>>>>>>> 'Multiple
> >>>>>>>>>>>>>> Key
> >>>>>>>>>>>>>> Exchanges in IKEv2' to Proposed
> >>>>>>>>>>>>>> Standard (draft-ietf-ipsecme-ikev2-multiple-ke-12.txt)
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Hi Valery,
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Can you confirm that we've captured this note correctly?
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> This note was captured correctly. Unfortunately, I found
> >>>>>>>>>>>>> one typo another note. Please, see below.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Note
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> The instructions for the designated experts are described
> >>>>>>>>>>>>>>> in
> >>>>>>>>>>>>>>> [RFC-ietf-ipsecme-ikev2-multiple-ke-12]. While
> >>>>>>>>>>>>>>> adding new Key Exchange methods, the following
> >>>>>>>>>>>>>>> considerations must be applied. A Key Exchange method
> >>>>>>>>>>>>>>> must take exactly one round-trip (one IKEv2 exchange)
> >>>>>>>>>>>>>>> and at the end of this exchange, both peers must be
> >>>>>>>>>>>>>>> able to derive the shared secret. In addition, any
> >>>>>>>>>>>>>>> public value that peers exchanged during a Key Exchange
> >>>>>>>>>>>>>>> method must fit into a single IKEv2 payload. If these
> >>>>>>>>>>>>>>> restrictions are not met for a Key Exchange method,
> >>>>>>>>>>>>>>> then there must be documentation on how this Key
> >>>>>>>>>>>>>>> Exchange method is used in IKEv2.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> The hyphen was removed from "round-trip," as it's only
> >>>>>>>>>>>>>> necessary
> >>>>>>>>>>>>>> when
> >>>>>>>>>>>>>> "round-trip" is used as an
> >>>>>>>>>>>>>> adjective.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> I agree. Thank you for catching this!
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> Please see
> >>>>>>>>>>>>>> https://www.iana.org/assignments/ikev2-parameters
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> If this is correct, we'll tell the RFC Editor we've completed
> >>>>>>>>>>>>>> the
> >>>>>>>>>>>>>> actions.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> While re-reading all new notes, I noticed a typo in another
> >>>>>>>>>>>>> note.
> >>>>>>>>>>>>> Note for "Transform Type Values" registry should be:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> CURRENT:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Note
> >>>>>>>>>>>>> "Transform Type 4 - Key Exchange Method Transform IDs"
> >>>>>>>>>>>>> was originally named "Transform Type 4 - Diffie-Hellman
> >>>>>>>>>>>>> Group Transform IDs" and was renamed to its current name
> >>>>>>>>>>>>> by [RFC-ietf-ipsecme-ikev2-multiple-ke-12]. It has been
> >>>>>>>>>>>>> referenced in its original name in a number of RFCs
> >>>>>>>>>>>>> published prior to the publication of
> >>>>>>>>>>>>> [RFC-ietf-ipsecme-ikev2-multiple-ke-12].
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> NEW:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Note
> >>>>>>>>>>>>> "Key Exchange Method (KE)" transform type was originally
> >>>>>>>>>>>>> named
> >>>>>>>>>>>>> "Diffie-Hellman Group (D-H)" and was renamed to its
> >>>>>>>>>>>>> current
> >>>>>>>>>>>>> name
> >>>>>>>>>>>>> by [RFC-ietf-ipsecme-ikev2-multiple-ke-12]. It has been
> >>>>>>>>>>>>> referenced in its original name in a number of RFCs
> >>>>>>>>>>>>> published prior to the publication of
> >>>>>>>>>>>>> [RFC-ietf-ipsecme-ikev2-multiple-ke-12].
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> This was a result of my carelessness - copy-paste of the note
> >>>>>>>>>>>>> for
> >>>>>>>>>>>>> the registry "Transform Type 4 - Key Exchange Method
> Transform
> >>>>>>>>>>>>> IDs"
> >>>>>>>>>>>>> instead of informing readers that the transform type itself was
> >>>>>>>>>>>>> also
> >>>>>>>>>>>>> renamed.
> >>>>>>>>>>>>> Sorry for this confusion.
> >>>>>>>>>>>>
> >>>>>>>>>>>> [ST] No problem. We've updated the note in the Transform Type
> >>>>>>>>>>>> Values
> >>>>>>>>>>>> registry:
> >>>>>>>>>>>>
> >>>>>>>>>>>> "Key Exchange Method (KE)" transform type was originally
> >>>>>>>>>>>> named "Diffie-Hellman Group (D-H)" and was renamed to its
> >>>>>>>>>>>> current name by [RFC-ietf-ipsecme-ikev2-multiple-ke-12].
> >>>>>>>>>>>> It has been referenced in its original name in a number of RFCs
> >>>>>>>>>>>> published prior to the publication of [RFC-ietf-ipsecme-ikev2-
> >>>>>>>>>>>> multiple-ke-12].
> >>>>>>>>>>>>
> >>>>>>>>>>>> Please see
> >>>>>>>>>>>> https://www.iana.org/assignments/ikev2-parameters
> >>>>>>>>>>>>
> >>>>>>>>>>>> Can you confirm that this is correct?
> >>>>>>>>>>>
> >>>>>>>>>>> YES!
> >>>>>>>>>>>
> >>>>>>>>>>> A minor nit: I noticed that the text "Key Exchange Methods" in
> >>>>>>>>>>> notes
> >>>>>>>>>>> is sometimes fully capitalized and sometimes not (as "Key
> Exchange
> >>>>>>>>>>> methods").
> >>>>>>>>>>> Just for aesthetical purpose can we make this consistent? I
> suggest
> >>>>>>>>>>> to
> >>>>>>>>>>> fully
> >>>>>>>>>>> de-capitalize it in notes, when it is not mentioned as a registry
> >>>>>>>>>>> name
> >>>>>>>>>>> or as a registry entry name.
> >>>>>>>>>>> So, the last two notes for registry "Transform Type 4 - Key
> >>>>>>>>>>> Exchange
> >>>>>>>>>>> Method Transform IDs"
> >>>>>>>>>>> would be changed:
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> CURRENT:
> >>>>>>>>>>> Note
> >>>>>>>>>>> To find out requirement levels for Key Exchange Methods
> >>>>>>>>>>> for IKEv2, see [RFC8247].
> >>>>>>>>>>>
> >>>>>>>>>>> Note
> >>>>>>>>>>> The instructions for the designated experts are described
> >>>>>>>>>>> in [RFC-ietf-ipsecme-ikev2-multiple-ke-12]. While adding new
> >>>>>>>>>>> Key Exchange methods, the following considerations must be
> >>>>>>>>>>> applied. A Key Exchange method must take exactly one
> >>>>>>>>>>> round trip (one IKEv2 exchange) and at the end of this
> >>>>>>>>>>> exchange, both peers must be able to derive the shared
> >>>>>>>>>>> secret. In addition, any public value that peers exchanged
> >>>>>>>>>>> during a Key Exchange method must fit into a single IKEv2
> >>>>>>>>>>> payload. If these restrictions are not met for a Key
> >>>>>>>>>>> Exchange method, then there must be documentation on how
> >>>>>>>>>>> this Key Exchange method is used in IKEv2.
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> NEW:
> >>>>>>>>>>> Note
> >>>>>>>>>>> To find out requirement levels for key exchange methods
> >>>>>>>>>>> for IKEv2, see [RFC8247].
> >>>>>>>>>>>
> >>>>>>>>>>> Note
> >>>>>>>>>>> The instructions for the designated experts are described
> >>>>>>>>>>> in [RFC-ietf-ipsecme-ikev2-multiple-ke-12]. While adding new
> >>>>>>>>>>> key exchange methods, the following considerations must be
> >>>>>>>>>>> applied. A key exchange method must take exactly one
> >>>>>>>>>>> round trip (one IKEv2 exchange) and at the end of this
> >>>>>>>>>>> exchange, both peers must be able to derive the shared
> >>>>>>>>>>> secret. In addition, any public value that peers exchanged
> >>>>>>>>>>> during a key exchange method must fit into a single IKEv2
> >>>>>>>>>>> payload. If these restrictions are not met for a key
> >>>>>>>>>>> exchange method, then there must be documentation on how
> >>>>>>>>>>> this key exchange method is used in IKEv2.
> >>>>>>>>>>>
> >>>>>>>>>>> [ST] This is done. Please see
> >>>>>>>>>>>
> >>>>>>>>>>> https://www.iana.org/assignments/ikev2-parameters
> >>>>>>>>>>>
> >>>>>>>>>>> Thank you,
> >>>>>>>>>>> Sabrina
> >>>>>>>>>>>
> >>>>>>>>>>> Regards,
> >>>>>>>>>>> Valery.
> >>>>>>>>>>>
> >>>>>>>>>>>> Thanks,
> >>>>>>>>>>>> Sabrina
> >>>>>>>>>>>>
> >>>>>>>>>>>>> Regards,
> >>>>>>>>>>>>> Valery.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> thanks,
> >>>>>>>>>>>>>> Amanda (filling in for Sabrina)
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> On Wed Dec 21 07:49:58 2022, [e-mail] wrote:
> >>>>>>>>>>>>>>> Hi Sabrina,
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> please, see inline (marked with [VS]).
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> -----Original Message-----
> >>>>>>>>>>>>>>>> From: Sabrina Tanamal via RT [mailto:drafts-
> >>>>>>>>>>>>>>>> [e-mail]]
> >>>>>>>>>>>>>>>> Sent: Tuesday, December 20, 2022 11:19 PM
> >>>>>>>>>>>>>>>> Cc: [e-mail]; [e-mail];
> >>>>>>>>>>>>>>>> [e-mail];
> >>>>>>>>>>>>>>>> mt@post-
> >>>>>>>>>>>>>>>> quantum.com; cjt@post-
> >>>>>>>>>>>>>>>> quantum.com; [e-mail];
> >>>>>>>>>>>>>>>> [e-mail];
> >>>>>>>>>>>>>>>> [e-mail];
> >>>>>>>>>>>>>>>> [e-mail]; [e-mail];
> >>>>>>>>>>>>>>>> [e-mail]
> >>>>>>>>>>>>>>>> Subject: [***SPAM***] [IANA #1262332] Protocol Action:
> >>>>>>>>>>>>>>>> 'Multiple
> >>>>>>>>>>>>>>>> Key
> >>>>>>>>>>>>>>>> Exchanges in IKEv2' to Proposed
> >>>>>>>>>>>>>>>> Standard (draft-ietf-ipsecme-ikev2-multiple-ke-12.txt)
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Hi Valery, Graham, all,
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> On Tue Dec 20 12:59:19 2022, [e-mail] wrote:
> >>>>>>>>>>>>>>>>> Hi Graham,
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> it’s my fault as non-native speaker :-)
> >>>>>>>>>>>>>>>>> Thank you for checking the text,
> >>>>>>>>>>>>>>>>> and of course I agree with this change.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Regards,
> >>>>>>>>>>>>>>>>> Valery.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> From: Graham Bartlett [mailto:[e-mail]]
> >>>>>>>>>>>>>>>>> Sent: Tuesday, December 20, 2022 3:48 PM
> >>>>>>>>>>>>>>>>> To: Valery Smyslov
> >>>>>>>>>>>>>>>>> Cc: [e-mail]; [e-mail];
> >>>>>>>>>>>>>>>>> [e-mail];
> >>>>>>>>>>>>>>>>> [e-mail]; [e-mail]; mt@post-
> >>>>>>>>>>>>>>>>> quantum.com;
> >>>>>>>>>>>>>>>>> [e-mail]; [e-mail];
> >>>>>>>>>>>>>>>>> [e-mail];
> >>>>>>>>>>>>>>>>> [e-mail]
> >>>>>>>>>>>>>>>>> Subject: Re: [IANA #1262332] Protocol Action: 'Multiple
> >>>>>>>>>>>>>>>>> Key
> >>>>>>>>>>>>>>>>> Exchanges
> >>>>>>>>>>>>>>>>> in IKEv2' to Proposed Standard (draft-ietf-ipsecme-
> >>>>>>>>>>>>>>>>> ikev2-
> >>>>>>>>>>>>>>>>> multiple-
> >>>>>>>>>>>>>>>>> ke-
> >>>>>>>>>>>>>>>>> 12.txt)
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Hi
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Can we also amend the text from;
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> In addition, any
> >>>>>>>>>>>>>>>>> public value peers exchanged during a Key Exchange
> >>>>>>>>>>>>>>>>> method must fit into a single IKE message. If these
> >>>>>>>>>>>>>>>>> restrictions are not met for a Key Exchange method,
> >>>>>>>>>>>>>>>>> then there must be documentation on how this Key
> >>>>>>>>>>>>>>>>> Exchange method is used in IKEv2.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> to;
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> In addition, any
> >>>>>>>>>>>>>>>>> public value that peers exchanged during a Key
> >>>>>>>>>>>>>>>>> Exchange
> >>>>>>>>>>>>>>>>> method must fit into a single IKE message. If these
> >>>>>>>>>>>>>>>>> restrictions are not met for a Key Exchange method,
> >>>>>>>>>>>>>>>>> then there must be documentation on how this Key
> >>>>>>>>>>>>>>>>> Exchange method is used in IKEv2.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> (simply adding 'that'). I had to read this a few times
> >>>>>>>>>>>>>>>>> earlier
> >>>>>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>> work
> >>>>>>>>>>>>>>>>> out what was being said.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> [ST] Thank you for pointing this out. We'll update this
> >>>>>>>>>>>>>>>> in
> >>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>> registry shortly.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> [ST] Regarding the expert's instructions section, may we
> >>>>>>>>>>>>>>>> suggest
> >>>>>>>>>>>>>>>> separating the instructions into its own
> >>>>>>>>>>>>>>>> note section? We don't typically have a bold heading for
> >>>>>>>>>>>>>>>> expert
> >>>>>>>>>>>>>>>> instructions across the registries. If it's
> >>>>>>>>>>>>>>>> helpful, perhaps the title "Instructions for Designated
> >>>>>>>>>>>>>>>> Experts"
> >>>>>>>>>>>>>>>> can
> >>>>>>>>>>>>>>>> be changed to something like, "The
> >>>>>>>>>>>>>>>> role of the designated expert is described in [RFC-ietf-
> >>>>>>>>>>>>>>>> ipsecme-
> >>>>>>>>>>>>>>>> ikev2-multiple-ke-12]." See the proposed
> >>>>>>>>>>>>>>>> changes below.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> OLD:
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Instructions for Designated Experts
> >>>>>>>>>>>>>>>> While adding new Key Exchange methods, the following
> >>>>>>>>>>>>>>>> considerations must be applied. A Key Exchange method
> >>>>>>>>>>>>>>>> must take exactly one round-trip (one IKEv2 exchange)
> >>>>>>>>>>>>>>>> and at the end of this exchange, both peers must be
> >>>>>>>>>>>>>>>> able to derive the shared secret. In addition, any
> >>>>>>>>>>>>>>>> public value peers exchanged during a Key Exchange
> >>>>>>>>>>>>>>>> method must fit into a single IKE message. If these
> >>>>>>>>>>>>>>>> restrictions are not met for a Key Exchange method,
> >>>>>>>>>>>>>>>> then there must be documentation on how this Key
> >>>>>>>>>>>>>>>> Exchange method is used in IKEv2.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> NEW:
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Note
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> The role of the designated expert is described in
> >>>>>>>>>>>>>>>> [RFC-ietf-ipsecme-ikev2-multiple-ke-12]. While
> >>>>>>>>>>>>>>>> adding new Key Exchange methods, the following
> >>>>>>>>>>>>>>>> considerations must be applied. A Key Exchange method
> >>>>>>>>>>>>>>>> must take exactly one round-trip (one IKEv2 exchange)
> >>>>>>>>>>>>>>>> and at the end of this exchange, both peers must be
> >>>>>>>>>>>>>>>> able to derive the shared secret. In addition, any
> >>>>>>>>>>>>>>>> public value that peers exchanged during a Key Exchange
> >>>>>>>>>>>>>>>> method must fit into a single IKE message. If these
> >>>>>>>>>>>>>>>> restrictions are not met for a Key Exchange method,
> >>>>>>>>>>>>>>>> then there must be documentation on how this Key
> >>>>>>>>>>>>>>>> Exchange method is used in IKEv2.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> ====
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Let me know if this works for you. If so, we can send a
> >>>>>>>>>>>>>>>> note
> >>>>>>>>>>>>>>>> about
> >>>>>>>>>>>>>>>> the changes to the RFC Editor.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> [VS] I see your point. Yes, adding these instructions as a
> >>>>>>>>>>>>>>> separate
> >>>>>>>>>>>>>>> note works for me.
> >>>>>>>>>>>>>>> And in this case there is no need to make any text (other
> >>>>>>>>>>>>>>> than
> >>>>>>>>>>>>>>> "Note")
> >>>>>>>>>>>>>>> in bold.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> I suggest to change "The role of the designated expert is
> >>>>>>>>>>>>>>> described
> >>>>>>>>>>>>>>> in
> >>>>>>>>>>>>>>> [RFC-ietf-ipsecme-ikev2-multiple-ke-12]." to
> >>>>>>>>>>>>>>> "The instructions for the designated experts are described
> >>>>>>>>>>>>>>> in
> >>>>>>>>>>>>>>> [RFC-
> >>>>>>>>>>>>>>> ietf-ipsecme-ikev2-multiple-ke-12]."
> >>>>>>>>>>>>>>> (because "the role" in my understanding is something more
> >>>>>>>>>>>>>>> general,
> >>>>>>>>>>>>>>> I
> >>>>>>>>>>>>>>> think it is defined in RFC 5226)
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> After re-reading the instructions text itself, I think that
> >>>>>>>>>>>>>>> it
> >>>>>>>>>>>>>>> is
> >>>>>>>>>>>>>>> not
> >>>>>>>>>>>>>>> accurate enough. The second
> >>>>>>>>>>>>>>> restriction followed from the first (obviously, if a KE
> >>>>>>>>>>>>>>> method
> >>>>>>>>>>>>>>> takes
> >>>>>>>>>>>>>>> one round trip, then
> >>>>>>>>>>>>>>> any exchanged public value must fit into a single message).
> >>>>>>>>>>>>>>> I
> >>>>>>>>>>>>>>> think
> >>>>>>>>>>>>>>> it
> >>>>>>>>>>>>>>> should instead state that
> >>>>>>>>>>>>>>> a public value must fit into a single payload. I recall
> >>>>>>>>>>>>>>> that
> >>>>>>>>>>>>>>> originally that was the case and it was me :-(,
> >>>>>>>>>>>>>>> who suggested to change it to its current form (at that
> >>>>>>>>>>>>>>> time I
> >>>>>>>>>>>>>>> was
> >>>>>>>>>>>>>>> thinking about the draft-tjhai-ikev2-beyond-64k-limit
> >>>>>>>>>>>>>>> draft,
> >>>>>>>>>>>>>>> but it is exactly what the last sentence of instructions
> >>>>>>>>>>>>>>> for).
> >>>>>>>>>>>>>>> It
> >>>>>>>>>>>>>>> was
> >>>>>>>>>>>>>>> my mistake. Can we change the instructions text to
> >>>>>>>>>>>>>>> (and notify the RFC Editor about the changes):
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> NEW:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Note
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> The instructions for the designated experts are described
> >>>>>>>>>>>>>>> in
> >>>>>>>>>>>>>>> [RFC-ietf-ipsecme-ikev2-multiple-ke-12]. While
> >>>>>>>>>>>>>>> adding new Key Exchange methods, the following
> >>>>>>>>>>>>>>> considerations must be applied. A Key Exchange method
> >>>>>>>>>>>>>>> must take exactly one round-trip (one IKEv2 exchange)
> >>>>>>>>>>>>>>> and at the end of this exchange, both peers must be
> >>>>>>>>>>>>>>> able to derive the shared secret. In addition, any
> >>>>>>>>>>>>>>> public value that peers exchanged during a Key Exchange
> >>>>>>>>>>>>>>> method must fit into a single IKEv2 payload. If these
> >>>>>>>>>>>>>>> restrictions are not met for a Key Exchange method,
> >>>>>>>>>>>>>>> then there must be documentation on how this Key
> >>>>>>>>>>>>>>> Exchange method is used in IKEv2.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Thank you,
> >>>>>>>>>>>>>>> Valery.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Thank you,
> >>>>>>>>>>>>>>>> Sabrina
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> cheers
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> On Tue, Dec 20, 2022 at 11:03 AM Valery Smyslov
> >>>>>>>>>>>>>>>>> <[e-mail]>
> >>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>> HI Sabrina,
> >>>>>>>>>>>>>>>>> all looks good, except for one minor nit. Please, see
> >>>>>>>>>>>>>>>>> [VS]
> >>>>>>>>>>>>>>>>> inline.
> >>>>>>>>>>>>>>>>>> -----Original Message-----
> >>>>>>>>>>>>>>>>>> From: Sabrina Tanamal via RT [mailto:drafts-
> >>>>>>>>>>>>>>>>>> [e-mail]]
> >>>>>>>>>>>>>>>>>> Sent: Monday, December 19, 2022 11:39 PM
> >>>>>>>>>>>>>>>>>> Cc: [e-mail]; [e-mail];
> >>>>>>>>>>>>>>>>>> [e-mail];
> >>>>>>>>>>>>>>>>>> [e-mail]; mt@post-
> >>>>>>>>>>>>>>>>>> quantum.com; [e-mail]; [e-mail];
> >>>>>>>>>>>>>>>>>> [e-mail]; [e-mail];
> >>>>>>>>>>>>>>>>>> [e-mail]; [e-mail]
> >>>>>>>>>>>>>>>>>> Subject: [***SPAM***] [IANA #1262332] Protocol
> >>>>>>>>>>>>>>>>>> Action:
> >>>>>>>>>>>>>>>>>> 'Multiple
> >>>>>>>>>>>>>>>>>> Key
> >>>>>>>>>>>>>>>>>> Exchanges in IKEv2' to Proposed
> >>>>>>>>>>>>>>>>>> Standard (draft-ietf-ipsecme-ikev2-multiple-ke-
> >>>>>>>>>>>>>>>>>> 12.txt)
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Hi Valery,
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Please see [ST] below.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> On Thu Dec 15 14:26:23 2022, [e-mail] wrote:
> >>>>>>>>>>>>>>>>>>> Hi Sabrina,
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> please, see inline.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> -----Original Message-----
> >>>>>>>>>>>>>>>>>>>> From: Sabrina Tanamal via RT [mailto:drafts-
> >>>>>>>>>>>>>>>>>>>> [e-mail]]
> >>>>>>>>>>>>>>>>>>>> Sent: Wednesday, December 14, 2022 10:17 PM
> >>>>>>>>>>>>>>>>>>>> Cc: [e-mail]; [e-mail];
> >>>>>>>>>>>>>>>>>>>> [e-mail];
> >>>>>>>>>>>>>>>>>>>> [e-mail];
> >>>>>>>>>>>>>>>>>>>> [e-mail]; [e-mail]; oscar.garcia-
> >>>>>>>>>>>>>>>>>>>> [e-mail];
> >>>>>>>>>>>>>>>>>>>> [e-mail];
> >>>>>>>>>>>>>>>>>>>> [e-mail]; [e-mail]; mt@post-
> >>>>>>>>>>>>>>>>>>>> quantum.com
> >>>>>>>>>>>>>>>>>>>> Subject: [IANA #1262332] Protocol Action:
> >>>>>>>>>>>>>>>>>>>> 'Multiple
> >>>>>>>>>>>>>>>>>>>> Key
> >>>>>>>>>>>>>>>>>>>> Exchanges
> >>>>>>>>>>>>>>>>>>>> in
> >>>>>>>>>>>>>>>>>>>> IKEv2' to Proposed Standard (draft-
> >>>>>>>>>>>>>>>>>>>> ietf-ipsecme-ikev2-multiple-ke-12.txt)
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Dear Authors:
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> ATTENTION: A RESPONSE TO THIS MESSAGE IS
> NEEDED
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> We've completed the registry actions for the
> >>>>>>>>>>>>>>>>>>>> following
> >>>>>>>>>>>>>>>>>>>> RFC-
> >>>>>>>>>>>>>>>>>>>> to-be:
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> draft-ietf-ipsecme-ikev2-multiple-ke-12
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> QUESTION: Should the instructions for the
> >>>>>>>>>>>>>>>>>>>> designated
> >>>>>>>>>>>>>>>>>>>> experts
> >>>>>>>>>>>>>>>>>>>> in
> >>>>>>>>>>>>>>>>>>>> Section 3.1 be added as a note in the
> >>>>>>>>>>>>>>>>>>>> Transform Type 4 - Key Exchange Method Transform
> >>>>>>>>>>>>>>>>>>>> IDs
> >>>>>>>>>>>>>>>>>>>> registry?
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Yes. Please, see below.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> ACTION 1:
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> We've added the following entry to the IKEv2
> >>>>>>>>>>>>>>>>>>>> Exchange
> >>>>>>>>>>>>>>>>>>>> Types
> >>>>>>>>>>>>>>>>>>>> registry:
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> 44 IKE_FOLLOWUP_KE [RFC-ietf-ipsecme-ikev2-
> >>>>>>>>>>>>>>>>>>>> multiple-
> >>>>>>>>>>>>>>>>>>>> ke-12]
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Please see
> >>>>>>>>>>>>>>>>>>>> https://www.iana.org/assignments/ikev2-parameters
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> This is correct.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> ACTION 2:
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> We've made the following changes in the Transform
> >>>>>>>>>>>>>>>>>>>> Type
> >>>>>>>>>>>>>>>>>>>> Values
> >>>>>>>>>>>>>>>>>>>> registry:
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> - Renamed Transform Type 4 to "Key Exchange
> >>>>>>>>>>>>>>>>>>>> Method
> >>>>>>>>>>>>>>>>>>>> (KE)"
> >>>>>>>>>>>>>>>>>>>> and
> >>>>>>>>>>>>>>>>>>>> listed
> >>>>>>>>>>>>>>>>>>>> this document as an additional
> >>>>>>>>>>>>>>>>>>>> reference.
> >>>>>>>>>>>>>>>>>>>> - Added the following entries:
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> 6 Additional Key Exchange 1 (optional in
> >>>>>>>>>>>>>>>>>>>> IKE,
> >>>>>>>>>>>>>>>>>>>> AH,
> >>>>>>>>>>>>>>>>>>>> ESP)
> >>>>>>>>>>>>>>>>>>>> [RFC-ietf-ipsecme-ikev2-multiple-ke-
> >>>>>>>>>>>>>>>>>>>> 12]
> >>>>>>>>>>>>>>>>>>>> 7 Additional Key Exchange 2 (optional in
> >>>>>>>>>>>>>>>>>>>> IKE,
> >>>>>>>>>>>>>>>>>>>> AH,
> >>>>>>>>>>>>>>>>>>>> ESP)
> >>>>>>>>>>>>>>>>>>>> [RFC-ietf-ipsecme-ikev2-multiple-ke-
> >>>>>>>>>>>>>>>>>>>> 12]
> >>>>>>>>>>>>>>>>>>>> 8 Additional Key Exchange 3 (optional in
> >>>>>>>>>>>>>>>>>>>> IKE,
> >>>>>>>>>>>>>>>>>>>> AH,
> >>>>>>>>>>>>>>>>>>>> ESP)
> >>>>>>>>>>>>>>>>>>>> [RFC-ietf-ipsecme-ikev2-multiple-ke-
> >>>>>>>>>>>>>>>>>>>> 12]
> >>>>>>>>>>>>>>>>>>>> 9 Additional Key Exchange 4 (optional in
> >>>>>>>>>>>>>>>>>>>> IKE,
> >>>>>>>>>>>>>>>>>>>> AH,
> >>>>>>>>>>>>>>>>>>>> ESP)
> >>>>>>>>>>>>>>>>>>>> [RFC-ietf-ipsecme-ikev2-multiple-ke-
> >>>>>>>>>>>>>>>>>>>> 12]
> >>>>>>>>>>>>>>>>>>>> 10 Additional Key Exchange 5 (optional in
> >>>>>>>>>>>>>>>>>>>> IKE,
> >>>>>>>>>>>>>>>>>>>> AH,
> >>>>>>>>>>>>>>>>>>>> ESP)
> >>>>>>>>>>>>>>>>>>>> [RFC-ietf-ipsecme-ikev2-multiple-ke-
> >>>>>>>>>>>>>>>>>>>> 12]
> >>>>>>>>>>>>>>>>>>>> 11 Additional Key Exchange 6 (optional in
> >>>>>>>>>>>>>>>>>>>> IKE,
> >>>>>>>>>>>>>>>>>>>> AH,
> >>>>>>>>>>>>>>>>>>>> ESP)
> >>>>>>>>>>>>>>>>>>>> [RFC-ietf-ipsecme-ikev2-multiple-ke-
> >>>>>>>>>>>>>>>>>>>> 12]
> >>>>>>>>>>>>>>>>>>>> 12 Additional Key Exchange 7 (optional in
> >>>>>>>>>>>>>>>>>>>> IKE,
> >>>>>>>>>>>>>>>>>>>> AH,
> >>>>>>>>>>>>>>>>>>>> ESP)
> >>>>>>>>>>>>>>>>>>>> [RFC-ietf-ipsecme-ikev2-multiple-ke-
> >>>>>>>>>>>>>>>>>>>> 12]
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> These actions are correct.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> - Added the following note:
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Transform Type "Transform Type 4 - Key Exchange
> >>>>>>>>>>>>>>>>>>>> Method
> >>>>>>>>>>>>>>>>>>>> Transform IDs" was originally named "Transform
> >>>>>>>>>>>>>>>>>>>> Type 4
> >>>>>>>>>>>>>>>>>>>> -
> >>>>>>>>>>>>>>>>>>>> Diffie-Hellman Group Transform IDs" and was
> >>>>>>>>>>>>>>>>>>>> renamed
> >>>>>>>>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>>>>> its current name by [RFC-ietf-ipsecme-ikev2-
> >>>>>>>>>>>>>>>>>>>> multiple-
> >>>>>>>>>>>>>>>>>>>> ke-
> >>>>>>>>>>>>>>>>>>>> 12].
> >>>>>>>>>>>>>>>>>>>> It has been referenced in its original name in a
> >>>>>>>>>>>>>>>>>>>> number
> >>>>>>>>>>>>>>>>>>>> of
> >>>>>>>>>>>>>>>>>>>> RFCs prior to [RFC-ietf-ipsecme-ikev2-multiple-
> >>>>>>>>>>>>>>>>>>>> ke-
> >>>>>>>>>>>>>>>>>>>> 12].
> >>>>>>>>>>>>>>>>>>>> All "Additional Key Exchange" entries use the
> >>>>>>>>>>>>>>>>>>>> same
> >>>>>>>>>>>>>>>>>>>> "Transform
> >>>>>>>>>>>>>>>>>>>> Type 4 - Key Exchange Method Transform IDs" as
> >>>>>>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>> "Key
> >>>>>>>>>>>>>>>>>>>> Exchange Method (KE)".
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> While this is a correct action as it is stated in
> >>>>>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>> draft,
> >>>>>>>>>>>>>>>>>>> we suggest that some editorial changes be done
> >>>>>>>>>>>>>>>>>>> for the sake of clarity and readability:
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> OLD:
> >>>>>>>>>>>>>>>>>>> Note
> >>>>>>>>>>>>>>>>>>> Transform Type "Transform Type 4 - Key Exchange
> >>>>>>>>>>>>>>>>>>> Method
> >>>>>>>>>>>>>>>>>>> Transform IDs" was originally named "Transform Type
> >>>>>>>>>>>>>>>>>>> 4
> >>>>>>>>>>>>>>>>>>> -
> >>>>>>>>>>>>>>>>>>> Diffie-Hellman Group Transform IDs" and was renamed
> >>>>>>>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>>>> its current name by [RFC-ietf-ipsecme-ikev2-
> >>>>>>>>>>>>>>>>>>> multiple-
> >>>>>>>>>>>>>>>>>>> ke-
> >>>>>>>>>>>>>>>>>>> 12].
> >>>>>>>>>>>>>>>>>>> It has been referenced in its original name in a
> >>>>>>>>>>>>>>>>>>> number of
> >>>>>>>>>>>>>>>>>>> RFCs prior to [RFC-ietf-ipsecme-ikev2-multiple-ke-
> >>>>>>>>>>>>>>>>>>> 12].
> >>>>>>>>>>>>>>>>>>> All "Additional Key Exchange" entries use the same
> >>>>>>>>>>>>>>>>>>> "Transform
> >>>>>>>>>>>>>>>>>>> Type 4 - Key Exchange Method Transform IDs" as the
> >>>>>>>>>>>>>>>>>>> "Key
> >>>>>>>>>>>>>>>>>>> Exchange Method (KE)".
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> NEW:
> >>>>>>>>>>>>>>>>>>> Note
> >>>>>>>>>>>>>>>>>>> "Transform Type 4 - Key Exchange Method
> >>>>>>>>>>>>>>>>>>> Transform IDs" was originally named "Transform Type
> >>>>>>>>>>>>>>>>>>> 4
> >>>>>>>>>>>>>>>>>>> -
> >>>>>>>>>>>>>>>>>>> Diffie-Hellman Group Transform IDs" and was renamed
> >>>>>>>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>>>> its current name by [RFC-ietf-ipsecme-ikev2-
> >>>>>>>>>>>>>>>>>>> multiple-
> >>>>>>>>>>>>>>>>>>> ke-
> >>>>>>>>>>>>>>>>>>> 12].
> >>>>>>>>>>>>>>>>>>> It has been referenced in its original name in a
> >>>>>>>>>>>>>>>>>>> number of
> >>>>>>>>>>>>>>>>>>> RFCs published prior to the publication of [RFC-
> >>>>>>>>>>>>>>>>>>> ietf-
> >>>>>>>>>>>>>>>>>>> ipsecme-
> >>>>>>>>>>>>>>>>>>> ikev2-
> >>>>>>>>>>>>>>>>>>> multiple-ke-12].
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Note
> >>>>>>>>>>>>>>>>>>> All "Additional Key Exchange *" transform types use
> >>>>>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>> same
> >>>>>>>>>>>>>>>>>>> "Transform
> >>>>>>>>>>>>>>>>>>> Type 4 - Key Exchange Method Transform IDs"
> >>>>>>>>>>>>>>>>>>> registry
> >>>>>>>>>>>>>>>>>>> as
> >>>>>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>> "Key
> >>>>>>>>>>>>>>>>>>> Exchange Method (KE)" transform type.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> The summary of the changes:
> >>>>>>>>>>>>>>>>>>> - split the note into two
> >>>>>>>>>>>>>>>>>>> - change "Additional Key Exchange" to "Additional
> >>>>>>>>>>>>>>>>>>> Key
> >>>>>>>>>>>>>>>>>>> Exchange
> >>>>>>>>>>>>>>>>>>> *"
> >>>>>>>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>>>> indicate there are multiple such transform types
> >>>>>>>>>>>>>>>>>>> - add "registry" after the "Transform Type 4 - Key
> >>>>>>>>>>>>>>>>>>> Exchange
> >>>>>>>>>>>>>>>>>>> Method
> >>>>>>>>>>>>>>>>>>> Transform IDs" for clarity
> >>>>>>>>>>>>>>>>>>> - add "transform type" after the transform type
> >>>>>>>>>>>>>>>>>>> names
> >>>>>>>>>>>>>>>>>>> (as a
> >>>>>>>>>>>>>>>>>>> clarification) and remove this clarification at the
> >>>>>>>>>>>>>>>>>>> beginning
> >>>>>>>>>>>>>>>>>>> of
> >>>>>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>> note (for readability)
> >>>>>>>>>>>>>>>>>>> - change "in a number of RFCs prior to" to "in a
> >>>>>>>>>>>>>>>>>>> number
> >>>>>>>>>>>>>>>>>>> of
> >>>>>>>>>>>>>>>>>>> RFCs
> >>>>>>>>>>>>>>>>>>> published prior to the publication of"
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> [ST] Done. Please see
> >>>>>>>>>>>>>>>>>> https://www.iana.org/assignments/ikev2-
> >>>>>>>>>>>>>>>>>> parameters/ikev2-
> >>>>>>>>>>>>>>>>>> parameters.xhtml#ikev2-parameters-3.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Please see
> >>>>>>>>>>>>>>>>>>>> https://www.iana.org/assignments/ikev2-parameters
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> ACTION 3:
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> We've made the following changes in the Transform
> >>>>>>>>>>>>>>>>>>>> Type 4
> >>>>>>>>>>>>>>>>>>>> -
> >>>>>>>>>>>>>>>>>>>> Key
> >>>>>>>>>>>>>>>>>>>> Exchange Method Transform IDs
> >>>>>>>>>>>>>>>>>>>> registry:
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> - Renamed the "Transform Type 4 - Diffie-Hellman
> >>>>>>>>>>>>>>>>>>>> Group
> >>>>>>>>>>>>>>>>>>>> Transform
> >>>>>>>>>>>>>>>>>>>> IDs"
> >>>>>>>>>>>>>>>>>>>> registry to "Transform Type 4 -
> >>>>>>>>>>>>>>>>>>>> Key Exchange Method Transform IDs" registry and
> >>>>>>>>>>>>>>>>>>>> listed
> >>>>>>>>>>>>>>>>>>>> this
> >>>>>>>>>>>>>>>>>>>> document
> >>>>>>>>>>>>>>>>>>>> as an additional reference.
> >>>>>>>>>>>>>>>>>>>> - Replaced the note in the Transform Type 4 - Key
> >>>>>>>>>>>>>>>>>>>> Exchange
> >>>>>>>>>>>>>>>>>>>> Method
> >>>>>>>>>>>>>>>>>>>> Transform IDs registry as follows:
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> This registry was originally named "Transform
> >>>>>>>>>>>>>>>>>>>> Type 4
> >>>>>>>>>>>>>>>>>>>> -
> >>>>>>>>>>>>>>>>>>>> Diffie-Hellman Group Transform IDs" and was
> >>>>>>>>>>>>>>>>>>>> renamed
> >>>>>>>>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>>>>> its current name by [RFC-ietf-ipsecme-ikev2-
> >>>>>>>>>>>>>>>>>>>> multiple-
> >>>>>>>>>>>>>>>>>>>> ke-
> >>>>>>>>>>>>>>>>>>>> 12].
> >>>>>>>>>>>>>>>>>>>> It has been referenced in its original name in a
> >>>>>>>>>>>>>>>>>>>> number
> >>>>>>>>>>>>>>>>>>>> of RFCs prior to [RFC-ietf-ipsecme-ikev2-
> >>>>>>>>>>>>>>>>>>>> multiple-ke-
> >>>>>>>>>>>>>>>>>>>> 12].
> >>>>>>>>>>>>>>>>>>>> To find out requirement levels for Key Exchange
> >>>>>>>>>>>>>>>>>>>> Methods
> >>>>>>>>>>>>>>>>>>>> for IKEv2, see [RFC8247].
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> - Added a new note:
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> All "Additional Key Exchange" entries use these
> >>>>>>>>>>>>>>>>>>>> values
> >>>>>>>>>>>>>>>>>>>> as the "Key Exchange Method (KE)".
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Please see
> >>>>>>>>>>>>>>>>>>>> https://www.iana.org/assignments/ikev2-parameters
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> While this is a correct action as it is stated in
> >>>>>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>> draft,
> >>>>>>>>>>>>>>>>>>> we suggest that some editorial changes be done
> >>>>>>>>>>>>>>>>>>> for the sake of clarity and readability. This
> >>>>>>>>>>>>>>>>>>> suggestion
> >>>>>>>>>>>>>>>>>>> also
> >>>>>>>>>>>>>>>>>>> includes the instructions for the DEs.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> OLD:
> >>>>>>>>>>>>>>>>>>> Note
> >>>>>>>>>>>>>>>>>>> This registry was originally named "Transform Type
> >>>>>>>>>>>>>>>>>>> 4 -
> >>>>>>>>>>>>>>>>>>> Diffie-Hellman Group Transform IDs" and was renamed
> >>>>>>>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>>>> its current name by [RFC-ietf-ipsecme-ikev2-
> >>>>>>>>>>>>>>>>>>> multiple-
> >>>>>>>>>>>>>>>>>>> ke-
> >>>>>>>>>>>>>>>>>>> 12].
> >>>>>>>>>>>>>>>>>>> It has been referenced in its original name in a
> >>>>>>>>>>>>>>>>>>> number
> >>>>>>>>>>>>>>>>>>> of RFCs prior to [RFC-ietf-ipsecme-ikev2-multiple-
> >>>>>>>>>>>>>>>>>>> ke-
> >>>>>>>>>>>>>>>>>>> 12].
> >>>>>>>>>>>>>>>>>>> To find out requirement levels for Key Exchange
> >>>>>>>>>>>>>>>>>>> Methods
> >>>>>>>>>>>>>>>>>>> for IKEv2, see [RFC8247].
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Note
> >>>>>>>>>>>>>>>>>>> All "Additional Key Exchange" entries use these
> >>>>>>>>>>>>>>>>>>> values
> >>>>>>>>>>>>>>>>>>> as the "Key Exchange Method (KE)".
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> NEW:
> >>>>>>>>>>>>>>>>>>> Note
> >>>>>>>>>>>>>>>>>>> This registry was originally named "Transform Type
> >>>>>>>>>>>>>>>>>>> 4 -
> >>>>>>>>>>>>>>>>>>> Diffie-Hellman Group Transform IDs" and was renamed
> >>>>>>>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>>>> its current name by [RFC-ietf-ipsecme-ikev2-
> >>>>>>>>>>>>>>>>>>> multiple-
> >>>>>>>>>>>>>>>>>>> ke-
> >>>>>>>>>>>>>>>>>>> 12].
> >>>>>>>>>>>>>>>>>>> It has been referenced in its original name in a
> >>>>>>>>>>>>>>>>>>> number
> >>>>>>>>>>>>>>>>>>> of RFCs published prior to the publication of [RFC-
> >>>>>>>>>>>>>>>>>>> ietf-
> >>>>>>>>>>>>>>>>>>> ipsecme-
> >>>>>>>>>>>>>>>>>>> ikev2-
> >>>>>>>>>>>>>>>>>>> multiple-ke-12].
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Note
> >>>>>>>>>>>>>>>>>>> All "Additional Key Exchange *" transform types use
> >>>>>>>>>>>>>>>>>>> these
> >>>>>>>>>>>>>>>>>>> values,
> >>>>>>>>>>>>>>>>>>> as well as the "Key Exchange Method (KE)" transform
> >>>>>>>>>>>>>>>>>>> type.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Note
> >>>>>>>>>>>>>>>>>>> To find out requirement levels for Key Exchange
> >>>>>>>>>>>>>>>>>>> Methods
> >>>>>>>>>>>>>>>>>>> for IKEv2, see [RFC8247].
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Instructions for Designated Experts
> >>>>>>>>>>>>>>>>>>> While adding new Key Exchange methods, the
> >>>>>>>>>>>>>>>>>>> following
> >>>>>>>>>>>>>>>>>>> considerations
> >>>>>>>>>>>>>>>>>>> must be
> >>>>>>>>>>>>>>>>>>> applied. A Key Exchange method must take exactly
> >>>>>>>>>>>>>>>>>>> one
> >>>>>>>>>>>>>>>>>>> round-
> >>>>>>>>>>>>>>>>>>> trip
> >>>>>>>>>>>>>>>>>>> (one
> >>>>>>>>>>>>>>>>>>> IKEv2
> >>>>>>>>>>>>>>>>>>> exchange) and at the end of this exchange, both
> >>>>>>>>>>>>>>>>>>> peers
> >>>>>>>>>>>>>>>>>>> must
> >>>>>>>>>>>>>>>>>>> be
> >>>>>>>>>>>>>>>>>>> able
> >>>>>>>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>>>> derive the shared secret. In addition, any public
> >>>>>>>>>>>>>>>>>>> value
> >>>>>>>>>>>>>>>>>>> peers
> >>>>>>>>>>>>>>>>>>> exchanged during a Key Exchange method must fit
> >>>>>>>>>>>>>>>>>>> into a
> >>>>>>>>>>>>>>>>>>> single
> >>>>>>>>>>>>>>>>>>> IKE
> >>>>>>>>>>>>>>>>>>> message. If
> >>>>>>>>>>>>>>>>>>> these restrictions are not met for a Key Exchange
> >>>>>>>>>>>>>>>>>>> method,
> >>>>>>>>>>>>>>>>>>> then
> >>>>>>>>>>>>>>>>>>> there
> >>>>>>>>>>>>>>>>>>> must be
> >>>>>>>>>>>>>>>>>>> documentation on how this Key Exchange method is
> >>>>>>>>>>>>>>>>>>> used
> >>>>>>>>>>>>>>>>>>> in
> >>>>>>>>>>>>>>>>>>> IKEv2.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> The summary of the changes:
> >>>>>>>>>>>>>>>>>>> - split the note into three (and change the order)
> >>>>>>>>>>>>>>>>>>> and
> >>>>>>>>>>>>>>>>>>> add
> >>>>>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>> instructions for DEs as an additional note with a
> >>>>>>>>>>>>>>>>>>> title
> >>>>>>>>>>>>>>>>>>> "Instructions
> >>>>>>>>>>>>>>>>>>> for Designated Experts"
> >>>>>>>>>>>>>>>>>>> - change "Additional Key Exchange" to "Additional
> >>>>>>>>>>>>>>>>>>> Key
> >>>>>>>>>>>>>>>>>>> Exchange
> >>>>>>>>>>>>>>>>>>> *"
> >>>>>>>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>>>> indicate there are multiple such transform types
> >>>>>>>>>>>>>>>>>>> - add "transform type" after the transform type
> >>>>>>>>>>>>>>>>>>> names
> >>>>>>>>>>>>>>>>>>> as a
> >>>>>>>>>>>>>>>>>>> clarification
> >>>>>>>>>>>>>>>>>>> - change "entries use these values as the" to
> >>>>>>>>>>>>>>>>>>> "transform
> >>>>>>>>>>>>>>>>>>> types
> >>>>>>>>>>>>>>>>>>> use
> >>>>>>>>>>>>>>>>>>> these values, as well as the"
> >>>>>>>>>>>>>>>>>>> - change "in a number of RFCs prior to" to "in a
> >>>>>>>>>>>>>>>>>>> number
> >>>>>>>>>>>>>>>>>>> of
> >>>>>>>>>>>>>>>>>>> RFCs
> >>>>>>>>>>>>>>>>>>> published prior to the publication of"
> >>>>>>>>>>>>>>>>>>> - the instructions for DEs are taken from the draft
> >>>>>>>>>>>>>>>>>>> intact,
> >>>>>>>>>>>>>>>>>>> except
> >>>>>>>>>>>>>>>>>>> that all uses of "KE" are expanded to "Key
> >>>>>>>>>>>>>>>>>>> Exchange"
> >>>>>>>>>>>>>>>>>>> and "IKE exchange" is changed to "IKEv2 exchange"
> >>>>>>>>>>>>>>>>>>> for
> >>>>>>>>>>>>>>>>>>> clarity
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> [ST] Done. Please see
> >>>>>>>>>>>>>>>>>> https://www.iana.org/assignments/ikev2-
> >>>>>>>>>>>>>>>>>> parameters/ikev2-
> >>>>>>>>>>>>>>>>>> parameters.xhtml#ikev2-parameters-8.
> >>>>>>>>>>>>>>>>> [VS] Thank you for making this changes. One minor nit:
> >>>>>>>>>>>>>>>>> can we make the line "Instructions for Designated
> >>>>>>>>>>>>>>>>> Experts"
> >>>>>>>>>>>>>>>>> a
> >>>>>>>>>>>>>>>>> subtitle?
> >>>>>>>>>>>>>>>>> In other words, can we unindent it and type it in bold,
> >>>>>>>>>>>>>>>>> as
> >>>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>> "Note"
> >>>>>>>>>>>>>>>>> above
> >>>>>>>>>>>>>>>>> (and in this case the colon at the end of the line
> >>>>>>>>>>>>>>>>> should
> >>>>>>>>>>>>>>>>> be
> >>>>>>>>>>>>>>>>> removed)?
> >>>>>>>>>>>>>>>>> It's a minor nit, but it is my feeling, that the
> >>>>>>>>>>>>>>>>> instructions
> >>>>>>>>>>>>>>>>> deserve
> >>>>>>>>>>>>>>>>> their own subtitle.
> >>>>>>>>>>>>>>>>> So I propose:
> >>>>>>>>>>>>>>>>> <bold>Instructions for Designated Experts</bold>
> >>>>>>>>>>>>>>>>> While adding new Key Exchange methods, the
> >>>>>>>>>>>>>>>>> following
> >>>>>>>>>>>>>>>>> considerations must be applied. A Key Exchange
> >>>>>>>>>>>>>>>>> method
> >>>>>>>>>>>>>>>>> must take exactly one round-trip (one IKEv2
> >>>>>>>>>>>>>>>>> exchange)
> >>>>>>>>>>>>>>>>> and at the end of this exchange, both peers must be
> >>>>>>>>>>>>>>>>> able to derive the shared secret. In addition, any
> >>>>>>>>>>>>>>>>> public value peers exchanged during a Key Exchange
> >>>>>>>>>>>>>>>>> method must fit into a single IKE message. If these
> >>>>>>>>>>>>>>>>> restrictions are not met for a Key Exchange method,
> >>>>>>>>>>>>>>>>> then there must be documentation on how this Key
> >>>>>>>>>>>>>>>>> Exchange method is used in IKEv2.
> >>>>>>>>>>>>>>>>> Regards,
> >>>>>>>>>>>>>>>>> Valery.
> >>>>>>>>>>>>>>>>>> [ST] Can you confirm that these changes have been
> >>>>>>>>>>>>>>>>>> completed
> >>>>>>>>>>>>>>>>>> correctly? If so, I'll tell the RFC Editor the
> >>>>>>>>>>>>>>>>>> IANA actions are complete.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> ACTION 4:
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> We've added the following entry to the IKEv2
> >>>>>>>>>>>>>>>>>>>> Notify
> >>>>>>>>>>>>>>>>>>>> Message
> >>>>>>>>>>>>>>>>>>>> Types
> >>>>>>>>>>>>>>>>>>>> -
> >>>>>>>>>>>>>>>>>>>> Status Types registry:
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> 16442 USE_AGGFRAG [RFC-ietf-ipsecme-iptfs-19]
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> This is a typo in the message (this action is for a
> >>>>>>>>>>>>>>>>>>> different
> >>>>>>>>>>>>>>>>>>> draft).
> >>>>>>>>>>>>>>>>>>> The correct action, which is already present on the
> >>>>>>>>>>>>>>>>>>> IANA
> >>>>>>>>>>>>>>>>>>> registry
> >>>>>>>>>>>>>>>>>>> page, is:
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> [ST] Sorry for the typo.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Thank you,
> >>>>>>>>>>>>>>>>>> Sabrina
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> 16441 ADDITIONAL_KEY_EXCHANGE [RFC-ietf-
> >>>>>>>>>>>>>>>>>>> ipsecme-
> >>>>>>>>>>>>>>>>>>> ikev2-
> >>>>>>>>>>>>>>>>>>> multiple-ke-12]
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Please see
> >>>>>>>>>>>>>>>>>>>> https://www.iana.org/assignments/ikev2-parameters
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> ACTION 5:
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> We've added the following entry to the IKEv2
> >>>>>>>>>>>>>>>>>>>> Notify
> >>>>>>>>>>>>>>>>>>>> Message
> >>>>>>>>>>>>>>>>>>>> Types
> >>>>>>>>>>>>>>>>>>>> -
> >>>>>>>>>>>>>>>>>>>> Error Types registry:
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> 47 STATE_NOT_FOUND [RFC-ietf-ipsecme-ikev2-
> >>>>>>>>>>>>>>>>>>>> multiple-
> >>>>>>>>>>>>>>>>>>>> ke-12]
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Please see
> >>>>>>>>>>>>>>>>>>>> https://www.iana.org/assignments/ikev2-parameters
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> This action is correct.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Regards,
> >>>>>>>>>>>>>>>>>>> Valery (on behalf of authors).
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Please let us know whether this document's
> >>>>>>>>>>>>>>>>>>>> registry
> >>>>>>>>>>>>>>>>>>>> actions
> >>>>>>>>>>>>>>>>>>>> have
> >>>>>>>>>>>>>>>>>>>> been
> >>>>>>>>>>>>>>>>>>>> completed correctly. Once we
> >>>>>>>>>>>>>>>>>>>> receive your confirmation, we'll notify the RFC
> >>>>>>>>>>>>>>>>>>>> Editor
> >>>>>>>>>>>>>>>>>>>> that
> >>>>>>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>> actions are complete. If a team of authors
> >>>>>>>>>>>>>>>>>>>> is responsible for the document, and the actions
> >>>>>>>>>>>>>>>>>>>> have
> >>>>>>>>>>>>>>>>>>>> been
> >>>>>>>>>>>>>>>>>>>> performed
> >>>>>>>>>>>>>>>>>>>> correctly, please send a single
> >>>>>>>>>>>>>>>>>>>> confirmation message.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> We'll update any references to this document in
> >>>>>>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>> registries
> >>>>>>>>>>>>>>>>>>>> when
> >>>>>>>>>>>>>>>>>>>> the RFC Editor notifies us that
> >>>>>>>>>>>>>>>>>>>> they've assigned an RFC number.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Best regards,
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Sabrina Tanamal
> >>>>>>>>>>>>>>>>>>>> Lead IANA Services Specialist
> >>>>>>>>>>
> >>>>>>>>>>> 5) Please review these differences between the current 2nd note
> in
> >>>>>>>>>>> the
> >>>>>>>>>>> “Transform Type Values” registry and the document:
> >>>>>>>>>>>
> >>>>>>>>>>> Current registry:
> >>>>>>>>>>> Note
> >>>>>>>>>>> All "Additional Key Exchange *" transform types use the same
> >>>>>>>>>>> "Transform Type 4 - Key Exchange Method Transform IDs"
> >>>>>>>>>>> registry as the "Key Exchange Method (KE)" transform type.
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> Current document:
> >>>>>>>>>>>   All "Additional Key Exchange" entries use the same "Transform
> >>>>>>>>>>> Type
> >>>>>>>>>>>   4 - Key Exchange Method Transform IDs" as the "Key Exchange
> >>>>>>>>>>> Method
> >>>>>>>>>>>   (KE)".
> >>>>>>>>>>>
> >>>>>>>>>>> 6) Please review the 2nd note of the “Transform Type 4 - Key
> >>>>>>>>>>> Exchange
> >>>>>>>>>>> Method Transform IDs” registry with what is listed in the
> document:
> >>>>>>>>>>>
> >>>>>>>>>>> Current registry:
> >>>>>>>>>>> Note
> >>>>>>>>>>> All "Additional Key Exchange *" transform types use these
> >>>>>>>>>>> values, as well as the "Key Exchange Method (KE)"
> >>>>>>>>>>> transform type.
> >>>>>>>>>>>
> >>>>>>>>>>> Current document:
> >>>>>>>>>>> All "Additional Key Exchange" entries use these values as the
> “Key
> >>>>>>>>>>> Exchange Method (KE)".
> >>>>>>>>>>>
> >>>>>>>>>>> Thank you.
> >>>>>>>>>>>
> >>>>>>>>>>> RFC Editor/mf
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>> On Apr 28, 2023, at 1:54 PM, Garcia Morchon O, Oscar
> >>>>>>>>>>>> <oscar.garcia-
> >>>>>>>>>>>> [e-mail]> wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>> Hi all,
> >>>>>>>>>>>>
> >>>>>>>>>>>> I approve these changes.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Kind regards, Oscar.
> >>>>>>>>>>>>
> >>>>>>>>>>>> On 27/04/2023, 15:20, "Scott Fluhrer (sfluhrer)"
> >>>>>>>>>>>> <[e-mail]
> >>>>>>>>>>>> <mailto:[e-mail]>> wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> Caution: This e-mail originated from outside of Philips, be
> >>>>>>>>>>>> careful
> >>>>>>>>>>>> for phishing.
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> I approve these changes
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>> -----Original Message-----
> >>>>>>>>>>>>> From: Megan Ferguson <[e-mail]
> >>>>>>>>>>>>> <mailto:[e-mail]>>
> >>>>>>>>>>>>> Sent: Thursday, April 27, 2023 9:09 AM
> >>>>>>>>>>>>> To: [e-mail] <mailto:oscar.garcia-
> >>>>>>>>>>>>> [e-mail]>; Scott Fluhrer (sfluhrer)
> >>>>>>>>>>>>> <[e-mail] <mailto:[e-mail]>>
> >>>>>>>>>>>>> Cc: [e-mail] <mailto:rfc-editor@rfc-
> >>>>>>>>>>>>> editor.org>;
> >>>>>>>>>>>>> [e-mail] <mailto:[e-mail]>;
> mt@post-
> >>>>>>>>>>>>> quantum.com; [e-mail]
> >>>>>>>>>>>>> <mailto:[e-mail]>; Valery Smyslov
> >>>>>>>>>>>>> <[e-mail]
> >>>>>>>>>>>>> <mailto:[e-mail]>>;
> >>>>>>>>>>>>> [e-mail] <mailto:[e-mail]>;
> ipsecme-
> >>>>>>>>>>>>> [e-mail] <mailto:[e-mail]>; Tero Kivinen
> >>>>>>>>>>>>> <[e-mail] <mailto:[e-mail]>>; Roman Danyliw
> >>>>>>>>>>>>> <[e-mail] <mailto:[e-mail]>>; auth48archive@rfc-
> >>>>>>>>>>>>> editor.org; Graham Bartlett <[e-mail]
> >>>>>>>>>>>>> <mailto:[e-mail]>>
> >>>>>>>>>>>>> Subject: Re: AUTH48: RFC-to-be 9370 <draft-ietf-ipsecme-
> ikev2-
> >>>>>>>>>>>>> multiple-ke-
> >>>>>>>>>>>>> 12> for your review
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Authors,
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Thank you for your replies to date. We are currently awaiting
> >>>>>>>>>>>>> approvals
> >>>>>>>>>>>>> from two authors, as indicated at
> >>>>>>>>>>>>>
> https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.rfc-
> >>>>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>
> editor.org%2Fauth48%2Frfc9370&data=05%7C01%7C%7Cc4f02e6ac7714d3405
> c308db472219f8%7C1a40
> >>>>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>
> 7a2d76754d178692b3ac285306e4%7C0%7C0%7C638181984127338856%7CUn
> known%7CTWFpbGZsb3d
> >>>>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>
> 8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3
> D%7C3000%7C%7C%7C&sd
> >>>>>>>>>>
> ata=H7KHAvLFTvw%2F4jhqpqcJVJ4Rti6Dikf681HSaqffDQM%3D&reserved=0
> >>>>>>>>>>>>>
> <https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.rfc
> -
> >>>>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>
> editor.org%2Fauth48%2Frfc9370&amp;data=05%7C01%7C%7Cc4f02e6ac7714d
> 3405c308db472219f8%7C
> >>>>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>
> 1a407a2d76754d178692b3ac285306e4%7C0%7C0%7C638181984127338856%
> 7CUnknown%7CTWFpbGZs
> >>>>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>
> b3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0
> %3D%7C3000%7C%7C%7C
> >>>>>>>>>>
> &amp;sdata=H7KHAvLFTvw%2F4jhqpqcJVJ4Rti6Dikf681HSaqffDQM%3D&amp;r
> eserved=0>.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Once we have received all approvals, we will move this
> document
> >>>>>>>>>>>>> forward in
> >>>>>>>>>>>>> the publication process.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Thank you.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> RFC Editor/mf
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> On Apr 22, 2023, at 3:32 AM, Graham Bartlett
> >>>>>>>>>>>>>> <[e-mail]
> >>>>>>>>>>>>>> <mailto:[e-mail]>>
> >>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Hi
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> I approve this RFC for publication.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> As per;
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> To approve your RFC for publication, please reply to this
> email
> >>>>>>>>>>>>>> stating that you approve this RFC for publication. Please use
> >>>>>>>>>>>>>> ‘REPLY
> >>>>>>>>>>>>>> ALL’, as all the parties CCed on this message need to see your
> >>>>>>>>>>>>>> approval.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> cheers
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> On Wed, Feb 22, 2023 at 3:34 PM <[e-mail]
> >>>>>>>>>>>>>> <mailto:[e-mail]>> wrote:
> >>>>>>>>>>>>>> *****IMPORTANT*****
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Updated 2023/02/22
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> RFC Author(s):
> >>>>>>>>>>>>>> --------------
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Instructions for Completing AUTH48
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Your document has now entered AUTH48. Once it has been
> reviewed
> >>>>>>>>>>>>>> and
> >>>>>>>>>>>>>> approved by you and all coauthors, it will be published as an
> >>>>>>>>>>>>>> RFC.
> >>>>>>>>>>>>>> If an author is no longer available, there are several remedies
> >>>>>>>>>>>>>> available as listed in the FAQ
> >>>>>>>>>>>>>>
> (https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rf
> c-
> >>>>>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>
> editor.org%2Ffaq%2F&data=05%7C01%7C%7Cc4f02e6ac7714d3405c308db472
> 219f8%7C1a407a2d76754
> >>>>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>
> d178692b3ac285306e4%7C0%7C0%7C638181984127338856%7CUnknown%7C
> TWFpbGZsb3d8eyJWIjoiM
> >>>>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>
> C4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%
> 7C%7C%7C&sdata=BNpkQ
> >>>>>>>>>> vCnDwM8GG4n4US9lj3hnzEt0kPZoZJ8drz0S6g%3D&reserved=0
> >>>>>>>>>>>>>>
> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rf
> c-
> >>>>>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>
> editor.org%2Ffaq%2F&amp;data=05%7C01%7C%7Cc4f02e6ac7714d3405c308d
> b472219f8%7C1a407a2d7
> >>>>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>
> 6754d178692b3ac285306e4%7C0%7C0%7C638181984127338856%7CUnknow
> n%7CTWFpbGZsb3d8eyJW
> >>>>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>
> IjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3
> 000%7C%7C%7C&amp;sda
> >>>>>>>>>>
> ta=BNpkQvCnDwM8GG4n4US9lj3hnzEt0kPZoZJ8drz0S6g%3D&amp;reserved=0
> >).
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> You and you coauthors are responsible for engaging other
> >>>>>>>>>>>>>> parties
> >>>>>>>>>>>>>> (e.g., Contributors or Working Group) as necessary before
> >>>>>>>>>>>>>> providing
> >>>>>>>>>>>>>> your approval.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Planning your review
> >>>>>>>>>>>>>> ---------------------
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Please review the following aspects of your document:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> * RFC Editor questions
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Please review and resolve any questions raised by the RFC
> >>>>>>>>>>>>>> Editor
> >>>>>>>>>>>>>> that have been included in the XML file as comments marked
> as
> >>>>>>>>>>>>>> follows:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> <!-- [rfced] ... -->
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> These questions will also be sent in a subsequent email.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> * Changes submitted by coauthors
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Please ensure that you review any changes submitted by your
> >>>>>>>>>>>>>> coauthors. We assume that if you do not speak up that you
> >>>>>>>>>>>>>> agree to changes submitted by your coauthors.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> * Content
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Please review the full content of the document, as this cannot
> >>>>>>>>>>>>>> change once the RFC is published. Please pay particular
> >>>>>>>>>>>>>> attention
> >>>>>>>>>>>>>> to:
> >>>>>>>>>>>>>> - IANA considerations updates (if applicable)
> >>>>>>>>>>>>>> - contact information
> >>>>>>>>>>>>>> - references
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> * Copyright notices and legends
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Please review the copyright notice and legends as defined in
> >>>>>>>>>>>>>> RFC 5378 and the Trust Legal Provisions
> >>>>>>>>>>>>>> (TLP –
> >>>>>>>>>>>>>>
> >>>>>>>
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrustee.i
> etf.org%2Flicense-
> >>>>>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>
> info%2F&data=05%7C01%7C%7Cc4f02e6ac7714d3405c308db472219f8%7C1a4
> 07a2d76754d178692b3ac
> >>>>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>
> 285306e4%7C0%7C0%7C638181984127338856%7CUnknown%7CTWFpbGZsb3
> d8eyJWIjoiMC4wLjAwMD
> >>>>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>
> AiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&
> sdata=MyG107uyOeMnTbl
> >>>>>>>>>> nVrUxa7G%2BGrX7X6A4k4e5PlnBLt4%3D&reserved=0
> >>>>>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>
> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrustee
> .ietf.org%2Flicense-
> >>>>>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>
> info%2F&amp;data=05%7C01%7C%7Cc4f02e6ac7714d3405c308db472219f8%7
> C1a407a2d76754d178692
> >>>>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>
> b3ac285306e4%7C0%7C0%7C638181984127338856%7CUnknown%7CTWFpbG
> Zsb3d8eyJWIjoiMC4wLjA
> >>>>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>
> wMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C
> %7C&amp;sdata=MyG107u
> >>>>>>>>>>
> yOeMnTblnVrUxa7G%2BGrX7X6A4k4e5PlnBLt4%3D&amp;reserved=0>).
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> * Semantic markup
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Please review the markup in the XML file to ensure that
> >>>>>>>>>>>>>> elements of
> >>>>>>>>>>>>>> content are correctly tagged. For example, ensure that
> >>>>>>>>>>>>>> <sourcecode>
> >>>>>>>>>>>>>> and <artwork> are set correctly. See details at
> >>>>>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>
> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauthor
> s.ietf.org%2Frfcxml-
> >>>>>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>
> vocabulary&data=05%7C01%7C%7Cc4f02e6ac7714d3405c308db472219f8%7C
> 1a407a2d76754d178692b3
> >>>>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>
> ac285306e4%7C0%7C0%7C638181984127338856%7CUnknown%7CTWFpbGZs
> b3d8eyJWIjoiMC4wLjAwM
> >>>>>>>>>>
> >>>>>>>
> >>>>
> >>
> DAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C
> &sdata=nThccVcPYcDGw
> >>>>>>>>>> WouGYv581Nx309T%2BoH4MwPR6ZzrXqI%3D&reserved=0>
> >>>>>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>
> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauthor
> s.ietf.org%2Frfcxml-
> >>>>>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>
> vocabulary&amp;data=05%7C01%7C%7Cc4f02e6ac7714d3405c308db472219f8
> %7C1a407a2d76754d1786
> >>>>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>
> 92b3ac285306e4%7C0%7C0%7C638181984127338856%7CUnknown%7CTWFp
> bGZsb3d8eyJWIjoiMC4wLj
> >>>>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>
> AwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7
> C%7C&amp;sdata=nThccVc
> >>>>>>>>>>
> PYcDGwWouGYv581Nx309T%2BoH4MwPR6ZzrXqI%3D&amp;reserved=0&gt;>.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> * Formatted output
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Please review the PDF, HTML, and TXT files to ensure that the
> >>>>>>>>>>>>>> formatted output, as generated from the markup in the XML
> file,
> >>>>>>>>>>>>>> is
> >>>>>>>>>>>>>> reasonable. Please note that the TXT will have formatting
> >>>>>>>>>>>>>> limitations compared to the PDF and HTML.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Submitting changes
> >>>>>>>>>>>>>> ------------------
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> To submit changes, please reply to this email using ‘REPLY
> ALL’
> >>>>>>>>>>>>>> as
> >>>>>>>>>>>>>> all
> >>>>>>>>>>>>>> the parties CCed on this message need to see your changes.
> The
> >>>>>>>>>>>>>> parties
> >>>>>>>>>>>>>> include:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> * your coauthors
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> * [e-mail] <mailto:[e-mail]>
> >>>>>>>>>>>>>> (the
> >>>>>>>>>>>>>> RPC team)
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> * other document participants, depending on the stream
> (e.g.,
> >>>>>>>>>>>>>> IETF Stream participants are your working group chairs, the
> >>>>>>>>>>>>>> responsible ADs, and the document shepherd).
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> * [e-mail] <mailto:auth48archive@rfc-
> >>>>>>>>>>>>>> editor.org>, which is a new archival mailing list
> >>>>>>>>>>>>>> to preserve AUTH48 conversations; it is not an active
> >>>>>>>>>>>>>> discussion
> >>>>>>>>>>>>>> list:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> * More info:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>
> >>>>
> >>
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarch
> ive.ietf.org%2Farch%2F
> >>>>>>>>>> msg%2Fietf-
> >>>>>>>>>>>>>> announce%2Fyb6lpIGh-
> >>>>>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>
> 4Q9l2USxI&data=05%7C01%7C%7Cc4f02e6ac7714d3405c308db472219f8%7C1
> a407a2d76754d178692b3
> >>>>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>
> ac285306e4%7C0%7C0%7C638181984127338856%7CUnknown%7CTWFpbGZs
> b3d8eyJWIjoiMC4wLjAwM
> >>>>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>
> DAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C
> &sdata=2wZ8ij8pH7P7XQR
> >>>>>>>>>> WxFlU%2B6hXbUWfR7DfGh%2B28Gz0Knw%3D&reserved=0
> >>>>>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>
> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarc
> hive.ietf.org%2Farch%2F
> >>>>>>>>>> msg%2Fietf-
> >>>>>>>>>>>>>> announce%2Fyb6lpIGh-
> >>>>>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>
> 4Q9l2USxI&amp;data=05%7C01%7C%7Cc4f02e6ac7714d3405c308db472219f8
> %7C1a407a2d76754d1786
> >>>>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>
> 92b3ac285306e4%7C0%7C0%7C638181984127338856%7CUnknown%7CTWFp
> bGZsb3d8eyJWIjoiMC4wLj
> >>>>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>
> AwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7
> C%7C&amp;sdata=2wZ8ij8
> >>>>>>>>>>
> pH7P7XQRWxFlU%2B6hXbUWfR7DfGh%2B28Gz0Knw%3D&amp;reserved=0>
> >>>>>>>>>>>>>> Ae6P8O4Zc
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> * The archive itself:
> >>>>>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarch
> ive.ietf.org%2Farch%2Fb
> >>>>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>
> rowse%2Fauth48archive%2F&data=05%7C01%7C%7Cc4f02e6ac7714d3405c30
> 8db472219f8%7C1a407a2
> >>>>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>
> d76754d178692b3ac285306e4%7C0%7C0%7C638181984127338856%7CUnkno
> wn%7CTWFpbGZsb3d8eyJ
> >>>>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>
> WIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7
> C3000%7C%7C%7C&sdata=
> >>>>>>>>>>
> M7n5d3xCIiSm0H96F6QXqnwhzCyn8q9RmHSMvPEOUc4%3D&reserved=0
> >>>>>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>
> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarc
> hive.ietf.org%2Farch%2F
> >>>>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>
> browse%2Fauth48archive%2F&amp;data=05%7C01%7C%7Cc4f02e6ac7714d34
> 05c308db472219f8%7C1a
> >>>>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>
> 407a2d76754d178692b3ac285306e4%7C0%7C0%7C638181984127338856%7C
> Unknown%7CTWFpbGZsb
> >>>>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>
> 3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0
> %3D%7C3000%7C%7C%7C
> >>>>>>>>>>
> &amp;sdata=M7n5d3xCIiSm0H96F6QXqnwhzCyn8q9RmHSMvPEOUc4%3D&am
> p;reserved=0>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> * Note: If only absolutely necessary, you may temporarily opt
> >>>>>>>>>>>>>> out
> >>>>>>>>>>>>>> of the archiving of messages (e.g., to discuss a sensitive
> >>>>>>>>>>>>>> matter).
> >>>>>>>>>>>>>> If needed, please add a note at the top of the message that
> you
> >>>>>>>>>>>>>> have dropped the address. When the discussion is
> concluded,
> >>>>>>>>>>>>>> [e-mail] <mailto:auth48archive@rfc-
> >>>>>>>>>>>>>> editor.org>
> >>>>>>>>>>>>>> will be re-added to the CC list and
> >>>>>>>>>>>>>> its addition will be noted at the top of the message.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> You may submit your changes in one of two ways:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> An update to the provided XML file
> >>>>>>>>>>>>>> — OR —
> >>>>>>>>>>>>>> An explicit list of changes in this format
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Section # (or indicate Global)
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> OLD:
> >>>>>>>>>>>>>> old text
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> NEW:
> >>>>>>>>>>>>>> new text
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> You do not need to reply with both an updated XML file and
> an
> >>>>>>>>>>>>>> explicit
> >>>>>>>>>>>>>> list of changes, as either form is sufficient.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> We will ask a stream manager to review and approve any
> changes
> >>>>>>>>>>>>>> that
> >>>>>>>>>>>>>> seem beyond editorial in nature, e.g., addition of new text,
> >>>>>>>>>>>>>> deletion
> >>>>>>>>>>>>>> of text, and technical changes. Information about stream
> >>>>>>>>>>>>>> managers
> >>>>>>>>>>>>>> can
> >>>>>>>>>>>>>> be found in the FAQ. Editorial changes do not require
> approval
> >>>>>>>>>>>>>> from
> >>>>>>>>>>>>>> a
> >>>>>>>>>>>>> stream manager.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Approving for publication
> >>>>>>>>>>>>>> --------------------------
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> To approve your RFC for publication, please reply to this
> email
> >>>>>>>>>>>>>> stating that you approve this RFC for publication. Please use
> >>>>>>>>>>>>>> ‘REPLY
> >>>>>>>>>>>>>> ALL’, as all the parties CCed on this message need to see your
> >>>>>>>>>>>>>> approval.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Files
> >>>>>>>>>>>>>> -----
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> The files are available here:
> >>>>>>>>>>>>>>
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc
> -
> >>>>>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>
> editor.org%2Fauthors%2Frfc9370.xml&data=05%7C01%7C%7Cc4f02e6ac7714d
> 3405c308db472219f8%7C
> >>>>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>
> 1a407a2d76754d178692b3ac285306e4%7C0%7C0%7C638181984127338856%
> 7CUnknown%7CTWFpbGZs
> >>>>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>
> b3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0
> %3D%7C3000%7C%7C%7C
> >>>>>>>>>>
> &sdata=zZeQ5kxPTxM1YXihznnKN5RFYrdrh%2B%2Bx%2BUDDflff78I%3D&reser
> ved=0
> >>>>>>>>>>>>>>
> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rf
> c-
> >>>>>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>
> editor.org%2Fauthors%2Frfc9370.xml&amp;data=05%7C01%7C%7Cc4f02e6ac7
> 714d3405c308db472219f
> >>>>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>
> 8%7C1a407a2d76754d178692b3ac285306e4%7C0%7C0%7C638181984127338
> 856%7CUnknown%7CTWF
> >>>>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>
> pbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI
> 6Mn0%3D%7C3000%7C%
> >>>>>>>>>>
> >>>>>>>
> >>>>
> >>
> 7C%7C&amp;sdata=zZeQ5kxPTxM1YXihznnKN5RFYrdrh%2B%2Bx%2BUDDflff78
> I%3D&amp;reserved=0>
> >>>>>>>>>>>>>>
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc
> -
> >>>>>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>
> editor.org%2Fauthors%2Frfc9370.html&data=05%7C01%7C%7Cc4f02e6ac7714
> d3405c308db472219f8%7
> >>>>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>
> C1a407a2d76754d178692b3ac285306e4%7C0%7C0%7C638181984127338856
> %7CUnknown%7CTWFpbG
> >>>>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>
> Zsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6M
> n0%3D%7C3000%7C%7C%
> >>>>>>>>>>
> 7C&sdata=eTnz3q6dXMTADGnXsZavznCS0UEkW5SasO8qU9Y8cO4%3D&reserv
> ed=0
> >>>>>>>>>>>>>>
> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rf
> c-
> >>>>>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>
> editor.org%2Fauthors%2Frfc9370.html&amp;data=05%7C01%7C%7Cc4f02e6ac
> 7714d3405c308db472219
> >>>>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>
> f8%7C1a407a2d76754d178692b3ac285306e4%7C0%7C0%7C638181984127338
> 856%7CUnknown%7CTW
> >>>>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>
> FpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXV
> CI6Mn0%3D%7C3000%7C
> >>>>>>>>>>
> >>>>>>
> >>
> %7C%7C&amp;sdata=eTnz3q6dXMTADGnXsZavznCS0UEkW5SasO8qU9Y8cO4%
> 3D&amp;reserved=0>
> >>>>>>>>>>>>>>
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc
> -
> >>>>>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>
> editor.org%2Fauthors%2Frfc9370.pdf&data=05%7C01%7C%7Cc4f02e6ac7714d
> 3405c308db472219f8%7C
> >>>>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>
> 1a407a2d76754d178692b3ac285306e4%7C0%7C0%7C638181984127495083%
> 7CUnknown%7CTWFpbGZs
> >>>>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>
> b3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0
> %3D%7C3000%7C%7C%7C
> >>>>>>>>>>
> &sdata=nVTPAvGmeHWn8%2FdzTfvPY%2BGYdDBfjzHkx355NBpblKI%3D&reser
> ved=0
> >>>>>>>>>>>>>>
> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rf
> c-
> >>>>>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>
> editor.org%2Fauthors%2Frfc9370.pdf&amp;data=05%7C01%7C%7Cc4f02e6ac7
> 714d3405c308db472219f
> >>>>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>
> 8%7C1a407a2d76754d178692b3ac285306e4%7C0%7C0%7C638181984127495
> 083%7CUnknown%7CTWF
> >>>>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>
> pbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI
> 6Mn0%3D%7C3000%7C%
> >>>>>>>>>>
> >>>>>>>
> >>>>
> >>
> 7C%7C&amp;sdata=nVTPAvGmeHWn8%2FdzTfvPY%2BGYdDBfjzHkx355NBpblKI
> %3D&amp;reserved=0>
> >>>>>>>>>>>>>>
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc
> -
> >>>>>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>
> editor.org%2Fauthors%2Frfc9370.txt&data=05%7C01%7C%7Cc4f02e6ac7714d3
> 405c308db472219f8%7C1
> >>>>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>
> a407a2d76754d178692b3ac285306e4%7C0%7C0%7C638181984127495083%7
> CUnknown%7CTWFpbGZs
> >>>>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>
> b3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0
> %3D%7C3000%7C%7C%7C
> >>>>>>>>>>
> &sdata=LKw31jFDr%2F1yIzwbKfMhbzb7sG6tOIKbl23EGSD8M4Q%3D&reserved
> =0
> >>>>>>>>>>>>>>
> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rf
> c-
> >>>>>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>
> editor.org%2Fauthors%2Frfc9370.txt&amp;data=05%7C01%7C%7Cc4f02e6ac77
> 14d3405c308db472219f8
> >>>>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>
> %7C1a407a2d76754d178692b3ac285306e4%7C0%7C0%7C6381819841274950
> 83%7CUnknown%7CTWFp
> >>>>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>
> bGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6
> Mn0%3D%7C3000%7C%7
> >>>>>>>>>>
> >>>>
> C%7C&amp;sdata=LKw31jFDr%2F1yIzwbKfMhbzb7sG6tOIKbl23EGSD8M4Q%3D
> &amp;reserved=0>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Diff file of the text:
> >>>>>>>>>>>>>>
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc
> -
> >>>>>>>>>>>>>> editor.org%2Fauthors%2Frfc9370-
> >>>>>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>
> diff.html&data=05%7C01%7C%7Cc4f02e6ac7714d3405c308db472219f8%7C1a4
> 07a2d76754d178692b3ac
> >>>>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>
> 285306e4%7C0%7C0%7C638181984127495083%7CUnknown%7CTWFpbGZsb3
> d8eyJWIjoiMC4wLjAwMD
> >>>>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>
> AiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&
> sdata=p4Ev12WlUbix5s2%
> >>>>>>>>>> 2FxlqYyrFGeHfSIWfQYwm0MlNQATQ%3D&reserved=0
> >>>>>>>>>>>>>>
> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rf
> c-
> >>>>>>>>>>>>>> editor.org%2Fauthors%2Frfc9370-
> >>>>>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>
> diff.html&amp;data=05%7C01%7C%7Cc4f02e6ac7714d3405c308db472219f8%
> 7C1a407a2d76754d17869
> >>>>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>
> 2b3ac285306e4%7C0%7C0%7C638181984127495083%7CUnknown%7CTWFpb
> GZsb3d8eyJWIjoiMC4wLjA
> >>>>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>
> wMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C
> %7C&amp;sdata=p4Ev12W
> >>>>>>>>>>
> lUbix5s2%2FxlqYyrFGeHfSIWfQYwm0MlNQATQ%3D&amp;reserved=0>
> >>>>>>>>>>>>>>
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc
> -
> >>>>>>>>>>>>>> editor.org%2Fauthors%2Frfc9370-
> >>>>>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>
> rfcdiff.html&data=05%7C01%7C%7Cc4f02e6ac7714d3405c308db472219f8%7C
> 1a407a2d76754d178692b
> >>>>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>
> 3ac285306e4%7C0%7C0%7C638181984127495083%7CUnknown%7CTWFpbGZ
> sb3d8eyJWIjoiMC4wLjAw
> >>>>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>
> MDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%
> 7C&sdata=x33dJu89T8H67f
> >>>>>>>>>> KSbb6aVes4HJvR8n1B6x5hDw%2FK%2FRE%3D&reserved=0
> >>>>>>>>>>>>>>
> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rf
> c-
> >>>>>>>>>>>>>> editor.org%2Fauthors%2Frfc9370-
> >>>>>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>
> rfcdiff.html&amp;data=05%7C01%7C%7Cc4f02e6ac7714d3405c308db472219f8
> %7C1a407a2d76754d178
> >>>>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>
> 692b3ac285306e4%7C0%7C0%7C638181984127495083%7CUnknown%7CTWF
> pbGZsb3d8eyJWIjoiMC4w
> >>>>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>
> LjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%
> 7C%7C&amp;sdata=x33dJ
> >>>>>>>>>>
> u89T8H67fKSbb6aVes4HJvR8n1B6x5hDw%2FK%2FRE%3D&amp;reserved=0>
> >>>>>>>>>>>>>> (side by
> >>>>>>>>>>>>>> side)
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Diff of the XML:
> >>>>>>>>>>>>>>
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc
> -
> >>>>>>>>>>>>>> editor.org%2Fauthors%2Frfc9370-
> >>>>>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>
> xmldiff1.html&data=05%7C01%7C%7Cc4f02e6ac7714d3405c308db472219f8%
> 7C1a407a2d76754d178692
> >>>>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>
> b3ac285306e4%7C0%7C0%7C638181984127495083%7CUnknown%7CTWFpbG
> Zsb3d8eyJWIjoiMC4wLjA
> >>>>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>
> wMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C
> %7C&sdata=KRa37xZmcrRC
> >>>>>>>>>> Xt0Ko%2ByazDYsTOPAf%2BH4GhI2Dgf2Pkc%3D&reserved=0
> >>>>>>>>>>>>>>
> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rf
> c-
> >>>>>>>>>>>>>> editor.org%2Fauthors%2Frfc9370-
> >>>>>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>
> xmldiff1.html&amp;data=05%7C01%7C%7Cc4f02e6ac7714d3405c308db47221
> 9f8%7C1a407a2d76754d17
> >>>>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>
> 8692b3ac285306e4%7C0%7C0%7C638181984127495083%7CUnknown%7CTW
> FpbGZsb3d8eyJWIjoiMC4
> >>>>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>
> wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C
> %7C%7C&amp;sdata=KRa3
> >>>>>>>>>>
> 7xZmcrRCXt0Ko%2ByazDYsTOPAf%2BH4GhI2Dgf2Pkc%3D&amp;reserved=0>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> The following files are provided to facilitate creation of your
> >>>>>>>>>>>>>> own
> >>>>>>>>>>>>>> diff files of the XML.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Initial XMLv3 created using XMLv2 as input:
> >>>>>>>>>>>>>>
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc
> -
> >>>>>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>
> editor.org%2Fauthors%2Frfc9370.original.v2v3.xml&data=05%7C01%7C%7Cc4f
> 02e6ac7714d3405c308db
> >>>>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>
> 472219f8%7C1a407a2d76754d178692b3ac285306e4%7C0%7C0%7C638181984
> 127495083%7CUnknown
> >>>>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>
> %7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haW
> wiLCJXVCI6Mn0%3D%7C30
> >>>>>>>>>>
> >>
> 00%7C%7C%7C&sdata=Ybe8R5qreaEUeBrJ4JGdoYcwG1wuDAQp2wfQDMVLMl
> A%3D&reserved=0
> >>>>>>>>>>>>>>
> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rf
> c-
> >>>>>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>
> editor.org%2Fauthors%2Frfc9370.original.v2v3.xml&amp;data=05%7C01%7C%
> 7Cc4f02e6ac7714d3405c3
> >>>>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>
> 08db472219f8%7C1a407a2d76754d178692b3ac285306e4%7C0%7C0%7C6381
> 81984127495083%7CUnkn
> >>>>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>
> own%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1h
> aWwiLCJXVCI6Mn0%3D%7
> >>>>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>
> C3000%7C%7C%7C&amp;sdata=Ybe8R5qreaEUeBrJ4JGdoYcwG1wuDAQp2wfQ
> DMVLMlA%3D&amp;reser
> >>>>>>>>>> ved=0>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> XMLv3 file that is a best effort to capture v3-related format
> >>>>>>>>>>>>>> updates
> >>>>>>>>>>>>>> only:
> >>>>>>>>>>>>>>
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc
> -
> >>>>>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>
> editor.org%2Fauthors%2Frfc9370.form.xml&data=05%7C01%7C%7Cc4f02e6ac7
> 714d3405c308db472219f
> >>>>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>
> 8%7C1a407a2d76754d178692b3ac285306e4%7C0%7C0%7C638181984127495
> 083%7CUnknown%7CTWF
> >>>>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>
> pbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI
> 6Mn0%3D%7C3000%7C%
> >>>>>>>>>>
> 7C%7C&sdata=USv7Ch5xzsAb%2BII74BELLqfx8mJBeRFTnle5SR57uZY%3D&rese
> rved=0
> >>>>>>>>>>>>>>
> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rf
> c-
> >>>>>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>
> editor.org%2Fauthors%2Frfc9370.form.xml&amp;data=05%7C01%7C%7Cc4f02
> e6ac7714d3405c308db47
> >>>>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>
> 2219f8%7C1a407a2d76754d178692b3ac285306e4%7C0%7C0%7C63818198412
> 7495083%7CUnknown%7
> >>>>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>
> CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiL
> CJXVCI6Mn0%3D%7C3000
> >>>>>>>>>>
> >>>>>>>
> >>>>
> >>
> %7C%7C%7C&amp;sdata=USv7Ch5xzsAb%2BII74BELLqfx8mJBeRFTnle5SR57uZ
> Y%3D&amp;reserved=0>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Tracking progress
> >>>>>>>>>>>>>> -----------------
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> The details of the AUTH48 status of your document are here:
> >>>>>>>>>>>>>>
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc
> -
> >>>>>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>
> editor.org%2Fauth48%2Frfc9370&data=05%7C01%7C%7Cc4f02e6ac7714d3405
> c308db472219f8%7C1a40
> >>>>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>
> 7a2d76754d178692b3ac285306e4%7C0%7C0%7C638181984127495083%7CUn
> known%7CTWFpbGZsb3d
> >>>>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>
> 8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3
> D%7C3000%7C%7C%7C&sd
> >>>>>>>>>>
> ata=Ba6mD%2FLBPUO%2BXWLhegXDeeHVH0Ajb%2BdeUx%2Ff9YAQ22Q%3D&
> reserved=0
> >>>>>>>>>>>>>>
> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rf
> c-
> >>>>>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>
> editor.org%2Fauth48%2Frfc9370&amp;data=05%7C01%7C%7Cc4f02e6ac7714d
> 3405c308db472219f8%7C
> >>>>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>
> 1a407a2d76754d178692b3ac285306e4%7C0%7C0%7C638181984127495083%
> 7CUnknown%7CTWFpbGZs
> >>>>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>
> b3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0
> %3D%7C3000%7C%7C%7C
> >>>>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>
> &amp;sdata=Ba6mD%2FLBPUO%2BXWLhegXDeeHVH0Ajb%2BdeUx%2Ff9YAQ2
> 2Q%3D&amp;reserved=0
> >>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Please let us know if you have any questions.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Thank you for your cooperation,
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> RFC Editor
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> --------------------------------------
> >>>>>>>>>>>>>> RFC9370 (draft-ietf-ipsecme-ikev2-multiple-ke-12)
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Title : Multiple Key Exchanges in IKEv2
> >>>>>>>>>>>>>> Author(s) : C. Tjhai, M. Tomlinson, G. Bartlett, S. Fluhrer, D.
> >>>>>>>>>>>>>> Van
> >>>>>>>>>>>>>> Geest,
> >>>>>>>>>>>>> O. Garcia-Morchon, V. Smyslov
> >>>>>>>>>>>>>> WG Chair(s) : Yoav Nir, Tero Kivinen
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Area Director(s) : Roman Danyliw, Paul Wouters
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> ________________________________
> >>>>>>>>>>>> The information contained in this message may be confidential
> and
> >>>>>>>>>>>> legally protected under applicable law. The message is intended
> >>>>>>>>>>>> solely for the addressee(s). If you are not the intended
> >>>>>>>>>>>> recipient,
> >>>>>>>>>>>> you are hereby notified that any use, forwarding, dissemination,
> >>>>>>>>>>>> or
> >>>>>>>>>>>> reproduction of this message is strictly prohibited and may be
> >>>>>>>>>>>> unlawful. If you are not the intended recipient, please contact
> >>>>>>>>>>>> the
> >>>>>>>>>>>> sender by return e-mail and destroy all copies of the original
> >>>>>>>>>>>> message.
> >>>>>>>>
> >>>>>
> >>>
> >>>
> >
> >