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@xxxxxxxxxx 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@xxxxxxxxx> >> Envoyé : samedi 25 juin 2022 04:02 >> À : Eric Vyncke (evyncke) <evyncke=40cisco.com@xxxxxxxxxxxxxx> >> Cc : ipv6@xxxxxxxx; dhcwg@xxxxxxxx; draft-ietf-add-dnr@xxxxxxxx; >> add@xxxxxxxx; last-call@xxxxxxxx >> 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@xxxxxxxxxxxxxx> 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@xxxxxxxx and last-call@xxxxxxxx in cc in all >> your replies. >> > >> > Thank very much in advance for your review >> > >> > Regards >> > >> > -éric >> > >> > >> > On 24/06/2022, 19:31, "iesg-secretary@xxxxxxxx on behalf of The >> IESG" <iesg-secretary@xxxxxxxx> 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@xxxxxxxx mailing lists by 2022-07-08. >> Exceptionally, comments may >> > be sent to iesg@xxxxxxxx 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@xxxxxxxx >> > 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@xxxxxxxx > https://www.ietf.org/mailman/listinfo/last-call -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
