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

From: Daniel Migault <[email-masked]>
Date: Fri, 9 Oct 2020 13:21:55 -0400

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

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Sun, 11 Oct 2020 08:20:59 +0000

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 <[email-masked]> on behalf of Daniel Migault <[email-masked]>
Date: Friday, 9 October 2020 at 19:22
To: homenet <[email-masked]>
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.

[1] https://datatracker.ietf.org/doc/draft-ietf-homenet-front-end-naming-delegation/

1.

"""

2.

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.

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.

--
Daniel Migault
Ericsson

---

From: Daniel Migault <[email-masked]>
Date: Sun, 11 Oct 2020 20:52:19 -0400

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) <[email-masked]>
wrote:

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

-- 
Daniel Migault
Ericsson