Subject: [tcpm] Comments on new rev of draft-ietf-tcpm-fastopen-06

From: Gorry Fairhurst <[email-masked]>
Date: Wed, 05 Feb 2014 18:53:02 +0000

Yuchung,

The comments/suggestions in the email below to -06 could all be 
editorial, please check and let me know if I can help.

Gorry

----

Formatting:

The abstract does not say this RFC-to-be is experimental. I suspect this 
is a requirement?

---
The first line of the introduction also does not say this is experimental.
I suggest something like:
/TCP Fast Open (TFO) enables/TCP Fast Open (TFO) is an experimental 
update to TCP that enables/
---

NiTs (mainly typos):

Section 2
/delivered to application/delivered to the application/
                                        ^^^

Section 2.1
/before 3WHS/before the 3-way handshake (3WHS)/
                     ^^^ ^^^^^^^^^^^^^^^

/It is not successful/It was not successful/
                          ^^^

4.1.2.
/But this is all server implementation/This is server implementation/
  ^^^         ^^^

4.1.3.1
/the client SHOULD disables/the client SHOULD disable/
                           ^

4.1.3.1
/ICMP Error messages/ I agree hard ICMP error messages are negative 
indications, but I think more needs to be said than just ICMP. Referring 
to RFC 5461 may help?

4.2.1
/to record servers that failed/to record the set of servers that failed/
                                          ^^^^^^^^^^^

4.2.1
- It may be worth considering a line-break after /period/. To cleanly 
separate the standards language from the other alternative?

4.2.2
/in particular the initial window/
- this seems to read oddly, do you perhaps mean:
/in managing the initial window/
- or setting the initial window?

5.1
- Starts with /However, the attacker/
- It may be better to simply start /An attacker/

5.1
/For this reason it is crucial for the TFO server to limit/
- This seems like it is a requirement, since the word crucial is used, 
and I understand that indeed this is important, although it could be 
better to say /To protect the server it is crucial.../. Does it need to 
be a MUST?

5.1.1.
/An attacker behind NAT/An attacker behind a NAT/
                                            ^^

6.1
/It is possible, though uncommon/
       ^^^^^^^^^^^^^^^^^^^^^^^^^^
- Seems like rather solid claims that need a reference to substantiate then.
- Something lie this could be better to write:
/It is possible, but thought to be not common in practice/

6.1 Last sentence.
This is a sentence with keywords that does not seem to parse to me, 
although from the rest of the document the meaning is OK.
/A client that cannot handle receiving the same SYN data more than once 
MUST NOT enable TFO to send data in a SYN. A server that cannot accept 
receiving the same SYN data more than once MUST NOT enable TFO to 
receive data in a SYN./

- I'd also suggest placing this in a separate para to ensure the 
standards language stands out.