datatracker.ietf.org
Sign in
Version 5.3.0, 2014-04-12
Report a bug

Indication of Support for Keep-Alive
RFC 6223

Note: This ballot was opened for revision 11 and is now closed.

Summary: Needs a YES. Needs 9 more YES or NO OBJECTION positions to pass.

Adrian Farrel

Comment (2011-01-17)

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.

[Alexey Melnikov]

Comment (2011-01-12)

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.

[Peter Saint-Andre]

Comment (2011-01-10)

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]

Comment (2011-01-20)

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/