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

[Tommy Jensen <[e-mail]>]

Good day Lynne,

All my feedback was accounted for in Med's review. I approve publication of this document.

Thanks,
Tommy

> -----Original Message-----
> From: Dan Wing <[e-mail]>
> Sent: Wednesday, September 13, 2023 9:02 AM
> To: Lynne Bartholomew <[e-mail]>
> Cc: Mohamed Boucadair <[e-mail]>; rfc-editor@rfc-
> editor.org; Tirumaleswar Reddy <[e-mail]>; dwing-
> [e-mail]; [e-mail]; Tommy Jensen
> <[e-mail]>; [e-mail]; [e-mail];
> [e-mail]; Eric Vyncke <[e-mail]>;
> [e-mail]
> Subject: [EXTERNAL] Re: AUTH48: RFC-to-be 9463 <draft-ietf-add-dnr-16> for
> your review
>
> My company name changed.
>
> on title page:
> OLD:
>                                                                  D. Wing
>                                                                   Citrix
> NEW:
>                                                                  D. Wing
>                                                     Cloud Software Group
>
> on authors page:
>
> OLD:
>    Dan Wing
>    Citrix Systems, Inc.
>    United States of America
>    Email: [e-mail]
> NEW:
>    Dan Wing
>    Cloud Software Group Holdings, Inc.
>    United States of America
>    Email: [e-mail]
>
> Thanks!
>
>
> -d
>
>
>
> > On Sep 13, 2023, at 8:40 AM, Lynne Bartholomew
> <[e-mail]> wrote:
> >
> > Hi, Med.
> >
> > Thank you very much for your prompt and informative replies!  We have
> updated this document per your emails below.
> >
> > The latest files are posted here (please refresh your browser):
> >
> >
> https://www.rfc/
> -
> editor.org%2Fauthors%2Frfc9463.txt&data=05%7C01%7CJensen.Thomas%40mi
> crosoft.com%7C6cf9d2f7220b40fa551008dbb472b9aa%7C72f988bf86f141af91
> ab2d7cd011db47%7C1%7C0%7C638302177525705213%7CUnknown%7CTWF
> pbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI
> 6Mn0%3D%7C3000%7C%7C%7C&sdata=echVnOrVVe9lB49cgCIvjWuU4NZimCy
> BwaZo%2F2EiOjI%3D&reserved=0
> >
> https://www.rfc/
> -
> editor.org%2Fauthors%2Frfc9463.pdf&data=05%7C01%7CJensen.Thomas%40m
> icrosoft.com%7C6cf9d2f7220b40fa551008dbb472b9aa%7C72f988bf86f141af9
> 1ab2d7cd011db47%7C1%7C0%7C638302177525705213%7CUnknown%7CTW
> FpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVC
> I6Mn0%3D%7C3000%7C%7C%7C&sdata=mwjBZXH62GmTvNKTMM9ys2Nei6v
> waJSspR7Yy0whmK8%3D&reserved=0
> >
> https://www.rfc/
> -
> editor.org%2Fauthors%2Frfc9463.html&data=05%7C01%7CJensen.Thomas%40
> microsoft.com%7C6cf9d2f7220b40fa551008dbb472b9aa%7C72f988bf86f141af
> 91ab2d7cd011db47%7C1%7C0%7C638302177525705213%7CUnknown%7CT
> WFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJX
> VCI6Mn0%3D%7C3000%7C%7C%7C&sdata=rqXkN7x2qATiOfN7tgzBI5vVluIVuj
> w6x%2BjvFcG2Ros%3D&reserved=0
> >
> https://www.rfc/
> -
> editor.org%2Fauthors%2Frfc9463.xml&data=05%7C01%7CJensen.Thomas%40m
> icrosoft.com%7C6cf9d2f7220b40fa551008dbb472b9aa%7C72f988bf86f141af9
> 1ab2d7cd011db47%7C1%7C0%7C638302177525705213%7CUnknown%7CTW
> FpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVC
> I6Mn0%3D%7C3000%7C%7C%7C&sdata=lNjZjHfQNpUbeQA8mP%2Fuw01Mce
> VrES%2BpRA1YkA3BAdo%3D&reserved=0
> >
> https://www.rfc/
> -editor.org%2Fauthors%2Frfc9463-
> diff.html&data=05%7C01%7CJensen.Thomas%40microsoft.com%7C6cf9d2f722
> 0b40fa551008dbb472b9aa%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C
> 0%7C638302177525861460%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLj
> AwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C
> %7C&sdata=sn4vtJFcS8joMWk6dd%2B87wmynJdncWj26DTNYukuCOk%3D&res
> erved=0
> >
> https://www.rfc/
> -editor.org%2Fauthors%2Frfc9463-
> rfcdiff.html&data=05%7C01%7CJensen.Thomas%40microsoft.com%7C6cf9d2f7
> 220b40fa551008dbb472b9aa%7C72f988bf86f141af91ab2d7cd011db47%7C1%
> 7C0%7C638302177525861460%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4
> wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C
> %7C%7C&sdata=I9V2XO3BAQKc2X0GjcVhMBKrJQfGMWhFqW2EpTKVNn8%3D
> &reserved=0
> >
> > https://www/.
> > rfc-editor.org%2Fauthors%2Frfc9463-
> auth48diff.html&data=05%7C01%7CJens
> >
> en.Thomas%40microsoft.com%7C6cf9d2f7220b40fa551008dbb472b9aa%7C72
> f988b
> >
> f86f141af91ab2d7cd011db47%7C1%7C0%7C638302177525861460%7CUnkno
> wn%7CTWF
> >
> pbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI
> 6M
> >
> n0%3D%7C3000%7C%7C%7C&sdata=TWcjRwEOB5xKAXumK2CgtXns2uOUfDoA
> Gg2jD6xuut
> > Y%3D&reserved=0
> >
> >
> https://www.rfc/
> -editor.org%2Fauthors%2Frfc9463-alt-
> diff.html&data=05%7C01%7CJensen.Thomas%40microsoft.com%7C6cf9d2f722
> 0b40fa551008dbb472b9aa%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C
> 0%7C638302177525861460%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLj
> AwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C
> %7C&sdata=9nHZ2U220gQCAb6BxF1evg4CiH2RGkpgFHJ6HvGxslI%3D&reserve
> d=0
> >
> https://www.rfc/
> -editor.org%2Fauthors%2Frfc9463-
> xmldiff1.html&data=05%7C01%7CJensen.Thomas%40microsoft.com%7C6cf9d2
> f7220b40fa551008dbb472b9aa%7C72f988bf86f141af91ab2d7cd011db47%7C
> 1%7C0%7C638302177525861460%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiM
> C4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%
> 7C%7C%7C&sdata=GOqfEKxNcKPXVGODamsmkRC8Im4%2Fb1%2B%2FD2t9RTs
> x%2Byg%3D&reserved=0
> >
> https://www.rfc/
> -editor.org%2Fauthors%2Frfc9463-
> xmldiff2.html&data=05%7C01%7CJensen.Thomas%40microsoft.com%7C6cf9d2
> f7220b40fa551008dbb472b9aa%7C72f988bf86f141af91ab2d7cd011db47%7C
> 1%7C0%7C638302177525861460%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiM
> C4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%
> 7C%7C%7C&sdata=YgKmE%2FkougrafcuWzkgmEfsuJ6Uaw9AbjFuzVq3r3zA%3D
> &reserved=0
> >
> > https://www/.
> > rfc-editor.org%2Fauthors%2Frfc9463-alt-diff.html&data=05%7C01%7CJensen
> >
> .Thomas%40microsoft.com%7C6cf9d2f7220b40fa551008dbb472b9aa%7C72f9
> 88bf8
> >
> 6f141af91ab2d7cd011db47%7C1%7C0%7C638302177525861460%7CUnknow
> n%7CTWFpb
> >
> GZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6M
> n0
> >
> %3D%7C3000%7C%7C%7C&sdata=9nHZ2U220gQCAb6BxF1evg4CiH2RGkpgFHJ
> 6HvGxslI%
> > 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://eu/
> >>>
> r03.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252F
> >>>
> &data=05%7C01%7CJensen.Thomas%40microsoft.com%7C6cf9d2f7220b40fa5
> 510
> >>>
> 08dbb472b9aa%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63830
> 21775
> >>>
> 25861460%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV
> 2luMzI
> >>>
> iLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=s9u8Sfpa0p
> eIJS
> >>> pyXQgKq3fcu6LjvQwFwnqY6g472E4%3D&reserved=0
> >>>
> http://www/
> >>> .rfc-
> editor.org%2F&data=05%7C01%7CJensen.Thomas%40microsoft.com%7C6c
> >>>
> f9d2f7220b40fa551008dbb472b9aa%7C72f988bf86f141af91ab2d7cd011db47
> %7C
> >>>
> 1%7C0%7C638302177525861460%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiM
> C4wLjAwM
> >>>
> DAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C
> &sd
> >>>
> ata=tiTlhVVCqrLaoYYKiNrYAPUvQvNyIetcEFBNBtdv6lY%3D&reserved=0%2Fauth
> >>> ors%2Frfc9460.html%23section-
> >>>
> 7.1&data=05%7C01%7Cmohamed.boucadair%40orange.com%7C543c6045d28f
> 49
> >>>
> 3499fe08dbb0e0a6ac%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7
> C63
> >>>
> 8298251434819527%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAi
> LCJQI
> >>>
> joiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=p
> Z
> >>>
> 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://e/
> >>>
> ur03.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252
> >>>
> 52&data=05%7C01%7CJensen.Thomas%40microsoft.com%7C6cf9d2f7220b40f
> a55
> >>>
> 1008dbb472b9aa%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638
> 30217
> >>>
> 7525861460%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjo
> iV2luM
> >>>
> zIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=8mWwuV
> 5h2AJZ
> >>> tIh4rVLkfE0nxX7mHjbUWcDA6XCb6kk%3D&reserved=0
> >>> Fwww.rfc-editor.org%2Fmaterials%2Fsourcecode-
> >>>
> types.txt&data=05%7C01%7Cmohamed.boucadair%40orange.com%7C543c604
> 5
> >>>
> d28f493499fe08dbb0e0a6ac%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%
> 7C
> >>>
> 0%7C638298251434819527%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLj
> AwMDA
> >>>
> 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://datatrac/
> ker.ietf.org%2Fdoc%2Fhtml%2Frfc7227%23section-
> 21&data=05%7C01%7CJensen.Thomas%40microsoft.com%7C6cf9d2f7220b40f
> a551008dbb472b9aa%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C
> 638302177525861460%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwM
> DAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C
> &sdata=rTztMNNZBmIYro%2FiUxUELd27WAwnzpVxhSvxpnEUKz4%3D&reserve
> d=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://e/
> >>>
> ur03.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252
> >>>
> 52&data=05%7C01%7CJensen.Thomas%40microsoft.com%7C6cf9d2f7220b40f
> a55
> >>>
> 1008dbb472b9aa%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638
> 30217
> >>>
> 7525861460%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjo
> iV2luM
> >>>
> zIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=8mWwuV
> 5h2AJZ
> >>> tIh4rVLkfE0nxX7mHjbUWcDA6XCb6kk%3D&reserved=0
> >>>
> Fen.wikipedia.org%2Fwiki%2F&data=05%7C01%7Cmohamed.boucadair%40ora
> >>>
> nge.com%7C543c6045d28f493499fe08dbb0e0a6ac%7C90c7a20af34b40bfbc48
> b
> >>>
> 9253b6f5d20%7C0%7C0%7C638298251434819527%7CUnknown%7CTWFpbG
> Zsb3d8e
> >>>
> yJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%
> >>>
> 7C3000%7C%7C%7C&sdata=NObhhyKiZa0tBeo4TFNWs5H9tW7BtZJBbkucSTIOA
> oQ%
> >>> 3D&reserved=0
> >>>           Evil_twin_(wireless_networks)>.
> >>>
> >>> Possibly:
> >>> [Evil-Twin]
> >>>           Wikipedia, "Evil twin (wireless networks)", November
> >>>           2022
> >>> <https://e/
> >>>
> ur03.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252
> >>>
> 52&data=05%7C01%7CJensen.Thomas%40microsoft.com%7C6cf9d2f7220b40f
> a55
> >>>
> 1008dbb472b9aa%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638
> 30217
> >>>
> 7525861460%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjo
> iV2luM
> >>>
> zIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=8mWwuV
> 5h2AJZ
> >>> tIh4rVLkfE0nxX7mHjbUWcDA6XCb6kk%3D&reserved=0
> >>>
> Fen.wikipedia.org%2Fwiki%2F&data=05%7C01%7Cmohamed.boucadair%40ora
> >>>
> nge.com%7C543c6045d28f493499fe08dbb0e0a6ac%7C90c7a20af34b40bfbc48
> b
> >>>
> 9253b6f5d20%7C0%7C0%7C638298251434819527%7CUnknown%7CTWFpbG
> Zsb3d8e
> >>>
> yJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%
> >>>
> 7C3000%7C%7C%7C&sdata=NObhhyKiZa0tBeo4TFNWs5H9tW7BtZJBbkucSTIOA
> oQ%
> >>> 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.o/
> rg%2Fdoi%2F10.1145%2F3133956.3134027&data=05%7C01%7CJensen.Thoma
> s%40microsoft.com%7C6cf9d2f7220b40fa551008dbb472b9aa%7C72f988bf86f
> 141af91ab2d7cd011db47%7C1%7C0%7C638302177525861460%7CUnknown
> %7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWw
> iLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=K79122lXLiflxu4rTkb0kXD4eW
> ILoYr7trmWaJuBatM%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://e/
> >>>
> ur03.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252
> >>>
> 52&data=05%7C01%7CJensen.Thomas%40microsoft.com%7C6cf9d2f7220b40f
> a55
> >>>
> 1008dbb472b9aa%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638
> 30217
> >>>
> 7525861460%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjo
> iV2luM
> >>>
> zIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=8mWwuV
> 5h2AJZ
> >>> tIh4rVLkfE0nxX7mHjbUWcDA6XCb6kk%3D&reserved=0
> >>>
> Fwww.krackattacks.com%2F&data=05%7C01%7Cmohamed.boucadair%40orang
> e
> >>>
> .com%7C543c6045d28f493499fe08dbb0e0a6ac%7C90c7a20af34b40bfbc48b9
> 25
> >>>
> 3b6f5d20%7C0%7C0%7C638298251434819527%7CUnknown%7CTWFpbGZsb3
> d8eyJW
> >>>
> IjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3
> >>>
> 000%7C%7C%7C&sdata=MSuNjA%2BB3M5PfKmff2fVBqrp1S%2FeunV0G8C6gta
> 1rdI
> >>> %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://ieeexpl/
> ore.ieee.org%2Fdocument%2F9152782&data=05%7C01%7CJensen.Thomas%40
> microsoft.com%7C6cf9d2f7220b40fa551008dbb472b9aa%7C72f988bf86f141af
> 91ab2d7cd011db47%7C1%7C0%7C638302177526017728%7CUnknown%7CT
> WFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJX
> VCI6Mn0%3D%7C3000%7C%7C%7C&sdata=qbBBrF0tVn6c5ZbQs%2B9yDCEub
> MXD%2B%2BuUX8DjcNQdHpE%3D&reserved=0).
> >>
> >>> Original:
> >>> [Dragonblood]
> >>>           The Unicode Consortium, "Dragonblood: Analyzing the
> >>>           Dragonfly Handshake of WPA3 and EAP-pwd",
> >>>
> >>> <https://e/
> >>>
> ur03.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252
> >>>
> 52&data=05%7C01%7CJensen.Thomas%40microsoft.com%7C6cf9d2f7220b40f
> a55
> >>>
> 1008dbb472b9aa%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638
> 30217
> >>>
> 7526017728%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjo
> iV2luM
> >>>
> zIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=5e8REAdr
> 7Onr
> >>> D3eH5Hb17CPA9oZxsplGH1fCNoYw42U%3D&reserved=0
> >>>
> Fpapers.mathyvanhoef.com%2Fdragonblood.pdf&data=05%7C01%7Cmohamed
> .
> >>>
> boucadair%40orange.com%7C543c6045d28f493499fe08dbb0e0a6ac%7C90c7a
> 2
> >>>
> 0af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638298251434819527%7CUnkn
> own%
> >>>
> 7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwi
> >>>
> LCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Fofu9ZA4AqH1JiT5aAJNvLU9V
> Qipk
> >>> 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://e/
> >>>
> ur03.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252
> >>>
> 52&data=05%7C01%7CJensen.Thomas%40microsoft.com%7C6cf9d2f7220b40f
> a55
> >>>
> 1008dbb472b9aa%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638
> 30217
> >>>
> 7526017728%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjo
> iV2luM
> >>>
> zIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=5e8REAdr
> 7Onr
> >>> D3eH5Hb17CPA9oZxsplGH1fCNoYw42U%3D&reserved=0
> >>> Fopenwrt.org%2Fdocs%2Fguide-
> >>>
> user%2Fnetwork%2Fwifi%2F&data=05%7C01%7Cmohamed.boucadair%40oran
> ge
> >>>
> .com%7C543c6045d28f493499fe08dbb0e0a6ac%7C90c7a20af34b40bfbc48b9
> 25
> >>>
> 3b6f5d20%7C0%7C0%7C638298251434819527%7CUnknown%7CTWFpbGZsb3
> d8eyJW
> >>>
> IjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3
> >>>
> 000%7C%7C%7C&sdata=gL6D7KzP2AvooWUD%2BTo92r0eh6U40nJIjjXkM8Rrzo
> I%3
> >>> D&reserved=0
> >>>           wireless.security.8021x>.
> >>>
> >>> Currently:
> >>> [dot1x]    OpenWrt, "Introduction to 802.1X", December 2021,
> >>>
> >>> <https://e/
> >>>
> ur03.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252
> >>>
> 52&data=05%7C01%7CJensen.Thomas%40microsoft.com%7C6cf9d2f7220b40f
> a55
> >>>
> 1008dbb472b9aa%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638
> 30217
> >>>
> 7526017728%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjo
> iV2luM
> >>>
> zIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=5e8REAdr
> 7Onr
> >>> D3eH5Hb17CPA9oZxsplGH1fCNoYw42U%3D&reserved=0
> >>> Fopenwrt.org%2Fdocs%2Fguide-
> >>>
> user%2Fnetwork%2Fwifi%2F&data=05%7C01%7Cmohamed.boucadair%40oran
> ge
> >>>
> .com%7C543c6045d28f493499fe08dbb0e0a6ac%7C90c7a20af34b40bfbc48b9
> 25
> >>>
> 3b6f5d20%7C0%7C0%7C638298251434819527%7CUnknown%7CTWFpbGZsb3
> d8eyJW
> >>>
> IjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3
> >>>
> 000%7C%7C%7C&sdata=gL6D7KzP2AvooWUD%2BTo92r0eh6U40nJIjjXkM8Rrzo
> I%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://e/
> >>>
> ur03.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252
> >>>
> 52&data=05%7C01%7CJensen.Thomas%40microsoft.com%7C6cf9d2f7220b40f
> a55
> >>>
> 1008dbb472b9aa%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638
> 30217
> >>>
> 7526017728%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjo
> iV2luM
> >>>
> zIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=5e8REAdr
> 7Onr
> >>> D3eH5Hb17CPA9oZxsplGH1fCNoYw42U%3D&reserved=0
> >>>
> Fwww.3gpp.org%2FDynaReport%2F24008.htm&data=05%7C01%7Cmohamed.
> bouc
> >>>
> adair%40orange.com%7C543c6045d28f493499fe08dbb0e0a6ac%7C90c7a20af
> 3
> >>>
> 4b40bfbc48b9253b6f5d20%7C0%7C0%7C638298251434819527%7CUnknown
> %7CTW
> >>>
> FpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJX
> >>>
> VCI6Mn0%3D%7C3000%7C%7C%7C&sdata=0nbE1Xf4OHcuFGd0NTLCXVFtuEaY
> 1am9%
> >>> 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://e/
> >>>
> ur03.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252
> >>>
> 52&data=05%7C01%7CJensen.Thomas%40microsoft.com%7C6cf9d2f7220b40f
> a55
> >>>
> 1008dbb472b9aa%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638
> 30217
> >>>
> 7526017728%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjo
> iV2luM
> >>>
> zIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=5e8REAdr
> 7Onr
> >>> D3eH5Hb17CPA9oZxsplGH1fCNoYw42U%3D&reserved=0
> >>> Fwww.rfc-
> >>> editor.org%2Fstyleguide%2Fpart2%2F%23inclusive_language&data=05%7C
> >>>
> 01%7Cmohamed.boucadair%40orange.com%7C543c6045d28f493499fe08dbb0
> e0
> >>>
> a6ac%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6382982514348
> 195
> >>>
> 27%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL
> CJ
> >>>
> 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.
> >>
> >>
> >>
> >
> >