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

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