Review of draft-ietf-dhc-dhcpv6-prefix-length-hint-issue-05

[Roni Even <[e-mail]>]

Reviewer: Roni Even
Review result: Almost Ready

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: