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

[Daniel Migault <[e-mail]>]

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
~~~

The document also requests a Supported Transport Registry:

~~~
Bit | Transport Protocol | Reference
----+--------------------+-----------
 0  | DNS over TLS       |
 1  | DNS over HTTPS     |
2-7 | unallocated        |
~~~

</mglt>



  *   Bernie