Indication of Support for Keep-Alive
draft-ietf-sipcore-keep-12

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.

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 <via-params>, <EQUAL> or <DIGIT> is defined. Please add the references as either ABNF comments or in the text before the grammar.

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).

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/