Early Review of draft-ietf-dmm-mag-multihoming-02
review-ietf-dmm-mag-multihoming-02-intdir-early-jiang-2017-01-19-00

Request Review of draft-ietf-dmm-mag-multihoming
Requested rev. no specific revision (document currently at 04)
Type Early Review
Team Internet Area Directorate (intdir)
Deadline 2017-01-19
Requested 2017-01-04
Requested by Suresh Krishnan
Other Reviews Genart Last Call review of -03 by Robert Sparks (diff)
Secdir Last Call review of -03 by Hilarie Orman (diff)
Genart Telechat review of -04 by Robert Sparks
Review State Completed
Reviewer Sheng Jiang
Review review-ietf-dmm-mag-multihoming-02-intdir-early-jiang-2017-01-19
Posted at https://mailarchive.ietf.org/arch/msg/int-dir/FBgHssSf9ykJvzx3TOcynTwGySE
Reviewed rev. 02 (document currently at 04)
Review result Almost Ready
Last updated 2017-01-19

Review
review-ietf-dmm-mag-multihoming-02-intdir-early-jiang-2017-01-19

Reviewer: Sheng Jiang

Review result: Almost Ready



I am an assigned INT directorate reviewer for draft-ietf-dmm-mag-multihoming-02. These comments were written primarily for the benefit of the Internet Area Directors. Document editors and shepherd(s) should treat these comments just like they would treat comments from any other IETF contributors and resolve them along with any other Last Call comments that have been received. For more details on the INT Directorate, see http://www.ietf.org/iesg/directorate.html.



Review Date:2017-1-19

Review Type : Early Review

IESG Telechat date:



Summary: This draft is almost ready for publication as a standard track RFC.


Major issues:



Minor issues:



The figure 2 seems imply a consecutive order of these steps, while some steps could and should be parallel, such as establishing the two connectivities, and the IP address assignment and data flow could and should start if one connectivity has established, but another is still in process. I guess authors have the same understanding. If so, adding some clarification text could address this issue.



The abstract seems to contain references, such as[RFC3963], etc., which it shouldn't. These references should be replaced by straight textual mentions of the documents.





The IANA consideration seems not in normal format. However, the required actions for IANA are described clearly.



Nits:



In abstract, "multiple Care-of Addresses  (CoAs) capabilities of Mobile IP an Network Mobility (NEMO)..."



an // and



In section 1, "In the continuation of [RFC4908], a Proxy Mobile IPv6 [RFC5213] based

   multihomed achitecture."



achitecture // architecture



also in section 1, "using GRE as mobile tuneling"



Tuneling//tunneling



Regards,



Sheng