Computing TCP's Retransmission Timer
draft-paxson-tcpm-rfc2988bis-02
Yes
No Objection
Note: This ballot was opened for revision 02 and is now closed.
(Adrian Farrel; former steering group member) (was Discuss) Yes
(Jari Arkko; former steering group member) Yes
Thank you for writing this. I do agree that the issue raised by Adrian needs to be resolved, however.
(Wesley Eddy; former steering group member) Yes
(Dan Romascanu; former steering group member) No Objection
1. I support Adrian's DISCUSS. 2. In the Introduction Section: > In some situations it may be beneficial for a TCP sender to be more conservative than the algorithms detailed in this document allow. However, a TCP MUST NOT be more aggressive than the following algorithms allow. s/TCP MUST NOT/TCP sender MUST NOT/ Also this paragraph should probably be moved to a later section, as it is not common practice to include key-worded statements in the Introduction, and certainly not before the paragraph that explains the role of keywords notations.
(Pete Resnick; former steering group member) No Objection
(Peter Saint-Andre; former steering group member) No Objection
(Ralph Droms; former steering group member) No Objection
I notice the file name for the document is draft-paxson-tcpm-rfc2988bis (not draft-ietf...). I can't tell from the history or the document writeup, so may I assume the document was formally adopted as a working group work item and went through a working group last call?
(Robert Sparks; former steering group member) No Objection
Support Adrian's discuss
(Ron Bonica; former steering group member) No Objection
(Russ Housley; former steering group member) No Objection
(Sean Turner; former steering group member) (was Discuss) No Objection
I support Adrian's discuss. Sec 6: r/This document requires a TCP to wait/This document requires a TCP *sender* to wait ? As noted in the SECDIR review there really needs to be a more overt homage to the security considerations in 5681. Something like the following would suffice: Refer to [RFC5681] for TCP congestion control security considerations.
(Stephen Farrell; former steering group member) No Objection
(Stewart Bryant; former steering group member) No Objection
I agree with Adrian's discuss.