Document: draft-ietf-tsvwg-quickstart-06.txt
Reviewer: Francis Dupont
Review Date:  28 sept 2006
IETF LC Date: 30 sept 2006

Summary: Not Ready

Comments: I have two major concerns and some minor comments:
 * the overview (section 2.1, pages 15-17) fails to introduce the
   real protocol: no mention of the report or of the fact the
   response is carried in a TCP option, at the opposite of request
   and report. So when a new reader reaches the page 20 he is lost
   (at least I was the first time :-).
   I believe it is easy to fix, the only issue is to get a "fresh"
   reader to check the new text...
 * the IPv6 part needs to be improved: I suggest to ask in the mailing
   list(s) or the WG chairs, perhaps more v6ops than ipv6 as questions
   are more about concrete details than protocol theory.
   See below for some examples of this concern.

 - (changes) page 3: formating -> formatting
 - 3.1 page 20: MUST sent -> MUST send
 - 3.2 "Note that [RFC2460] specifies that when a specific flow label has
      been assigned to packets, the contents of the Hop-by-Hop options,
      excluding the next header field, must originate with the same
      contents throughout the IP flow lifetime."
   This is in the Appendix A about Flow Labels which was obsoleted
   by RFC 3697. BTW the "must" even does not apply to different
   fragments of the same packet (-:)!
   To fix this I suggest to replace the whole paragraph by a
   reference to RFC 3697 "IPv6 Flow Label Specification".
 - 3.3 page 22 introduces the idea to remove the option but
   this kind of operation is supposed to be forbidden, in particular
   with IPv6. IMHO the risk to break path MTU discovery is very high too.
   The alternative, zeroing the quick-start option fields, seems far
   better even it is more expensive for subsequent routers. I'd prefer
   to get it as the default behavior.
 - 3.4 page 26: guessable -> predictable
 - 4.1 page 28: there is a nice discussion about end point address
   changes. As it should become common with IPv6 multi-homing IMHO
   it should be read by IPv6 people...
 - 4.5 page 33: the TCP *receiver* can't deduct RTT from a request/
   response pair. IMHO it is a typo: the pair is request/report.
 - 9.6 page 55: overly-larqe -> overly-large
 - 11 page 60: update RFC 2402 by 4302 and add a pointer to entry page 85
   in the references.
 - A.2 page 65: conformant -> compliant
 - B.1.1 page 68: update [RFC2401] by [RFC4301] and add "ESP" between
   IPsec and tunnel mode.
 - B.2 page 70: put a reference for RFC 3390.
 - B.3 page 72: (about MSS) to spoof the TCP options is both a bad idea
   and not applicable when IPsec encrypts them...
 - D page 81: simpliest -> simplest