Re: [auth48] AUTH48: RFC-to-be 9463 <draft-ietf-add-dnr-16> for your review

[Lynne Bartholomew <[e-mail]>]

Hi, Dan.  No worries!  We have noted your approval:

   https://www.rfc-editor.org/auth48/rfc9463

We now have all approvals for this document.  Please note that this document normatively depends on RFCs-to-be 9460 and 9461, and will be published along with those documents.

Thank you!

RFC Editor/lb


> On Sep 21, 2023, at 11:31 AM, Dan Wing <[e-mail]> wrote:
> 
> On Sep 14, 2023, at 8:45 AM, Lynne Bartholomew <[e-mail]> wrote:
>> 
>> Hi, Dan, Tommy, Med, Tiru, and Neil.
>> 
>> Dan, we have updated this document with your new contact information.  Please refresh your browser to see the latest:
> 
> 
> I reviewed the document and it all looks great.  Sorry for my delayed review.
> 
> -d
> 
> 
>> 
>>  https://www.rfc-editor.org/authors/rfc9463.txt
>>  https://www.rfc-editor.org/authors/rfc9463.pdf
>>  https://www.rfc-editor.org/authors/rfc9463.html
>>  https://www.rfc-editor.org/authors/rfc9463.xml
>>  https://www.rfc-editor.org/authors/rfc9463-diff.html
>>  https://www.rfc-editor.org/authors/rfc9463-rfcdiff.html
>>  https://www.rfc-editor.org/authors/rfc9463-auth48diff.html
>>  https://www.rfc-editor.org/authors/rfc9463-lastdiff.html
>>  https://www.rfc-editor.org/authors/rfc9463-lastrfcdiff.html
>> 
>>  https://www.rfc-editor.org/authors/rfc9463-xmldiff1.html
>>  https://www.rfc-editor.org/authors/rfc9463-xmldiff2.html
>>  https://www.rfc-editor.org/authors/rfc9463-alt-diff.html
>> 
>> Tommy, Med, Tiru, and Neil, we have noted your approvals on the AUTH48 status page:
>> 
>>  https://www.rfc-editor.org/auth48/rfc9463
>> 
>> Thank you!
>> 
>> RFC Editor/lb
>> 
>> 
>>> On Sep 14, 2023, at 12:20 AM, Neil Cook <[e-mail]> wrote:
>>> 
>>> I approve publication of this version also.
>>> 
>>> Thanks to everyone involved in getting this to RFC,
>>> 
>>> Neil
>> 
>> 
>> 
>>> On Sep 14, 2023, at 12:18 AM, tirumal reddy <[e-mail]> wrote:
>>> 
>>> Update looks good, I approve the publication.
>>> 
>>> Cheers,
>>> -Tiru
>> 
>> 
>> 
>>> On Sep 13, 2023, at 11:39 PM, [e-mail] wrote:
>>> 
>>> Hi Lynne, all,
>>> 
>>> This changes look good to me. I approve the publication of this version.
>>> 
>>> Many thanks for all your effort.
>>> 
>>> Cheers,
>>> Med
>> 
>> 
>> 
>>> On Sep 13, 2023, at 6:48 PM, Tommy Jensen <[e-mail]> wrote:
>>> 
>>> Good day Lynne,
>>> 
>>> All my feedback was accounted for in Med's review. I approve publication of this document.
>>> 
>>> Thanks,
>>> Tommy
>> 
>> 
>> 
>>> On Sep 13, 2023, at 9:01 AM, Dan Wing <[e-mail]> wrote:
>>> 
>>> My company name changed.
>>> 
>>> on title page:
>>> OLD:
>>>                                                               D. Wing
>>>                                                                Citrix
>>> NEW:
>>>                                                               D. Wing
>>>                                                  Cloud Software Group
>>> 
>>> on authors page:
>>> 
>>> OLD:
>>> Dan Wing
>>> Citrix Systems, Inc.
>>> United States of America
>>> Email: [e-mail]
>>> NEW:
>>> Dan Wing
>>> Cloud Software Group Holdings, Inc.
>>> United States of America
>>> Email: [e-mail]
>>> 
>>> Thanks!
>>> 
>>> 
>>> -d
>>> 
>>> 
>>> 
>>>> On Sep 13, 2023, at 8:40 AM, Lynne Bartholomew <[e-mail]> wrote:
>>>> 
>>>> Hi, Med.
>>>> 
>>>> Thank you very much for your prompt and informative replies!  We have updated this document per your emails below.
>>>> 
>>>> The latest files are posted here (please refresh your browser):
>>>> 
>>>> https://www.rfc-editor.org/authors/rfc9463.txt
>>>> https://www.rfc-editor.org/authors/rfc9463.pdf
>>>> https://www.rfc-editor.org/authors/rfc9463.html
>>>> https://www.rfc-editor.org/authors/rfc9463.xml
>>>> https://www.rfc-editor.org/authors/rfc9463-diff.html
>>>> https://www.rfc-editor.org/authors/rfc9463-rfcdiff.html
>>>> https://www.rfc-editor.org/authors/rfc9463-auth48diff.html
>>>> 
>>>> https://www.rfc-editor.org/authors/rfc9463-alt-diff.html
>>>> https://www.rfc-editor.org/authors/rfc9463-xmldiff1.html
>>>> https://www.rfc-editor.org/authors/rfc9463-xmldiff2.html
>>>> https://www.rfc-editor.org/authors/rfc9463-alt-diff.html
>>>> 
>>>> Please review our updates carefully, and let us know if we missed anything.
>>>> 
>>>> Thanks again for your help!
>>>> 
>>>> RFC Editor/lb
>>>> 
>>>> 
>>>>> On Sep 12, 2023, at 4:12 AM, [e-mail] wrote:
>>>>> 
>>>>> Re-,
>>>>> 
>>>>> Please find below some comments about the edited version:
>>>>> 
>>>>> (1) Abstract: add a missing "and"
>>>>> 
>>>>> OLD:
>>>>> This document specifies new DHCP and IPv6 Router Advertisement
>>>>> options to discover encrypted DNS resolvers (e.g., DNS over HTTPS,
>>>>> DNS over TLS, DNS over QUIC).
>>>>> 
>>>>> NEW:
>>>>> 
>>>>> This document specifies new DHCP and IPv6 Router Advertisement
>>>>> options to discover encrypted DNS resolvers (e.g., DNS over HTTPS,
>>>>> DNS over TLS, and DNS over QUIC).
>>>>> 
>>>>> (2) Introduction: be more explicit this is about discovery of resolvers
>>>>> 
>>>>> OLD:
>>>>> This document focuses on the discovery of encrypted DNS protocols
>>>>> such as DNS over HTTPS (DoH) [RFC8484], DNS over TLS (DoT) [RFC7858],
>>>>> or DNS over QUIC (DoQ) [RFC9250] in local networks.
>>>>> 
>>>>> NEW:
>>>>> This document focuses on the discovery of encrypted DNS resolvers which are using protocols
>>>>> such as DNS over HTTPS (DoH) [RFC8484], DNS over TLS (DoT) [RFC7858],
>>>>> or DNS over QUIC (DoQ) [RFC9250] in local networks.
>>>>> 
>>>>> (3) Section 3.1.3: simplify the ULA wording
>>>>> 
>>>>> OLD:
>>>>> Whether one or more IP addresses are returned in an Encrypted DNS
>>>>> option is deployment specific.  For example, a router embedding a
>>>>> recursive server or a forwarder has to include one single IP address
>>>>> pointing to one of its LAN-facing interfaces.  Typically, this IP
>>>>> address can be a private IPv4 address, a Link-Local address, a Unique
>>>>> Local IPv6 unicast Address (Unique Local Address (ULA)), or a Global
>>>>> Unicast Address (GUA).
>>>>> 
>>>>> NEW:
>>>>> Whether one or more IP addresses are returned in an Encrypted DNS
>>>>> option is deployment specific.  For example, a router embedding a
>>>>> recursive server or a forwarder has to include one single IP address
>>>>> pointing to one of its LAN-facing interfaces.  Typically, this IP
>>>>> address can be a private IPv4 address, a Link-Local address, an IPv6 
>>>>> Unique Local Address (ULA), or a Global Unicast Address (GUA).
>>>>> 
>>>>> (3) Section 4.1: correct an error about the field name
>>>>> 
>>>>> OLD: 
>>>>>  An example of the authentication-domain-name encoding is shown in
>>>>>  Figure 2.  This example conveys the FQDN "doh1.example.com.", and
>>>>>  the resulting Option-length field is 18.
>>>>> 
>>>>> NEW:
>>>>>  An example of the authentication-domain-name encoding is shown in
>>>>>  Figure 2.  This example conveys the FQDN "doh1.example.com.", and
>>>>>  the resulting ADN Length field is 18.
>>>>> 
>>>>> (4) Section 6.1: Revert to the initial wording for consistency with other fields
>>>>> 
>>>>> OLD:
>>>>> Service Priority:  The priority of this Encrypted DNS option instance
>>>>>  compared to other instances.  This 16-bit unsigned integer is
>>>>>  interpreted following the rules specified in Section 2.4.1 of
>>>>>  [RFC9460].
>>>>> 
>>>>> NEW:
>>>>> Service Priority:  16-bit unsigned integer.  The priority of this Encrypted DNS option instance
>>>>>  compared to other instances.  This field is
>>>>>  interpreted following the rules specified in Section 2.4.1 of
>>>>>  [RFC9460].
>>>>> 
>>>>> Thank you. 
>>>>> 
>>>>> Cheers,
>>>>> Med
>>>> 
>>>> 
>>>>> On Sep 12, 2023, at 12:56 AM, [e-mail] wrote:
>>>>> 
>>>>> Dear RFC Editor, 
>>>>> 
>>>>> Please see inline. 
>>>>> 
>>>>> I let my co-authors further comments as appropriate. 
>>>>> 
>>>>> Cheers,
>>>>> Med
>>>>> 
>>>>>> -----Message d'origine-----
>>>>>> De : [e-mail] <[e-mail]>
>>>>>> Envoyé : samedi 9 septembre 2023 04:56
>>>>>> À : BOUCADAIR Mohamed INNOV/NET <[e-mail]>;
>>>>>> [e-mail]; [e-mail]; [e-mail];
>>>>>> [e-mail]
>>>>>> Cc : [e-mail]; [e-mail]; add-
>>>>>> [e-mail]; [e-mail];
>>>>>> [e-mail]; [e-mail]
>>>>>> Objet : Re: AUTH48: RFC-to-be 9463 <draft-ietf-add-dnr-16> 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] Abbreviated (running) document title, which
>>>>>> appears in the PDF:
>>>>>> FYI, we updated the abbreviated title to "DNR", along the lines of
>>>>>> the running title "DDR" in the companion document 9462 (draft-
>>>>>> ietf-add-ddr).
>>>>>> Please let us know if you prefer otherwise.
>>>>>> 
>>>>>> Original:
>>>>>> Internet-Draft  Discovery of Network-designated Resolver
>>>>>> April 2023
>>>>>> 
>>>>>> Current PDF:
>>>>>> RFC 9463                          DNR
>>>>>> September 2023
>>>>>> -->
>>>>>> 
>>>>> 
>>>>> [Med] OK
>>>>> 
>>>>>> 
>>>>>> 2) <!-- [rfced] Datatracker "idnits" output for the original
>>>>>> approved document included the following warning.  Please let us
>>>>>> know if any changes are needed as related to this warning:
>>>>>> 
>>>>>> == There are [sic] 1 instance of lines with non-RFC2606-compliant
>>>>>> FQDNs in the
>>>>>> document. -->
>>>>>> 
>>>>> 
>>>>> [Med] No change is needed. Idnits complains about "a1.a2.a3.a4" but that is not a name.
>>>>> 
>>>>>> 
>>>>>> 3) <!-- [rfced] Section 1:  Please note that companion document
>>>>>> 9462 (draft-ietf-add-ddr) cites both RFCs 4861 and 8106 when
>>>>>> referring to IPv6 Router Advertisement options.  We have asked the
>>>>>> authors of that document if the same RFC should be cited in both
>>>>>> places.
>>>>>> 
>>>>>> Please note, however, that we do not see any mention of Router
>>>>>> Advertisement options in RFC 4861 - only Neighbor Discovery
>>>>>> options.
>>>>>> 
>>>>>> Would you like to see how/if draft-ietf-add-ddr updates its
>>>>>> comparable citation and update this document (or not) to match?
>>>>>> 
>>>>>> Original:
>>>>>> In particular, the document specifies how a local encrypted DNS
>>>>>> resolver can be discovered by connected hosts by means of DHCPv4
>>>>>> [RFC2132], DHCPv6 [RFC8415], and IPv6 Router Advertisement (RA)
>>>>>> [RFC4861] options. -->
>>>>>> 
>>>>> 
>>>>> [Med] It would be good if DDR aligns with this, but we leave that to DDR authors to decide. No change is needed to DNR.
>>>>> 
>>>>>> 
>>>>>> 4) <!-- [rfced] Section 3:  This sentence did not parse.  We
>>>>>> removed the colon (":").  If this is incorrect, please clarify
>>>>>> "and Neighbor Discovery protocol (Section 6): Encrypted DNS
>>>>>> options".
>>>>>> 
>>>>>> Original:
>>>>>> This document describes how a DNS client can discover local
>>>>>> encrypted  DNS resolvers using DHCP (Sections 4 and 5) and
>>>>>> Neighbor Discovery  protocol (Section 6): Encrypted DNS options.
>>>>>> 
>>>>>> Currently:
>>>>>> This document describes how a DNS client can discover local
>>>>>> encrypted  DNS resolvers using DHCP (Sections 4 and 5) and
>>>>>> Neighbor  Discovery protocol (Section 6) Encrypted DNS options. --
>>>>>>> 
>>>>>> 
>>>>> 
>>>>> [Med] OK.
>>>>> 
>>>>>> 
>>>>>> 5) <!-- [rfced] Section 3.2:  Should "the encrypted DNS is
>>>>>> discovered"
>>>>>> be "encrypted DNS resolvers are discovered"?  If the suggested
>>>>>> text is not correct, please clarify.
>>>>>> 
>>>>>> Original:
>>>>>> If the encrypted DNS is discovered by a host using both RA and
>>>>>> DHCP,  the rules discussed in Section 5.3.1 of [RFC8106] MUST be
>>>>>> followed.
>>>>>> 
>>>>>> Suggested:
>>>>>> If encrypted DNS resolvers are discovered by a host using both RA
>>>>>> and DHCP, the rules discussed in Section 5.3.1 of [RFC8106] MUST
>>>>>> be  followed. -->
>>>>>> 
>>>>> 
>>>>> [Med] The suggested text is better. Thanks.
>>>>> 
>>>>>> 
>>>>>> 6) <!-- [rfced] Section 3.3:  As [I-D.ietf-dnsop-svcb-https] does
>>>>>> not have a Section 6.1 and the title of its Section 7.1 is '"alpn"
>>>>>> and "no-default-alpn"', we updated the cited section number
>>>>>> accordingly.
>>>>>> If this is incorrect, please provide the correct citation.
>>>>>> 
>>>>>> Original:
>>>>>> ALPN-related considerations can be found in Section 6.1 of  [I-
>>>>>> D.ietf-dnsop-svcb-https].
>>>>>> 
>>>>>> Currently:
>>>>>> ALPN-related considerations
>>>>>> can be found in Section 7.1 of [RFC9460].
>>>>>> 
>>>>> 
>>>>> [Med] Good catch. Thanks. 
>>>>> 
>>>>>> (see
>>>>>> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2F
>>>>>> www.rfc-editor.org%2Fauthors%2Frfc9460.html%23section-
>>>>>> 7.1&data=05%7C01%7Cmohamed.boucadair%40orange.com%7C543c6045d28f49
>>>>>> 3499fe08dbb0e0a6ac%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C63
>>>>>> 8298251434819527%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQI
>>>>>> joiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=pZ
>>>>>> PbJQ35JUDdQ5%2BjFN%2FMa3yPBZV4qKOr4gGsNOSjxsk%3D&reserved=0)-->
>>>>>> 
>>>>>> 
>>>>>> 7) <!-- [rfced] Section 3.4:  This sentence does not parse.  If
>>>>>> the suggested text is not correct, please provide clarifying text.
>>>>>> 
>>>>>> Original:
>>>>>> Such considerations fall under the generic issue of handling
>>>>>> multiple  provisioning sources and which should not be dealt
>>>>>> within each option  separately as per the recommendation in
>>>>>> Section 12 of [RFC7227].
>>>>>> 
>>>>>> Suggested:
>>>>>> Such considerations fall under the generic issue of handling
>>>>>> multiple  provisioning sources and should not be processed in each
>>>>>> option  separately, as per the recommendation in Section 12 of
>>>>>> [RFC7227]. -->
>>>>>> 
>>>>> 
>>>>> [Med] OK. 
>>>>> 
>>>>>> 
>>>>>> 8) <!-- [rfced] Should any of the artwork elements (<artwork>) be
>>>>>> tagged as sourcecode or another element?  Please review
>>>>>> <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%7C543c6045
>>>>>> d28f493499fe08dbb0e0a6ac%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C
>>>>>> 0%7C638298251434819527%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDA
>>>>>> iLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sd
>>>>>> ata=22kRc4mRl1dWX6EBtFHzoKXIIxeLW5WtAPemy4BJDPE%3D&reserved=0>; if
>>>>>> the current list of preferred values for "type" does not contain
>>>>>> an applicable type, please let us know.  Also, it is acceptable to
>>>>>> leave the "type" attribute not set. -->
>>>>>> 
>>>>>> 
>>>>> 
>>>>> [Med] We don't have a suitable type for the ones in the draft. We can leave this unset. 
>>>>> 
>>>>>> 9) <!-- [rfced] Sections 4.1 and 5.1:  These definitions read
>>>>>> oddly, as the items preceding the colon are not the field name,
>>>>>> unlike all of the other field entries that follow each of them.
>>>>>> May we update as suggested?
>>>>>> 
>>>>>> Original:
>>>>>> Option-code:  OPTION_V6_DNR (TBA1, see Section 9.1) ...
>>>>>> Code:  OPTION_V4_DNR (TBA2, see Section 9.2).
>>>>>> 
>>>>> 
>>>>> [Med] Please keep the original as this is a convention used in DHCP documents. Thanks. 
>>>>> 
>>>>>> Perhaps:
>>>>>> OPTION_V6_DNR:  An Option Code (144; see Section 9.1).
>>>>>> ...
>>>>>> OPTION_V4_DNR:  An Option Code (162; see Section 9.2). -->
>>>>>> 
>>>>>> 
>>>>>> 10) <!-- [rfced] Figure 3:  We changed the field name in the
>>>>>> diagram from "ipv6-address" to "ipv6-address(es)" per usage in the
>>>>>> rest of this document (e.g., "shown in Figure 3" in Section 6.1)
>>>>>> and also updated the figure title accordingly.  Please let us know
>>>>>> any objections.
>>>>>> 
>>>>>> Original:
>>>>>> |                         ipv6-address                          |
>>>>>> ...
>>>>>> Figure 3: Format of the IPv6 Addresses Field
>>>>>> 
>>>>>> Currently:
>>>>>> |                       ipv6-address(es)                        |
>>>>>> ...
>>>>> 
>>>>> [Med] Please keep the original figure as it is correct. Each field includes only one IP address, but multiple fields with each an IP address can be included if needed.
>>>>> 
>>>>>> Figure 3: Format of the ipv6-address(es) Field -->
>>>>>> 
>>>>>> 
>>>>> 
>>>>> [Med] OK to update the title as suggested. 
>>>>> 
>>>>> 
>>>>>> 11) <!-- [rfced] Section 4.2:  Section 18.2.5 of RFC 8415 does not
>>>>>> explicitly mention the Option Request Option or "ORO".  Please
>>>>>> confirm that the citation for Section 18.2.5 of RFC 8415 will be
>>>>>> clear to readers.
>>>>>> 
>>>>>> Original:
>>>>>> To discover an encrypted DNS resolver, the DHCPv6 client MUST
>>>>>> include  OPTION_V6_DNR in an Option Request Option (ORO), as in
>>>>>> Sections  18.2.1, 18.2.2, 18.2.4, 18.2.5, 18.2.6, and 21.7 of
>>>>>> [RFC8415]. -->
>>>>>> 
>>>>> 
>>>>> [Med] The original text is OK as that section is explicitly listed in the template in https://datatracker.ietf.org/doc/html/rfc7227#section-21 (cited as 18.1.4 of 3315 which was replaced since then by RFC8415).
>>>>> 
>>>>>> 
>>>>>> 12) <!-- [rfced] Section 5.2:  Should 'multiple DNR instance data'
>>>>>> be 'multiple "DNR Instance Data" field entries' here?  If the
>>>>>> suggested text is not correct, please provide clarifying text.
>>>>>> 
>>>>>> Original:
>>>>>> The DHCPv4 client MUST be prepared to receive multiple DNR
>>>>>> instance  data in the OPTION_V4_DNR option; each instance is to be
>>>>>> treated as a  separate encrypted DNS resolver.
>>>>>> 
>>>>>> Suggested:
>>>>>> The DHCPv4 client MUST be prepared to receive multiple "DNR
>>>>>> Instance  Data" field entries in the OPTION_V4_DNR option; each
>>>>>> instance is to  be treated as a separate encrypted DNS resolver. -
>>>>>> ->
>>>>> 
>>>>> [Med] Works for me. 
>>>>>> 
>>>>>> 
>>>>>> 13) <!-- [rfced] Section 6.1:  We see that Figure 7 has the
>>>>>> "0 ... 1 ... 2 ... 3" ruler markers above the
>>>>>> "0 1 2 3 4 5 6 7 8 9 ..." ruler lines but Figures 1 and 3 do not.
>>>>>> (We're not sure whether or not Figures 4 and 5 would also apply
>>>>>> here.)  Would you like to place additional ruler-marker lines over
>>>>>> Figures 1 and 3, and perhaps Figures 4 and 5?  (For example,
>>>>>> similar figures in companion document 9464 (draft-ietf-ipsecme-
>>>>>> add-ike) all include the additional ruler-marker line.)
>>>>>> 
>>>>>> Original (best viewed with a fixed-point font such as Courier):
>>>>>> 0                   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 -
>>>>>> ->
>>>>>> 
>>>>> 
>>>>> [Med] OK to add those to Figures 1/3 and similar line to Figures 4/5.
>>>>> 
>>>>>> 
>>>>>> 14) <!-- [rfced] Section 6.1: FYI, in Figure 7, rather than insert
>>>>>> the value for TBA3 (144), we put the word "Type" to correspond to
>>>>>> the text below the figure. Please let us know if you prefer
>>>>>> otherwise.
>>>>>> 
>>>>>> Original:
>>>>>> |     TBA3      |     Length    |        Service Priority       |
>>>>>> 
>>>>>> Current:
>>>>>> |     Type      |     Length    |        Service Priority       |
>>>>>> -->
>>>>>> 
>>>>>> 
>>>>> 
>>>>> [Med] OK.
>>>>> 
>>>>>> 15) <!-- [rfced] Section 6.1:  We changed 'Service Parameters
>>>>>> field' to '"Service Parameters (SvcParams)" field' per the field
>>>>>> name.  Please let us know any objections.
>>>>>> 
>>>>>> Original:
>>>>>> SvcParams Length:  16-bit unsigned integer.  This field indicates
>>>>>> the
>>>>>> length of the Service Parameters field in octets.
>>>>>> 
>>>>>> Currently:
>>>>>> SvcParams Length:  16-bit unsigned integer.  This field indicates
>>>>>> the
>>>>>> length of the "Service Parameters (SvcParams)" field in
>>>>>> octets. -->
>>>>>> 
>>>>>> 
>>>>> 
>>>>> [Med] OK.
>>>>> 
>>>>>> 16) <!-- [rfced] Section 7.1:  We defined "CA" as "Certificate
>>>>>> Authority"
>>>>>> per companion document 9464 (draft-ietf-ipsecme-add-ike).  If this
>>>>>> is incorrect, please provide the correct definition.
>>>>>> 
>>>>>> Original:
>>>>>> The attacker can get a domain name with a domain-  validated
>>>>>> public certificate from a CA and host an encrypted DNS  resolver.
>>>>>> 
>>>>>> Currently:
>>>>>> The attacker can get a domain name with a domain-  validated
>>>>>> public certificate from a Certificate Authority (CA) and  host an
>>>>>> encrypted DNS resolver. -->
>>>>>> 
>>>>>> 
>>>>> 
>>>>> [Med] OK.
>>>>> 
>>>>>> 17) <!-- [rfced] Section 7.1:  It appears that "but cannot
>>>>>> provide"
>>>>>> refers to the endpoint, but does it refer to the mechanisms?
>>>>> 
>>>>> [Med] It refers to the mechanisms.
>>>>> 
>>>>> If
>>>>>> the endpoint, may we update as suggested?
>>>>>> 
>>>>>> Original:
>>>>>> The above mechanisms would ensure that the endpoint receives the
>>>>>> correct configuration information of the encrypted DNS resolvers
>>>>>> selected by the DHCP server (or RA sender), but cannot provide any
>>>>>> information about the DHCP server or the entity hosting the DHCP
>>>>>> server (or RA sender).
>>>>>> 
>>>>>> Suggested ("endpoint can receive ... but cannot provide"):
>>>>>> The above mechanisms would ensure that the endpoint can receive
>>>>>> the  correct configuration information of the encrypted DNS
>>>>>> resolvers  selected by the DHCP server (or RA sender) but cannot
>>>>>> provide any  information about the DHCP server or the entity
>>>>>> hosting the DHCP  server (or RA sender). -->
>>>>>> 
>>>>>> 
>>>>>> 18) <!-- [rfced] Section 7.4:  We see that "PSK" has been defined
>>>>>> but not "WPA".  Will this abbreviation be clear to readers?  If
>>>>>> not, how should it be defined?
>>>>>> 
>>>>>> Original:
>>>>>> If the pre-shared key (PSK) is the same for all clients that
>>>>>> connect  to the same WLAN (e.g., WPA-PSK), the shared key will be
>>>>>> available to  all nodes, including attackers.
>>>>>> 
>>>>>> Possibly:
>>>>>> If the pre-shared key (PSK) is the same for all clients that
>>>>>> connect  to the same WLAN (e.g., Wi-Fi Protected Access Pre-Shared
>>>>>> Key  (WPA-PSK)), the shared key will be available to all nodes,
>>>>>> including attackers. -->
>>>>>> 
>>>>> 
>>>>> [Med] ACK.
>>>>> 
>>>>>> 
>>>>>> 19) <!-- [rfced] Section 8:  To what does "but does not" refer in
>>>>>> this sentence - the mechanism, or the DHCP client or IPv6 host?
>>>>>> 
>>>>> 
>>>>> [Med] This refers to the mechanisms.
>>>>> 
>>>>>> Also, we see "mechanisms specified in this document" in Sections
>>>>>> 3.1.9 and 3.4.  Which mechanism is referred to here?
>>>>>> 
>>>>> 
>>>>> [Med] We refer to all of them. Please make this change: s/mechanism defined/mechanisms defined
>>>>> 
>>>>>> Original:
>>>>>> The
>>>>>> mechanism defined in this document can be used to infer that a
>>>>>> DHCP  client or IPv6 host support encrypted DNS options, but does
>>>>>> not  explicitly reveal whether local DNS clients are able to
>>>>>> consume these  options or infer their encryption capabilities. -->
>>>>>> 
>>>>>> 
>>>>>> 20) <!-- [rfced] References:  We could not find a connection
>>>>>> between the Unicode Consortium and the [Evil-Twin] Wikipedia page.
>>>>>> If the "Possibly" text is not correct, please provide an
>>>>>> appropriate URL for "Evil twin (wireless networks)".
>>>>>> 
>>>>>> Original:
>>>>>> [Evil-Twin]
>>>>>>        The Unicode Consortium, "Evil twin (wireless
>>>>>> networks)",
>>>>>> 
>>>>>> <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2
>>>>>> Fen.wikipedia.org%2Fwiki%2F&data=05%7C01%7Cmohamed.boucadair%40ora
>>>>>> nge.com%7C543c6045d28f493499fe08dbb0e0a6ac%7C90c7a20af34b40bfbc48b
>>>>>> 9253b6f5d20%7C0%7C0%7C638298251434819527%7CUnknown%7CTWFpbGZsb3d8e
>>>>>> yJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%
>>>>>> 7C3000%7C%7C%7C&sdata=NObhhyKiZa0tBeo4TFNWs5H9tW7BtZJBbkucSTIOAoQ%
>>>>>> 3D&reserved=0
>>>>>>        Evil_twin_(wireless_networks)>.
>>>>>> 
>>>>>> Possibly:
>>>>>> [Evil-Twin]
>>>>>>        Wikipedia, "Evil twin (wireless networks)", November
>>>>>>        2022
>>>>>> <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2
>>>>>> Fen.wikipedia.org%2Fwiki%2F&data=05%7C01%7Cmohamed.boucadair%40ora
>>>>>> nge.com%7C543c6045d28f493499fe08dbb0e0a6ac%7C90c7a20af34b40bfbc48b
>>>>>> 9253b6f5d20%7C0%7C0%7C638298251434819527%7CUnknown%7CTWFpbGZsb3d8e
>>>>>> yJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%
>>>>>> 7C3000%7C%7C%7C&sdata=NObhhyKiZa0tBeo4TFNWs5H9tW7BtZJBbkucSTIOAoQ%
>>>>>> 3D&reserved=0
>>>>>>        Evil_twin_(wireless_networks)>. -->
>>>>>> 
>>>>>> 
>>>>> 
>>>>> [Med] Works for me. Thanks.
>>>>> 
>>>>>> 21) <!-- [rfced] References:  We could not find a connection
>>>>>> between the Unicode Consortium and the [Krack] paper.  Should
>>>>>> author Mathy Vanhoef be listed instead?
>>>>>> 
>>>>> 
>>>>> [Med] Yes, please.
>>>>> 
>>>>>> Also, please confirm that the provided URL is stable.
>>>>> 
>>>>> [Med] We can use this more stable link: " https://dl.acm.org/doi/10.1145/3133956.3134027". Please update also the title to "Key Reinstallation Attacks: Forcing Nonce Reuse in WPA2".
>>>>> 
>>>>>> 
>>>>>> Original:
>>>>>> [Krack]    The Unicode Consortium, "Key Reinstallation Attacks",
>>>>>>        2017,
>>>>>> <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2
>>>>>> Fwww.krackattacks.com%2F&data=05%7C01%7Cmohamed.boucadair%40orange
>>>>>> .com%7C543c6045d28f493499fe08dbb0e0a6ac%7C90c7a20af34b40bfbc48b925
>>>>>> 3b6f5d20%7C0%7C0%7C638298251434819527%7CUnknown%7CTWFpbGZsb3d8eyJW
>>>>>> IjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3
>>>>>> 000%7C%7C%7C&sdata=MSuNjA%2BB3M5PfKmff2fVBqrp1S%2FeunV0G8C6gta1rdI
>>>>>> %3D&reserved=0>. -->
>>>>>> 
>>>>>> 
>>>>>> 22) <!-- [rfced] References:  We could not find a connection
>>>>>> between the Unicode Consortium and the [Dragonblood] paper.  Also,
>>>>>> the provided URL appears to be a personal URL.
>>>>>> 
>>>>>> Will the currently listed URL remain stable?  Is there a site
>>>>>> related to the Unicode Consortium that also provides this paper?
>>>>>> If not, should the authors (Mathy Vanhoef and Eyal Ronen) be
>>>>>> credited?
>>>>>> 
>>>>> 
>>>>> [Med] We can cite the authors + use this stable link instead (https://ieeexplore.ieee.org/document/9152782).
>>>>> 
>>>>>> Original:
>>>>>> [Dragonblood]
>>>>>>        The Unicode Consortium, "Dragonblood: Analyzing the
>>>>>>        Dragonfly Handshake of WPA3 and EAP-pwd",
>>>>>> 
>>>>>> <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2
>>>>>> Fpapers.mathyvanhoef.com%2Fdragonblood.pdf&data=05%7C01%7Cmohamed.
>>>>>> boucadair%40orange.com%7C543c6045d28f493499fe08dbb0e0a6ac%7C90c7a2
>>>>>> 0af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638298251434819527%7CUnknown%
>>>>>> 7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwi
>>>>>> LCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Fofu9ZA4AqH1JiT5aAJNvLU9VQipk
>>>>>> qMwRVkQbZMVdYc%3D&reserved=0>. -->
>>>>>> 
>>>>>> 
>>>>>> 23) <!-- [rfced] References:  We could not find any mention of
>>>>>> Cisco on the provided web page.  We updated this listing as noted
>>>>>> below.  If this is incorrect, please provide the correct title and
>>>>>> the matching URL.
>>>>>> 
>>>>>> Original:
>>>>>> [dot1x]    Cisco, "Basic 802.1x Wireless User Authentication",
>>>>>> 
>>>>>> <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2
>>>>>> Fopenwrt.org%2Fdocs%2Fguide-
>>>>>> user%2Fnetwork%2Fwifi%2F&data=05%7C01%7Cmohamed.boucadair%40orange
>>>>>> .com%7C543c6045d28f493499fe08dbb0e0a6ac%7C90c7a20af34b40bfbc48b925
>>>>>> 3b6f5d20%7C0%7C0%7C638298251434819527%7CUnknown%7CTWFpbGZsb3d8eyJW
>>>>>> IjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3
>>>>>> 000%7C%7C%7C&sdata=gL6D7KzP2AvooWUD%2BTo92r0eh6U40nJIjjXkM8RrzoI%3
>>>>>> D&reserved=0
>>>>>>        wireless.security.8021x>.
>>>>>> 
>>>>>> Currently:
>>>>>> [dot1x]    OpenWrt, "Introduction to 802.1X", December 2021,
>>>>>> 
>>>>>> <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2
>>>>>> Fopenwrt.org%2Fdocs%2Fguide-
>>>>>> user%2Fnetwork%2Fwifi%2F&data=05%7C01%7Cmohamed.boucadair%40orange
>>>>>> .com%7C543c6045d28f493499fe08dbb0e0a6ac%7C90c7a20af34b40bfbc48b925
>>>>>> 3b6f5d20%7C0%7C0%7C638298251434819527%7CUnknown%7CTWFpbGZsb3d8eyJW
>>>>>> IjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3
>>>>>> 000%7C%7C%7C&sdata=gL6D7KzP2AvooWUD%2BTo92r0eh6U40nJIjjXkM8RrzoI%3
>>>>>> D&reserved=0
>>>>>>        wireless.security.8021x>. -->
>>>>>> 
>>>>> 
>>>>> [Med] Works for me.
>>>>> 
>>>>>> 
>>>>>> 24) <!-- [rfced] References:  We see on the provided URL, under
>>>>>> the "Versions" tab, that quite a few versions have been added
>>>>>> since December 2019 (Release 16.3.0).  Should this listing be
>>>>>> updated?
>>>>>> We see that the latest version (Release 18 / version 18.3.0, dated
>>>>>> June 2023) also mentions "protocol configuration options" and
>>>>>> "ePCO".
>>>>>> 
>>>>> 
>>>>> [Med] Thank you for checking. We can update the reference entry to point to the latest rel/ver.
>>>>> 
>>>>>> Original:
>>>>>> [TS.24008] 3GPP, "Mobile radio interface Layer 3 specification;
>>>>>> Core
>>>>>>        network protocols; Stage 3 (Release 16)", December
>>>>>> 2019,
>>>>>> 
>>>>>> <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2
>>>>>> Fwww.3gpp.org%2FDynaReport%2F24008.htm&data=05%7C01%7Cmohamed.bouc
>>>>>> adair%40orange.com%7C543c6045d28f493499fe08dbb0e0a6ac%7C90c7a20af3
>>>>>> 4b40bfbc48b9253b6f5d20%7C0%7C0%7C638298251434819527%7CUnknown%7CTW
>>>>>> FpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJX
>>>>>> VCI6Mn0%3D%7C3000%7C%7C%7C&sdata=0nbE1Xf4OHcuFGd0NTLCXVFtuEaY1am9%
>>>>>> 2BprJtryl3ew%3D&reserved=0>. -->
>>>>>> 
>>>>>> 
>>>>>> 25) <!-- [rfced] Acknowledgments:  We found this sentence
>>>>>> confusing, as Section 7.3.1 of [RFC8310] says "... does not
>>>>>> provide an authentication domain name for the DNS resolver" and
>>>>>> "This document does not specify or request any DHCP extension to
>>>>>> provide authentication domain names".  The current text seems to
>>>>>> indicate the opposite.  Will this text be clear to readers, or
>>>>>> should it be updated?
>>>>>> 
>>>>> 
>>>>> [Med] That text is meant to ACK that RFC8310 identified DHCP as a candidate to convey ADN (although it does not specify how). What about:
>>>>> 
>>>>> NEW:
>>>>> 
>>>>> The use of DHCP as a candidate protocol to retrieve an authentication domain name was
>>>>> mentioned in Section 7.3.1 of [RFC8310] and in an Internet-Draft
>>>>> authored by Tom Pusateri and Willem Toorop
>>>>> [I-D.pusateri-dhc-dns-driu].
>>>>> 
>>>>> 
>>>>>> Original:
>>>>>> The use of DHCP to retrieve an authentication domain name was
>>>>>> discussed in Section 7.3.1 of [RFC8310] and in an Internet-Draft
>>>>>> authored by Tom Pusateri and Willem Toorop  [I-D.pusateri-dhc-dns-
>>>>>> driu].
>>>>>> 
>>>>>> Possibly *:
>>>>>> An issue related to using DHCP to retrieve an ADN is discussed in
>>>>>> Section 7.3.1 of [RFC8310].  [DNS-TLS-DHCPv6-Options], authored by
>>>>>> Tom Pusateri and Willem Toorop, discusses ways to address the
>>>>>> issue.
>>>>>> 
>>>>>> * Per this text from [I-D.pusateri-dhc-dns-driu]:
>>>>>> This document was motivated in part by Section 7.3.1 of
>>>>>> [RFC8310].
>>>>>> Thanks to the authors Sara Dickinson, Daniel Kahn Gillmor, and
>>>>>> Tirumaleswar Reddy for documenting the issue. -->
>>>>>> 
>>>>>> 
>>>>>> 26) <!-- [rfced] Acknowledgments:  Please confirm that, unlike the
>>>>>> other individuals listed here, Rich Salz did more than one review
>>>>>> ("secdir reviews").
>>>>>> 
>>>>> 
>>>>> [Med] I confirm.
>>>>> 
>>>>>> Original:
>>>>>> Thanks to Rich Salz for the secdir reviews, Joe Clarke for the
>>>>>> ops-  dir review, Robert Sparks for the artart review, and David
>>>>>> Blacka for  the dnsdir review. -->
>>>>>> 
>>>>>> 
>>>>>> 27) <!-- [rfced] Contributors section:  Per RFC 7322 (RFC Style
>>>>>> Guide), we changed "Contributing Authors" to "Contributors".
>>>>>> 
>>>>> 
>>>>> [Med] OK.
>>>>> 
>>>>>> If desired, you can add some information to the Contributors
>>>>>> section to describe their contributions.
>>>>> 
>>>>> [Med] No change is needed.
>>>>> 
>>>>> If Nicolai Leymann and
>>>>>> Zhiwei Yan should be credited as coauthors, the following could be
>>>>>> added (e.g., see RFC 9089).
>>>>>> Please let us know how you would like to proceed.
>>>>>> 
>>>>>> Original:
>>>>>> 11.  Contributing Authors
>>>>>> 
>>>>>> Nicolai Leymann
>>>>>> ...
>>>>>> 
>>>>>> Currently:
>>>>>> Contributors
>>>>>> 
>>>>>> Nicolai Leymann
>>>>>> ...
>>>>>> 
>>>>>> Possibly:
>>>>>> The following people contributed to the content of this document
>>>>>> and  should be considered coauthors:
>>>>>> 
>>>>>> Nicolai Leymann
>>>>>> ... -->
>>>>>> 
>>>>>> 
>>>>>> 28) <!-- [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%7C543c6045d28f493499fe08dbb0e0
>>>>>> a6ac%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6382982514348195
>>>>>> 27%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJ
>>>>>> BTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=r%2BjtER12cPY%2B
>>>>>> VIbvQEusFVzZOXp0Z%2F3%2Fu3X%2F7sq85DQ%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] All seems OK to me.
>>>>> 
>>>>>> 
>>>>>> 29) <!-- [rfced] The following term appears to be used
>>>>>> inconsistently in this document.  Please let us know which form is
>>>>>> preferred.
>>>>>> 
>>>>>> Encrypted DNS Option (1 instance - last paragraph of Section 7.1)
>>>>>> /
>>>>>> Encrypted DNS option (23 instances) /
>>>>>> encrypted DNS option (1 instance - Section 8, Paragraph 1)*
>>>>>> 
>>>>>> * As it appears that the option is of type "Encrypted DNS", we
>>>>>> suggest "Encrypted DNS option".
>>>>>> 
>>>>> 
>>>>> [Med] Deal!
>>>>> 
>>>>>> Also, some field names are quoted, but some are not.  Would you
>>>>>> like to apply a consistent style (i.e., all quoted or none
>>>>>> quoted)?
>>>>>> Please review usage, and advise.
>>>>>> 
>>>>>> For example:
>>>>>> authentication-domain-name field
>>>>>> 
>>>>>> Option-length field
>>>>>> 
>>>>>> Type and Length fields
>>>>>> 
>>>>>> "DNR Instance Data" field
>>>>>> 
>>>>>> "Addr Length", "IPv4 Address(es)", and "Service Parameters
>>>>>> (SvcParams)" fields ... -->
>>>>>> 
>>>>> 
>>>>> [Med] I don't think a change is needed. However, we will report any when reviewing the edited version. Thanks. 
>>>>> 
>>>>>> 
>>>>>> Thank you.
>>>>>> 
>>>>>> RFC Editor/lb/ar
>>>>>> 
>>>>>> 
>>>>>> On Sep 8, 2023, [e-mail] wrote:
>>>>>> 
>>>>> ...
>>>>>> RFC Editor
>>>>>> 
>>>>>> --------------------------------------
>>>>>> RFC9463 (draft-ietf-add-dnr-16)
>>>>>> 
>>>>>> Title            : DHCP and Router Advertisement Options for the
>>>>>> Discovery of Network-designated Resolvers (DNR)
>>>>>> Author(s)        : M. Boucadair, Ed., T. Reddy.K, Ed., D. Wing, N.
>>>>>> Cook, T. Jensen
>>>>>> WG Chair(s)      : David C Lawrence, Glenn Deen
>>>>>> Area Director(s) : Erik Kline, Éric Vyncke
>>>>> ____________________________________________________________________________________________________________
>>>>> 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.
>>>>> 
>>>>> 
>>>>> 
>>>> 
>>>> 
>>> 
>> 
>> 
>