Re: [Gen-art] review of draft-ietf-homenet-hncp-09.txt

[Markus Stenberg <[e-mail]>]

First of all, thanks for the review. 

Steven Barth already incorporated some of the comments but did not reply, so I am here to provide inline answers to the rest.
The ‘fixed’ things are addressed in git staged version (to-be -10; we are waiting for further IESG-caused reviews before publishing).

On 27.10.2015, at 14.00, Francis Dupont <[e-mail]> wrote:
> Nits/editorial comments:
> - ToC page 3 and D page 38: Acknowledgements -> Acknowledgments
>  (BTW usually the Acknowledgments section is a section, i.e., not
>   an appendix)
> 
> - 1 page 3: please introduce the HNCP abbrev
> 
> - 1 page 4: lease introduce the DNCP abbrev
> 
> - 5.1 page 9: please add the title of RFC 6092
> 
> - 6.2 page 12: Announcements of individual external connections may consist
>  (ambiguous “may": please change it for a synonym or a MAY)

Fixed.

> - 7.1 page 19: there are new (i.e., other than 4861 or 3315) ways
>  to build not-temporary IPv6 addresses. Perhaps wording should be
>  updated to include them? In doubt please contact Fernando Gont
>  who is (co-)author of most of them.

I am not sure how this is relevant. At least RFC7217 is essentially just 4861 with slightly different address bits (which are irrelevant to us; all we care is someone is doing something based on A-bit being set to 1).

We do not define host behavior, and router behavior is the same regardless; either you send RAs with A/M bits, or you do not.

> - 9 page 21: (=DTLS) -> (i.e., DTLS) or something more written...
> 
> - 9 page 22: the Managed PSK TLV must generate -> MUST?
> 
> - 9 page 22 last paragraph: this should be submitted to the security
>  directorate to check if it is secured (IMHO it is) or if there is
>  a better solution.

I am not sure what this refers to. Looking at -09 on datatracker, last paragraph of page 22 is:

   An External Connection TLV is a container TLV used to gather network
   configuration information associated with a single external
   connection (
Section 6.2
) to be shared across the HNCP network.  A
   node MAY publish an arbitrary number of instances of this TLV to
   share the desired number of external connections.  Upon reception,

> - 10.1 page 22 and many other places: I deeply dislike the way open
>  fields are displayed in your ASCII art.

What would be your preference be? We did not get push-back for using same format in DNCP so ideally we would like to stay consistent.

> - 10.2.1.1 page 25: I have many concerns about "DNS Zone":
>  * first it should be a DNS domain (note the term zone has a specific
>    meaning for DNS)
>  * it should be not compressed
>  * it should be terminated by . (coded as an empty label).
>  For the last 2 points 10.6 page 29 has them so a reference is enough.

Hm, attempted to correct it bit in upcoming version and cut-n-pasted the two extra requirements from 10.6 here (as well as as to 10.5) as we usually get flak for too many references.

> - 10.5 pages 28 and 29: 3 should -> SHOULD?

Fixed.

> - 12.1 page 33: (for your info) there is a secure DHCPv6 I-D under
>  IESG review which should bring more security to DHCP (at least far
>  better than current "authentication" which is both poor as a security
>  point of view and deployed nowhere...

I doubt it will ever be deployed anywhere in volume as it requires provisioning on both ends of the connection; however, I will be happy to be proven wrong.
(If you have non-zeroconfiguration setup on both ends of the link, you do not need interface classification either. Zeroconfiguration + security is  .. hard.)

Cheers,

-Markus