Indication of Support for Keep-Alive
Note: This ballot was opened for revision 12 and is now closed.
(Robert Sparks) Yes
(Ron Bonica) No Objection
(Stewart Bryant) No Objection
(Gonzalo Camarillo) No Objection
(Ralph Droms) No Objection
(Lars Eggert) No Objection
(Adrian Farrel) No Objection
Comment (2011-01-17 for -)
I found this a clear and well-written document, thanks. I have two smal points I would like the authors to think about, but nothing that blocks publication. Section 1.2 In some cases all SIP entities that need to be able to negotiate the usage of keep-alives might not support SIP Outbound. However, they might still support the keep-alive mechanisms defined in SIP Outbound, and need to be able to negotiate usage of them. Do you actually mean... In some cases not all SIP entities that need to be able to negotiate the use of keep-alives might support SIP Outbound. However, they might still support the keep-alive mechanisms defined in SIP Outbound, and need to be able to negotiate usage of them. Or maybe more elegant as... In some cases some SIP entities that need to be able to negotiate the use of keep-alives might not support SIP Outbound. However, they might still support the keep-alive mechanisms defined in SIP Outbound, and need to be able to negotiate usage of them.
(Russ Housley) No Objection
Alexey Melnikov No Objection
Comment (2011-01-12 for -)
I read the whole document and in general I don't have any objections to publishing it as an RFC. However I have a minor complain: 8. Grammar This specification defines a new Via header field parameter, "keep". The ABNF [RFC5234] is: via-params =/ keep keep = "keep" [ EQUAL 1*(DIGIT) ] This doesn't tell me where
, or is defined. Please add the references as either ABNF comments or in the text before the grammar.
(Tim Polk) No Objection
(Dan Romascanu) No Objection
(Peter Saint-Andre) No Objection
Comment (2011-01-10 for -)
This is a fine document. I have only a few comments. 1. In second paragraph of the Security Considerations, please spell out "TLS" and "DTLS" on first use and add informative references for the relevant specifications. 2. In the fourth paragraph of the Security Considerations, the specification says that a SIP entity MUST stop sending keep-alive requests if it does not receive responses to the STUN keep-alives that it sends to an adjacent downstream SIP entity. However, this does not take into account the fact that STUN requests and responses could be dropped, so it would be good to provide some more specific guidance here, e.g., stop sending STUN keep-alive requests if no STUN responses are received after sending two or more STUN requests (it seems suboptimal to stop sending STUN keep-alive requests if no response is received to only the very first STUN keep-alive request). Furthermore, no guidance is provided about the number of seconds the sender should wait before concluding that the adjacent downstream SIP entity has not responded. If these matters are covered in RFC 5389 then it would be helpful to cite the specific sections where they are discussed (e.g., Section 7.2.1 regarding retransmission timeouts).
(Sean Turner) No Objection
Comment (2011-01-20 for -)
Juergen Schoenwaelder spotted two editorial nits in the security considerations during his SECDIR review: a) [...] This specification does not specify a connection reuse mechanism, and it does it address security issues related to connection reuse. [...] s/it does it/it does not/ b) [...] They do not instruct the enity to place a value in a "keep" parameter of any request it forwards. [...] s/enity/entity/