Re: [homenet] AD review of draft-ietf-homenet-naming-architecture-dhc-options-16

[Daniel Migault <[e-mail]>]

Hi Eric,

Thank you for the review. Please find inline how we addressed your
comments.

You can also find the change on github on the link below:
https://github.com/ietf-homenet-wg/front-end-naming-delegation-dhc-options/pull/1/commits/088c8f783279a4506f55345b6dcc99b9f1555662

I will also send the IANA section for additional review to the IANA.

Yours,
Daniel

On Mon, Aug 8, 2022 at 10:44 AM Eric Vyncke (evyncke) <evyncke=
[e-mail]> wrote:

> As usual, I do my own review before requesting the IETF Last Call for all
> documents. The intent is to give another polishing pass on the I-D.
>
>
>
> For this review, the MD format is used.
>
>
>
> Hope this helps
>
>
>
> Regards
>
>
>
> -éric
>
>
>
>
>
> # Éric Vyncke, INT AD, comments for
> draft-ietf-homenet-naming-architecture-dhc-options-16
>
>
>
> CC @evyncke
>
>
>
> Thank you for the work put into this document.
>
>
>
> Please find below some blocking DISCUSS points, some non-blocking COMMENT
> points (but replies would be appreciated even if only for my own education).
>
>
>
> Special thanks to Stephen Farrel for the shepherd's detailed write-up
> including the WG consensus, *but* it lacks the justification of the
> intended status (and the WGLC was extended to the DHC WG).
>
>
>
> I hope that this review helps to improve the document,
>
>
>
> Regards,
>
>
>
> -éric
>
>
>
>
>
> ## DISCUSS
>
>
>
> ### Section 4.2 port ?
>
>
>
> The DHCP option does not allow to run DoT over a non-standard port. Or if
> another transport is defined without an associated default port, then there
> is no way to specify a port.
>
>
That is correct, the rationale was to minimize the number of arguments and
reduce the complexity of handling the DHCP Option. If we would consider
adding ports, these should be added to every supported transport. This
would move the Supported Transport field being a list of ( transport, port
). While not technically infeasible, that seemed to introduce too much
complexity with regard to using a dedicated IP address for the DM.
If the DM really needs to use another port  one may think of storing such
information in the DNS.

>
>
> ### Section 6 sub-sections
>
>
>
> As there are two IANA requests, please use 2 sub-sections, one per request.
>
done

>
>
> ### Section 6 reference
>
>
>
> For the request about option codes, in the table add the obvious 'this
> document' in the to-be-added column 'Reference' + the relevant section
> number.
>
done

>
>
> ### Section 6 registry
>
>
>
> s/IANA is requested to maintain a new number space/IANA is requested to
> create a new registry/
>
>
>
done

> Also follow RFC 8126 section 1.3 (and others) by notably adding a
> description, the parent grouping (DHC I guess)
>
>
>
 The sub section has been updated as follows:

## Supported Transport parameter

IANA is requested to maintain a new registry of Supported Transport
parameter in the Distributed Manager Option (OPTION_DIST_MANAGER) or the
Reverse Distribution Manager Option (OPTION_REVERSE_DIST_MANAGER). The
different parameters are defined in {{tab-st}} in {{sec-st}}.

The Name of the registry is: Supported Transport parameter

The registry description is:  The Supported Transport field of the DHCPv6
option is a tow byte field that indicates the supported transport protocols.
Each bit represents a specific transport mechanism.

The parent grouping is Dynamic Host Configuration Protocol for IPv6
(DHCPv6) at
https://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xhtml#dhcpv6-parameters-2
.

New entry MUST specify the bit position, the Transport Protocol Description
a Mnemonic and a Reference as defined in {{tab-iana}}.

The initial registry is as specified in {{tab-iana}}.

Changes of the  format or policies of the registry is left to the IETF via
the IESG.

Future code points are assigned under Specification Required as per
{{!RFC8126}}. The expert is expected to be familiar with DHCP.

~~~
Bit Position | Transport Protocol Description |  Mnemonic | Reference
-------------+--------------------------------+-----------+-----------
      0      | DNS over TLS                   | DoT       | This-RFC
     1-15    | unallocated                    |  -        |  -
~~~
{:#tab-iana title="Supported Transport" }

> ### Appendix B and its sub-sections
>
>
>
> Please use foo.example to stick to the example TLDs.
>
>
>
changed

> ## COMMENTS
>
>
>
> ### Shepherd's review, intended status
>
> Stephen, as noted above, please include some justification for the
> intended PS status.
>
>
>
> ### Abstract
>
>
>
> An 'agnostic' HNA is only defined in the appendix of the main document and
> is unclear without this context. Suggest to remove this word.
>
>
>
removed

>
>
> ### Section 2 DOI
>
>
>
> Isn't it 'DNS Outsourcing Infrastructure' ?
>
correct and changed

>
>
> ### Section 2 DOI or DM ?
>
>
>
> ```
>
>    This document describes how a network can provision the HNA with a
>
>    specific DOI.
>
> ```
>
> Is it DOI or DM?
>
Both can be used. The DM is a specific entity while DOI is a bit more
abstract. As this is the second sentence where we just described DOI, it
might be clearer for the reader to keep DOI - in my opinion.

>
>
> ### Section CE or CPE
>
>
>
> Please use CPE to be consistent with the companion document.
>
>
>
changed

> ### Section 4.2 option name
>
>
>
> By consistency with section 4.3, should this be
> OPTION_FORWARD_DIST_MANAGER ?
>
The rational was to have forward as default, but we can change that to
remain fair with the reverse dm. Let us know your thoughts.

>
>
> ### Section 4.2 FQDN
>
>
>
> Some explanations about the use of a FQDN vs. IP addresses would be
> welcome.
>
>
>
 We added the following text:

However, the use of a FQDN provides multiple advantages over IP addresses.
Firstly, it makes the DHCPv6 Option easier to parse and smaller -
especially when IPv4 and IPv6  addresses are expected to be provided.
Then the FQDN can reasonably be seen as a more stable identifier as well as
a pointer to additional information than the IP addresses may be useful to
in the future to establish the communication between the HNA and the DM.

### Section 4.2.1 flow
>
>
>
> As this section is also used by section 4.3, suggestion to move it after
> section 4.3 as section 4.4
>
>
>
moved

> ### Section 6 spec required
>
>
>
> I am concerned that 'spec required' is enough for such a 16-bit flags
> field. Should it be 'RFC required' ?
>
>
>
I am not too worried, but I am fine using the RFC required. Given the
reduced space this might be safer.

> ### References
>
>
>
> Unsure whether ietf-homenet-front-end-naming-delegation is normative, it
> is rather informative. Same for RFC 9103 and RFC 7858
>
>
>
I moved these references as informative. Regarding the status for
ietf-homenet. For the DHCP option itself, this is correct information is
probably right but to use the DHCP option this might lean toward
normative.


> ### App B
>
>
>
> The 1st and 3rd paragraph are quite repetitive.
>
>
>
The 1-3 paragraphs have been changed as follows:
OLD:
  This section considers the case when the end user wants its home
   network to use example.com not managed by her ISP (foo) as a
   Registered Homenet Domain.  This section still consider the ISP
   manages the home network and still provides example.foo as a
   Registered Homenet Domain.

   When the end user buys the domain name example.com, it may request to
   redirect the name example.com to example.foo using static redirection
   with CNAME [RFC2181], [RFC1034], DNAME [RFC6672] or CNAME+DNAME
   [I-D.sury-dnsext-cname-dname].

   This configuration is performed once when the domain name example.com
   is registered.  The only information the end user needs to know is
   the domain name assigned by the ISP.  Once this configuration is done
   no additional configuration is needed anymore.  More specifically,
   the HNA may be changed, the zone can be updated as in Appendix B
   without any additional configuration from the end user.

NEW:
 This section considers the case when the end user wants its home network
to use example.com not managed by her ISP (foo) as a Registered Homenet
Domain.
This section still considers the ISP manages the home network and still
provides foo.example as a Registered Homenet Domain.

When the end user buys the domain name example.com, it may request to
redirect the name example.com to foo.example using static redirection with
CNAME {{?RFC2181}}, {{?RFC1034}}, DNAME {{?RFC6672}} or CNAME+DNAME
{{?I-D.sury-dnsext-cname-dname}}.
The only information the end user needs to know is the domain name assigned
by the ISP.
Once the redirection has been configured, the HNA may be changed, the zone
can be updated as in {{sec-scenario-1}} without any additional
configuration from the end user.
>
> ### Appendix, why here ?
>
>
>
> There is little DHCP-related content in the appendix and the scenario
> would probably be more useful in the companion document.
>

The purpose of the appendix was to show that these DHCP option cannot be
used by an ISP to prevent users from using their own registered domain
names. I do not think that better fits the companion document which
describes the architecture and protocols to outsource the DNS zone. These
appendixes are focused on what can be done when the ISP provides an
outsourcing service.

>
>
> ## Notes
>
>
>
> This review is in the ["IETF Comments" Markdown format][ICMF], You can use
> the
>
> [`ietf-comments` tool][ICT] to automatically convert this review into
>
> individual GitHub issues.
>
>
>
> [ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
>
> [ICT]: https://github.com/mnot/ietf-comments
>
>
> _______________________________________________
> homenet mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/homenet
>


-- 
Daniel Migault
Ericsson