Hi, Sure, we will publish both drafts updated by the end of the week.
Yours, Daniel On Sun, Oct 11, 2020 at 4:21 AM Eric Vyncke (evyncke) <evyn...@cisco.com> wrote: > Daniel, thank you for the update on this draft. > > > > May the WG expect a revised I-D (and possibly one for the DHCPv6 draft) in > the coming days? > > > > Regards > > > > -éric > > > > *From: *homenet <homenet-boun...@ietf.org> on behalf of Daniel Migault < > mglt.i...@gmail.com> > *Date: *Friday, 9 October 2020 at 19:22 > *To: *homenet <homenet@ietf.org> > *Subject: *[homenet] draft-ietf-homenet-front-end-naming-delegation > > > > Hi, > > > > I have reviewed the draft. I have addressed some nits and clarification. > I believe the draft is in a good shape and should be ready for WGLC soon. > It seems to me that the only thing to do is to document how provisioning > the HNA can be done automatically or at least requiring a > minimal configuration steps from the end user. I expect this to be set in > the next two weeks and a clean version being published. > > > > Initially, we wanted to request an authorization token to establish the > channel between the HNA and the DM. However, we have not seen any > mechanisms that enable to carry this OAUTH token via TLS -only. As a > result, we envisioned the end user authenticate to a registrar, provide a > token to the HNA. The HNA uses that token to a resource server from where > the DM retrieves the certificate used for its authentication by the DM. > > > > Please find other comments below: > > > > [1] > https://datatracker.ietf.org/doc/draft-ietf-homenet-front-end-naming-delegation/ > > > > 1. > > """ > The main one is that the Dynamic DNS update > would also update the zone's NS records, while the goal is to update the > Distribution Master's configuration files. > """ > > We maybe need to clarify why the zone's NS RRset needs to be updated. > > 2. > This specification also assumes the same transport protocol and ports > used by the DM to serve the Control Channel and by the HNA to serve the > Synchronization Channel are the same. > > I think the sentence can be clarified. I think what we want to say is that > the specification assumes that: > * the DM serves both the Control Channel and Synchronization Channel on a > single IP address, single port and with a single transport protocol. > * the HNA uses a single IP address for both the Control and > Synchronization channel by default. However, the HNA MAY use disctinct IP > addresses - see section {{sec-sync}} for more details. > > I would like to add that DNS over TLS SHOULD be supported. > > 3. > Should we replace Outsroucing Infrastructure by OI ? At some point I > believe that would ease the reading. Ss most of the document describes > interactions between DM and HNA and the DM belongs to the Outsourcing > Infratsructure. > > 4. > It seems that the Envisionned deployment scenarios section can be removed > or at least merged with hna-provisionning section. > > 5. > section "Example: HNA necessary parameters for outsourcing > {#sec-configuration-parameters}" may also be removed / merged with > hna-provisionning > > 6. > Maybe hna-provisionning section can be put in the appendix. > > > > -- > > Daniel Migault > > Ericsson > -- Daniel Migault Ericsson
_______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
