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

[[e-mail]]

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.