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@xxxxxxxxxxxxxx> 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@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
