Thanks for the feed back. I have just posted a new version with an updated IANA section.
Yours, Daniel The current IANA section is as follows: 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 IANA is requested to maintain a new number space of Supported Transport parameter in the Distributed Master Option (OPTION_DIST_MASTER) or the Reverse Distribution Master Server Option (OPTION_REVERSE_DIST_MASTER). The different parameters are defined in Figure 3 in Section 4.2.1. Future code points 4 - 8 are assigned under the IETF Review, other code points are assigned under Specification Required as per [RFC8126]. On Thu, Apr 1, 2021 at 3:48 PM Bernie Volz (volz) <volz= [email protected]> wrote: > 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]> > *Sent:* Tuesday, March 9, 2021 11:54 AM > *To:* [email protected] < > [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 > -- Daniel Migault Ericsson
_______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
