Subject: [sipcore] WGLC: draft-ietf-sipcore-keep

From: Adam Roach <[email-masked]>
Date: Wed, 14 Jul 2010 09:02:13 -0500

[as chair]

The author of draft-ietf-sipcore-keep believes that the document has no 
remaining open issues, and is ready to be evaluated by the IESG for 
publication. Today, we begin a three-week Working Group Last Call 
period, which ends on Wednesday, August 4th. (This WGLC is three weeks 
instead of the more traditional two to account for the upcoming IETF 
meeting).

The latest version of the document can be retrieved here:

http://tools.ietf.org/html/draft-ietf-sipcore-keep

Any comments on the document should be sent to the SIPCORE mailing list.

As a note to document reviewers: the document's author is on holiday 
through August 2nd, and will respond to any direct queries after returning.

/a

---

From: Adam Roach <[email-masked]>
Date: Fri, 16 Jul 2010 10:55:46 -0500

As an addendum: if you have read the document and think it is ready 
for publication, please send an email to the list indicating this fact. 
We can't request publication if the WG hasn't taken a good look at the 
document.

/a

On 7/14/10 9:02 AM, Adam Roach wrote:
>  [as chair]
>
> The author of draft-ietf-sipcore-keep believes that the document has 
> no remaining open issues, and is ready to be evaluated by the IESG for

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 19 Jul 2010 15:57:01 +0200

This has some minor issues that need fixing before it is ready to go.

1. In 4.2.2: ".  Once negotiated, keep-
   alives are sent until the registration is terminated, or until a
   subsequent registration refresh request is sent or forwarded.  When a
   subsequent registration refresh request is sent or forwarded, if a
   SIP entity is willing to continue sending keep-alives associated with
   the registration, usage of keep-alives MUST be re-negotiated.  If
   usage is not successfully re-negotiated, the SIP entity MUST cease
   sending of keep-alives associated with the registration."
Yet in 4.2.3:
"Once negotiated, keep-alives MUST
   be sent for the lifetime of the dialog, until the dialog is
   terminated.  Once usage of keep-alives associated with a dialog has
   been negotiated, it is not possible to re-negotiate the usage
   associated with the dialog."
There seems to be inconsistency between registrations and dialogs. For a registration, keep-alive can be terminated when the registration is refreshed, whereas for a dialog there is no way to terminate keep-alives (without terminating the dialog). Would it not be better to align the two? The use case for being able to negotiate no keep-alives during a registration that is already using keep-alives is not clear. It might be simpler to say that, once keep-alive has been negotiated, it remains in place for the duration of the registration or dialog.

2. "When the SIP entity receives the associated response, if the "keep"
   parameter in its Via header field of the response contains a
   parameter value, it MUST start to send keep-alives towards the same
   destination where it would send a subsequent request (e.g.  REGISTER
   requests and initial requests for dialog) associated with the
   registration (if the keep-alive negotiation is for a registration),
   or where it would send subsequent mid-dialog requests (if the keep-
   alive negotiation is for a dialog)."
This sentence is rather long. But my main concern is with the dialog-initiating case. Whilst "where it would send subsequent mid-dialog requests" is correct, that is not necessarily where the Via header field entry with 'keep' has come from. Or putting it another way, if a non-record-routing proxy were to include 'keep', sending keep-alives towards that proxy would be pointless. Of course, a non-record-routing proxy should not include 'keep'. In this case the first mid-dialog request should contain 'keep' again, and if the response to that also contains 'keep' (with a value) then keep-alives can start.
So although the 'keep' in Via in principle works for both registrations and dialogues, there are subtle differences. The present wording doesn't seem to be wrong, but it certainly doesn't convey the real situation very satisfactorily, IMO. It might be useful to have separate statements for registrations and dialogs. It might also be useful to state that a non-record-routing proxy MUST NOT insert 'keep' (probably more appropriate in 4.4).

3. "Once a SIP entity has negotiated sending of keep-alives associated
   with a dialog towards its adjacent upstream SIP entity, it MUST NOT
   insert a "keep" parameter in any subsequent SIP requests associated
   with the dialog."
This doesn't seem to be quite correct. A sends 'keep' to B on a dialog-forming request. B does not record route. A sends mid-dialog request to C. Surely in this case, A needs to be able to include 'keep'? But this text seems to forbid it.

A note further down seems to cover the points I made in 2 and 3 above, but I don't think that is satisfactory. In particular, using a note to contradict a MUST NOT is incorrect.

4. "NOTE: If a SIP entity inserts a "keep" parameter in its Via header
   field of an INVITE request, and it receives multiple responses
   (provisional or final) associated with the request, as long as at
   least one of the responses, per dialog, contains a "keep" parameter
   with a parameter value it is seen as an indication that the adjacent
   upstream SIP entity is willing to receive keep-alives associated with
   the dialog."
This isn't incorrect, but it is hard to work out what it means. If there is a dialog-forming response, and then further responses on that same dialog, then 'keep' in any one of these should be sufficient. But if there are multiple dialog-forming responses, then 'keep' on any one of these will (I assume) apply only to that dialog, and not other dialogs formed by other responses. I think there is room for stating this more clearly.

5. In 4.3: "The SIP entity must support the amount of STUN
   which is required to apply the STUN keep-alive mechanism defined in
   [RFC5626], and it must support the CRLF keep-alive mechanism defined
   in [RFC5626]."
I assume the use of lower case "must" (two instances) is motivated by the belief that we are repeating what is in RFC 5626. However, I don't think that is correct - we are stating new normative requirements (i.e., to apply the mechanisms in RFC 5626 to the cases covered by this I-D). Therefore I think we should use "MUST" in each case. Similarly in 4.4.

6. The Security Considerations section merely states: "This specification does not introduce security considerations in
   addition to those specified in [RFC5626]."
Considering the I-D addresses dialogs, not just registrations, it sounds like this statement might not be sufficient. For example, if a dialog hop crosses a firewall, use of keep-alive is likely to keep the firewall pin-hole open for an extended period. I leave it to the security experts to determine whether this is an issue.

7. In section 3: ""keep" parameter: A SIP Via header field parameter that a SIP entity
   can insert in its Via header field of a request to explicitly
   indicate willingness to send keep-alives towards it adjacent upstream
   SIP entity.  If a SIP entity is willing to receive keep-alives from
   its adjacent downstream SIP entity, and the Via header field
   associated with the adjacent downstream SIP entity contains a "keep"
   parameter, the SIP entity willing to receive keep-alives can add an
   integer parameter value to that "keep" parameter.  The integer
   parameter value can be used to indicate a recommended keep-alive
   frequency.  A zero value indicates that the SIP entity is willing to
   receive keep-alives, but that a recommended keep-alive frequency is
   not provided."
This seems top be far too much for a definition. Some of the material should instead be covered later in the document (and I suspect it already is).

Nits:
N1. Change "Eventhough" to "Even though".

N2. "since usage of keep-alives in most cases are implicitly
   negotiated"
Change "are" to "is".

N3. "usage of keep-alives
   are not implicitly negotiated"
Change "are" to "is".

N4. "usage keep-alives". Change to "usage of keep-alives".

N5: "why usage needs to be
   explicitly negotiated."
The word "why" seems to be wrong. Should it be "where"?

N6: "towards it adjacent upstream
   SIP entity"
Change "it" to "its".

N7: "the amount of STUN
   which is required" (two instances)
In each case, change to "those aspects of STUN that are required".

John

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Adam Roach
> Sent: 14 July 2010 15:02
> To: SIPCORE
> Cc: [email-masked]; 
> [email-masked]
> Subject: [sipcore] WGLC: draft-ietf-sipcore-keep
> 
>   [as chair]
> 
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: Adam Roach <[email-masked]>
Date: Sat, 24 Jul 2010 16:49:46 +0200

Reminder: we're in the last week of the WGLC for this document. If you 
want to see it published, you need to read it and comment on this list 
(even if your comment is only "it looks ready to publish to me.")

We have had exactly one person provide feedback so far.

/a

On 7/16/10 5:55 PM, Adam Roach wrote:
> for publication, please send an email to the list indicating this 
> fact. We can't request publication if the WG hasn't taken a good look 
> at the document.
>
> /a
>
>> no remaining open issues, and is ready to be evaluated by the IESG 
>> for publication. Today, we begin a three-week Working Group Last Call 
>> period, which ends on Wednesday, August 4th. (This WGLC is three 
>> weeks instead of the more traditional two to account for the upcoming 
>> IETF meeting).
>>