Re: [homenet] draft-ietf-homenet-front-end-naming-delegation

[Daniel Migault <[e-mail]>]

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) <[e-mail]>
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 <[e-mail]> on behalf of Daniel Migault <
> [e-mail]>
> *Date: *Friday, 9 October 2020 at 19:22
> *To: *homenet <[e-mail]>
> *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