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

From: Daniel Migault <[email-masked]>
Date: Thu, 1 Apr 2021 16:18:47 +0000

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-masked]>
Sent: Tuesday, March 9, 2021 11:54 AM
To: [email-masked] <[email-masked]>
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

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 1 Apr 2021 19:48:09 +0000

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-masked]>
Sent: Thursday, April 1, 2021 12:19 PM
To: Bernie Volz (volz) <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: Re: draft-ietf-homenet-naming-architecture-dhc-options-08

Hi Bernie,

Thanks for the review!

Yours,
Daniel
________________________________
From: Bernie Volz (volz) <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, March 9, 2021 11:54 AM
To: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
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.  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>

~~~
BV> This look good.

BV> See above.

~~~

</mglt>

  *   Bernie

---

From: Daniel Migault <[email-masked]>
Date: Thu, 1 Apr 2021 18:07:16 -0400

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.

   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-masked]> 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:
>
>
>
>    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
>
>    policy as described in [RFC5226 <https://tools.ietf.org/html/rfc5226>].
> Future proposed suboptions are to
>
> Two “BV>” comments in-line below.
>
>
>
>    - Bernie
>
>
>
> *From:* Daniel Migault <[email-masked]>
> *Sent:* Thursday, April 1, 2021 12:19 PM
> *To:* Bernie Volz (volz) <[email-masked]>;
> [email-masked]
> *Cc:* [email-masked]
> *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.
>
>
>
> ------------------------------
>
> *From:* Bernie Volz (volz) <[email-masked]>
> *Sent:* Tuesday, March 9, 2021 11:54 AM
> *To:* [email-masked] <
> [email-masked]>
> *Subject:* draft-ietf-homenet-naming-architecture-dhc-options-08
>
>
>
> Hi:
>
>
>
>    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>
>
>    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. 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>
>
> 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.
>
>
>
>
> ~~~
>
>    - Bernie
> _______________________________________________
> homenet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homenet
>

-- 
Daniel Migault
Ericsson

---

From: "Ray Hunter (v6ops)" <[email-masked]>
Date: Fri, 2 Apr 2021 14:07:34 +0200

Hi Daniel,

I have a question both for this draft and our "own" Homenet draft

Up until now we've been passing the specification of the DM * Reverse DM 
connections via separate configuration parameters: address/name, port 
number, and transport protocol.

Should we instead be using a DNS URI from 
https://tools.ietf.org/html/rfc4501?

That reduces the DM spec to a single parameter that is also extensible 
for the future.

regards,

Daniel Migault wrote on 01/04/2021 18:18:
> 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.
>
> ------------------------------------------------------------------------
> *To:* [email-masked] 
> <[email-masked]>
>  2. For the FQDN option data, please make sure you refer to encoding
>  3. In 4.1, the diagram shows “Public Key Data” yet the definition
>  4. 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>
>
>  5. You still reference RFC3315 when current DHCPv6 standard is RFC8415.
>
> <mglt>
>  6. The IANA considerations needs some work. You might see
> wondering if a specific registry needs to be created or not. For now I 
> have assumed yes. The IANA section looks like:
>
> the registry maintained in: 

-- 
regards,
RayH
<https://www.postbox-inc.com/?utm_source=email&utm_medium=siglink&utm_campaign=reach>

---

From: Daniel Migault <[email-masked]>
Date: Tue, 13 Apr 2021 09:46:33 -0400

Hi Ray,

Thanks for the question. I do not think that using such URI really fits our
needs here. To my understanding, the URI provides an abstract way to
designate the DNS entry without specifying how these entries are reached or
resolved. Typically, when multiple servers are hosting that DNS entry, the
user does not really care which server will be reached. At the time the URI
was defined, only Do53 was used. This has changed, so the URI designates a
DNS entry that may be reached multiple transports. This also means that
there is a need to discover which transport will be used. Such discovery
mechanism are in scope of the add WG but are not yet defined. Currently the
add WG is focused on auto upgrade mechanisms. This means you know this
server has enabled DoH and you switch the use DoH instead of Do53. In our
case, the architecture document define the DoT as a base line but does not
prevent other mechanisms to be used such as DoH for example. It is likely
that some auto upgrade mechanism could apply as well - when standardized. I
think that in our case one issue we have is that we would like to mandate
that the channels are secured, but the URI abstraction does not enable
this.
The other aspect that makes the use of such URI difficult is that we are
re-using DNS messages to configure a Primary / Secondary which is a bit out
of scope of the designation of the DNS data.

Yours,
Daniel

On Fri, Apr 2, 2021 at 8:08 AM Ray Hunter (v6ops) <[email-masked]> wrote:

> That reduces the DM spec to a single parameter that is also extensible for
> the future.
>
> regards,
>
> *From:* Bernie Volz (volz) <[email-masked]> <[email-masked]>
> homenet mailing [email-masked]://www.ietf.org/mailman/listinfo/homenet
>
>
> --
> regards,
> RayH
>

-- 
Daniel Migault
Ericsson