Hi, Francis, Thanks so much for your feedback! Please find my comments inline....
> 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) These have been published "as is" in previous RFCs I have authored... > - 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"? The term "a TCP" is usually employed as a short form for "a TCP instance" > - 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. 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 > 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 (creating a connection in the SYN-RECEIVED state). Better? > - 2 page 6: KB/s -> kbytes/s or kilobytes/s (at least K (Kelvin) -> > k (kilo) and B -> bytes in letters) I will change it to "kilobytes/second". > - 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 You're right. Thanks for catching this one! -- Will fix it. > connections that are not easily-predictable by an off-path attacker." > > - 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, -- 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
