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 <homenet-boun...@ietf.org> on behalf of Daniel Migault <mglt.i...@gmail.com> Date: Friday, 12 August 2022 at 02:04 To: "Eric Vyncke (evyncke)" <evyncke=40cisco....@dmarc.ietf.org> Cc: "homenet@ietf.org" <homenet@ietf.org> 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=40cisco....@dmarc.ietf.org<mailto:40cisco....@dmarc.ietf.org>> 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
_______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
