Last Call Review of draft-ietf-dmm-hnprenum-06

Request Review of draft-ietf-dmm-hnprenum
Requested rev. no specific revision (document currently at 07)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2017-02-10
Requested 2017-01-27
Authors Zhiwei Yan, Jong-Hyouk Lee, XiaoDong Lee
Draft last updated 2017-03-02
Completed reviews Intdir Early review of -03 by Jean-Michel Combes (diff)
Opsdir Last Call review of -06 by Tim Chown (diff)
Genart Last Call review of -05 by Meral Shirazipour (diff)
Genart Telechat review of -06 by Meral Shirazipour (diff)
Assignment Reviewer Tim Chown 
State Completed
Review review-ietf-dmm-hnprenum-06-opsdir-lc-chown-2017-03-02
Reviewed rev. 06 (document currently at 07)
Review result Has Nits
Review completed: 2017-03-02



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. 

The draft describes a mechanism by which renumbering of the Home Network Prefix for a set of Mobile Nodes can be supported.  In this process it is assumed that serving Local Mobility Anchor(s) are not renumbered. 

Overall, the document is well-written. 


In Section 5, part (3), the document says both Preferred and Valid Lifetime should be set to 0.   Certainly the Preferred Lifetime can be set to 0 (to deprecate the prefix for address selection) but can the Valid Lifetime be set below 2 hours?  Are the RAs authenticated in this scenario? (see 5.5.3 of RFC 4862, part (e).2).

It is good to see documents from the (now closed) 6renum WG being cited (RFC6879 and RFC7010).

The document includes RFC2119 requirements language, but then doesn’t seem to use it.  Either the Requirements Language section should be removed, or the body should use RFC2119 style terminology. 


There are a handful of editorial nits, e.g. “not the type of PI” in Section 1.

Otherwise, the document is Ready for publication.

Best wishes,