Skip to main content

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 revision 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 J. Handley , Olivier Bonaventure , Christoph Paasch
I-D last updated 2019-04-26
Completed reviews Secdir Early review of -11 by Donald E. Eastlake 3rd (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
Request Last Call review on draft-ietf-mptcp-rfc6824bis by General Area Review Team (Gen-ART) Assigned
Reviewed revision 13 (document currently at 18)
Result Ready
Completed 2019-04-26
review-ietf-mptcp-rfc6824bis-13-genart-lc-robles-2019-04-26-00
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.