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

[Megan Ferguson <[e-mail]>]

Sabrina and Valery,

Thank you for your replies and clarifications.

We have updated the file as requested below and marked IANA as “Approved” on the AUTH48 status page (see below).  We request review and approval of these changes to the document from one of the authors.  Once we have received confirmation of the document in its current form, it will be ready to move forward in the publication process.

  The files have been posted here:
   https://www.rfc-editor.org/authors/rfc9370.txt
   https://www.rfc-editor.org/authors/rfc9370.pdf
   https://www.rfc-editor.org/authors/rfc9370.html
   https://www.rfc-editor.org/authors/rfc9370.xml

  The relevant diff files have been posted here:
   https://www.rfc-editor.org/authors/rfc9370-diff.html (comprehensive)
   https://www.rfc-editor.org/authors/rfc9370-rfcdiff.html (comprehensive rfcdiff)
   https://www.rfc-editor.org/authors/rfc9370-auth48diff.html (all AUTH48 changes)
   https://www.rfc-editor.org/authors/rfc9370-lastdiff.html (last version to this)
   https://www.rfc-editor.org/authors/rfc9370-lastrfcdiff.html (last version to this rfcdiff)

  The AUTH48 status page is viewable here:
   http://www.rfc-editor.org/auth48/rfc9370

Thank you.

RFC Editor/mf


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