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

["Eric Vyncke (evyncke)" <[e-mail]>]

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