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 <noreply@xxxxxxxx> 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 > Gen-art@xxxxxxxx > https://www.ietf.org/mailman/listinfo/gen-art
