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

[Megan Ferguson <[e-mail]>]

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]; [e-mail]; Graham Bartlett;
>> [e-mail]; [e-mail]; [e-mail]
>> 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; [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'; [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 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; [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 <[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]; [e-mail];
>>>>>>>>>>>> [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:[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%7Cc4f02e6ac7714d3405c308db472219f8%7C1a40
>>>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>> 
>> 7a2d76754d178692b3ac285306e4%7C0%7C0%7C638181984127338856%7CUnknown%7CTWFpbGZsb3d
>>>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>> 
>> 8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%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%7Cc4f02e6ac7714d3405c308db472219f8%7C
>>>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>> 
>> 1a407a2d76754d178692b3ac285306e4%7C0%7C0%7C638181984127338856%7CUnknown%7CTWFpbGZs
>>>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>> 
>> b3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C
>>>>>>>>>> &amp;sdata=H7KHAvLFTvw%2F4jhqpqcJVJ4Rti6Dikf681HSaqffDQM%3D&amp;reserved=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.rfc-
>>>>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>> 
>> editor.org%2Ffaq%2F&data=05%7C01%7C%7Cc4f02e6ac7714d3405c308db472219f8%7C1a407a2d76754
>>>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>> 
>> d178692b3ac285306e4%7C0%7C0%7C638181984127338856%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiM
>>>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>> 
>> C4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=BNpkQ
>>>>>>>>>> vCnDwM8GG4n4US9lj3hnzEt0kPZoZJ8drz0S6g%3D&reserved=0
>>>>>>>>>>>>>> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-
>>>>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>> 
>> editor.org%2Ffaq%2F&amp;data=05%7C01%7C%7Cc4f02e6ac7714d3405c308db472219f8%7C1a407a2d7
>>>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>> 
>> 6754d178692b3ac285306e4%7C0%7C0%7C638181984127338856%7CUnknown%7CTWFpbGZsb3d8eyJW
>>>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>> 
>> IjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%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.ietf.org%2Flicense-
>>>>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>> 
>> info%2F&data=05%7C01%7C%7Cc4f02e6ac7714d3405c308db472219f8%7C1a407a2d76754d178692b3ac
>>>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>> 
>> 285306e4%7C0%7C0%7C638181984127338856%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMD
>>>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>> 
>> 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%7C1a407a2d76754d178692
>>>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>> 
>> b3ac285306e4%7C0%7C0%7C638181984127338856%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjA
>>>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>> 
>> 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%2Fauthors.ietf.org%2Frfcxml-
>>>>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>> 
>> vocabulary&data=05%7C01%7C%7Cc4f02e6ac7714d3405c308db472219f8%7C1a407a2d76754d178692b3
>>>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>> 
>> ac285306e4%7C0%7C0%7C638181984127338856%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwM
>>>>>>>>>> 
>>>>>>> 
>>>> 
>> DAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=nThccVcPYcDGw
>>>>>>>>>> WouGYv581Nx309T%2BoH4MwPR6ZzrXqI%3D&reserved=0>
>>>>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauthors.ietf.org%2Frfcxml-
>>>>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>> 
>> vocabulary&amp;data=05%7C01%7C%7Cc4f02e6ac7714d3405c308db472219f8%7C1a407a2d76754d1786
>>>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>> 
>> 92b3ac285306e4%7C0%7C0%7C638181984127338856%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLj
>>>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>> 
>> AwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%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%2Fmailarchive.ietf.org%2Farch%2F
>>>>>>>>>> msg%2Fietf-
>>>>>>>>>>>>>> announce%2Fyb6lpIGh-
>>>>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>> 
>> 4Q9l2USxI&data=05%7C01%7C%7Cc4f02e6ac7714d3405c308db472219f8%7C1a407a2d76754d178692b3
>>>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>> 
>> ac285306e4%7C0%7C0%7C638181984127338856%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwM
>>>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>> 
>> DAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=2wZ8ij8pH7P7XQR
>>>>>>>>>> WxFlU%2B6hXbUWfR7DfGh%2B28Gz0Knw%3D&reserved=0
>>>>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>> 
>> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2F
>>>>>>>>>> msg%2Fietf-
>>>>>>>>>>>>>> announce%2Fyb6lpIGh-
>>>>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>> 
>> 4Q9l2USxI&amp;data=05%7C01%7C%7Cc4f02e6ac7714d3405c308db472219f8%7C1a407a2d76754d1786
>>>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>> 
>> 92b3ac285306e4%7C0%7C0%7C638181984127338856%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLj
>>>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>> 
>> AwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%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%2Fmailarchive.ietf.org%2Farch%2Fb
>>>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>> 
>> rowse%2Fauth48archive%2F&data=05%7C01%7C%7Cc4f02e6ac7714d3405c308db472219f8%7C1a407a2
>>>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>> 
>> d76754d178692b3ac285306e4%7C0%7C0%7C638181984127338856%7CUnknown%7CTWFpbGZsb3d8eyJ
>>>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>> 
>> WIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=
>>>>>>>>>> M7n5d3xCIiSm0H96F6QXqnwhzCyn8q9RmHSMvPEOUc4%3D&reserved=0
>>>>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>> 
>> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2F
>>>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>> 
>> browse%2Fauth48archive%2F&amp;data=05%7C01%7C%7Cc4f02e6ac7714d3405c308db472219f8%7C1a
>>>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>> 
>> 407a2d76754d178692b3ac285306e4%7C0%7C0%7C638181984127338856%7CUnknown%7CTWFpbGZsb
>>>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>> 
>> 3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C
>>>>>>>>>> &amp;sdata=M7n5d3xCIiSm0H96F6QXqnwhzCyn8q9RmHSMvPEOUc4%3D&amp;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%7Cc4f02e6ac7714d3405c308db472219f8%7C
>>>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>> 
>> 1a407a2d76754d178692b3ac285306e4%7C0%7C0%7C638181984127338856%7CUnknown%7CTWFpbGZs
>>>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>> 
>> b3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C
>>>>>>>>>> &sdata=zZeQ5kxPTxM1YXihznnKN5RFYrdrh%2B%2Bx%2BUDDflff78I%3D&reserved=0
>>>>>>>>>>>>>> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-
>>>>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>> 
>> editor.org%2Fauthors%2Frfc9370.xml&amp;data=05%7C01%7C%7Cc4f02e6ac7714d3405c308db472219f
>>>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>> 
>> 8%7C1a407a2d76754d178692b3ac285306e4%7C0%7C0%7C638181984127338856%7CUnknown%7CTWF
>>>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>> 
>> pbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%
>>>>>>>>>> 
>>>>>>> 
>>>> 
>> 7C%7C&amp;sdata=zZeQ5kxPTxM1YXihznnKN5RFYrdrh%2B%2Bx%2BUDDflff78I%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%7Cc4f02e6ac7714d3405c308db472219f8%7
>>>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>> 
>> C1a407a2d76754d178692b3ac285306e4%7C0%7C0%7C638181984127338856%7CUnknown%7CTWFpbG
>>>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>> 
>> Zsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%
>>>>>>>>>> 7C&sdata=eTnz3q6dXMTADGnXsZavznCS0UEkW5SasO8qU9Y8cO4%3D&reserved=0
>>>>>>>>>>>>>> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-
>>>>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>> 
>> editor.org%2Fauthors%2Frfc9370.html&amp;data=05%7C01%7C%7Cc4f02e6ac7714d3405c308db472219
>>>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>> 
>> f8%7C1a407a2d76754d178692b3ac285306e4%7C0%7C0%7C638181984127338856%7CUnknown%7CTW
>>>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>> 
>> FpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%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%7Cc4f02e6ac7714d3405c308db472219f8%7C
>>>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>> 
>> 1a407a2d76754d178692b3ac285306e4%7C0%7C0%7C638181984127495083%7CUnknown%7CTWFpbGZs
>>>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>> 
>> b3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C
>>>>>>>>>> &sdata=nVTPAvGmeHWn8%2FdzTfvPY%2BGYdDBfjzHkx355NBpblKI%3D&reserved=0
>>>>>>>>>>>>>> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-
>>>>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>> 
>> editor.org%2Fauthors%2Frfc9370.pdf&amp;data=05%7C01%7C%7Cc4f02e6ac7714d3405c308db472219f
>>>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>> 
>> 8%7C1a407a2d76754d178692b3ac285306e4%7C0%7C0%7C638181984127495083%7CUnknown%7CTWF
>>>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>> 
>> pbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%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%7Cc4f02e6ac7714d3405c308db472219f8%7C1
>>>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>> 
>> a407a2d76754d178692b3ac285306e4%7C0%7C0%7C638181984127495083%7CUnknown%7CTWFpbGZs
>>>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>> 
>> b3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C
>>>>>>>>>> &sdata=LKw31jFDr%2F1yIzwbKfMhbzb7sG6tOIKbl23EGSD8M4Q%3D&reserved=0
>>>>>>>>>>>>>> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-
>>>>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>> 
>> editor.org%2Fauthors%2Frfc9370.txt&amp;data=05%7C01%7C%7Cc4f02e6ac7714d3405c308db472219f8
>>>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>> 
>> %7C1a407a2d76754d178692b3ac285306e4%7C0%7C0%7C638181984127495083%7CUnknown%7CTWFp
>>>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>> 
>> bGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%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%7C1a407a2d76754d178692b3ac
>>>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>> 
>> 285306e4%7C0%7C0%7C638181984127495083%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMD
>>>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>> 
>> AiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=p4Ev12WlUbix5s2%
>>>>>>>>>> 2FxlqYyrFGeHfSIWfQYwm0MlNQATQ%3D&reserved=0
>>>>>>>>>>>>>> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-
>>>>>>>>>>>>>> editor.org%2Fauthors%2Frfc9370-
>>>>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>> 
>> diff.html&amp;data=05%7C01%7C%7Cc4f02e6ac7714d3405c308db472219f8%7C1a407a2d76754d17869
>>>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>> 
>> 2b3ac285306e4%7C0%7C0%7C638181984127495083%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjA
>>>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>> 
>> 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%7C1a407a2d76754d178692b
>>>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>> 
>> 3ac285306e4%7C0%7C0%7C638181984127495083%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAw
>>>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>> 
>> 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.rfc-
>>>>>>>>>>>>>> editor.org%2Fauthors%2Frfc9370-
>>>>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>> 
>> rfcdiff.html&amp;data=05%7C01%7C%7Cc4f02e6ac7714d3405c308db472219f8%7C1a407a2d76754d178
>>>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>> 
>> 692b3ac285306e4%7C0%7C0%7C638181984127495083%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4w
>>>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>> 
>> 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%7CTWFpbGZsb3d8eyJWIjoiMC4wLjA
>>>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>> 
>> 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.rfc-
>>>>>>>>>>>>>> editor.org%2Fauthors%2Frfc9370-
>>>>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>> 
>> xmldiff1.html&amp;data=05%7C01%7C%7Cc4f02e6ac7714d3405c308db472219f8%7C1a407a2d76754d17
>>>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>> 
>> 8692b3ac285306e4%7C0%7C0%7C638181984127495083%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4
>>>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>> 
>> 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%7Cc4f02e6ac7714d3405c308db
>>>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>> 
>> 472219f8%7C1a407a2d76754d178692b3ac285306e4%7C0%7C0%7C638181984127495083%7CUnknown
>>>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>> 
>> %7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C30
>>>>>>>>>> 
>> 00%7C%7C%7C&sdata=Ybe8R5qreaEUeBrJ4JGdoYcwG1wuDAQp2wfQDMVLMlA%3D&reserved=0
>>>>>>>>>>>>>> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-
>>>>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>> 
>> editor.org%2Fauthors%2Frfc9370.original.v2v3.xml&amp;data=05%7C01%7C%7Cc4f02e6ac7714d3405c3
>>>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>> 
>> 08db472219f8%7C1a407a2d76754d178692b3ac285306e4%7C0%7C0%7C638181984127495083%7CUnkn
>>>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>> 
>> own%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7
>>>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>> 
>> C3000%7C%7C%7C&amp;sdata=Ybe8R5qreaEUeBrJ4JGdoYcwG1wuDAQp2wfQDMVLMlA%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%7Cc4f02e6ac7714d3405c308db472219f
>>>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>> 
>> 8%7C1a407a2d76754d178692b3ac285306e4%7C0%7C0%7C638181984127495083%7CUnknown%7CTWF
>>>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>> 
>> pbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%
>>>>>>>>>> 7C%7C&sdata=USv7Ch5xzsAb%2BII74BELLqfx8mJBeRFTnle5SR57uZY%3D&reserved=0
>>>>>>>>>>>>>> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-
>>>>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>> 
>> editor.org%2Fauthors%2Frfc9370.form.xml&amp;data=05%7C01%7C%7Cc4f02e6ac7714d3405c308db47
>>>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>> 
>> 2219f8%7C1a407a2d76754d178692b3ac285306e4%7C0%7C0%7C638181984127495083%7CUnknown%7
>>>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>> 
>> CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000
>>>>>>>>>> 
>>>>>>> 
>>>> 
>> %7C%7C%7C&amp;sdata=USv7Ch5xzsAb%2BII74BELLqfx8mJBeRFTnle5SR57uZY%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%7Cc4f02e6ac7714d3405c308db472219f8%7C1a40
>>>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>> 
>> 7a2d76754d178692b3ac285306e4%7C0%7C0%7C638181984127495083%7CUnknown%7CTWFpbGZsb3d
>>>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>> 
>> 8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%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.rfc-
>>>>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>> 
>> editor.org%2Fauth48%2Frfc9370&amp;data=05%7C01%7C%7Cc4f02e6ac7714d3405c308db472219f8%7C
>>>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>> 
>> 1a407a2d76754d178692b3ac285306e4%7C0%7C0%7C638181984127495083%7CUnknown%7CTWFpbGZs
>>>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>> 
>> b3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C
>>>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>> 
>> &amp;sdata=Ba6mD%2FLBPUO%2BXWLhegXDeeHVH0Ajb%2BdeUx%2Ff9YAQ22Q%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.
>>>>>>>> 
>>>>> 
>>> 
>>> 
> 
>