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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
