Re: [multipathtcp] [Gen-art] Genart last call review of draft-ietf-mptcp-rfc6824bis-13

[Alissa Cooper <[e-mail]>]

Ines, thanks for your review. I see that your suggestions have been incorporated into the -15, so thanks to the authors for that. I have entered a DISCUSS ballot to chat about the interaction between the B-flag and version negotiation.

Alissa


> On Apr 26, 2019, at 5:51 AM, Ines Robles via Datatracker <[e-mail]> wrote:
> 
> Reviewer: Ines Robles
> Review result: Ready
> 
> 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.
> 
> _______________________________________________
> Gen-art mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/gen-art