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

[[e-mail]]

Hi Martin,

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Martin Thomson <[e-mail]>
> Envoyé : mardi 28 juin 2022 02:09
> À : BOUCADAIR Mohamed INNOV/NET <[e-mail]>;
> Bernie Volz <[e-mail]>
> Cc : [e-mail]; [e-mail]; [e-mail];
> [e-mail]
> Objet : Re: [Last-Call] [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
> 
> 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?
> 

[Med] Multiple instances are possible but are likely to be split into multiple options. The main point of listing more than one instance in Figure 4 is to make it explicit how each DNR instance data can be unambiguously identified when concatenated and without making an assumption on the split boundaries. 

> Related: why is "DNR Instance Data Length" 2 bytes?

[Med] We do already allow for a single long DNR instance data to be split into multiple options. 2 bytes is used to accommodate such cases.

> 
> On Mon, Jun 27, 2022, at 16:06, [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]; draft-ietf-add-
> [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.