TCP Extensions for Multipath Operation with Multiple Addresses
draft-ietf-mptcp-rfc6824bis-18

[Ballot comment]
Thanks for the work everyone has put into this document and moving from v0 to v1 of MPTCP. The document is also very easy to read even with its length ;-) Congratulations!

I am also trusting my SEC AD peers about whether the fixed length of the 160-bnit HMAC/ 32-bit random number fields will still be valid in the future.


== COMMENTS ==

-- section 3.4.1 --

"for example, IPv6 addresses when it has IPv4 only" when talking about what about "an implementation MAY discard incoming address advertisements at will" but what about a device getting IPv6 connectivity after the initial connection? Or the other way round, finally getting an IPv4 address via DHCPv4 'long after' IPv6 SLAAC+ optimistic DAD are executed? I understand that this is a MAY but...


-- section 3.4.2 --

An IPv6 address can also become no more preferred as you know, so may I suggest to add this case in addition to 'interface disappears' ?

-- section 6 --

While indeed MPTCP can increase the number of false positives in IPS/IDS, I would be more concerned by false negatives (== not detecting a threat) or are we using different meanings for 'false positive' ? Perhaps worth writing in the clear 'not detecting a threat' ?

== NITS ==

--section 3.1--

the bits labelled 'A'to 'H' could have been numbered or labelled with 'meaningful' letters.

[Ballot comment]
I probably would be “Yes”, if I am to finish reading this document before the telechat.

A couple of small things:

“Appendix E.  Changes from RFC6184”

- Did you intent to write RFC6824 here?

Section 2.4 uses “DSS”, while section 2.6 uses “DATA_SEQUENCE_SIGNAL”. If I understood correctly they are the same thing. I suggest you use consistent terminology.

I agree with Alissa that the meaning of extensibility flag (and its interaction with versionning) should be clarified.

[Ballot comment]
It’s really nice to have this update; thanks for all the work on it.

— Section 8.3 —

  Initial values for this registry are give in Table 4

Make it “given”.

Also, as Specification Required includes appointment of a designated expert, it would help a lot to include some brief guidance to the expert (see RFC 8126).

[Ballot comment]
Thanks for everyone who has worked on moving MPTCP onto
the standards track. I'd like to offer particular thanks
to the authors for refraining from making structural changes
to the document: the diff between RFC 6824 and this document
is clean and easy to use.

I found only one very minor editorial nit that you may want to fix if you
need to otherwise revise the document.

§3.7:

>  So far this section has discussed the lost of MPTCP options, either

Nit: "...the loss of..."

[Ballot comment]
Thanks for everyone who has worked on moving MPTCP onto
the standards track. I'd like to offer particular thanks
to the authors for refraining from making structural changes
to the document: the diff between RFC 6824 and this document
is clean and easy to use.

I found only one very minor editorial nit.

§3.7:

>  So far this section has discussed the lost of MPTCP options, either

Nit: "...the loss of..."

[Ballot comment]
(1) Section 2.3.  Editorial.  s/successful reception/successful receipt/

(2) Section 5.  Thanks for mentioning the possibility of a downgrade attack in both the protocol version and algorithm negotiation.  Since [RFC7430] spells out a clear attacker taxonomy, I’d recommend using it here too (just like it was used in the new text added for the downgrade attack on the version negotiation). 

Old:
Note that this would be susceptible to bid-down attacks only if the attacker was on-path (and thus would be able to modify the data anyway).

Proposed New:
Note that this negotiation would be susceptible to a bid-down attack by an on-path active attacker who could modify the crypto capability bits response from the receiver to use a less secure crypto mechanism.

(3) Section 6.
> Intrusion Detection Systems look out for traffic patterns and
>    content that could threaten a network.  Multipath will mean that
>    such data is potentially spread, so it is more difficult for an
>      IDS to analyze the whole traffic, and potentially increases the
>      risk of false positives.

I’d recommend being a bit clearer on the impact to NIDS.  Perhaps something like the following:

Intrusion Detection/Prevention Systems (IDS/IPS) observe packet streams for patterns and content that could threaten a network.  Multipath may require the instrumentation of additional paths and correlation of data from these paths to maintain comparable visibility into all of the traffic between end-points.  Without such changes, an IDS would get an incomplete view of the traffic where by increasing the risk of missing traffic of interest and producing false positive alerts.  MPTCP-aware IDS/IPS would need to read tokens to correlate multiple subflows and reassemble them for analysis.

[Ballot discuss]
I have a question about the interaction between the protocol versioning and the way the flags B-H are defined. This doc specifies that B MUST be set to 0 and that future specs might require it to be set to 1, which could alter the meanings of the C-H flags. This is the same way that B is defined in RFC 6824. This spec goes on to define C and H differently from how they are defined in RFC 6824. Thus, both v0 and v1 implementations will have B set to 0, but they will have C and H defined differently. I guess it depends on how you interpret "extensibility flag," but my interpretation of this is that the version number negotiated using MP_CAPABLE is the actual extensibility mechanism that this specification is making use of, because although it changed C and H it did not change B. Is this right?

If so, I'm wondering what the threshold is for defining new versions of this protocol versus using this extensibility mechanism based on the B flag. Given the way the version negotiation mechanism is defined -- requiring extra round-trips in the event of a fallback attempt, and it being subject to a downgrade attack -- I'm wondering if some guidance needs to be provided about which sorts of protocol changes are expected to be made using the B-flag mechanism versus using the version negotiation mechanism. I guess the drawback of using the B-flag mechanism is that once a future spec sets it to 1, from then on logic within implementations will be required to interpret potentially multiple different semantics of C-H. I guess this potentially raises another question, which is why the B flag isn't just deprecated given the addition of the version negotiation mechanism.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?
Standards track. It obsoletes RFC6824. This is considered a replacement for RFC6824, as it improves it in several ways. It is not backwards compatible with RFC6824 due to a couple of protocol changes.
After creating the Experimental RFC6824, the primary goal of the MPTCP working group has been to create a bis version of the protocol document on the Standards track, incorporating experience from (for example) implementations, interoperability events, experiments, usage scenarios, protocol corner cases, and feedback from TCPM.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:
Multipath TCP provides the ability to simultaneously use multiple paths between peers.  This document presents a set of extensions to traditional TCP to support multipath operation.  The protocol offers the same type of service to applications as TCP (i.e., reliable bytestream), and it provides the components necessary to establish and use multiple TCP flows across potentially disjoint paths. This document specifies v1 of Multipath TCP, obsoleting v0 as specified in RFC6824, through clarifications and modifications primarily driven by deployment experience.

Working Group Summary:
After creating the Experimental RFC6824, the primary goal of the MPTCP working group has been to create a bis version of the protocol document on the Standards track, incorporating experience from (for example) implementations, interoperability events, experiments, usage scenarios, protocol corner cases, and feedback from TCPM. This process led to several changes, a couple of which make RFC6824bis incompatible with RFC6824. Hence this document obsoletes RFC6824.
There is WG agreement to move ahead with publishing the document.
Document Quality:
This document has been reviewed by various people. There is one implementation and other implementers of RFC6824 have indicated that they will implement against the new RFC.

Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?
The original MPTCP spec has been widely implemented and deployed and the Linux implementation is publicly available.
The main new aspects of the bis (the new MP_CAPABLE and ADD_ADDR) have been implemented in Linux. The new ADD_ADDR has been available for some time and the new MP_CAPABLE was recently made available https://sympa-2.sipr.ucl.ac.be/sympa/arc/mptcp-dev/2019-04/msg00003.html . However, other new aspects are yet to be implemented.
Vendors /implementers have indicated that they will implement against the new RFC.

Philip Eardley is the Document Shepherd and Mirja Kuehlewind is the Responsible Area Director.
As document shepherd I wrote a summary of all the main changes between the BIS document (v11) and RFC6824, the reason for those changes and when the significant changes were discussed and agreed. A slightly shortened version is included as Appendix E of the internet draft (the longer version is available from Philip Eardley).

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.
The document has been reviewed by the document shepherd who considers it ready.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?
The document has been relatively stable with only minor changes for a considerable period of time. A reasonable number of reviews have been done.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.
Since the protocol changes from RFC6824 affect the security, a security review was requested from the Security Directorate, who considered it Ready.
OPSAREA and GENART reviews considered it ready.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.
None.
At the time the WG ‘requested publication’ the only issue was the lack of public code for the bis. Christoph Paasch had implemented it in Linux and tried to get permission from his employer, Apple, to release the code but this was not forthcoming after many months of trying and the document being stable. Therefore it seemed time to move ahead with publishing the protocol rather than waiting further. The WG were OK with this (no dissent).
However, subsequently the code was released. This implements the new MP_CAPABLE, as well as the new ADD_ADDR that was already available, but does not implement other new aspects. (Personally I consider the other aspects are less significant changes.)
https://sympa-2.sipr.ucl.ac.be/sympa/arc/mptcp-dev/2019-04/msg00003.html


(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?
Yes
(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.
Yes, IPR has been disclosed.
The WG is happy to move ahead.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?
It has solid consensus

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)
None

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.
There is are warnings about downref to RFC 2104 and RFC 6234. They appear in the DOWNREF Registry. These two references were upgraded from informative to normative in draft-ietf-mptcp-rfc6824bis-15.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews.
Not sure about formal review criteria – I think none.
(13) Have all references within this document been identified as either normative or informative?
Yes
(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?
No

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.
Yes, there are downward references to RFC 2104 and RFC 6234. They appear in the DOWNREF Registry. These two references were upgraded from informative to normative in draft-ietf-mptcp-rfc6824bis-15 (after WG & IETF last calls).

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.
Yes, the document obsoletes RFC6824. This is mentioned in the title page, abstract and introduction.
The main motivation for the change was to alter the MP_CAPABLE exchange so that it is reliable, in particular to help a server operate statelessly when a host initiates a MPTCP connection with it. Also, the SYN no longer includes the initiator’s key, which allows more space for other options in the SYN. The MP_CAPABLE exchange for v1 is not compatible with v0.
An issue is what happens if a host running v1 of MPTCP initiates a connection with a listener that only runs v0. The listener sees that the SYN includes an MP_CAPABLE option without the initiator's key. It therefore replies with a SYN/ACK that does not include an MP_CAPABLE. The initiator MAY choose to immediately fall back to TCP or MAY choose to attempt a connection using MPTCP v0 (if the initiator supports v0). Its choice could be based on, for instance, its previous knowledge about the deployment scenario and the capability of this peer (for instance, given the limited deployment of MPTCP servers to date, it may prefer the first choice).

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226).
I have checked the IANA considerations section and it seems good to me. The registries are defined and the references to the sections that define them.
The IANA considerations section has been updated after discussion with IANA.
(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.
RFC6824 defined a new TCP option for MPTCP and assigned a value of 30 (decimal) from the TCP option space.
RFC6824 also defined two new sub-registries: MPTCP Option Subtypes and MPTCP Handshake Algorithms.
RFC6824bis changes the definition of these two sub-registries (and so effectively obsoletes the allocation in RFC6824). Further changes (still) require Standards Action.
RFC6824bis also creates a new sub-registry: MP_TCPRST Reason Codes. Future assignments are to be defined by Specification Required.


(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc.
Not applicable.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?
Standards track. It obsoletes RFC6824. This is considered a replacement for RFC6824, as it improves it in several ways. It is not backwards compatible with RFC6824 due to a couple of protocol changes.
After creating the Experimental RFC6824, the primary goal of the MPTCP working group has been to create a bis version of the protocol document on the Standards track, incorporating experience from (for example) implementations, interoperability events, experiments, usage scenarios, protocol corner cases, and feedback from TCPM.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:
Multipath TCP provides the ability to simultaneously use multiple paths between peers.  This document presents a set of extensions to traditional TCP to support multipath operation.  The protocol offers the same type of service to applications as TCP (i.e., reliable bytestream), and it provides the components necessary to establish and use multiple TCP flows across potentially disjoint paths. This document specifies v1 of Multipath TCP, obsoleting v0 as specified in RFC6824, through clarifications and modifications primarily driven by deployment experience.

Working Group Summary:
After creating the Experimental RFC6824, the primary goal of the MPTCP working group has been to create a bis version of the protocol document on the Standards track, incorporating experience from (for example) implementations, interoperability events, experiments, usage scenarios, protocol corner cases, and feedback from TCPM. This process led to several changes, a couple of which make RFC6824bis incompatible with RFC6824. Hence this document obsoletes RFC6824.
There is WG agreement to move ahead with publishing the document.
Document Quality:
This document has been reviewed by various people. There is one implementation and other implementers of RFC6824 have indicated that they will implement against the new RFC.

Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?
The original MPTCP spec has been widely implemented and deployed and the Linux implementation is publicly available. The bis document has been implemented in Linux and recently this was made available https://sympa-2.sipr.ucl.ac.be/sympa/arc/mptcp-dev/2019-04/msg00003.html
Vendors /implementers have indicated that they will implement against the new RFC.


Philip Eardley is the Document Shepherd and Mirja Kuehlewind is the Responsible Area Director.
As document shepherd I wrote a summary of all the main changes between the BIS document (v11) and RFC6824, the reason for those changes and when the significant changes were discussed and agreed. A slightly shortened version is included as Appendix E of the internet draft (the longer version is available from Philip Eardley).

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.
The document has been reviewed by the document shepherd who considers it ready.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?
The document has been relatively stable with only minor changes for a considerable period of time. A reasonable number of reviews have been done.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.
Since the protocol changes from RFC6824 affect the security, a security review was requested from the Security Directorate, who considered it Ready.
OPSAREA and GENART reviews considered it ready.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.
None.
The code implementing the bis version of the protocol has now been made public https://sympa-2.sipr.ucl.ac.be/sympa/arc/mptcp-dev/2019-04/msg00003.html
At the time the WG ‘requested publication’ the only issue was the lack of public code for the bis. Christoph Paasch had implemented it in Linux and tried to get permission from his employer, Apple, to release the code but this was not forthcoming after many months of trying and the document being stable. Therefore it seemed time to move ahead with publishing the protocol rather than waiting further. The WG were OK with this (no dissent).
However, subsequently the code was released.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?
Yes
(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.
Yes, IPR has been disclosed.
The WG is happy to move ahead.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?
It has solid consensus

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)
None

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.
Yes. The nits (warnings and comments) seem mainly to be mis-identifications by the nits tool.
There is one warning about a possible downref to [SHS]. This has prompted the authors to plan the following changes:  [1] Remove [SHS] as a reference and replace with reference to RFC6234 ; [2] Upgrade RFC2104, RFC5961 and RFC6234 to normative references from informative.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews.
Not sure about formal review criteria – I think none.
(13) Have all references within this document been identified as either normative or informative?
Yes
(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?
No

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.
None – see question (11).

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.
Yes, the document obsoletes RFC6824. This is mentioned in the title page, abstract and introduction.
The main motivation for the change was to alter the MP_CAPABLE exchange so that it is reliable, in particular to help a server operate statelessly when a host initiates a MPTCP connection with it. Also, the SYN no longer includes the initiator’s key, which allows more space for other options in the SYN. The MP_CAPABLE exchange for v1 is not compatible with v0.
An issue is what happens if a host running v1 of MPTCP initiates a connection with a listener that only runs v0. The listener sees that the SYN includes an MP_CAPABLE option without the initiator's key. It therefore replies with a SYN/ACK that does not include an MP_CAPABLE. The initiator MAY choose to immediately fall back to TCP or MAY choose to attempt a connection using MPTCP v0 (if the initiator supports v0) – based on for instance its previous knowledge about the deployment scenario and the capability of this peer (for instance, given the limited deployment of MPTCP servers to date, it may prefer the first choice).

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226).
I have checked the IANA considerations section and it seems good to me. The registries are defined and the references to the sections that define them.
The IANA considerations section has been updated after discussion with IANA.
(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.
RFC6824 defined a new TCP option for MPTCP and assigned a value of 30 (decimal) from the TCP option space.
RFC6824 also defined two new sub-registries: MPTCP Option Subtypes and MPTCP Handshake Algorithms.
RFC6824bis changes the definition of these two sub-registries (and so effectively obsoletes RFC6824). Further changes (still) require Standards Action.
RFC6824bis also creates a new sub-registry: MP_TCPRST Reason Codes. Future assignments are to be defined by Specification Required.


(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc.
Not applicable.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?
Standards track. It obsoletes RFC6824. This is considered a replacement for RFC6824, as it improves it in several ways. It is not backwards compatible with RFC6824 due to a couple of protocol changes.
After creating the Experimental RFC6824, the primary goal of the MPTCP working group has been to create a bis version of the protocol document on the Standards track, incorporating experience from (for example) implementations, interoperability events, experiments, usage scenarios, protocol corner cases, and feedback from TCPM.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:
Multipath TCP provides the ability to simultaneously use multiple paths between peers.  This document presents a set of extensions to traditional TCP to support multipath operation.  The protocol offers the same type of service to applications as TCP (i.e., reliable bytestream), and it provides the components necessary to establish and use multiple TCP flows across potentially disjoint paths. This document specifies v1 of Multipath TCP, obsoleting v0 as specified in RFC6824, through clarifications and modifications primarily driven by deployment experience.

Working Group Summary:
After creating the Experimental RFC6824, the primary goal of the MPTCP working group has been to create a bis version of the protocol document on the Standards track, incorporating experience from (for example) implementations, interoperability events, experiments, usage scenarios, protocol corner cases, and feedback from TCPM. This process led to several changes, a couple of which make RFC6824bis incompatible with RFC6824. Hence this document obsoletes RFC6824.
There is WG agreement to move ahead with publishing the document.
Document Quality:
This document has been reviewed by various people. There is one (non-public) implementation and other implementers of RFC6824 have indicated that they will implement against the new RFC.

Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?
The original MPTCP spec has been widely implemented and deployed and the Linux implementation is publicly available. The bis document has been implemented in Linux, but permission to release this code has not been forthcoming. The WG is OK with publishing the RFC at this stage rather than waiting further, and vendors /implementers have indicated that they will implement against the new RFC.


Philip Eardley is the Document Shepherd and Mirja Kuehlewind is the Responsible Area Director.
As document shepherd I wrote a summary of all the main changes between the BIS document (v11) and RFC6824, the reason for those changes and when the significant changes were discussed and agreed. A slightly shortened version is included as Appendix E of the internet draft (the longer version is available from Philip Eardley).

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.
The document has been reviewed by the document shepherd who considers it ready.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?
The document has been relatively stable with only minor changes for a considerable period of time. A reasonable number of reviews have been done.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.
Since the protocol changes from RFC6824 affect the security, a security review was requested from the Security Directorate, who considered it Ready.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.
None – except for the lack of public code for the bis. Christoph Paasch has implemented it in Linux and he has tried to get permission from his employer, Apple, to release the code but this has not been forthcoming after many months of trying and the document being stable. Therefore it seems time to move ahead with publishing the protocol rather than waiting further. The WG are OK with this (no dissent).

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?
Yes
(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.
Yes, IPR has been disclosed.
The WG is happy to move ahead.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?
It has solid consensus

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)
None

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.
Yes. Most of the nits are mis-identifications by the nits tool. There is one real nit ("Downref: Normative reference to an Informational RFC: RFC 6182") which can be fixed in the next version, by moving RFC6182 to the Informative references.
(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews.
Not sure about formal review criteria – I think none.
(13) Have all references within this document been identified as either normative or informative?
Yes (see note under (11))
(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?
No (see note under (11))

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.
There is one (to RFC6182, “Architectural Guidelines for Multipath TCP Development”). I think it’s acceptable to move this to the Informative references.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.
Yes, the document obsoletes RFC6824. This is mentioned in the title page, abstract and introduction.
(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226).
I have checked the IANA considerations section and it seems good to me. The registries are defined and the references to the sections that define them.
(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.
I think review can be handled by IANA. The changes compared with the RFC6824 have been suggested by the implementers, and are the creation of a code to indicate experiments and a registry for Reset reasons.
(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc.
Not applicable.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-mptcp-rfc6824bis-13. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator has questions about three of the four actions requested in the IANA Considerations section of this document.

The IANA Functions Operator understands that upon approval of this document, there are four actions which we must complete.

First, in the TCP Option Kind Numbers registry on the Transmission Control Protocol (TCP) Parameters registry page located at

https://www.iana.org/assignments/tcp-parameters

the existing registration for

Kind: 30
Length: N
Meaning: Multipath TCP (MPTCP)

will have its reference changed from RFC6824 to [ RFC-to-be ].

Second, in the MPTCP Option Subtypes registry also on the Transmission Control Protocol (TCP) Parameters registry page located at:

https://www.iana.org/assignments/tcp-parameters/

the references for each registration and the registry itself are to be changed to [ RFC-to-be ].

The new version of the registry is to be as follows:

+-------+-----------------+-------------------------+---------------+
| Value | Symbol | Name | Reference |
+-------+-----------------+-------------------------+---------------+
| 0x0 | MP_CAPABLE | Multipath Capable |[ RFC-to-be ] |
| | | | Section 3.1 |
| 0x1 | MP_JOIN | Join Connection |[ RFC-to-be ] |
| | | | Section 3.2 |
| 0x2 | DSS | Data Sequence Signal |[ RFC-to-be ] |
| | | (Data ACK and data | Section 3.3 |
| | | sequence mapping) | |
| 0x3 | ADD_ADDR (deprecated) | Add Address |[ RFC-to-be ] |
| | | | Section 3.4.1 |
| 0x4 | REMOVE_ADDR | Remove Address |[ RFC-to-be ] |
| | | | Section 3.4.2 |
| 0x5 | MP_PRIO | Change Subflow Priority |[ RFC-to-be ] |
| | | | Section 3.3.8 |
| 0x6 | MP_FAIL | Fallback |[ RFC-to-be ] |
| | | | Section 3.7 |
| 0x7 | MP_FASTCLOSE | Fast Close |[ RFC-to-be ] |
| | | | Section 3.5 |
| 0x8 | MP_TCPRST | Subflow Reset |[ RFC-to-be ] |
| | | | Section 3.6 |
| 0xf | MP_EXPERIMENTAL | Reserved for private | |
| | | experiments | |
+-------+-----------------+-------------------------+---------------+

Values 0x9 through 0xe are unassigned.

IANA Questions --> Section 8.1 of the current draft states, "This document defines one additional subtype (ADD_ADDR) and updates the references to this document for all sub- types except ADD_ADDR, which is deprecated." Is the additional subtype meant to be MP_TCPRST, which has not yet been added to the registry, instead of ADD_ADDR? Also, can you confirm that ADD_ADDR is the registration that should be marked as deprecated? In Table 2, no registrations are marked as deprecated.

Third, in the MPTCP Handshake Algorithms registry also on the Transmission Control Protocol (TCP) Parameters registry page located at

https://www.iana.org/assignments/tcp-parameters/

the references for the three existing registrations and for the registry itself are to be changed to [ RFC-to-be ].

IANA Question --> Is the Flag Bit (C) a new registration in this registry? If so, the resulting registry will look like this:

+-------+----------------------------------------+------------------+
| Flag | Meaning | Reference |
| Bit | | |
+-------+----------------------------------------+------------------+
| A | Checksum required | [ RFC-to-be ] |
| | | Section 3.1 |
| B | Extensibility | [ RFC-to-be ] |
| | | Section 3.1 |
| C | Do not attempt to establish new | [ RFC-to-be ] |
| | subflows to the source address. | Section 3.1 |
| D-G | Unassigned | |
| H | HMAC-SHA256 | [ RFC-to-be ] |
| | | Section 3.2 |
+-------+----------------------------------------+------------------+

Fourth, a new registry called MP_TCPRST Reason Codes will be created. The new registry will be located on the Transmission Control Protocol (TCP) Parameters registry page located at

https://www.iana.org/assignments/tcp-parameters/

IANA Question --> What is the registration policy (please see RFC8126) for the new registry?

IANA Question --> Is 0xFF the maximum available value in this registry?

These will be the initial registrations:

+------+-----------------------------+----------------------------+
| Code | Meaning | Reference |
+------+-----------------------------+----------------------------+
| 0x00 | Unspecified TCP error | [ RFC-to-be ] Section 3.6 |
| 0x01 | MPTCP specific error | [ RFC-to-be ] Section 3.6 |
| 0x02 | Lack of resources | [ RFC-to-be ] Section 3.6 |
| 0x03 | Administratively prohibited | [ RFC-to-be ] Section 3.6 |
| 0x04 | Too much outstanding data | [ RFC-to-be ] Section 3.6 |
| 0x05 | Unacceptable performance | [ RFC-to-be ] Section 3.6 |
| 0x06 | Middlebox interference | [ RFC-to-be ] Section 3.6 |
+------+-----------------------------+----------------------------+

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Amanda Baber
Lead IANA Services Specialist

The following Last Call announcement was sent out (ends 2019-04-26):

From: The IESG
To: IETF-Announce
CC: mptcp-chairs@ietf.org, multipathtcp@ietf.org, philip.eardley@bt.com, Philip Eardley , ietf@kuehlewind.net, draft-ietf-mptcp-rfc6824bis@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (TCP Extensions for Multipath Operation with Multiple Addresses) to Proposed Standard


The IESG has received a request from the Multipath TCP WG (mptcp) to consider
the following document: - 'TCP Extensions for Multipath Operation with
Multiple Addresses'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2019-04-26. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  TCP/IP communication is currently restricted to a single path per
  connection, yet multiple paths often exist between peers.  The
  simultaneous use of these multiple paths for a TCP/IP session would
  improve resource usage within the network and, thus, improve user
  experience through higher throughput and improved resilience to
  network failure.

  Multipath TCP provides the ability to simultaneously use multiple
  paths between peers.  This document presents a set of extensions to
  traditional TCP to support multipath operation.  The protocol offers
  the same type of service to applications as TCP (i.e., reliable
  bytestream), and it provides the components necessary to establish
  and use multiple TCP flows across potentially disjoint paths.

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




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-mptcp-rfc6824bis/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-mptcp-rfc6824bis/ballot/

The following IPR Declarations may be related to this I-D:

  https://datatracker.ietf.org/ipr/1842/
  https://datatracker.ietf.org/ipr/1843/
  https://datatracker.ietf.org/ipr/3242/



The document contains these normative downward references.
See RFC 3967 for additional information:
    rfc6182: Architectural Guidelines for Multipath TCP Development (Informational - IETF stream)

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?
Standards track. It obsoletes RFC6824. This is considered a replacement for RFC6824, as it improves it in several ways. It is not backwards compatible with RFC6824 due to a couple of protocol changes.
After creating the Experimental RFC6824, the primary goal of the MPTCP working group has been to create a bis version of the protocol document on the Standards track, incorporating experience from (for example) implementations, interoperability events, experiments, usage scenarios, protocol corner cases, and feedback from TCPM.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:
Multipath TCP provides the ability to simultaneously use multiple paths between peers.  This document presents a set of extensions to traditional TCP to support multipath operation.  The protocol offers the same type of service to applications as TCP (i.e., reliable bytestream), and it provides the components necessary to establish and use multiple TCP flows across potentially disjoint paths. This document specifies v1 of Multipath TCP, obsoleting v0 as specified in RFC6824, through clarifications and modifications primarily driven by deployment experience.

Working Group Summary:
After creating the Experimental RFC6824, the primary goal of the MPTCP working group has been to create a bis version of the protocol document on the Standards track, incorporating experience from (for example) implementations, interoperability events, experiments, usage scenarios, protocol corner cases, and feedback from TCPM. This process led to several changes, a couple of which make RFC6824bis incompatible with RFC6824. Hence this document obsoletes RFC6824.
There is WG agreement to move ahead with publishing the document.
Document Quality:
This document has been reviewed by various people. There is one (non-public) implementation and other implementers of RFC6824 have indicated that they will implement against the new RFC.

Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?
The original MPTCP spec has been widely implemented and deployed and the Linux implementation is publicly available. The bis document has been implemented in Linux, but permission to release this code has not been forthcoming. The WG is OK with publishing the RFC at this stage rather than waiting further, and vendors /implementers have indicated that they will implement against the new RFC.


Philip Eardley is the Document Shepherd and Mirja Kuehlewind is the Responsible Area Director.
As document shepherd I wrote a summary of all the main changes between the BIS document (v11) and RFC6824, the reason for those changes and when the significant changes were discussed and agreed. A slightly shortened version is included as Appendix E of the internet draft (the longer version is available from Philip Eardley).

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.
The document has been reviewed by the document shepherd who considers it ready.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?
The document has been relatively stable with only minor changes for a considerable period of time. A reasonable number of reviews have been done.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.
Since the protocol changes from RFC6824 affect the security, a security review was requested from the Security Directorate, who considered it Ready.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.
None – except for the lack of public code for the bis. Christoph Paasch has implemented it in Linux and he has tried to get permission from his employer, Apple, to release the code but this has not been forthcoming after many months of trying and the document being stable. Therefore it seems time to move ahead with publishing the protocol rather than waiting further. The WG are OK with this (no dissent).

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?
Yes
(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.
Yes, IPR has been disclosed.
The WG is happy to move ahead.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?
It has solid consensus

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)
None

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.
Yes. Most of the nits are mis-identifications by the nits tool. There is one real nit ("Downref: Normative reference to an Informational RFC: RFC 6182") which can be fixed in the next version, by moving RFC6182 to the Informative references.
(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews.
Not sure about formal review criteria – I think none.
(13) Have all references within this document been identified as either normative or informative?
Yes (see note under (11))
(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?
No (see note under (11))

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.
There is one (to RFC6182, “Architectural Guidelines for Multipath TCP Development”). I think it’s acceptable to move this to the Informative references.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.
Yes, the document obsoletes RFC6824. This is mentioned in the title page, abstract and introduction.
(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226).
I have checked the IANA considerations section and it seems good to me. The registries are defined and the references to the sections that define them.
(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.
I think review can be handled by IANA. The changes compared with the RFC6824 have been suggested by the implementers, and are the creation of a code to indicate experiments and a registry for Reset reasons.
(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc.
Not applicable.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?
Standards track. It obsoletes RFC6824. This is considered a replacement for RFC6824, as it improves it in several ways. It is not backwards compatible with RFC6824 due to a couple of protocol changes.
After creating the Experimental RFC6824, the primary goal of the MPTCP working group has been to create a bis version of the protocol document on the Standards track, incorporating experience from (for example) implementations, interoperability events, experiments, usage scenarios, protocol corner cases, and feedback from TCPM.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:
Multipath TCP provides the ability to simultaneously use multiple paths between peers.  This document presents a set of extensions to traditional TCP to support multipath operation.  The protocol offers the same type of service to applications as TCP (i.e., reliable bytestream), and it provides the components necessary to establish and use multiple TCP flows across potentially disjoint paths. This document specifies v1 of Multipath TCP, obsoleting v0 as specified in RFC6824, through clarifications and modifications primarily driven by deployment experience.

Working Group Summary:
After creating the Experimental RFC6824, the primary goal of the MPTCP working group has been to create a bis version of the protocol document on the Standards track, incorporating experience from (for example) implementations, interoperability events, experiments, usage scenarios, protocol corner cases, and feedback from TCPM. This process led to several changes, a couple of which make RFC6824bis incompatible with RFC6824. Hence this document obsoletes RFC6824.
There is WG agreement to move ahead with publishing the document.
Document Quality:
This document has been reviewed by various people. There is one (non-public) implementation and other implementers of RFC6824 have indicated that they will implement against the new RFC.

Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?
The original MPTCP spec has been widely implemented and deployed and the Linux implementation is publicly available. The bis document has been implemented in Linux, but permission to release this code has not been forthcoming. The WG is OK with publishing the RFC at this stage rather than waiting further, and vendors /implementers have indicated that they will implement against the new RFC.


Philip Eardley is the Document Shepherd and Mirja Kuehlewind is the Responsible Area Director.
As document shepherd I wrote a summary of all the main changes between the BIS document (v11) and RFC6824, the reason for those changes and when the significant changes were discussed and agreed. A slightly shortened version is included as Appendix E of the internet draft (the longer version is available from Philip Eardley).

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.
The document has been reviewed by the document shepherd who considers it ready.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?
The document has been relatively stable with only minor changes for a considerable period of time. A reasonable number of reviews have been done.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.
Since the protocol changes from RFC6824 affect the security, a security review was requested from the Security Directorate, who considered it Ready.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.
None – except for the lack of public code for the bis. Christoph Paasch has implemented it in Linux and he has tried to get permission from his employer, Apple, to release the code but this has not been forthcoming after many months of trying and the document being stable. Therefore it seems time to move ahead with publishing the protocol rather than waiting further. The WG are OK with this (no dissent).

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?
Yes
(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.
Yes, IPR has been disclosed.
The WG is happy to move ahead.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?
It has solid consensus

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)
None

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.
Yes. Most of the nits are mis-identifications by the nits tool. There is one real nit ("Downref: Normative reference to an Informational RFC: RFC 6182") which can be fixed in the next version, by moving RFC6182 to the Informative references.
(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews.
Not sure about formal review criteria – I think none.
(13) Have all references within this document been identified as either normative or informative?
Yes (see note under (11))
(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?
No (see note under (11))

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.
There is one (to RFC6182, “Architectural Guidelines for Multipath TCP Development”). I think it’s acceptable to move this to the Informative references.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.
Yes, the document obsoletes RFC6824. This is mentioned in the title page, abstract and introduction.
(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226).
I have checked the IANA considerations section and it seems good to me. The registries are defined and the references to the sections that define them.
(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.
I think review can be handled by IANA. The changes compared with the RFC6824 have been suggested by the implementers, and are the creation of a code to indicate experiments and a registry for Reset reasons.
(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc.
Not applicable.

This starts a WG Last Call for draft-ietf-mptcp-rfc6824bis. Please send comments by the end of June.
Please note there are three IPR disclosures (we're working on getting them added to the rfc6824bis page):
* two are inherited from RFC6824 https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-mptcp-multiaddressed
* one is inherited from draft-paasch-mptcp-syncookies (which got include in rfc6824bis) https://datatracker.ietf.org/ipr/2678/