(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 protected] _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
