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

[Lynne Bartholomew <[e-mail]>]

Hi, Med.

Thank you for your prompt replies to this document as well!  We have updated it per your notes below.

Regarding these updates:

> (1) Section 3.1: I wonder if we can simply say
> 
> OLD: The descriptions of the fields shown in Figure 1 are as follows
> NEW: The description of the fields shown in Figure 1 is as follows:

. . .

> (3) Section 3.2: Idem as 3.1
> 
> OLD: The descriptions of the fields shown in Figure 3 are as follows
> NEW: The description of the fields shown in Figure 3 is as follows:

We followed suit for Figure 4, as the same idea applies.  Please let us know any objections.

= = = = =

Regarding this item:

>> 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.

We could not make this determination.  Please review, and let us know if any updates are needed.

= = = = =

The latest files are posted here (please refresh your browser):

   https://www.rfc-editor.org/authors/rfc9464.txt
   https://www.rfc-editor.org/authors/rfc9464.pdf
   https://www.rfc-editor.org/authors/rfc9464.html
   https://www.rfc-editor.org/authors/rfc9464.xml
   https://www.rfc-editor.org/authors/rfc9464-diff.html
   https://www.rfc-editor.org/authors/rfc9464-rfcdiff.html
   https://www.rfc-editor.org/authors/rfc9464-auth48diff.html

   https://www.rfc-editor.org/authors/rfc9464-alt-diff.html
   https://www.rfc-editor.org/authors/rfc9464-xmldiff1.html
   https://www.rfc-editor.org/authors/rfc9464-xmldiff2.html
   https://www.rfc-editor.org/authors/rfc9464-alt-diff.html

Please review our updates carefully, and let us know if we missed anything.

Thanks again!

RFC Editor/lb


> On Sep 12, 2023, at 4:33 AM, [e-mail] wrote:
> 
> Re-,
> 
> Please find below some very minor comments about the edited version:
> 
> (1) Section 3.1: I wonder if we can simply say
> 
> OLD: The descriptions of the fields shown in Figure 1 are as follows
> NEW: The description of the fields shown in Figure 1 is as follows:
> 
> (2) FWIW, the original text right after Figures 1/3/4 followed the same style for describing the fields similar to what is used in RFC7296 (see, e.g., the text right after Figure 4 of RFC7296). We may maintain that same style for consistency.
> 
> An example of revert back would be:
> 
> CURRENT: 
>   R (Reserved) (1 bit):  MUST be set to zero and MUST be ignored on
>      receipt (see Section 3.15.1 of [RFC7296] for details).
> 
> NEW:
>   R (Reserved, 1 bit) - This bit MUST be set to zero and MUST be ignored on
>      receipt (see Section 3.15.1 of [RFC7296] for details).
> 
> (3) Section 3.2: Idem as 3.1
> 
> OLD: The descriptions of the fields shown in Figure 3 are as follows
> NEW: The description of the fields shown in Figure 3 is as follows:
> 
> (4) Section 4
> 
> OLD: The DNS client establishes an encrypted DNS session (e.g., DoT, DoH, DoQ)
> NEW: The DNS client establishes an encrypted DNS session (e.g., DoT, DoH, or DoQ)
> 
> Thank you.
> 
> Cheers,
> Med


> On Sep 12, 2023, at 1:53 AM, [e-mail] wrote:
> 
> 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.
> 
> 
>