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

[Megan Ferguson <[e-mail]>]

Hi Valery,

These have been added to the XML file posted.  Note that they were already included our database, so search functionality on rfc-editor.org is good to go.

You can see these updates in the XML file below (please refresh).

https://www.rfc-editor.org/authors/rfc9370.xml

We have recorded your approval of the document in this form and will move forward in the publication process at this time.

The AUTH48 status page is viewable here:

http://www.rfc-editor.org/auth48/rfc9370

Thanks!

Megan


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