Last Call Review of draft-ietf-dhc-dhcpv6-prefix-length-hint-issue-05
review-ietf-dhc-dhcpv6-prefix-length-hint-issue-05-genart-lc-even-2017-01-29-00

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

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-dhc-dhcpv6-prefix-length-hint-issue-05
Reviewer: Roni Even
Review Date: 2017-01-29
IETF LC End Date: 2017-02-09
IESG Telechat date: 2017-02-16

Summary: This draft is almost ready for publication as a standard track RFC.

Major issues:

Minor issues:

1.      I think that this document updates RFC3633 and it should be mentioned
in the title and abstract 2.      In section 3.1 reference RFC3315 for solicit
message and 3.3 for advertise messge 3.      In section 3.1 solution last
paragraph is the order of the two IAPREFIX options important? 4.      In
section 3.2 solution why are you suing SHOULD and not MUST in all
recommendations? 5.      In section 3.2 solution, what should the server do if
cannot provide any of the requests 6.      In section 3.2 solution last
paragraph “SHOULD try to provide” and in the first paragraph “SHOULD provide”
should be the same in both. 7.      In section 3.4 “If the client decided to
use  the prefix provided by the server despite being longer than the 
prefix-length hint” yet I did not see in section 3.2 that the server can
provide a longer prefix. 8.      In section 3.5 solution the document use “as
close as possible” and section 3.2 only talk about smaller. 9.     In section
3.5 solution why offer options 3 and 4. The draft says that option 3 will break
client connections and 4 talks about “a  short non-zero valid-lifetime” which
may cause the  client to lose connection if "too short for the client" since
“short” is not an exact value

Nits/editorial comments: