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

Request Review of draft-ietf-dhc-dhcpv6-prefix-length-hint-issue
Requested rev. no specific revision (document currently at 06)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2017-02-09
Requested 2017-01-26
Authors Tianxiang Li, Cong Liu, Yong Cui
Draft last updated 2017-01-29
Completed reviews Genart Last Call review of -05 by Roni Even (diff)
Secdir Last Call review of -05 by Hilarie Orman (diff)
Opsdir Last Call review of -05 by Susan Hares (diff)
Assignment Reviewer Roni Even 
State Completed
Review review-ietf-dhc-dhcpv6-prefix-length-hint-issue-05-genart-lc-even-2017-01-29
Reviewed rev. 05 (document currently at 06)
Review result Almost Ready
Review completed: 2017-01-29


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