TCP User Timeout Option
RFC 5482
Yes
No Objection
Recuse
Note: This ballot was opened for revision 11 and is now closed.
Lars Eggert Recuse
(Magnus Westerlund; former steering group member) Yes
(Chris Newman; former steering group member) (was Discuss) No Objection
(Cullen Jennings; former steering group member) No Objection
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
(Jari Arkko; former steering group member) No Objection
(Lisa Dusseault; former steering group member) No Objection
(Mark Townsley; former steering group member) No Objection
(Pasi Eronen; former steering group member) (was Discuss) No Objection
(Ron Bonica; former steering group member) (was Discuss) No Objection
(Ross Callon; former steering group member) No Objection
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
(Tim Polk; former steering group member) No Objection
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.