TCP Fast Open
draft-ietf-tcpm-fastopen-10

[Ballot comment]
It may be worth noting for completeness that a server could implement a scheme where cookie values are entirely random, with state stored on the server.  And also worth noting the (many) reasons that this is a bad idea.

In section 4.1.2, I would expand the second property to note that this implies that the cookie must be generated with a cryptographic operation using a secret key specific to the server, such as encryption, MAC, or signature.

[Ballot comment]
Please do consider Barry's questions - I'm not repeating them, but I had several of them myself.

For Martin: this specification points out that TFO can be used to speed up TLS (piggybacking on the SYN exchange). Is it obvious whether TCPINC could also use TFO?

[Ballot comment]

general: would this work with CGAs? I guess, only for a short
while, but that's probably ok for consenting peers, right?
Presumably not worth a mention.

possible new security consideration: if an application
supports TFO and might include sensitive data in the SYN
(think cookies) then this seems to provide a new and slightly
more efficient way to steal that sensitive data. I don't
think this is worth noting to be honest, but raise it just in
case you do. I think the bad actor here has to write less
code maybe compared to the situation without TFO.

6.3.4 - I wondered how TFO would affect page load times if
all links are accessed via TLS. Any info on that?

The author affiliations on page 1 don't quite match those at
the end.

The secdir review [1] noted some nits and was ack'd but I
think the nits are maybe still there (one anyway).

  [1] https://www.ietf.org/mail-archive/web/secdir/current/msg04708.html

[Ballot comment]
I agree with Barry that this a useful experimental document.  I have a few things for the authors/WG to consider as a part of this experimentation.

1. How does this functionality work in the presence of an anycast IP address for the server?

2. Are there functional changes needed to work with load balancers?

[Ballot comment]
I think this is a Truly Fine thing to experiment with, and I'm very eager to see more deployment of it.

I have a number of comments about the document.  None of these are blocking, but some of them are quite significant and I urge you to consider them and to chat with me about them if it will help.  Thanks.

To the document shepherd: thanks especially for the detailed answer to question 9 in the shepherd writeup.

-- Section 4.1.1 --
You talk about two options (Fast Open Cookie and Fast Open Cookie Request), but they're really the same option, so that's a little confusing.  To make it more confusing, the document at least once refers just to a "Fast Open option".

I suggest that you consistently refer to this as the "Fast Open Option" throughout the document, and say that a Fast Open request is made using a Fast Open Option with a length of 2, and a Fast Open cookie is sent using a Fast Open Option with a length greater than 2.  I think this will make things much more consistent, and clearer.

-- Section 4.1.2 --

  The server is in charge of cookie generation and authentication. The
  cookie SHOULD be a message authentication code tag with the following
  properties:

Why "SHOULD"?  What might be a reason for a server not to do this?

-- Section 4.1.3 --
Please expand "MSS" on first use.

The "RECOMMEND" in the second paragraph doesn't appear to be a protocol requirement, and should probaby be lower case, not a 2119 key word.

  In particular it's known an IPv4 receiver
  advertised MSS less than 536 bytes would result in transmission of an
  unexpected large segment.

I can't parse that.  Can you rephrase, please?

In general, this section has quite a number of English problems that would benefit from a quick editing pass by a native speaker.

-- Section 4.2.1 --
Is the double "SHOULD" in bullet 2 really what you want?  It seems to me that what this means to say, 2119-wise, is that when the server responds with a SYN-ACK, the SYN-ACK SHOULD [be set up as specified].

The last two paragraphs seem out of place here.  I suggest putting them into a new Section 4.2.1.1, clearly labelled as an alternative solution that could be explored if problems develop with this one.  Or perhaps even put this into the "related work" section (currently Section 8, but see my comment below).

-- Section 4.2.2 --

  5. Send the SYN-ACK packet. The packet MAY include a Fast Open
      Option.

Doesn't that MAY conflict with the SHOULD that I complain about above, in Section 4.2.1 ?

-- Section 6 --
I think the "i.e." here is not correct, and that you mean "e.g."  (This is one reason I recommend that people avoid using these Latin abbreviations.)

-- Section 6.3.1 --

  Although not all GET requests are idem-potent

Really?  According to RFC 7231, Sections 4.2.2 and 4.2.1, GET is an idempotent method.

RFC 7231, Section 4.2.2:
  Of the request methods
  defined by this specification, PUT, DELETE, and safe request methods
  are idempotent.

RFC 7231, Section 4.2.1:
  Of the request methods defined by this specification, the GET, HEAD,
  OPTIONS, and TRACE methods are defined to be safe.

And "idempotent" is one word, not hyphenated; please fix that here and in Section 6.3.3.

-- Section 6.3.2 --
What does this section have to do with this spec?

-- Section 7.1 --

  Further study is required to
  evaluate the performance impact of these malicious drop behaviors.

It may work against this protocol, but is there actually evidence that there's malicious intent here?  If not, I would avoid describing it as "malicious".  Dropping the word (if not the packets) seems like the right thing.

  Another interesting study is the (loss of) TFO performance benefit
  behind certain carrier-grade NAT.

Why the parentheses?  Shouldn't it just be "the loss of TFO performance benefit", without the parens?

-- Section 7.2 --

  The implementation can provide an experimental feature
  to allow zero length, or null, cookies as opposed to the minimum 4
  bytes cookies. Thus the server may return a null cookie and the
  client will send data in SYN with it subsequently.

Haven't you cut yourself off here by using a zero-length cookie to mean a cookie request?  How would this work?

-- Section 8 --
A very small point: I would make this an Appendix, rather than a mainline section.

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-tcpm-fastopen-09.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

IANA's reviewer has the following comments/questions:

IANA understands that, upon approval of this document, there is a single action which IANA must complete.

In the TCP Option Kind Numbers registry in Transmission Control Protocol (TCP) Parameters at

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

a new option kind number is to be registered as follows:

Kind: [ TBD-at-registration ]
Length: variable
Meaning: TCP Fast Open Cookie
Reference: [ RFC-to-be ]

IANA understands that this is the only action required to be completed upon approval of this document.

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 only to confirm what actions will be performed.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (TCP Fast Open) to Experimental RFC


The IESG has received a request from the TCP Maintenance and Minor
Extensions WG (tcpm) to consider the following document:
- 'TCP Fast Open'
  as Experimental RFC

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 2014-07-23. 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


  This document describes an experimental TCP mechanism TCP Fast Open
  (TFO). TFO allows data to be carried in the SYN and SYN-ACK packets
  and consumed by the receiving end during the initial connection
  handshake, thus saving up to one full round trip time (RTT) compared
  to the standard TCP, which requires a three-way handshake (3WHS) to
  complete before data can be exchanged. However TFO deviates from the
  standard TCP semantics since the data in the SYN could be replayed to
  an application in some rare circumstances. Applications should not
  use TFO unless they can tolerate this issue detailed in the
  Applicability section.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-tcpm-fastopen/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-tcpm-fastopen/ballot/


No IPR declarations have been submitted directly on this I-D.

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

The intended status is Experimental, as indicated on the title page
header.

It is consensus of the TCPM working group that this document should be
published as experimental RFC, given that it describes a TCP extension
that deviates from the standard TCP semantics in certain corner
cases. Because of the same reason, this extension is not recommended
for being used by default. The document explicitly lists certain areas
of further experimentation in Section 7.


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

  This document describes an experimental TCP mechanism TCP Fast Open
  (TFO). TFO allows data to be carried in the SYN and SYN-ACK packets
  and consumed by the receiving end during the initial connection
  handshake, thus saving up to one full round trip time (RTT)
  compared to the standard TCP, which requires a three-way handshake
  (3WHS) to complete before data can be exchanged. However TFO
  deviates from the standard TCP semantics since the data in the SYN
  could be replayed to an application in some rare
  circumstances. Applications should not use TFO unless they can
  tolerate this issue detailed in the Applicability section.

Working Group Summary:

  This document was extensively discussed and reviewed by the TCPM
  working group and there is strong support to publish the
  document. While being an experimental document, the TCPM working
  group decided to ask IESG for approving an IANA allocation of a new
  TCP option codepoint.

Document Quality:

  The protocol extension described in this document is implemented and
  deployed in the Linux TCP/IP stack, and it is supported by the Chrome
  Web browser and all Google servers. Experimental results have been
  discussed in the TCPM working group. An early SECDIR review
  concluded that the document had no substantive issues.

Personnel:

  The Document Shepherd is Michael Scharf
  . The Responsible Area Director
  is Martin Stiemerling .


(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 Shepherd read the document and he reviewed all
discussions during WGLC and follow-up discussions after WGLC. The
document is considered ready for publication.


(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No. This document was extensively reviewed by the TCPM working group.

The protocol extension described in this document is implemented and
deployed in the Linux TCP/IP stack, and it is supported by the Chrome
Web browser and all Google servers.


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

Given the security implications of this TCP extension, the Document
Shepherd decided to ask for an early SECDIR review. The review was
performed by Shawn M. Emery with the conclusion that "the various
risks associated with this protocol are outlined in the draft and
provides sufficient techniques for mitigating against such
attacks". The review only identified two editorial nits.


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

There are no such issues.


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

All authors have confirmed that the appropriate IPR disclusures have
been filed.


(8) Has an IPR disclosure been filed that references this document? If
so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

There are no IPR disclosures.


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

This document has been extensively discussed in the TCPM working
group, both on the mailing list and in several face-to-face
meetings. It has been reviewed in detail by several contributors. It
can be assumed that TCPM working group as a whole understands the
mechanism.

There have been several discussions on the implications on TCP
congestion control, in particular if this document is being used in
combination with RFC 6928 ("IW10"), since this document allows a
server to send an initial window of data before completing the
three-way TCP handshake. As an outcome of these discussion, the
document mandates in Section 4.2.2 "the server MUST follow [RFC5681]
(based on [RFC3390]) to set the initial congestion window for sending
more data packets" and lists this topic as an areas for further
experimentation in Section 7.3. These statements are considered
sufficient by the vast majority of the TCPM WG participants.

Two issues have been raised during WGLC:

* Regarding allocation of a dedicated TCP option code point for a
  non-standards-track protocol, one contributor disagreed. However,
  there is clear and strong consensus in the TCPM working group that
  in this specific case it seems worthwile to allocate a TCP option
  number (see below).

* The have been concerns concern regarding the rigorousness of the
  protocol specification, in particular if a further specification of
  the client caching behavior is needed. Yet, the consensus in the WG
  is that these heuristics are implementation details that do not
  affect interoperability.

In summary, there is strong consensus in TCPM to publish the document.


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

There is no known extreme discontent.


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

The document passes IDnits with one editorial error ("There is 1
instance of lines with control characters in the document").


(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

Such review is not required.


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

There are no such normative references.


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

Not applicable


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

The document does not change the status of any RFC.


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

The TCPM working group decided with strong consensus to ask for IANA
allocation of a TCP option number for this experimental document.

Reasoning: The protocol has always followed the guidelines of RFC 6994
and it currently uses an experimental TCP option number in combination
with a registered experimental identifier (0xF989). This consumes two
bytes of very scarce 40B option space in TCP SYN segments, which could
thus prevent other, future TCP extensions. Right now, there is no
significant shortage of IANA-assigned TCP option codepoints for users
following the IETF process: Out of 256 codepoints, IANA has only 14
codepoints assigned to an non-obsoleted RFC, 6 other registrations
(legacy), 9 obsoleted codepoints, and of the order of 10-15 known
unauthorized uses. Given the benefits and the deployment of this
protocol on the one hand side, and the large number of unallocated and
available TCP option codepoints on the other hand, use of a dedicated
option codepoint is considered to be the right trade-off. The TCPM
working group therefore asks the IESG for approving a TCP option
codepoint allocation for this experimental document.


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

Not applicable


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

The intended status is Experimental, as indicated on the title page
header.

It is consensus of the TCPM working group that this document should be
published as experimental RFC, given that it describes a TCP extension
that deviates from the standard TCP semantics in certain corner
cases. Because of the same reason, this extension is not recommended
for being used by default. The document explicitly lists certain areas
of further experimentation in Section 7.


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

  This document describes an experimental TCP mechanism TCP Fast Open
  (TFO). TFO allows data to be carried in the SYN and SYN-ACK packets
  and consumed by the receiving end during the initial connection
  handshake, thus saving up to one full round trip time (RTT)
  compared to the standard TCP, which requires a three-way handshake
  (3WHS) to complete before data can be exchanged. However TFO
  deviates from the standard TCP semantics since the data in the SYN
  could be replayed to an application in some rare
  circumstances. Applications should not use TFO unless they can
  tolerate this issue detailed in the Applicability section.

Working Group Summary:

  This document was extensively discussed and reviewed by the TCPM
  working group and there is strong support to publish the
  document. While being an experimental document, the TCPM working
  group decided to ask IESG for approving an IANA allocation of a new
  TCP option codepoint.

Document Quality:

  This protocol extension is implemented and deployed in the Linux
  TCP/IP stack, and experimental results have been discussed in the
  TCPM working group. An early SECDIR concluded that the document had
  no substantive issues.

Personnel:

  The Document Shepherd is Michael Scharf
  . The Responsible Area Director
  is Martin Stiemerling .


(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 Shepherd read the document and he reviewed all
discussions during WGLC and follow-up discussions after WGLC. The
document is considered ready for publication.


(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No. This document was extensively reviewed by the TCPM working group.

The protocol extension described in this document is implemented and deployed in the Linux TCP/IP stack, and it is supported by the Chrome Web browser and all Google servers.


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

Given the security implications of this TCP extension, the Document
Shepherd decided to ask for an early SECDIR review. The review was
performed by Shawn M. Emery with the conclusion that "the various
risks associated with this protocol are outlined in the draft and
provides sufficient techniques for mitigating against such
attacks". The review only identified two editorial nits.


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

There are no such issues.


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

All authors have confirmed that the appropriate IPR disclusures have
been filed.


(8) Has an IPR disclosure been filed that references this document? If
so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

There are no IPR disclosures.


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

This document has been extensively discussed in the TCPM working
group, both on the mailing list and in several face-to-face
meetings. It has been reviewed in detail by several contributors. It
can be assumed that TCPM working group as a whole understands the
mechanism.

There have been several discussions on the implications on TCP
congestion control, in particular if this document is being used in
combination with RFC 6928 ("IW10"), since this document allows a
server to send an initial window of data before completing the
three-way TCP handshake. As an outcome of these discussion, the
document mandates in Section 4.2.2 "the server MUST follow [RFC5681]
(based on [RFC3390]) to set the initial congestion window for sending
more data packets" and lists this topic as an areas for further
experimentation in Section 7.3. These statements are considered
sufficient by the vast majority of the TCPM WG participants.

Two issues have been raised during WGLC:

* Regarding allocation of a dedicated TCP option code point for a
  non-standards-track protocol, one contributor disagreed. However,
  there is clear and strong consensus in the TCPM working group that
  in this specific case it seems worthwile to allocate a TCP option
  number (see below).

* The have been concerns concern regarding the rigorousness of the
  protocol specification, in particular if a further specification of
  the client caching behavior is needed. Yet, the consensus in the WG
  is that these heuristics are implementation details that do not
  affect interoperability.

In summary, there is strong consensus in TCPM to publish the document.


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

There is no known extreme discontent.


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

The document passes IDnits with one editorial error ("There is 1
instance of lines with control characters in the document").


(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

Such review is not required.


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

There are no such normative references.


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

Not applicable


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

The document does not change the status of any RFC.


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

The TCPM working group decided with strong consensus to ask for IANA
allocation of a TCP option number for this experimental document.

Reasoning: The protocol has always followed the guidelines of RFC 6994
and it currently uses an experimental TCP option number in combination
with a registered experimental identifier (0xF989). This consumes two
bytes of very scarce 40B option space in TCP SYN segments, which could
thus prevent other, future TCP extensions. Right now, there is no
significant shortage of IANA-assigned TCP option codepoints for users
following the IETF process: Out of 256 codepoints, IANA has only 14
codepoints assigned to an non-obsoleted RFC, 6 other registrations
(legacy), 9 obsoleted codepoints, and of the order of 10-15 known
unauthorized uses. Given the benefits and the deployment of this
protocol on the one hand side, and the large number of unallocated and
available TCP option codepoints on the other hand, use of a dedicated
option codepoint is considered to be the right trade-off. The TCPM
working group therefore asks the IESG for approving a TCP option
codepoint allocation for this experimental document.


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

Not applicable


(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

The shepherd write-up is silent about any existing implementation of this. I know about Google's implementation and it would be really good to mention this, and potentially also in which Operating Systems this has been implemented and deployed.

The review:

In general, I do not see any issues with the document, but please address the issues below and submit an updated version of the draft.

Blocking issues:
* Instructions for IANA:
The current instructions for IANA are not precis enough to let IANA know what the intention is.

Please update these two parts of the document:
- in Section 4.1.1. "TCP Options":
OLD-1
Kind            1 byte: constant TBD (assigned by IANA)
NEW-1
Kind            1 byte: constant-TBD (to be assigned by IANA)

OLD-2
Kind            1 byte: same as the Fast Open Cookie option
NEW-2
Kind            1 byte: constant-TBD  (same value as the Fast Open Cookie option above)

- in Section 9. "IANA Considerations"

OLD
  The Fast Open Cookie Option and Fast Open Cookie Request Option
  define no new namespace. The options require IANA to allocate one
  value from the TCP option Kind namespace.
NEW
  IANA is requested to allocate one value from the TCP Option Kind
  Numbers: The constant-TBD in Section Section 4.1.1 has to be
  replaced with the newly assigned value.
  The length of the new TCP option Kind is variable and the Meaning
  should be set to "TCP Fast Open Cookie".

* Section 4.2.2, page 12:
"1. Update the cookie cache if the SYN-ACK has a Fast Open Cookie"

Update with what? I guess the received cookie out of the Fast Open Cookie. This sounds pendatic, but clear language helps to avoid misunderstandings.


Editorials:
- Section 1, 2nd paragraph: Please add a reference to the Chome browser, just for completeness.

- Section 1.1, 1st paragrahp: Please make "TFO refers to TCP Fast..." an new paragraph just to separate it from the RFC 2119 language.

- In multiple places:
You always talk about encryption of IP addresses for the cookies, but I believe you are talking about hashing them. However, I am not going to die about this, as the security reviewer apparently didn't yell at you about this.

- Section 4.1.2 and other places, about the server generating a new cookie and how does the client find this out. To my understanding, the client is always using the latest cookie from the SYN-ACK sent by the server and stores this. However, this is not explicitly mentioned in the draft. Please add this to make this clear or let me know if I got this wrong.

- Section 4.1.2, at the end of page 8: Please add a reference to AES_128, just for completeness.

- Section 4.1.3, first paragraph: remember your non-native folks (including but not limited to me ;) and make sentences easier to read :)
OLD
For a multi-homed client, the cookies are both client and server IP dependent.
NEW
For a multi-homed client, the cookies are dependent on the client IP address and server IP address.


- Section 4.1.3, first paragraph: Please separate this sentences from the first paragraph and merge it with the 2nd paragraph:
"Beside the cookie we RECOMMEND that the client caches the MSS to the server to enhance performance."

- Section 4.2: "The server keeps two variables per listening port:"
I am not sure that this sentences is correct. An implementation can maintain such variables on a per socket basis (port+IP) or per port (independent of the IP address). How about adding "or listening socket (IP address & port).

- Section  4.2.1, page 11, 1st paragraph:
OLD
Next Section describes
NEW
The next Section describes

- Section 6.1, 2nd paragraph:
The cited measurement supports your argument that duplicated SYNs are not a big deal, but there is a number of networks where this might be big deal, e.g., not so well dimesioned networks in developing countries.
I woud add something along these lines "Further investigation is needed to judge about the probability of receiving duplicated SYN or SYN-ACK with data in non-Tier 1 networks."

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

The intended status is Experimental, as indicated on the title page
header.

It is consensus of the TCPM working group that this document should be
published as experimental RFC, given that it describes a TCP extension
that deviates from the standard TCP semantics in certain corner
cases. Because of the same reason, this extension is not recommended
for being used by default. The document explicitly lists certain areas
of further experimentation in Section 7.


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

  This document describes an experimental TCP mechanism TCP Fast Open
  (TFO). TFO allows data to be carried in the SYN and SYN-ACK packets
  and consumed by the receiving end during the initial connection
  handshake, thus saving up to one full round trip time (RTT)
  compared to the standard TCP, which requires a three-way handshake
  (3WHS) to complete before data can be exchanged. However TFO
  deviates from the standard TCP semantics since the data in the SYN
  could be replayed to an application in some rare
  circumstances. Applications should not use TFO unless they can
  tolerate this issue detailed in the Applicability section.

Working Group Summary:

  This document was extensively discussed and reviewed by the TCPM
  working group and there is strong support to publish the
  document. While being an experimental document, the TCPM working
  group decided to ask IESG for approving an IANA allocation of a new
  TCP option codepoint.

Document Quality:

  This protocol extension is implemented and deployed in the Linux
  TCP/IP stack, and experimental results have been discussed in the
  TCPM working group. An early SECDIR concluded that the document had
  no substantive issues.

Personnel:

  The Document Shepherd is Michael Scharf
  . The Responsible Area Director
  is Martin Stiemerling .


(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 Shepherd read the document and he reviewed all
discussions during WGLC and follow-up discussions after WGLC. The
document is considered ready for publication.


(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No. This document was extensively reviewed by the TCPM working group.


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

Given the security implications of this TCP extension, the Document
Shepherd decided to ask for an early SECDIR review. The review was
performed by Shawn M. Emery with the conclusion that "the various
risks associated with this protocol are outlined in the draft and
provides sufficient techniques for mitigating against such
attacks". The review only identified two editorial nits.


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

There are no such issues.


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

All authors have confirmed that the appropriate IPR disclusures have
been filed.


(8) Has an IPR disclosure been filed that references this document? If
so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

There are no IPR disclosures.


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

This document has been extensively discussed in the TCPM working
group, both on the mailing list and in several face-to-face
meetings. It has been reviewed in detail by several contributors. It
can be assumed that TCPM working group as a whole understands the
mechanism.

There have been several discussions on the implications on TCP
congestion control, in particular if this document is being used in
combination with RFC 6928 ("IW10"), since this document allows a
server to send an initial window of data before completing the
three-way TCP handshake. As an outcome of these discussion, the
document mandates in Section 4.2.2 "the server MUST follow [RFC5681]
(based on [RFC3390]) to set the initial congestion window for sending
more data packets" and lists this topic as an areas for further
experimentation in Section 7.3. These statements are considered
sufficient by the vast majority of the TCPM WG participants.

Two issues have been raised during WGLC:

* Regarding allocation of a dedicated TCP option code point for a
  non-standards-track protocol, one contributor disagreed. However,
  there is clear and strong consensus in the TCPM working group that
  in this specific case it seems worthwile to allocate a TCP option
  number (see below).

* The have been concerns concern regarding the rigorousness of the
  protocol specification, in particular if a further specification of
  the client caching behavior is needed. Yet, the consensus in the WG
  is that these heuristics are implementation details that do not
  affect interoperability.

In summary, there is strong consensus in TCPM to publish the document.


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

There is no known extreme discontent.


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

The document passes IDnits with one editorial error ("There is 1
instance of lines with control characters in the document").


(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

Such review is not required.


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

There are no such normative references.


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

Not applicable


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

The document does not change the status of any RFC.


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

The TCPM working group decided with strong consensus to ask for IANA
allocation of a TCP option number for this experimental document.

Reasoning: The protocol has always followed the guidelines of RFC 6994
and it currently uses an experimental TCP option number in combination
with a registered experimental identifier (0xF989). This consumes two
bytes of very scarce 40B option space in TCP SYN segments, which could
thus prevent other, future TCP extensions. Right now, there is no
significant shortage of IANA-assigned TCP option codepoints for users
following the IETF process: Out of 256 codepoints, IANA has only 14
codepoints assigned to an non-obsoleted RFC, 6 other registrations
(legacy), 9 obsoleted codepoints, and of the order of 10-15 known
unauthorized uses. Given the benefits and the deployment of this
protocol on the one hand side, and the large number of unallocated and
available TCP option codepoints on the other hand, use of a dedicated
option codepoint is considered to be the right trade-off. The TCPM
working group therefore asks the IESG for approving a TCP option
codepoint allocation for this experimental document.


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

Not applicable


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

The intended status is Experimental, as indicated on the title page
header.

It is consensus of the TCPM working group that this document should be
published as experimental RFC, given that it describes a TCP extension
that deviates from the standard TCP semantics in certain corner
cases. Because of the same reason, this extension is not recommended
for being used by default. The document explicitly lists certain areas
of further experimentation in Section 7.


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

  This document describes an experimental TCP mechanism TCP Fast Open
  (TFO). TFO allows data to be carried in the SYN and SYN-ACK packets
  and consumed by the receiving end during the initial connection
  handshake, thus saving up to one full round trip time (RTT)
  compared to the standard TCP, which requires a three-way handshake
  (3WHS) to complete before data can be exchanged. However TFO
  deviates from the standard TCP semantics since the data in the SYN
  could be replayed to an application in some rare
  circumstances. Applications should not use TFO unless they can
  tolerate this issue detailed in the Applicability section.

Working Group Summary:

  This document was extensively discussed and reviewed by the TCPM
  working group and there is strong support to publish the
  document. While being an experimental document, the TCPM working
  group decided to ask IESG for approving an IANA allocation of a new
  TCP option codepoint.

Document Quality:

  This protocol extension is implemented and deployed in the Linux
  TCP/IP stack, and experimental results have been discussed in the
  TCPM working group. An early SECDIR concluded that the document had
  no substantive issues.

Personnel:

  The Document Shepherd is Michael Scharf
  . The Responsible Area Director
  is Martin Stiemerling .


(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 Shepherd read the document and he reviewed all
discussions during WGLC and follow-up discussions after WGLC. The
document is considered ready for publication.


(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No. This document was extensively reviewed by the TCPM working group.


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

Given the security implications of this TCP extension, the Document
Shepherd decided to ask for an early SECDIR review. The review was
performed by Shawn M. Emery with the conclusion that "the various
risks associated with this protocol are outlined in the draft and
provides sufficient techniques for mitigating against such
attacks". The review only identified two editorial nits.


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

There are no such issues.


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

All authors have confirmed that the appropriate IPR disclusures have
been filed.


(8) Has an IPR disclosure been filed that references this document? If
so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

There are no IPR disclosures.


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

This document has been extensively discussed in the TCPM working
group, both on the mailing list and in several face-to-face
meetings. It has been reviewed in detail by several contributors. It
can be assumed that TCPM working group as a whole understands the
mechanism.

There have been several discussions on the implications on TCP
congestion control, in particular if this document is being used in
combination with RFC 6928 ("IW10"), since this document allows a
server to send an initial window of data before completing the
three-way TCP handshake. As an outcome of these discussion, the
document mandates in Section 4.2.2 "the server MUST follow [RFC5681]
(based on [RFC3390]) to set the initial congestion window for sending
more data packets" and lists this topic as an areas for further
experimentation in Section 7.3. These statements are considered
sufficient by the vast majority of the TCPM WG participants.

Two issues have been raised during WGLC:

* Regarding allocation of a dedicated TCP option code point for a
  non-standards-track protocol, one contributor disagreed. However,
  there is clear and strong consensus in the TCPM working group that
  in this specific case it seems worthwile to allocate a TCP option
  number (see below).

* The have been concerns concern regarding the rigorousness of the
  protocol specification, in particular if a further specification of
  the client caching behavior is needed. Yet, the consensus in the WG
  is that these heuristics are implementation details that do not
  affect interoperability.

In summary, there is strong consensus in TCPM to publish the document.


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

There is no known extreme discontent.


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

The document passes IDnits with one editorial error ("There is 1
instance of lines with control characters in the document").


(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

Such review is not required.


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

There are no such normative references.


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

Not applicable


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

The document does not change the status of any RFC.


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

The TCPM working group decided with strong consensus to ask for IANA
allocation of a TCP option number for this experimental document.

Reasoning: The protocol has always followed the guidelines of RFC 6994
and it currently uses an experimental TCP option number in combination
with a registered experimental identifier (0xF989). This consumes two
bytes of very scarce 40B option space in TCP SYN segments, which could
thus prevent other, future TCP extensions. Right now, there is no
significant shortage of IANA-assigned TCP option codepoints for users
following the IETF process: Out of 256 codepoints, IANA has only 14
codepoints assigned to an non-obsoleted RFC, 6 other registrations
(legacy), 9 obsoleted codepoints, and of the order of 10-15 known
unauthorized uses. Given the benefits and the deployment of this
protocol on the one hand side, and the large number of unallocated and
available TCP option codepoints on the other hand, use of a dedicated
option codepoint is considered to be the right trade-off. The TCPM
working group therefore asks the IESG for approving a TCP option
codepoint allocation for this experimental document.


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

Not applicable


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

The intended status is Experimental, as indicated on the title page
header.

It is consensus of the TCPM working group that this document should be
published as experimental RFC, given that it describes a TCP extension
that deviates from the standard TCP semantics in certain corner
cases. Because of the same reason, this extension is not recommended
for being used by default. The document explicitly lists certain areas
of further experimentation in Section 7.


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

  This document describes an experimental TCP mechanism TCP Fast Open
  (TFO). TFO allows data to be carried in the SYN and SYN-ACK packets
  and consumed by the receiving end during the initial connection
  handshake, thus saving up to one full round trip time (RTT)
  compared to the standard TCP, which requires a three-way handshake
  (3WHS) to complete before data can be exchanged. However TFO
  deviates from the standard TCP semantics since the data in the SYN
  could be replayed to an application in some rare
  circumstances. Applications should not use TFO unless they can
  tolerate this issue detailed in the Applicability section.

Working Group Summary:

  This document was extensively discussed and reviewed by the TCPM
  working group and there is strong support to publish the
  document. While being an experimental document, the TCPM working
  group decided to ask IESG for approving an IANA allocation of a new
  TCP option codepoint.

Document Quality:

  This protocol extension is implemented and deployed in the Linux
  TCP/IP stack, and experimental results have been discussed in the
  TCPM working group. An early SECDIR concluded that the document had
  no substantive issues.

Personnel:

  The Document Shepherd is Michael Scharf
  . The Responsible Area Director
  is Martin Stiemerling .


(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 Shepherd read the document and he reviewed all
discussions during WGLC and follow-up discussions after WGLC. The
document is considered ready for publication.


(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No. This document was extensively reviewed by the TCPM working group.


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

Given the security implications of this TCP extension, the Document
Shepherd decided to ask for an early SECDIR review. The review was
performed by Shawn M. Emery with the conclusion that "the various
risks associated with this protocol are outlined in the draft and
provides sufficient techniques for mitigating against such
attacks". The review only identified two editorial nits.


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

There are no such issues.


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

All authors have confirmed that the appropriate IPR disclusures have
been filed.


(8) Has an IPR disclosure been filed that references this document? If
so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

There are no IPR disclosures.


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

This document has been extensively discussed in the TCPM working
group, both on the mailing list and in several face-to-face
meetings. It has been reviewed in detail by several contributors. It
can be assumed that TCPM working group as a whole understands the
mechanism.

There have been several discussions on the implications on TCP
congestion control, in particular if this document is being used in
combination with RFC 6928 ("IW10"), since this document allows a
server to send an initial window of data before completing the
three-way TCP handshake. As an outcome of these discussion, the
document mandates in Section 4.2.2 "the server MUST follow [RFC5681]
(based on [RFC3390]) to set the initial congestion window for sending
more data packets" and lists this topic as an areas for further
experimentation in Section 7.3. These statements are considered
sufficient by the vast majority of the TCPM WG participants.

Two issues have been raised during WGLC:

* Regarding allocation of a dedicated TCP option code point for a
  non-standards-track protocol, one contributor disagreed. However,
  there is clear and strong consensus in the TCPM working group that
  in this specific case it seems worthwile to allocate a TCP option
  number (see below).

* The have been concerns concern regarding the rigorousness of the
  protocol specification, in particular if a further specification of
  the client caching behavior is needed. Yet, the consensus in the WG
  is that these heuristics are implementation details that do not
  affect interoperability.

In summary, there is strong consensus in TCPM to publish the document.


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

There is no known extreme discontent.


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

The document passes IDnits with one editorial error ("There is 1
instance of lines with control characters in the document").


(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

Such review is not required.


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

There are no such normative references.


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

Not applicable


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

The document does not change the status of any RFC.


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

The TCPM working group decided with strong consensus to ask for IANA
allocation of a TCP option number for this experimental document.

Reasoning: The protocol has always followed the guidelines of RFC 6994
and it currently uses an experimental TCP option number in combination
with a registered experimental identifier (0xF989). This consumes two
bytes of very scarce 40B option space in TCP SYN segments, which could
thus prevent other, future TCP extensions. Right now, there is no
significant shortage of IANA-assigned TCP option codepoints for users
following the IETF process: Out of 256 codepoints, IANA has only 14
codepoints assigned to an non-obsoleted RFC, 6 other registrations
(legacy), 9 obsoleted codepoints, and of the order of 10-15 known
unauthorized uses. Given the benefits and the deployment of this
protocol on the one hand side, and the large number of unallocated and
available TCP option codepoints on the other hand, use of a dedicated
option codepoint is considered to be the right trade-off. The TCPM
working group therefore asks the IESG for approving a TCP option
codepoint allocation for this experimental document.


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

Not applicable


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

The intended status is Experimental, as indicated on the title page
header.

It is consensus of the TCPM working group that this document should be
published as experimental RFC, given that it describes a TCP extension
that deviates from the standard TCP semantics in certain corner
cases. Because of the same reason, this extension is not recommended
for being used by default. The document explicitly lists certain areas
of further experimentation in Section 7.


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

  This document describes an experimental TCP mechanism TCP Fast Open
  (TFO). TFO allows data to be carried in the SYN and SYN-ACK packets
  and consumed by the receiving end during the initial connection
  handshake, thus saving up to one full round trip time (RTT)
  compared to the standard TCP, which requires a three-way handshake
  (3WHS) to complete before data can be exchanged. However TFO
  deviates from the standard TCP semantics since the data in the SYN
  could be replayed to an application in some rare
  circumstances. Applications should not use TFO unless they can
  tolerate this issue detailed in the Applicability section.

Working Group Summary:

  This document was extensively discussed and reviewed by the TCPM
  working group and there is strong support to publish the
  document. While being an experimental document, the TCPM working
  group decided to ask IESG for approving an IANA allocation of a new
  TCP option codepoint.

Document Quality:

  This protocol extension is implemented and deployed in the Linux
  TCP/IP stack, and experimental results have been discussed in the
  TCPM working group. An early SECDIR concluded that the document had
  no substantive issues.

Personnel:

  The Document Shepherd is Michael Scharf
  . The Responsible Area Director
  is Martin Stiemerling .


(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 Shepherd read the document and he reviewed all
discussions during WGLC and follow-up discussions after WGLC. The
document is considered ready for publication.


(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No. This document was extensively reviewed by the TCPM working group.


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

Given the security implications of this TCP extension, the Document
Shepherd decided to ask for an early SECDIR review. The review was
performed by Shawn M. Emery with the conclusion that "the various
risks associated with this protocol are outlined in the draft and
provides sufficient techniques for mitigating against such
attacks". The review only identified two editorial nits.


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

There are no such issues.


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

All authors have confirmed that the appropriate IPR disclusures have been filed.


(8) Has an IPR disclosure been filed that references this document? If
so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

There are no IPR disclosures.


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

This document has been extensively discussed in the TCPM working
group, both on the mailing list and in several face-to-face
meetings. It has been reviewed in detail by several contributors. It
can be assumed that TCPM working group as a whole understands the
mechanism.

There have been several discussions on the implications on TCP
congestion control, in particular if this document is being used in
combination with RFC 6928 ("IW10"), since this document allows a
server to send an initial window of data before completing the
three-way TCP handshake. As an outcome of these discussion, the
document mandates in Section 4.2.2 "the server MUST follow [RFC5681]
(based on [RFC3390]) to set the initial congestion window for sending
more data packets" and lists this topic as an areas for further
experimentation in Section 7.3. These statements are considered
sufficient by the vast majority of the TCPM WG participants.

Two issues have been raised during WGLC:

* Regarding allocation of a dedicated TCP option code point for a
  non-standards-track protocol, one contributor disagreed. However,
  there is clear and strong consensus in the TCPM working group that
  in this specific case it seems worthwile to allocate a TCP option
  number (see below).

* The have been concerns concern regarding the rigorousness of the
  protocol specification, in particular if a further specification of
  the client caching behavior is needed. Yet, the consensus in the WG
  is that these heuristics are implementation details that do not
  affect interoperability.

In summary, there is strong consensus in TCPM to publish the document.


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

There is no known extreme discontent.


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

The document passes IDnits with one editorial error ("There is 1
instance of lines with control characters in the document").


(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

Such review is not required.


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

There are no such normative references.


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

Not applicable


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

The document does not change the status of any RFC.


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

The TCPM working group decided with strong consensus to ask for IANA
allocation of a TCP option number for this experimental document.

Reasoning: The protocol has always followed the guidelines of RFC 6994
and it currently uses an experimental TCP option number in combination
with a registered experimental identifier (0xF989). This consumes two
bytes of very scarce 40B option space in TCP SYN segments, which could
thus prevent other, future TCP extensions. Right now, there is no
significant shortage of IANA-assigned TCP option codepoints for users
following the IETF process: Out of 256 codepoints, IANA has only 14
codepoints assigned to an non-obsoleted RFC, 6 other registrations
(legacy), 9 obsoleted codepoints, and of the order of 10-15 known
unauthorized uses. Given the benefits and the deployment of this
protocol on the one hand side, and the large number of unallocated and
available TCP option codepoints on the other hand, use of a dedicated
option codepoint is considered to be the right trade-off. The TCPM
working group therefore asks the IESG for approving a TCP option
codepoint allocation for this experimental document.


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

Not applicable


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

The intended status is Experimental, as indicated on the title page header.

It is consensus of the TCPM working group that this document should be published as experimental RFC, given that it describes a TCP extension that deviates from the standard TCP semantics in certain corner cases. Because of the same reason, this extension is not recommended for being used by default. The document explicitly lists certain areas of further experimentation in Section 7.


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

  This document describes an experimental TCP mechanism TCP Fast Open
  (TFO). TFO allows data to be carried in the SYN and SYN-ACK packets
  and consumed by the receiving end during the initial connection
  handshake, thus saving up to one full round trip time (RTT) compared
  to the standard TCP, which requires a three-way handshake (3WHS) to
  complete before data can be exchanged. However TFO deviates from the
  standard TCP semantics since the data in the SYN could be replayed to
  an application in some rare circumstances. Applications should not
  use TFO unless they can tolerate this issue detailed in the
  Applicability section.

Working Group Summary:

  This document was extensively discussed and reviewed by the TCPM working group and there is strong support to publish the document. While being an experimental document, the TCPM working group decided to ask IESG for approving an IANA allocation of a new TCP option codepoint.

Document Quality:

  This protocol extension is implemented and deployed in the Linux TCP/IP stack, and experimental results have been discussed in the TCPM working group. An early SECDIR concluded that the document had no substantive issues.

Personnel:

  The Document Shepherd is Michael Scharf . The Responsible Area Director is Martin Stiemerling .


(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 Shepherd read the document and he reviewed all discussions during WGLC and follow-up discussions after WGLC. The document is considered ready for publication.


(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No. This document was extensively reviewed by the TCPM working group.


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

Given the security implications of this TCP extension, the Document Shepherd decided to ask for an early SECDIR review. The review was performed by Shawn M. Emery with the conclusion that "the various risks associated with this protocol are outlined in the draft and provides sufficient techniques for mitigating against such attacks". The review only identified two editorial nits.


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

There are no such issues.


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

All authors have confirmed that the appropriate IPR disclusures have been filed.


(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

There are no IPR disclosures.


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

This document has been extensively discussed in the TCPM working group, both on the mailing list and in several face-to-face meetings. It has been reviewed in detail by several contributors. It can be assumed that TCPM working group as a whole understands the mechanism.

There have been several discussions on the implications on TCP congestion control, in particular if this document is being used in combination with RFC 6928 ("IW10"), since this document allows a server to send an initial window of data before completing the three-way TCP handshake. As an outcome of these discussion, the document mandates in Section 4.2.2 "the server MUST follow [RFC5681] (based on [RFC3390]) to set the initial congestion window for sending more data packets" and lists this topic as an areas for further experimentation in Section 7.3. These statements are considered sufficient by the vast majority of the TCPM WG participants.

Two issues have been raised during WGLC:

* Regarding allocation of a dedicated TCP option code point for a non-standards-track protocol, one contributor disagreed. However, there is clear and strong consensus in the TCPM working group that in this specific case it seems worthwile to allocate a TCP option number (see below).

* The have been concerns concern regarding the rigorousness of the protocol specification, in particular if a further specification of the client caching behavior is needed. Yet, the consensus in the WG is that these heuristics are implementation details that do not affect interoperability.

In summary, there is strong consensus in TCPM to publish the document.


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

There is no known extreme discontent.


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

The document passes IDnits with one editorial error ("There is 1 instance of lines with control characters in the document").


(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews.

Such review is not required.


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

There are no such normative references.


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

Not applicable


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

The document does not change the status of any RFC.


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

The TCPM working group decided with strong consensus to ask for IANA allocation of a TCP option number for this experimental document.

Reasoning: The protocol has always followed the guidelines of RFC 6994 and it currently uses an experimental TCP option number in combination with a registered experimental identifier (0xF989). This consumes two bytes of very scarce 40B option space in TCP SYN segments, which could thus prevent other, future TCP extensions. Right now, there is no significant shortage of IANA-assigned TCP option codepoints for users following the IETF process: Out of 256 codepoints, IANA has only 14 codepoints assigned to an non-obsoleted RFC, 6 other registrations (legacy), 9 obsoleted codepoints, and of the order of 10-15 known unauthorized uses. Given the benefits and the deployment of this protocol on the one hand side, and the large number of unallocated and available TCP option codepoints on the other hand, use of a dedicated option codepoint is considered to be the right trade-off. The TCPM working group therefore asks the IESG for approving a TCP option codepoint allocation for this experimental document.


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

Not applicable


(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