[multipathtcp] Genart last call review of draft-ietf-mptcp-rfc6824bis-13
Ines Robles via Datatracker <firstname.lastname@example.org> Fri, 26 April 2019 09:51 UTC
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id ECDE012019F; Fri, 26 Apr 2019 02:51:55 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
From: Ines Robles via Datatracker <email@example.com>
Cc: firstname.lastname@example.org, email@example.com, firstname.lastname@example.org
Reply-To: Ines Robles <email@example.com>
Date: Fri, 26 Apr 2019 02:51:55 -0700
Subject: [multipathtcp] Genart last call review of draft-ietf-mptcp-rfc6824bis-13
List-Id: Multi-path extensions for TCP <multipathtcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/multipathtcp>, <mailto:firstname.lastname@example.org?subject=unsubscribe>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/multipathtcp>, <mailto:email@example.com?subject=subscribe>
X-List-Received-Date: Fri, 26 Apr 2019 09:51:56 -0000
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.
- [multipathtcp] Genart last call review of draft... Ines Robles via Datatracker
- Re: [multipathtcp] [Gen-art] Genart last call r... Alissa Cooper