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

[tirumal reddy <[e-mail]>]

Update looks good, I approve the publication.

Cheers,
-Tiru

On Thu, 14 Sept 2023 at 12:10, <[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.
>
>