Subject: [Gen-art] review of draft-ietf-tcpm-tcp-timestamps-02.txt

From: Francis Dupont <[email-masked]>
Date: Fri, 10 Dec 2010 10:23:35 +0100

(note: I was a bit late to send the review so I updated it to the new
 version which was published between review time and today)

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at <
http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments you
may receive.

Document: draft-ietf-tcpm-tcp-timestamps-02.txt
Reviewer: Francis Dupont
Review Date: 2010-12-06 / 2010-12-10
IETF LC End Date: 2010-12-07
IESG Telechat date: unknown

Summary: Ready with Nits

Major issues: None

Minor issues: None

Nits/editorial comments:
 - ToC page 2 and 7 page 8: Acknowledgements -> Acknowledgments
 (BTW the american for "honour" is "honor" too, ask the RFC Editor
  to change honour spelling if he wants)

 - 1 page 3: in
  "The Timestamps option, specified in RFC 1323 [RFC1323], allows a TCP
   to include a timestamp value in its segments, that can be used to"

  perhaps there is a missing word (like "speaker") after "TCP"?

 - 2 pages 4 and 5: I don't understand where the difference between
  these two texts comes from:

        "the Sequence Number of the incoming SYN segment
         is larger than the last sequence number seen on the previous
         incarnation of the connection (for that direction of the data
         transfer), then honour the connection request (creating a
         connection in the SYN-RECEIVED state)."
        "the Sequence Number of the incoming SYN
         segment is larger than the last sequence number seen on the
         previous incarnation of the connection (for the same direction
         of the data transfer), then honour the incoming connection
         request (even if the sequence number of the incoming SYN
         segment falls within the receive window of the previous
         incarnation of the connection)."

  i.e., I can easily tell whether the small variations between similar
  specifications are just to make reading less boring or are about
  real differences.

 - 2 page 6: KB/s -> kbytes/s or kilobytes/s (at least K (Kelvin) ->
  k (kilo) and B -> bytes in letters)

 - 4 page 7: I guess it is a typo:

  "[CPNI-TCP].  [RFC1948] proposes an alternative ISN-generation scheme
   which results in monotonically-increasing timestamps across
                                             ^^^^^^^^^^ ISNs
  connections that are not easily-predictable by an off-path attacker."

 - 8.2 page 9 [INFOCOM-99] and [Silbersack]]: ' .' -> '.'

Thanks

[email-masked]

---

From: Lars Eggert <[email-masked]>
Date: Fri, 10 Dec 2010 12:05:50 +0200

Hi,

thanks for the review. Fernando, please see if you want to address any of these in your working copy. (But don't post a new revision until after the document has been discussed by the IESG.)

Thanks,
Lars

On 2010-12-10, at 11:23, Francis Dupont wrote:

> _______________________________________________
> Gen-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gen-art

---

From: Fernando Gont <[email-masked]>
Date: Fri, 10 Dec 2010 14:12:14 -0300

Hi, Lars,

I will respond to Francis' comments this weekend and address his
comments shortly.

Thanks!

Kind regards,
Fernando

On 12/10/10, Lars Eggert <[email-masked]> wrote:
> Hi,
>
> thanks for the review. Fernando, please see if you want to address any of
> these in your working copy. (But don't post a new revision until after the
> document has been discussed by the IESG.)
>
> Thanks,
> Lars
>

-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Fernando Gont <[email-masked]>
Date: Mon, 13 Dec 2010 03:05:40 -0300

Hi, Francis,

Thanks so much for your feedback! Please find my comments inline....

>   to change honour spelling if he wants)

These have been published "as is" in previous RFCs I have authored...

>   perhaps there is a missing word (like "speaker") after "TCP"?

The term "a TCP" is usually employed as a short form for "a TCP instance"

>   specifications are just to make reading less boring or are about

Fair enough. I will update the text on page 5 as follows, such to avoid
the minor differences with the text in page 4:

>       *  If TCP timestamps would be enabled for the new incarnation of
>          the connection, honour the incoming connection request (creating
>          a connection in the SYN-RECEIVED state).
> 
>       *  If TCP timestamps would not be enabled for the new incarnation
>          of the connection, but the Sequence Number of the incoming SYN
>          request (creating a connection in the SYN-RECEIVED state).

Better?

>   k (kilo) and B -> bytes in letters)

I will change it to "kilobytes/second".

>    which results in monotonically-increasing timestamps across

You're right. Thanks for catching this one! -- Will fix it.

>  - 8.2 page 9 [INFOCOM-99] and [Silbersack]]: ' .' -> '.'

These will be fixed by the RFC-Ed... (they usually play xml tricks to
make the output look nicer)

Thanks!

Kind regards,