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

[Sabrina Tanamal via RT <[e-mail]>]

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.