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

["Eric Vyncke (evyncke)" <[e-mail]>]

Merci Daniel,

By looking at the diff -17-18, you have addressed all my concerns 😊

It would be ready for IETF Last Call, but you were too energetic when removing the last sentence of section 6.2, you have actually removed the whole paragraph 😲 and the IANA registry must have a registration policy. So, we need to keep

"Future code points are assigned under RFC Required as per [RFC8126]."

Regards

-éric-waiting-for-19 ;-)

Also waiting for the revision of draft-ietf-homenet-front-end-naming-delegation-17 as my plan is to group the two I-D for the last call

From: Daniel Migault <[e-mail]>
Date: Tuesday, 20 September 2022 at 15:05
To: Eric Vyncke <[e-mail]>
Cc: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, Stephen Farrell <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Re: [homenet] AD review of draft-ietf-homenet-naming-architecture-dhc-options-16

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]<mailto:[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]<mailto:[e-mail]>> on behalf of Daniel Migault <[e-mail]<mailto:[e-mail]>>
Date: Friday, 12 August 2022 at 02:04
To: "Eric Vyncke (evyncke)" <evyncke=[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[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]<mailto:[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