Hi: I think what you want to do to is request IANA to create a new registry for these values and to populate the table with the values in the document. You also need to specify how new assignments are made. You might look at some of the recent I-Ds that created some of the other registry (such as on the DHCPv6 page). Such as from https://tools.ietf.org/html/draft-ietf-ntp-dhcpv6-ntp-opt-06:
IANA is required to maintain a new number space of NTP time source suboptions, located in the BOOTP-DHCP Parameters Registry. The initial suboptions are described in section 4<https://tools.ietf.org/html/draft-ietf-ntp-dhcpv6-ntp-opt-06#section-4> of this document. IANA assigns future NTP time source suboptions with a "IETF Consensus" policy as described in [RFC5226<https://tools.ietf.org/html/rfc5226>]. Future proposed suboptions are to be referenced symbolically in the Internet-Drafts that describe them, and shall be assigned numeric codes by IANA when approved for publication as an RFC. Two "BV>" comments in-line below. * Bernie From: Daniel Migault <[email protected]> Sent: Thursday, April 1, 2021 12:19 PM To: Bernie Volz (volz) <[email protected]>; [email protected] Cc: [email protected] Subject: Re: draft-ietf-homenet-naming-architecture-dhc-options-08 Hi Bernie, I apology for missing that email. Your comments addressed an old version, however most of them applies to the new version. I think all comments have been addressed on my working local copy and I provide more details on how we addressed them. I do have one remaining question regarding the IANA section on whether the specific values associated to a field of the DHCP option are part of the IANA section with the creation of a new registry or not. Please see inline my response for more details. Thanks for the review! Yours, Daniel ________________________________ From: Bernie Volz (volz) <[email protected]<mailto:[email protected]>> Sent: Tuesday, March 9, 2021 11:54 AM To: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Subject: draft-ietf-homenet-naming-architecture-dhc-options-08 Hi: Took a quick look at the document ... just a few nits to point out: 1. You use "Homnet" in 2 places; I think that should be Homenet? <mglt> fixed thanks. </mglt> 1. For the FQDN option data, please make sure you refer to encoding used is specified in https://tools.ietf.org/html/rfc8415#section-10 <<https://tools.ietf.org/html/rfc8415#section-10>mglt> thanks, the encoding has been specified for all FQDN data, i.e., the Registered Domain, the Distribusion Master and Reverse Distribution Master. </mglt> 1. In 4.1, the diagram shows "Public Key Data" yet the definition below it has "Client Public Key Data"; fix them to match. <mglt> This has been fixed in the previous version by removing these options. </mglt> 1. Sometimes you indicate the "length" of the data in the options, sometimes you don't; and "(varaiable)" is used in one place which is misspelled. <mglt> Variable has been fixed. I suppose the these comments has been fixed from the latest version. As far as i can see, the current version has (variable) indicated for all variable fields. and option-len field in each description. </mglt> 1. You still reference RFC3315 when current DHCPv6 standard is RFC8415. <mglt> I have updated the reference. Thanks. </mglt> 1. The IANA considerations needs some work. You might see https://datatracker.ietf.org/doc/draft-ietf-dots-server-discovery/15/?include_text=1 as an example of a recent very good IANA considerations section. <mglt> I have updated the IANA section. I do have one remaining question. One option specifies the the values of a field in a DHCP option. I am wondering if a specific registry needs to be created or not. For now I have assumed yes. The IANA section looks like: IANA is requested to assign the following new DHCPv6 Option Codes in the registry maintained in: https://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xhtml#dhcpv6-parameters-2. ~~~ Value Description Client ORO Singleton Option TBD1 OPTION_REGISTERED_DOMAIN Yes Yes TBD2 OPTION_DIST_MASTER Yes Yes TBD3 OPTION_REVERSE_DIST_MASTER Yes Yes BV> This look good. The document also requests a Supported Transport Registry: BV> See above. ~~~ Bit | Transport Protocol | Reference ----+--------------------+----------- 0 | DNS over TLS | 1 | DNS over HTTPS | 2-7 | unallocated | ~~~ </mglt> * Bernie
_______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
