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