Re: [dhcwg] FW: Last Call: <draft-ietf-add-dnr-09.txt> (DHCP and Router Advertisement Options for the Discovery of Network-designated Resolvers (DNR)) to Proposed Standard

[Bernie Volz <[e-mail]>]

Hi … yes, that looks much better! Thanks.

- Bernie Volz

> On Jun 27, 2022, at 2:06 AM, [e-mail] wrote:
> 
> Hi Bernie,
> 
> Thank you for the comment.
> 
> Please check https://tinyurl.com/latest-dnr-changes and let me know if any other change is needed. 
> 
> Cheers,
> Med
> 
>> -----Message d'origine-----
>> De : Bernie Volz <[e-mail]>
>> Envoyé : samedi 25 juin 2022 04:02
>> À : Eric Vyncke (evyncke) <evyncke=[e-mail]>
>> Cc : [e-mail]; [e-mail]; [e-mail];
>> [e-mail]; [e-mail]
>> Objet : Re: [dhcwg] FW: Last Call: <draft-ietf-add-dnr-09.txt>
>> (DHCP and Router Advertisement Options for the Discovery of
>> Network-designated Resolvers (DNR)) to Proposed Standard
>> 
>> Hi:
>> 
>> Thanks Eric for adding dhc wg. I have the following comment
>> related to DHCP.
>> 
>> For DHCPv4, you will need to reconsider the option encoding as
>> multiple instances of options are usually concatenated as per RFC
>> 3396. As an example, you may want to refer to how the Vender-
>> Identifying Vendor-Specific Information Option (127) is handled -
>> see RFC 3925. You already reference RFC 3396 to be able to encode
>> long domain names. Basically RFC 3925 uses an additional “data”
>> length field for each instance (this adds one additional octet per
>> instance). You might want to consider whether that is a single
>> octet or perhaps two octets given the potential size of the
>> option?
>> 
>> - Bernie Volz, dhc co-chair
>> 
>>> On Jun 24, 2022, at 2:16 PM, Eric Vyncke (evyncke)
>> <evyncke=[e-mail]> wrote:
>>> 
>>> Extending the IETF Last Call to DHC and 6MAN WG as this IETF
>> draft contains extension to DHC and IPv6 RA.
>>> 
>>> Please keep [e-mail] and [e-mail] in cc in all
>> your replies.
>>> 
>>> Thank very much in advance for your review
>>> 
>>> Regards
>>> 
>>> -éric
>>> 
>>> 
>>> On 24/06/2022, 19:31, "[e-mail] on behalf of The
>> IESG" <[e-mail]> wrote:
>>> 
>>> 
>>>   The IESG has received a request from the Adaptive DNS
>> Discovery WG (add) to
>>>   consider the following document: - 'DHCP and Router
>> Advertisement Options for
>>>   the Discovery of Network-
>>>      designated Resolvers (DNR)'
>>>     <draft-ietf-add-dnr-09.txt> as Proposed Standard
>>> 
>>>   The IESG plans to make a decision in the next few weeks, and
>> solicits final
>>>   comments on this action. Please send substantive comments to
>> the
>>>   [e-mail] mailing lists by 2022-07-08.
>> Exceptionally, comments may
>>>   be sent to [e-mail] instead. In either case, please
>> retain the beginning
>>>   of the Subject line to allow automated sorting.
>>> 
>>>   Abstract
>>> 
>>> 
>>>      The 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).  Particularly, it allows a host to
>> learn an
>>>      authentication domain name together with a list of IP
>> addresses and a
>>>      set of service parameters to reach such encrypted DNS
>> resolvers.
>>> 
>>> 
>>> 
>>> 
>>>   The file can be obtained via
>>>   https://datatracker.ietf.org/doc/draft-ietf-add-dnr/
>>> 
>>>   The ADD WG has another document
>> https://datatracker.ietf.org/doc/draft-ietf-add-ddr/, which should
>> probably be reviewed at the same time.
>>> 
>>>   No IPR declarations have been submitted directly on this I-D.
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> dhcwg mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/dhcwg
> 
> _________________________________________________________________________________________________________________________
> 
> 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.
>