Skip to main content

TCP User Timeout Option
RFC 5482

Yes

(Magnus Westerlund)

No Objection

(Chris Newman)
(Dan Romascanu)
(Jari Arkko)
(Lisa Dusseault)
(Mark Townsley)
(Pasi Eronen)
(Ron Bonica)
(Russ Housley)

Recuse

Lars Eggert

Note: This ballot was opened for revision 11 and is now closed.

Lars Eggert Recuse

(Magnus Westerlund; former steering group member) Yes

Yes ()

                            

(Chris Newman; former steering group member) (was Discuss) No Objection

No Objection ()

                            

(Cullen Jennings; former steering group member) No Objection

No Objection (2008-12-17)
I think this is great (as long as it works through firewalls and nats - and support that part of Pasi discuss) but I think that it has to be exposed to apps and support that parts of Chris' discuss.

(Dan Romascanu; former steering group member) (was Discuss) No Objection

No Objection ()

                            

(Jari Arkko; former steering group member) No Objection

No Objection ()

                            

(Lisa Dusseault; former steering group member) No Objection

No Objection ()

                            

(Mark Townsley; former steering group member) No Objection

No Objection ()

                            

(Pasi Eronen; former steering group member) (was Discuss) No Objection

No Objection ()

                            

(Ron Bonica; former steering group member) (was Discuss) No Objection

No Objection ()

                            

(Ross Callon; former steering group member) No Objection

No Objection (2008-12-18)
In the security considerations section, where the document mentions MD5, it should also mention TCP-AO as another option (with an informative reference to TCP-AO).

(Russ Housley; former steering group member) (was Discuss) No Objection

No Objection ()

                            

(Tim Polk; former steering group member) No Objection

No Objection (2008-12-17)
I support Chris's and Pasi's discusses.  The failure rate with middleboxes could present a significant problem unless the TCP stack is clever enough to establish new connections
without using uto after failure.  The onus is clearly on the TCP stack to adjust since the
"communication of timeout information between the TCP stack and application software
has been so poor in the past" to quote Chris's discuss.