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

[Daniel Migault <[e-mail]>]

Hi,

I just submitted version 18. All comments have been addressed except moving
the appendices to a companion document. I would be a bit hesitant to start
a full process of adoption, last call while this can be shipped in an
appendix.  If that is not the case and there is a strong incentive toward
having a companion document we can easily publish such a document.

Yours,
Daniel

On Tue, Sep 20, 2022 at 8:17 AM Eric Vyncke (evyncke) <[e-mail]>
wrote:

> Daniel, Ralf, Tomek,
>
>
>
> Thank you for posting the -17 revision.
>
>
>
> Before requesting the IETF Last Call, I kindly request one small changes
> in -17 in the IANA section + a couple of minor suggestions that can be
> ignored, see below for EV>
>
>
>
> Stephen, as the doc shepherd, would you mind explaining why "PS" is the
> right intended status?
>
>
>
> We can aim to request the Last Call still this week if this I-D and the
> architecture revised I-Ds are quickly posted.
>
>
>
> Regards
>
>
>
> -éric
>
>
>
>
>
> *From: *homenet <[e-mail]> on behalf of Daniel Migault <
> [e-mail]>
> *Date: *Friday, 12 August 2022 at 02:04
> *To: *"Eric Vyncke (evyncke)" <evyncke=[e-mail]>
> *Cc: *"[e-mail]" <[e-mail]>
> *Subject: *Re: [homenet] AD review of
> draft-ietf-homenet-naming-architecture-dhc-options-16
>
>
>
> 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.
>
>
>
> EV> it would have been nice to have some text explaining this reasoning.
> Up to the authors to decide whether it is worth adding it.
>
> ### 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.
>
> EV> -17 has 'RFC required' (which is better -- see my previous point), but
> there is no expert for RFC/Spec required policies. So, remove the last
> sentence :)
>
>
>
>
>
>
> ~~~
> Bit Position | Transport Protocol Description |  Mnemonic | Reference
> -------------+--------------------------------+-----------+-----------
>       0      | DNS over TLS                   | DoT       | This-RFC
>      1-15    | unallocated                    |  -        |  -
> ~~~
> {:#tab-iana title="Supported Transport" }
>
> ## COMMENTS
>
>
>
> ### Shepherd's review, intended status
>
> Stephen, as noted above, please include some justification for the
> intended PS status.
>
>
>
>
>
> ### 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.
>
>
>
> EV> slight preference for including FORWARD, but up to you really
>
> ### 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.
>
>
>
> EV> I am still no convinced though ;-), but this is up to the authors
>
>
>


-- 
Daniel Migault
Ericsson