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

[[e-mail]]

Hi Lynne, all,

This changes look good to me. I approve the publication of this version.

Many thanks for all your effort.

Cheers,
Med

> -----Message d'origine-----
> De : Lynne Bartholomew <[e-mail]>
> Envoyé : mercredi 13 septembre 2023 17:40
> À : BOUCADAIR Mohamed INNOV/NET <[e-mail]>
> Cc : [e-mail]; [e-mail]; dwing-
> [e-mail]; [e-mail]; [e-mail]; add-
> [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail]
> Objet : Re: AUTH48: RFC-to-be 9463 <draft-ietf-add-dnr-16> for your
> review
>
> 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%2Fauthors%2Frfc9463.txt&data=05%7C01%7Cmohamed.boucadair%40
> orange.com%7Cbe492b66eb5b429dd5b608dbb4701221%7C90c7a20af34b40bfbc48b9
> 253b6f5d20%7C0%7C0%7C638302166134366339%7CUnknown%7CTWFpbGZsb3d8eyJWIj
> oiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C
> %7C%7C&sdata=xgW9WvXaksz%2BZcYl%2BnsNmHs3tHDa6fYx60set2WX2lA%3D&reserv
> ed=0
>
> https://www/.
> rfc-
> editor.org%2Fauthors%2Frfc9463.pdf&data=05%7C01%7Cmohamed.boucadair%40
> orange.com%7Cbe492b66eb5b429dd5b608dbb4701221%7C90c7a20af34b40bfbc48b9
> 253b6f5d20%7C0%7C0%7C638302166134366339%7CUnknown%7CTWFpbGZsb3d8eyJWIj
> oiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C
> %7C%7C&sdata=LYQrsGrAXgzMGIc98V1PKbZH%2Fe9Kzzcx47HSj1Woyjg%3D&reserved
> =0
>
> https://www/.
> rfc-
> editor.org%2Fauthors%2Frfc9463.html&data=05%7C01%7Cmohamed.boucadair%4
> 0orange.com%7Cbe492b66eb5b429dd5b608dbb4701221%7C90c7a20af34b40bfbc48b
> 9253b6f5d20%7C0%7C0%7C638302166134522558%7CUnknown%7CTWFpbGZsb3d8eyJWI
> joiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7
> C%7C%7C&sdata=52G9BM3vFUuwMXAbxx9G%2BdXSC%2BwxNLmQBPHnFyUb1Ws%3D&reser
> ved=0
>
> https://www/.
> rfc-
> editor.org%2Fauthors%2Frfc9463.xml&data=05%7C01%7Cmohamed.boucadair%40
> orange.com%7Cbe492b66eb5b429dd5b608dbb4701221%7C90c7a20af34b40bfbc48b9
> 253b6f5d20%7C0%7C0%7C638302166134522558%7CUnknown%7CTWFpbGZsb3d8eyJWIj
> oiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C
> %7C%7C&sdata=49T3ezktfTO9ZHbv4DaJ%2FiHyQRF0DCJSFTHT57u6JDc%3D&reserved
> =0
>
> https://www/.
> rfc-editor.org%2Fauthors%2Frfc9463-
> diff.html&data=05%7C01%7Cmohamed.boucadair%40orange.com%7Cbe492b66eb5b
> 429dd5b608dbb4701221%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6383
> 02166134522558%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2l
> uMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=PIMXQNRnKQB3
> 0O2EwTzY868KBNVmWpOXp3TxI5oq6IM%3D&reserved=0
>
> https://www/.
> rfc-editor.org%2Fauthors%2Frfc9463-
> rfcdiff.html&data=05%7C01%7Cmohamed.boucadair%40orange.com%7Cbe492b66e
> b5b429dd5b608dbb4701221%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6
> 38302166134522558%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoi
> V2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=MJb6ePu2r
> wXWGfPsOS%2BpkFOv%2BELvIad1tXL10AcyXlE%3D&reserved=0
>
> https://www/.
> rfc-editor.org%2Fauthors%2Frfc9463-
> auth48diff.html&data=05%7C01%7Cmohamed.boucadair%40orange.com%7Cbe492b
> 66eb5b429dd5b608dbb4701221%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%
> 7C638302166134522558%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQI
> joiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=v5YxYL
> DhnS5rCaTsg5L2UDEAQQzyNhzncQngCuc25tE%3D&reserved=0
>
>
> https://www/.
> rfc-editor.org%2Fauthors%2Frfc9463-alt-
> diff.html&data=05%7C01%7Cmohamed.boucadair%40orange.com%7Cbe492b66eb5b
> 429dd5b608dbb4701221%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6383
> 02166134522558%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2l
> uMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=0GHnj8%2FgVp
> qAbIHCsTa%2BCnvZvv94IFXCYo%2BTehrwHNs%3D&reserved=0
>
> https://www/.
> rfc-editor.org%2Fauthors%2Frfc9463-
> xmldiff1.html&data=05%7C01%7Cmohamed.boucadair%40orange.com%7Cbe492b66
> eb5b429dd5b608dbb4701221%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C
> 638302166134522558%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjo
> iV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Cs35OVuK
> DV6YEoTXHIiwqWaKmt63rE5X%2BM%2B41Cfk0Sw%3D&reserved=0
>
> https://www/.
> rfc-editor.org%2Fauthors%2Frfc9463-
> xmldiff2.html&data=05%7C01%7Cmohamed.boucadair%40orange.com%7Cbe492b66
> eb5b429dd5b608dbb4701221%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C
> 638302166134522558%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjo
> iV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=qcma2S3J
> ZmHCKs6zeJvj3FVYVi4NdQ%2BOmIPwy6KEzwc%3D&reserved=0
>
> https://www/.
> rfc-editor.org%2Fauthors%2Frfc9463-alt-
> diff.html&data=05%7C01%7Cmohamed.boucadair%40orange.com%7Cbe492b66eb5b
> 429dd5b608dbb4701221%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6383
> 02166134522558%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2l
> uMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=0GHnj8%2FgVp
> qAbIHCsTa%2BCnvZvv94IFXCYo%2BTehrwHNs%3D&reserved=0
>
> 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
> >>
> http://www/.
> >> rfc-
> editor.org%2F&data=05%7C01%7Cmohamed.boucadair%40orange.com%7Cbe4
> >>
> 92b66eb5b429dd5b608dbb4701221%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%
> >>
> 7C0%7C638302166134522558%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAi
> >>
> LCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=
> >>
> cQUFlS6RkTTbMPnqcXKx1bKlBnAc5C4OQ%2FYr6drT2no%3D&reserved=0%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%252
> >> 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://data/
> tracker.ietf.org%2Fdoc%2Fhtml%2Frfc7227%23section-
> 21&data=05%7C01%7Cmohamed.boucadair%40orange.com%7Cbe492b66eb5b429dd5b
> 608dbb4701221%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C63830216613
> 4522558%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLC
> JBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=7X%2BDdRCfAcAYGf3M0
> O%2FMsQG9Gb%2FIDBCeLxJh%2FJO22%2FQ%3D&reserved=0 (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%252
> >> 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%252
> >> 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.a/
> cm.org%2Fdoi%2F10.1145%2F3133956.3134027&data=05%7C01%7Cmohamed.boucad
> air%40orange.com%7Cbe492b66eb5b429dd5b608dbb4701221%7C90c7a20af34b40bf
> bc48b9253b6f5d20%7C0%7C0%7C638302166134522558%7CUnknown%7CTWFpbGZsb3d8
> eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3
> 000%7C%7C%7C&sdata=wz7jd9XFinjFzQ8xR4v%2BJ%2FAW1nWNVmkUfmEDHGk6yeM%3D&
> reserved=0". 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%252
> >> 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://iee/
> explore.ieee.org%2Fdocument%2F9152782&data=05%7C01%7Cmohamed.boucadair
> %40orange.com%7Cbe492b66eb5b429dd5b608dbb4701221%7C90c7a20af34b40bfbc4
> 8b9253b6f5d20%7C0%7C0%7C638302166134522558%7CUnknown%7CTWFpbGZsb3d8eyJ
> WIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000
> %7C%7C%7C&sdata=ovlmksDWI%2BdbBMh6K6pMCHIg2SWDq4ZaybQdUATRxhk%3D&reser
> ved=0).
> >
> >> 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%252
> >> 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%252
> >> 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%252
> >> 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%252
> >> 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%252
> >> 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.