Last Call Review of draft-ietf-mptcp-rfc6824bis-13
review-ietf-mptcp-rfc6824bis-13-genart-lc-robles-2019-04-26-00

Request Review of draft-ietf-mptcp-rfc6824bis
Requested rev. no specific revision (document currently at 18)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2019-04-26
Requested 2019-04-12
Authors Alan Ford, Costin Raiciu, Mark Handley, Olivier Bonaventure, Christoph Paasch
Draft last updated 2019-04-26
Completed reviews Secdir Early review of -11 by Donald Eastlake (diff)
Genart Last Call review of -13 by Ines Robles (diff)
Opsdir Last Call review of -13 by Sheng Jiang (diff)
Opsdir Telechat review of -15 by Sheng Jiang (diff)
Assignment Reviewer Ines Robles
State Completed
Review review-ietf-mptcp-rfc6824bis-13-genart-lc-robles-2019-04-26
Reviewed rev. 13 (document currently at 18)
Review result Ready
Review completed: 2019-04-26

Review
review-ietf-mptcp-rfc6824bis-13-genart-lc-robles-2019-04-26

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

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-mptcp-rfc6824bis-13
Reviewer: Ines Robles
Review Date: 2019-04-26
IETF LC End Date: 2019-04-26
IESG Telechat date: Not scheduled for a telechat

Summary:

I believe the draft is technically good. This document is well written and clear to understand. I found the document quite complete.

The document specifies v1 of Multipath TCP, obsoleting v0 as specified in RFC6824, through clarifications and modifications primarily driven by deployment experience.

I have some minor questions for the authors.

Major issues: Not found

Minor issues: Not found

Nits/editorial comments: 

    Section 1.1 " the working group imposed..." --> " mptcp working group imposed..."

Some Comments/Questions:

  - Section 1.4: "...A1<->B2 and A2<->B2.  Although this additional session is shown as being initiated from A2, it could equally have been initiated from B1." --> would it be "initiated from B2"? or you mean B1 following the example showed in Figure 2?

  - For Figure 5 (Pag.24), Figure 6(Pag.26) and Figure 11(Pag.40): would it be correct to add "(rsv)" in the empty field (between "Subtype" and "B" fields) as showed in Figure 12 (Pag. 44).?

  - Section 8.1:
  "This document defines one additional subtype (ADD_ADDR) and updates the references to this document for all subtypes except ADD_ADDR, which is deprecated.":

  - It seems that the additional subtype is MP_TCPRST and not ADD_ADDR, comparing table 2 between this draft and RFC6824.

  - Would it be correct state instead of "ADD_ADDR deprecated" to "ADD_ADDR modified"? In Appendix E states; "The ADD_ADDR option (Section 3.4.1), which is used to inform the other host about another potential address, is different in several ways.  It now includes an HMAC of the added address, for enhanced security.  In addition, reliability for the ADD_ADDR option has been added: the IPVer field is replaced with a flag field, and one flag is assigned (E) which is used as an 'Echo' so a host can indicate that it has received the option."


  Thanks for this document,

  Ines.