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: