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

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.