Skip to main content

Last Call Review of draft-ietf-dmm-hnprenum-06
review-ietf-dmm-hnprenum-06-opsdir-lc-chown-2017-03-02-01

Request Review of draft-ietf-dmm-hnprenum
Requested revision 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
I-D 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
Request Last Call review on draft-ietf-dmm-hnprenum by Ops Directorate Assigned
Reviewed revision 06 (document currently at 07)
Result Has nits
Completed 2017-03-02
review-ietf-dmm-hnprenum-06-opsdir-lc-chown-2017-03-02-01
Hi,

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.

Comments:

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.

Nits:

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,
Tim