Re: [dhcwg] [Last-Call] 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

If you have more than one instance, you need a way to handle that because of the way options are concatenated.

If the DNR Instance Data Length was only a byte, the data would be limited to 255 bytes in length. That could not accommodate the longest possible domain name plus the additional data. Probably very unlikely someone would use such a long domain name, but safest to accommodate it?

- Bernie Volz

> On Jun 27, 2022, at 8:09 PM, Martin Thomson <mt@lowentropy.net> wrote:
> 
> How feasible is it to have multiple instances of ADN+IP+parameters in DHCPv4?  (I agree that the changes look good, but is this likely to ever allow anything more than say 2 instances?
> 
> Related: why is "DNR Instance Data Length" 2 bytes?
> 
>> On Mon, Jun 27, 2022, at 16:06, mohamed.boucadair@orange.com 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 <bevolz@gmail.com>
>>> Envoyé : samedi 25 juin 2022 04:02
>>> À : Eric Vyncke (evyncke) <evyncke=40cisco.com@dmarc.ietf.org>
>>> Cc : ipv6@ietf.org; dhcwg@ietf.org; draft-ietf-add-dnr@ietf.org;
>>> add@ietf.Org; last-call@ietf.org
>>> 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=40cisco.com@dmarc.ietf.org> wrote:
>>>> 
>>>> Extending the IETF Last Call to DHC and 6MAN WG as this IETF
>>> draft contains extension to DHC and IPv6 RA.
>>>> 
>>>> Please keep add@ietf.Org and last-call@ietf.org in cc in all
>>> your replies.
>>>> 
>>>> Thank very much in advance for your review
>>>> 
>>>> Regards
>>>> 
>>>> -éric
>>>> 
>>>> 
>>>> On 24/06/2022, 19:31, "iesg-secretary@ietf.org on behalf of The
>>> IESG" <iesg-secretary@ietf.org> 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
>>>>   last-call@ietf.org mailing lists by 2022-07-08.
>>> Exceptionally, comments may
>>>>   be sent to iesg@ietf.org 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
>>>> dhcwg@ietf.org
>>>> 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.
>> 
>> -- 
>> last-call mailing list
>> last-call@ietf.org
>> https://www.ietf.org/mailman/listinfo/last-call