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

[Francis Dupont]

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

.

Document: draft-ietf-homenet-hncp-09.txt
Reviewer: Francis Dupont
Review Date: 20151026
IETF LC End Date: 20151023
IESG Telechat date: 20151119

Summary: Ready

Major issues: None

Minor issues: None

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)

 - 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.

 - 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.

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

 - 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.

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

 - 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...

Regards

francis.dup...@fdupont.fr

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Gen-art LC review: draft-ietf-isis-route-preference-02

[Robert Sparks]

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

.

Document: draft-ietf-isis-route-preference
Reviewer: Robert Sparks
Review Date: 27Oct2015
IETF LC End Date: 30Oct2015
IESG Telechat date: Not yet scheduled

Summary: Ready for publication as Proposed Standard

This document reads easily despite most of it being detailed lists. I 
have no objection to it moving forward, but I would like to check one thing:


The sparsity of detail at the end of section 2, where you call out 
potential interoperability issues and suggest that "implementers may 
wish to support transition mechanisms" is concerning.  It might be worth 
being explicit here about the interoperability issues, and what a 
transition mechanism might look like, particularly if there's a chance 
of having to deal with a peer that won't implement what's described in 
this draft?


Did the group consider defining a couple of new code points and 
deprecating these two, to avoid that transition issue?


___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art