Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) Heartbeat Extension
draft-ietf-tls-dtls-heartbeat-04
Yes
(David Harrington)
(Jari Arkko)
(Sean Turner)
No Objection
(Dan Romascanu)
(Gonzalo Camarillo)
(Peter Saint-Andre)
(Ralph Droms)
(Robert Sparks)
(Ron Bonica)
(Russ Housley)
(Stephen Farrell)
Note: This ballot was opened for revision 04 and is now closed.
David Harrington Former IESG member
Yes
Yes
()
Unknown
Jari Arkko Former IESG member
(was Discuss)
Yes
Yes
()
Unknown
Sean Turner Former IESG member
Yes
Yes
()
Unknown
Adrian Farrel Former IESG member
(was Discuss)
No Objection
No Objection
(2011-11-02)
Unknown
Section 4 When a HeartbeatRequest message is received, a corresponding HeartbeatResponse message MUST be sent carrying an exact copy of the payload of the HeartbeatRequest. I know what you mean, but several places in the text contradict this by giving cases when a response is not to be sent. --- I wonder why section 5.2 doesn't discuss the question of whether it is necessary to have both ends transmitting heartbeats, or good enough for just one to do it.
Dan Romascanu Former IESG member
No Objection
No Objection
()
Unknown
Gonzalo Camarillo Former IESG member
No Objection
No Objection
()
Unknown
Pete Resnick Former IESG member
No Objection
No Objection
(2011-10-31)
Unknown
Section 3 says, "If no corresponding HeartbeatResponse message has been received after some amount of time, the DTLS/TLS connection MAY be terminated by the user." Who is "the user" in this case? The reason I ask is that I'm afraid this sentence is going to cause some not-so-bright implementers to need instructions like we had to provide in draft-ietf-tcpm-persist, taking it to mean that only an end-user can terminate a DTLS/TLS connection. Do you mean "the application that initiated the HeartbeatRequest can terminate the connection"? Or that "the DTLS/TLS layer can terminate the connection"? A little more clarity here would minimize future stupidity.
Peter Saint-Andre Former IESG member
No Objection
No Objection
()
Unknown
Ralph Droms Former IESG member
No Objection
No Objection
()
Unknown
Robert Sparks Former IESG member
No Objection
No Objection
()
Unknown
Ron Bonica Former IESG member
No Objection
No Objection
()
Unknown
Russ Housley Former IESG member
No Objection
No Objection
()
Unknown
Stephen Farrell Former IESG member
(was Discuss)
No Objection
No Objection
()
Unknown
Stewart Bryant Former IESG member
No Objection
No Objection
(2011-11-03)
Unknown
I agree with Adrian's concerns WRT guidance on message frequency and timeout.
Wesley Eddy Former IESG member
No Objection
No Objection
(2011-11-02)
Unknown
Stephen's DISCUSS seems very important to consider, though I'm no expert in this area, I support Stephen's DISCUSS.