Just posted the 19 - usually I have one line per sentence... but not in that case ;-)
I suspect we did not address all your concerns for the draft-ietf-homenet-front-end-naming-delegation but we are waiting for your feedbacks to see what else needs to be addressed. Thank you for the follow up! Yours, Daniel On Tue, Sep 20, 2022 at 9:30 AM Eric Vyncke (evyncke) <evyn...@cisco.com> wrote: > 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 <mglt.i...@gmail.com> > *Date: *Tuesday, 20 September 2022 at 15:05 > *To: *Eric Vyncke <evyn...@cisco.com> > *Cc: *"ralf.we...@akamai.com" <ralf.we...@akamai.com>, " > tomasz.mrugal...@gmail.com" <tomasz.mrugal...@gmail.com>, Stephen Farrell > <stephen.farr...@cs.tcd.ie>, "homenet@ietf.org" <homenet@ietf.org> > *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) <evyn...@cisco.com> > 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 <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> 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 > -- Daniel Migault Ericsson
_______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
