TCP User Timeout Option
draft-ietf-tcpm-tcp-uto-11
Yes
(Magnus Westerlund)
No Objection
(Chris Newman)
(Dan Romascanu)
(Jari Arkko)
(Lisa Dusseault)
(Mark Townsley)
(Pasi Eronen)
(Ron Bonica)
(Russ Housley)
(Tim Polk)
Recuse
(Lars Eggert)
Note: This ballot was opened for revision 11 and is now closed.
Magnus Westerlund Former IESG member
Yes
Yes
()
Unknown
Chris Newman Former IESG member
(was Discuss)
No Objection
No Objection
()
Unknown
Cullen Jennings Former IESG member
No Objection
No Objection
(2008-12-17)
Unknown
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 IESG member
(was Discuss)
No Objection
No Objection
()
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
()
Unknown
Lisa Dusseault Former IESG member
No Objection
No Objection
()
Unknown
Mark Townsley Former IESG member
No Objection
No Objection
()
Unknown
Pasi Eronen Former IESG member
(was Discuss)
No Objection
No Objection
()
Unknown
Ron Bonica Former IESG member
(was Discuss)
No Objection
No Objection
()
Unknown
Ross Callon Former IESG member
No Objection
No Objection
(2008-12-18)
Unknown
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 IESG member
(was Discuss)
No Objection
No Objection
()
Unknown
Tim Polk Former IESG member
No Objection
No Objection
(2008-12-17)
Unknown
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.
Lars Eggert Former IESG member
Recuse
Recuse
()
Unknown