Skip to main content

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 steering group member) (was Discuss) Yes

Yes ()

                            

(Jari Arkko; former steering group member) Yes

Yes (2011-04-28)
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

Yes ()

                            

(Dan Romascanu; former steering group member) No Objection

No Objection (2011-04-27)
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

No Objection ()

                            

(Peter Saint-Andre; former steering group member) No Objection

No Objection ()

                            

(Ralph Droms; former steering group member) No Objection

No Objection (2011-04-27)
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

No Objection (2011-04-25)
Support Adrian's discuss

(Ron Bonica; former steering group member) No Objection

No Objection ()

                            

(Russ Housley; former steering group member) No Objection

No Objection ()

                            

(Sean Turner; former steering group member) (was Discuss) No Objection

No Objection (2011-04-26)
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

No Objection ()

                            

(Stewart Bryant; former steering group member) No Objection

No Objection (2011-04-27)
I agree with Adrian's discuss.