Computing TCP's Retransmission Timer
draft-paxson-tcpm-rfc2988bis-02
Yes
(Adrian Farrel)
(Wesley Eddy)
No Objection
(Pete Resnick)
(Peter Saint-Andre)
(Ron Bonica)
(Russ Housley)
(Stephen Farrell)
Note: This ballot was opened for revision 02 and is now closed.
Adrian Farrel Former IESG member
(was Discuss)
Yes
Yes
()
Unknown
Jari Arkko Former IESG member
Yes
Yes
(2011-04-28)
Unknown
Thank you for writing this. I do agree that the issue raised by Adrian needs to be resolved, however.
Wesley Eddy Former IESG member
Yes
Yes
()
Unknown
Dan Romascanu Former IESG member
No Objection
No Objection
(2011-04-27)
Unknown
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 IESG member
No Objection
No Objection
()
Unknown
Peter Saint-Andre Former IESG member
No Objection
No Objection
()
Unknown
Ralph Droms Former IESG member
No Objection
No Objection
(2011-04-27)
Unknown
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 IESG member
No Objection
No Objection
(2011-04-25)
Unknown
Support Adrian's discuss
Ron Bonica Former IESG member
No Objection
No Objection
()
Unknown
Russ Housley Former IESG member
No Objection
No Objection
()
Unknown
Sean Turner Former IESG member
(was Discuss)
No Objection
No Objection
(2011-04-26)
Unknown
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 IESG member
No Objection
No Objection
()
Unknown
Stewart Bryant Former IESG member
No Objection
No Objection
(2011-04-27)
Unknown
I agree with Adrian's discuss.