Re: [auth48] AUTH48: RFC-to-be 9464 <draft-ietf-ipsecme-add-ike-14> for your review

[Valery Smyslov <[e-mail]>]

Hi Lynne, Med, all,

I agree with the resolutions proposed by Med.

I have one minor comment.

Upper part of Figure 4:

CURRENT:
                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-----------------------------+-------------------------------+
   |R|         Attribute Type      |            Length             |
   +-+-----------------------------+---------------+---------------+
...

NEW:
                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-----------------------------+-------------------------------+
   |R|         Attribute Type      |            Length             |
   +-+-----------------------------+-------------------------------+
...

(erroneous '+' instead of '-').

Regards,
Valery.


> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> Sent: Tuesday, September 12, 2023 11:53 AM
> To: [e-mail]; [e-mail]; [e-mail]; [e-mail]
> Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]; auth48archive@rfc-
> editor.org
> Subject: [***SPAM***] RE: AUTH48: RFC-to-be 9464 <draft-ietf-ipsecme-add-ike-14> for your review
> 
> Dear RFC Editor,
> 
> Please see inline.
> 
> I let my co-authors further comment as appropriate.
> 
> Cheers,
> Med
> 
> > -----Message d'origine-----
> > De : [e-mail] <[e-mail]>
> > Envoyé : samedi 9 septembre 2023 05:00
> > À : BOUCADAIR Mohamed INNOV/NET <[e-mail]>;
> > [e-mail]; [e-mail]; [e-mail]
> > Cc : [e-mail]; [e-mail]; ipsecme-
> > [e-mail]; [e-mail]; [e-mail]; auth48archive@rfc-
> > editor.org
> > Objet : Re: AUTH48: RFC-to-be 9464 <draft-ietf-ipsecme-add-ike-14>
> > for your review
> >
> > Authors,
> >
> > While reviewing this document during AUTH48, please resolve (as
> > necessary) the following questions, which are also in the XML
> > file.
> >
> > 1) <!-- [rfced] Section 2:  We had trouble following this
> > paragraph; "but could be located outside of it" followed by "the
> > latter option becomes plausible" is a bit confusing.  If the
> > suggested text doesn't adequately clarify things, would you like
> > to provide alternative text that does?
> >
> > Original:
> >  For many years, typical designs have often considered that the
> > DNS  resolver was usually located inside the protected domain, but
> > could  be located outside of it.  With encrypted DNS, the latter
> > option  becomes plausible.  Note that existing VPN client
> > implementations  might not expect that the discovered DNS resolver
> > IP addresses to be  outside of the covered IP address ranges of
> > the VPN tunnel.
> >
> > Suggested:
> >  For many years, typical designs have often assumed that the DNS
> > resolver was usually located inside the protected domain, but they
> > don't consider implementations where the DNS resolver could be
> > located outside of it.  With encrypted DNS, managing the latter
> > scenario becomes plausible.  Note that existing VPN client
> > implementations might not expect the discovered DNS resolver IP
> > addresses to be outside of the covered IP address ranges of the
> > VPN  tunnel. -->
> >
> 
> [Med] OK with "s/managing/implementing" or "s/managing/deploying".
> 
> >
> > 2) <!-- [rfced] Section 3.1:  Please clarify the meaning of "to
> > configure ... to an initiator".
> >
> > Original:
> >  The ENCDNS_IP* IKEv2 Configuration Payload Attribute Types,
> >  ENCDNS_IP4 and ENCDNS_IP6, are used to configure encrypted DNS
> > resolvers to an initiator. -->
> >
> 
> [Med] What about?
> 
> NEW:
>    The ENCDNS_IP* IKEv2 Configuration Payload Attribute Types,
>    ENCDNS_IP4 and ENCDNS_IP6, are used to configure an initiator
>    with encrypted DNS resolvers.
> 
> >
> > 3) <!-- [rfced] Please review each artwork element.  Should any of
> > them be tagged as sourcecode?  If the current list of preferred
> > values for "type"
> > (https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2
> > Fwww.rfc-editor.org%2Fmaterials%2Fsourcecode-
> > types.txt&data=05%7C01%7Cmohamed.boucadair%40orange.com%7Cb2a1f0de
> > e85244493d1908dbb0e0e24c%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C
> > 0%7C638298252306689579%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDA
> > iLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sd
> > ata=owrKC%2BaVwCKIaYUrlgQ%2FjOWPPgMyIDNDCh9P6A3ynOI%3D&reserved=0)
> > does not contain an applicable type, please let us know.  Also, it
> > is acceptable to leave the "type" attribute not set. -->
> >
> 
> [Med] We can leave this not set.
> 
> >
> > 4) <!-- [rfced] Figure 1:  We corrected the field-name mismatch
> > per
> > "IP Address(es) (variable) - Includes one or more IP addresses" as
> > listed in the descriptions below.  Please let us know any
> > objections.
> >
> > Original:
> >  ~                         IP Addresses                          ~
> >
> > Currently:
> >  ~                        IP Address(es)                         ~
> > -->
> >
> 
> [Med] OK.
> 
> >
> > 5) <!-- [rfced] Section 3.1:  The use of "attribute" versus
> > "attributes"
> > was confusing here.  We updated the figure title and the next
> > sentence as follows.  If this is incorrect, please provide a clear
> > figure title and following text.
> >
> > Original:
> >                       Figure 1: Attributes Format
> >
> >  The description of the fields of the attribute shown in Figure 1
> > is
> >  as follows:
> >
> > Currently:
> >      Figure 1: Format of ENCDNS_IP4 and ENCDNS_IP6 Attribute Types
> >
> >  The descriptions of the fields shown in Figure 1 are as follows:
> > -->
> 
> [Med] I suggest to update as follows:
> 
> NEW:
>       Figure 1: Format of ENCDNS_IP4 and ENCDNS_IP6 Configuration Attributes
> 
> >
> >
> > 6) <!-- [rfced] Sections 3.1 and 3.2:  Should these three
> > instances of
> > "Configuration Attribute Type" be "Configuration Payload Attribute
> > Type"?
> 
> [Med] We can maintain the original text as that is aligned with the usage in
> https://datatracker.ietf.org/doc/html/rfc7296#section-3.15.1.
> 
> >
> > Original:
> >  *  Attribute Type (15 bits) - Identifier for Configuration
> > Attribute
> >     Type.  This is set to TBA1 for ENCDNS_IP4 or TBA2 for
> > ENCDNS_IP6,
> >     as registered in Section 8.
> > ...
> >  *  Attribute Type (15 bits) - Identifier for Configuration
> > Attribute
> >     Type; is set to TBA3 value listed in Section 8.
> > ...
> >  *  Attribute Type (15 bits) - Identifier for Configuration
> > Attribute
> >     Type; is set to TBA3 value listed in Section 8. -->
> >
> >
> > 7) <!-- [rfced] Section 3.1:  It looks odd to have 'Length of the
> > ADN'
> > but no quotes around Length of SvcParams.  May we update as
> > suggested?
> >
> > Original:
> >  -  (4 + 'Length of the ADN' + N * 4 + Length of SvcParams) for
> > ...
> >  -  (4 + 'Length of the ADN' + N * 16 + Length of SvcParams) for
> >
> > Suggested:
> >  *  (4 + 'Length of the ADN' + N * 4 + 'Length of SvcParams') for
> > ...
> >  *  (4 + 'Length of the ADN' + N * 16 + 'Length of SvcParams') for
> > -->
> >
> 
> [Med] The suggested text is OK.
> 
> >
> > 8) <!-- [rfced] Figure 2:  We found it confusing that the
> > description
> > for the "Certificate Digest" field only appears after Figure 4.
> > Will readers readily find the field description, or should some
> > clarifying text be added?
> >
> 
> [Med] I don't think a change is needed here.
> 
> > Original:
> >  Some of the fields shown in Figure 2 can be omitted as further
> >  detailed below.
> >
> > Possibly:
> >  Some of the fields shown in Figure 2 can be omitted, as further
> >  detailed below.  Descriptions for the "Authentication Domain
> > Name"
> >  and "Certificate Digest" fields are provided below Figure 4. -->
> >
> >
> > 9) <!-- [rfced] Section 4:  Per Section 6.2 of RFC 8310 ("Section
> > 8
> > discusses these mechanisms ..."), should "the mechanism" be "the
> > mechanisms" here, or should one mechanism in particular from
> > Section 8 of RFC 8310 be cited here?
> >
> 
> [Med] OK to update to "mechanisms".
> 
> > Original:
> >  The DNS client establishes an encrypted DNS session (e.g., DoT,
> > DoH,
> >  DoQ) with the address(es) conveyed in ENCDNS_IP* and uses the
> >  mechanism discussed in Section 8 of [RFC8310] to authenticate the
> > DNS
> >  resolver certificate using the authentication domain name
> > conveyed in
> >  ENCDNS_IP*. -->
> >
> >
> > 10) <!-- [rfced] Section 4:  Please confirm that "PKIX-EE(1) with
> > selector SPKI(1)" is correct.  We could only find "DANE-EE(3) and
> > selector SPKI(1)" and "DANE-EE(3) with selector SPKI(1)" in RFC
> > 7671.
> >
> 
> [Med] Yes, please see 5.3 of RFC7671.
> 
> > Original:
> >  This approach is
> >  similar to certificate usage PKIX-EE(1) with selector SPKI(1)
> > defined
> >  in [RFC7671] but without PKIX validation. -->
> >
> >
> > 11) <!-- [rfced] Section 4:  The first sentence in the "Note:"
> > paragraph
> > did not parse.  We updated it as noted below.  Please let us know
> > any objections.
> >
> > Also, please review whether the "Note:" paragraph should be in the
> > <aside> element.  It is defined as "a container for content that
> > is
> > semantically less important or tangential to the content that
> > surrounds it"
> > (https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2
> > Fauthors.ietf.org%2Fen%2Frfcxml-
> > vocabulary%23aside&data=05%7C01%7Cmohamed.boucadair%40orange.com%7
> > Cb2a1f0dee85244493d1908dbb0e0e24c%7C90c7a20af34b40bfbc48b9253b6f5d
> > 20%7C0%7C0%7C638298252306689579%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC
> > 4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C
> > %7C%7C&sdata=I7PImckstjLTTo5K5l1VC8TFPxvqIThfb2C%2BxZ2gDTE%3D&rese
> > rved=0).
> >
> 
> [Med] The use of <aside> element is not justified here. Please maintain the original format.
> 
> > Original:
> >  Note: [RFC8598] requires INTERNAL_IP6_DNS (or INTERNAL_IP4_DNS)
> >  attribute to be mandatory present when INTERNAL_DNS_DOMAIN is
> >  included.  This specification relaxes that constraint in the
> >  presence of ENCDNS_IP* attributes.  That is, if ENCDNS_IP*
> >  attributes are supplied, it is allowed for responders to include
> >  INTERNAL_DNS_DOMAIN even in the absence of INTERNAL_IP6_DNS (or
> >  INTERNAL_IP4_DNS) attributes.
> >
> > Currently:
> >  Note: [RFC8598] requires that the INTERNAL_IP6_DNS (or
> >  INTERNAL_IP4_DNS) attribute be present when INTERNAL_DNS_DOMAIN
> > is
> >  included.  This specification relaxes that constraint in the
> >  presence of ENCDNS_IP* attributes.  That is, if ENCDNS_IP*
> >  attributes are supplied, responders are allowed to include
> >  INTERNAL_DNS_DOMAIN even in the absence of INTERNAL_IP6_DNS (or
> >  INTERNAL_IP4_DNS) attributes. -->
> >
> 
> [Med] The suggested text looks good to me.
> 
> >
> > 12) <!-- [rfced] Section 5:  We do not see SHA2-256 mentioned in
> > RFC 6234.  Will this citation be clear to readers?
> >
> > Original:
> >  Implementations MUST support SHA2-256 [RFC6234]. -->
> >
> 
> [Med] Yes. As we are relying on the IANA registry (https://www.iana.org/assignments/ikev2-
> parameters/ikev2-parameters.xhtml#hash-algorithms), we are using the label that used in that registry +
> authoritative spec with the hash algo. No change is needed here.
> 
> >
> > 13) <!-- [rfced] Section 6:  Please clarify the meaning of "does
> > not
> > alter the trust on" in this sentence.  Are some words missing?
> >
> > Original:
> >  This document adheres to the security considerations defined in
> >  [RFC7296].  In particular, this document does not alter the trust
> > on
> >  the DNS configuration provided by a responder. -->
> >
> 
> [Med] What about:
> 
> NEW:
>    In particular, this document does not alter the trust that the initiator
>    have on the DNS configuration provided by a responder.
> 
> >
> > 14) <!-- [rfced] Section 6:  We had trouble parsing this sentence.
> > Please clarify "returned ENCDNS_IP* resolvers configuration" and
> > to what "it" refers (the responder or the initiator?).
> >
> 
> [Med] the initiator.
> 
> > Original:
> >  If the IKEv2 responder has used NULL Authentication method
> > [RFC7619]
> >  to authenticate itself, the initiator MUST NOT use returned
> >  ENCDNS_IP* resolvers configuration unless it is pre-configured,
> > e.g.,
> >  in the operating system or the application. -->
> >
> >
> > 15) <!-- [rfced] Regarding the references to IANA subregistries,
> > we note
> > that [IANA-IKE-HASH] is normative, whereas [IANA-IKE-CFG] is
> > informative.
> > Would you like these both to be one or the other?
> >
> 
> [Med] The current classification is correct. We had this comment during the publication process. IANA-
> IKE-HASH is normative as this is key for interoperability.
> 
> > For background:
> > "Normative references specify documents that must be read to
> > understand
> > or implement the technology in the new RFC, or whose technology
> > must be
> > present for the technology in the new RFC to work. An informative
> > reference is not normative; rather, it only provides additional
> > information."
> > from
> > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> > www.ietf.org%2Fabout%2Fgroups%2Fiesg%2Fstatements%2Fnormative-
> > informative-
> > references%2F&data=05%7C01%7Cmohamed.boucadair%40orange.com%7Cb2a1
> > f0dee85244493d1908dbb0e0e24c%7C90c7a20af34b40bfbc48b9253b6f5d20%7C
> > 0%7C0%7C638298252306689579%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjA
> > wMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7
> > C&sdata=ey5hl4Xv5MyTVuxIXlWrbMmiVEkAbgrhCZL5D9vH6ys%3D&reserved=0)
> >
> >    [IANA-IKE-HASH]
> >               IANA, "IKEv2 Hash Algorithms",
> >
> > <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2
> > Fwww.iana.org%2Fassignments%2Fikev2-
> > parameters%2F&data=05%7C01%7Cmohamed.boucadair%40orange.com%7Cb2a1
> > f0dee85244493d1908dbb0e0e24c%7C90c7a20af34b40bfbc48b9253b6f5d20%7C
> > 0%7C0%7C638298252306689579%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjA
> > wMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7
> > C&sdata=ARTDuz1COFOC%2FBCc24fCN%2FXoihzfU0PBlxSKXdd6QiM%3D&reserve
> > d=0>.
> >
> >    [IANA-IKE-CFG]
> >               IANA, "IKEv2 Configuration Payload Attribute Types",
> >
> > <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2
> > Fwww.iana.org%2Fassignments%2Fikev2-
> > parameters%2F&data=05%7C01%7Cmohamed.boucadair%40orange.com%7Cb2a1
> > f0dee85244493d1908dbb0e0e24c%7C90c7a20af34b40bfbc48b9253b6f5d20%7C
> > 0%7C0%7C638298252306689579%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjA
> > wMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7
> > C&sdata=ARTDuz1COFOC%2FBCc24fCN%2FXoihzfU0PBlxSKXdd6QiM%3D&reserve
> > d=0>.
> > -->
> >
> >
> > 16) <!-- [rfced] Appendix A.1:  Please clarify the meaning of
> > "There is
> > no ambiguity to" in this sentence.
> >
> > Original:
> >  There is no ambiguity to identify the
> >  encrypted resolver associated with the supplied digest.
> >
> > Possibly:
> >  Identifying the encrypted resolver associated with the supplied
> >  digest is therefore unambiguous. -->
> >
> 
> [Med] The proposed wording is better. Thanks.
> 
> >
> > 17) <!-- [rfced] Please review the "Inclusive Language" portion of
> > the
> > online Style Guide at
> > <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2
> > Fwww.rfc-
> > editor.org%2Fstyleguide%2Fpart2%2F%23inclusive_language&data=05%7C
> > 01%7Cmohamed.boucadair%40orange.com%7Cb2a1f0dee85244493d1908dbb0e0
> > e24c%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6382982523066895
> > 79%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJ
> > BTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=MzcH%2F6iSwrVdkU
> > hLib6XWKcOo7aJn11FBbYieLo8oLg%3D&reserved=0>,
> > and let us know if any changes are needed.
> >
> > Note that our script did not flag any words in particular, but
> > this
> > should still be reviewed as a best practice. -->
> >
> 
> [Med] I don't have any comment here.
> 
> >
> > 18) <!-- [rfced] Please let us know if any changes are needed for
> > the
> > following:
> >
> > a) The following terms were used inconsistently in this document.
> > We chose to use the latter forms.  Please let us know any
> > objections.
> >
> >  configuration payload attribute (in text; 1 instance) /
> >    Configuration Payload Attribute (in text; 3 instances)
> >
> 
> [Med] We can use "Configuration Payload Attribute"
> 
> >  Num addresses / Num Addresses (field name)
> >
> 
> [Med] We can use "Num Addresses"
> 
> > b) The following terms/expressions appear to be used
> > inconsistently in this document.  Please let us know which form is
> > preferred.
> >
> >  hash algorithm identifiers / 'Hash Algorithm Identifiers' /
> >    Hash Algorithm Identifiers
> >    For example:
> >      included hash algorithm identifiers
> >      included 'Hash Algorithm Identifiers'
> >      the Hash Algorithm Identifier
> >      the hash algorithm identifiers
> >
> 
> [Med] We can use 'Hash Algorithm Identifiers' only when referring to the field name and hash algorithm
> identifiers in the description text.
> 
> >  set to zero / set to 0 / set to '0'
> 
> [Med] Please note that both "set to zero" and "set to 0" are used in rfc7296. We can change "set to '0'" to
> "set to 0".
> 
> >
> >  the ENCDNS_IP* Configuration Payload Attribute /
> >    the ENCDNS_IP* Configuration Payload Attribute(s) /
> >    the ENCDNS_IP* Configuration Payload Attributes
> >
> 
> [Med] "ENCDNS_IP* Configuration Payload Attributes" is used to refer to both IPv4/IPv6 attributes. The
> singular form is better when describing the field. I suggest to make these changes in Section 3.1:
> 
> OLD: in the ENCDNS_IP* Configuration Payload Attribute(s).
> NEW: in the ENCDNS_IP* Configuration Payload Attribute.
> 
> OLD: multiple ADNs are included in the ENCDNS_IP* Configuration Payload Attributes.
> NEW: multiple ADNs are included in the ENCDNS_IP* Configuration Payload Attribute.
> 
> > c) Please note that, per elsewhere in this document and per the
> > rest
> > of this cluster of documents
> > (https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2
> > Fwww.rfc-
> > editor.org%2Fcluster_info.php%3Fcid%3DC461&data=05%7C01%7Cmohamed.
> > boucadair%40orange.com%7Cb2a1f0dee85244493d1908dbb0e0e24c%7C90c7a2
> > 0af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638298252306689579%7CUnknown%
> > 7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwi
> > LCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=kgB%2BVVVsL5u0%2F7ewYwO%2FHks
> > JsKFXUGsczfCrlaNEyCk%3D&reserved=0), we changed
> > the single-quoted field names to double-quoted.  Please let us
> > know
> > any concerns. -->
> >
> >
> > Thank you.
> >
> > RFC Editor/lb/ar
> >
> >
> > On Sep 8, 2023, [e-mail] wrote:
> >
> > *****IMPORTANT*****
> >
> > Updated 2023/09/08
> >
> > 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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2
> > Fwww.rfc-
> > editor.org%2Ffaq%2F&data=05%7C01%7Cmohamed.boucadair%40orange.com%
> > 7Cb2a1f0dee85244493d1908dbb0e0e24c%7C90c7a20af34b40bfbc48b9253b6f5
> > d20%7C0%7C0%7C638298252306689579%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiM
> > C4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7
> > C%7C%7C&sdata=AVmnlP7tXmIfvKcCbcKWP02MVqeSPbtjVM%2FX%2Ba5oJmE%3D&r
> > eserved=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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> > trustee.ietf.org%2Flicense-
> > info%2F&data=05%7C01%7Cmohamed.boucadair%40orange.com%7Cb2a1f0dee8
> > 5244493d1908dbb0e0e24c%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%
> > 7C638298252306689579%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiL
> > CJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdat
> > a=CLVTn9%2FahmzPfRa7wbrqZX3hdy3XyTokVZR5mG5Y7m0%3D&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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2
> > Fauthors.ietf.org%2Frfcxml-
> > vocabulary&data=05%7C01%7Cmohamed.boucadair%40orange.com%7Cb2a1f0d
> > ee85244493d1908dbb0e0e24c%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7
> > C0%7C638298252306689579%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMD
> > AiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&s
> > data=z%2BMn8kpajc5kiHpa3ysWH7kTeAhugXRE2m616iMNdrY%3D&reserved=0>.
> >
> > *  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] (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], which is a new archival mailing
> > list
> >      to preserve AUTH48 conversations; it is not an active
> > discussion
> >      list:
> >
> >     *  More info:
> >
> > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> > mailarchive.ietf.org%2Farch%2Fmsg%2Fietf-announce%2Fyb6lpIGh-
> > 4Q9l2USxIAe6P8O4Zc&data=05%7C01%7Cmohamed.boucadair%40orange.com%7
> > Cb2a1f0dee85244493d1908dbb0e0e24c%7C90c7a20af34b40bfbc48b9253b6f5d
> > 20%7C0%7C0%7C638298252306689579%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC
> > 4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C
> > %7C%7C&sdata=%2Fs6iQAXfBoXAipisgn1aB2Op8OzZo9Om3v18pCvMzRQ%3D&rese
> > rved=0
> >
> >     *  The archive itself:
> >
> > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> > mailarchive.ietf.org%2Farch%2Fbrowse%2Fauth48archive%2F&data=05%7C
> > 01%7Cmohamed.boucadair%40orange.com%7Cb2a1f0dee85244493d1908dbb0e0
> > e24c%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6382982523066895
> > 79%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJ
> > BTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=9N2d3iC33AbY5pVU
> > %2FPJkD%2BFQDDBExuhHf9i1axXSM%2Bc%3D&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] 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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> > www.rfc-
> > editor.org%2Fauthors%2Frfc9464.xml&data=05%7C01%7Cmohamed.boucadai
> > r%40orange.com%7Cb2a1f0dee85244493d1908dbb0e0e24c%7C90c7a20af34b40
> > bfbc48b9253b6f5d20%7C0%7C0%7C638298252306689579%7CUnknown%7CTWFpbG
> > Zsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6
> > Mn0%3D%7C3000%7C%7C%7C&sdata=JGFmMJGNpWQgBX73UkQlpkX3iZM80t0z2EOvv
> > Szk6xc%3D&reserved=0
> >
> > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> > www.rfc-
> > editor.org%2Fauthors%2Frfc9464.html&data=05%7C01%7Cmohamed.boucada
> > ir%40orange.com%7Cb2a1f0dee85244493d1908dbb0e0e24c%7C90c7a20af34b4
> > 0bfbc48b9253b6f5d20%7C0%7C0%7C638298252306846778%7CUnknown%7CTWFpb
> > GZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI
> > 6Mn0%3D%7C3000%7C%7C%7C&sdata=JyumPy2ZshtNSIunfh19bKsl9t29rMU%2BrI
> > VR30mTfWE%3D&reserved=0
> >
> > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> > www.rfc-
> > editor.org%2Fauthors%2Frfc9464.pdf&data=05%7C01%7Cmohamed.boucadai
> > r%40orange.com%7Cb2a1f0dee85244493d1908dbb0e0e24c%7C90c7a20af34b40
> > bfbc48b9253b6f5d20%7C0%7C0%7C638298252306846778%7CUnknown%7CTWFpbG
> > Zsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6
> > Mn0%3D%7C3000%7C%7C%7C&sdata=l1ehzpcaHu4X96xfBRIDWFyYKjXE7NCBwPsEk
> > zdZ8C0%3D&reserved=0
> >
> > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> > www.rfc-
> > editor.org%2Fauthors%2Frfc9464.txt&data=05%7C01%7Cmohamed.boucadai
> > r%40orange.com%7Cb2a1f0dee85244493d1908dbb0e0e24c%7C90c7a20af34b40
> > bfbc48b9253b6f5d20%7C0%7C0%7C638298252306846778%7CUnknown%7CTWFpbG
> > Zsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6
> > Mn0%3D%7C3000%7C%7C%7C&sdata=a8%2F3eUZlwam9Tif2qeGNgp2aZWRl8l6026u
> > J5ID0cyg%3D&reserved=0
> >
> > Diff file of the text:
> >
> > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> > www.rfc-editor.org%2Fauthors%2Frfc9464-
> > diff.html&data=05%7C01%7Cmohamed.boucadair%40orange.com%7Cb2a1f0de
> > e85244493d1908dbb0e0e24c%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C
> > 0%7C638298252306846778%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDA
> > iLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sd
> > ata=MiclK0p0x%2FwWwjK6hdOs5aRRBV6AfmvzSH1hZA1pxO0%3D&reserved=0
> >
> > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> > www.rfc-editor.org%2Fauthors%2Frfc9464-
> > rfcdiff.html&data=05%7C01%7Cmohamed.boucadair%40orange.com%7Cb2a1f
> > 0dee85244493d1908dbb0e0e24c%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0
> > %7C0%7C638298252306846778%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAw
> > MDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C
> > &sdata=U6xedH0t5w2ciI7Uc2Jg3jYw0C%2BCKXIJwS%2Fy8mGqCG0%3D&reserved
> > =0 (side by side)
> >
> > Diff of the XML:
> >
> > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> > www.rfc-editor.org%2Fauthors%2Frfc9464-
> > xmldiff1.html&data=05%7C01%7Cmohamed.boucadair%40orange.com%7Cb2a1
> > f0dee85244493d1908dbb0e0e24c%7C90c7a20af34b40bfbc48b9253b6f5d20%7C
> > 0%7C0%7C638298252306846778%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjA
> > wMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7
> > C&sdata=BMT9%2BLuSD5RDu9QFtfvDmaiKeQt7DG7QUBJJhH1SjGE%3D&reserved=
> > 0
> >
> > This diff file compares an altered original and the RFC
> > (in order to make the changes in moved text viewable):
> >
> > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> > www.rfc-editor.org%2Fauthors%2Frfc9464-alt-
> > diff.html&data=05%7C01%7Cmohamed.boucadair%40orange.com%7Cb2a1f0de
> > e85244493d1908dbb0e0e24c%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C
> > 0%7C638298252306846778%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDA
> > iLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sd
> > ata=jFixXSJXkUar7rD9uvhkGXCcdPOLLWIztsXE3slNgmE%3D&reserved=0
> >
> > Tracking progress
> > -----------------
> >
> > The details of the AUTH48 status of your document are here:
> >
> > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> > www.rfc-
> > editor.org%2Fauth48%2Frfc9464&data=05%7C01%7Cmohamed.boucadair%40o
> > range.com%7Cb2a1f0dee85244493d1908dbb0e0e24c%7C90c7a20af34b40bfbc4
> > 8b9253b6f5d20%7C0%7C0%7C638298252306846778%7CUnknown%7CTWFpbGZsb3d
> > 8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3
> > D%7C3000%7C%7C%7C&sdata=9pKsy6EOrWJesRXiI%2F2%2BjSeLkQBPV18FvKScRJ
> > 97Oag%3D&reserved=0
> >
> > Please let us know if you have any questions.
> >
> > Thank you for your cooperation,
> >
> > RFC Editor
> >
> > --------------------------------------
> > RFC9464 (draft-ietf-ipsecme-add-ike-14)
> >
> > Title            : Internet Key Exchange Protocol Version 2
> > (IKEv2) Configuration for Encrypted DNS
> > Author(s)        : M. Boucadair, T. Reddy.K, D. Wing, V. Smyslov
> > WG Chair(s)      : Yoav Nir, Tero Kivinen
> > Area Director(s) : Roman Danyliw, Paul Wouters
> ______________________________________________________________________________________
> ______________________
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne
> doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez
> le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles
> d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
> 
> This message and its attachments may contain confidential or privileged information that may be
> protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its
> attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or
> falsified.
> Thank you.