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 <[email protected]> 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 _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
