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 protected]> 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 > > On 2010-12-10, at 11:23, Francis Dupont wrote: > >> (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 > > -- Fernando Gont e-mail: [email protected] || [email protected] PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
