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

[Megan Ferguson <[e-mail]>]

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]; [e-mail]
>>> 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.
>>>> 
>