Last Call Review of draft-ietf-v6ops-unique-ipv6-prefix-per-host-02
review-ietf-v6ops-unique-ipv6-prefix-per-host-02-opsdir-lc-banks-2017-06-20-00

Request Review of draft-ietf-v6ops-unique-ipv6-prefix-per-host
Requested rev. no specific revision (document currently at 13)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2017-06-06
Requested 2017-05-23
Other Reviews Genart Last Call review of -02 by Joel Halpern (diff)
Intdir Last Call review of -02 by Jouni Korhonen (diff)
Opsdir Last Call review of -03 by Tim Chown (diff)
Genart Last Call review of -03 by Joel Halpern (diff)
Secdir Last Call review of -03 by Watson Ladd (diff)
Genart Telechat review of -07 by Joel Halpern (diff)
Review State Completed
Reviewer Sarah Banks
Review review-ietf-v6ops-unique-ipv6-prefix-per-host-02-opsdir-lc-banks-2017-06-20
Posted at https://www.ietf.org/mail-archive/web/ops-dir/current/msg02693.html
Reviewed rev. 02 (document currently at 13)
Review result Has Nits
Draft last updated 2017-06-20
Review completed: 2017-06-20

Review
review-ietf-v6ops-unique-ipv6-prefix-per-host-02-opsdir-lc-banks-2017-06-20

Hello,
	I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review.  Document editors and WG chairs should treat these comments just like any other last call comments.
 
Summary: Ready to go, with comments

No major issues, however, the document reads to me as if we're suggesting that operators assign unique prefixes//64s to hosts; I'm not sure that's the intention here, and a bit more text around the abstract/introduction sections would help clarify that. 

Also, nits isn't clean. yes, I know you probably intend to clean that up (no pun intended) but I do like to see drafts come into last call with clean nits, so there you go. :) The references to RFC2119 aren't a big deal to resolve.

Thanks
Sarah