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

[Neil Cook <[e-mail]>]

I approve publication of this version also.

Thanks to everyone involved in getting this to RFC,

Neil

> On 14 Sep 2023, at 07:39, [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
> 
>> -----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.
>