Shepherd writeup
rfc8684-18

(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. 
Back