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

Gorry Fairhurst <gorry@erg.abdn.ac.uk> Wed, 05 February 2014 18:53 UTC

Message-ID: <52F2888E.6070109@erg.abdn.ac.uk>
Date: Wed, 05 Feb 2014 18:53:02 +0000
From: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683.
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: tcpm@ietf.org
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: [tcpm] Comments on new rev of draft-ietf-tcpm-fastopen-06
Precedence: list
Reply-To: gorry@erg.abdn.ac.uk

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.

[tcpm] Comments on new rev of draft-ietf-tcpm-fas… Gorry Fairhurst