Re: [homenet] draft-ietf-homenet-naming-architecture-dhc-options-08

[Daniel Migault <[e-mail]>]

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=
[e-mail]> 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 <[e-mail]>
> *Sent:* Thursday, April 1, 2021 12:19 PM
> *To:* Bernie Volz (volz) <[e-mail]>om>;
> [e-mail]
> *Cc:* [e-mail]
> *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) <[e-mail]>
> *Sent:* Tuesday, March 9, 2021 11:54 AM
> *To:* [e-mail] <
> [e-mail]>
> *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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/homenet
>


-- 
Daniel Migault
Ericsson