Re: [sipcore] AD review: draft-ietf-sipcore-keep-08

Christer Holmberg <> Mon, 29 November 2010 20:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1365428C108 for <>; Mon, 29 Nov 2010 12:50:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.428
X-Spam-Status: No, score=-6.428 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ossTbP9zPv54 for <>; Mon, 29 Nov 2010 12:50:47 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id DA1D128C0D7 for <>; Mon, 29 Nov 2010 12:50:46 -0800 (PST)
X-AuditID: c1b4fb3d-b7b8cae0000016b1-ca-4cf4126c6085
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 68.12.05809.C6214FC4; Mon, 29 Nov 2010 21:51:56 +0100 (CET)
Received: from ([]) by ([]) with mapi; Mon, 29 Nov 2010 21:51:55 +0100
From: Christer Holmberg <>
To: Robert Sparks <>
Date: Mon, 29 Nov 2010 21:51:55 +0100
Thread-Topic: AD review: draft-ietf-sipcore-keep-08
Thread-Index: AcuP4Cy+gxyrqPJ5SbSwfYR8lEtKLQAI3h59
Message-ID: <>
References: <> <>, <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAA==
Subject: Re: [sipcore] AD review: draft-ietf-sipcore-keep-08
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIP Core Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 29 Nov 2010 20:50:49 -0000


Comments inline ([CHH]).


>>> * Section 4.4 talks about normative server behavior for using
>>> this mechanism with INVITE initiated dialogs.
>>> where is the companion set of normative requirements for
>>> using the mechanism to keep alive a REGISTRATION
>>> flow?
>> [CHH] The 2nd paragraph is the generic rule, which covers both INVITE and REGISTER.
>> The 3rd paragraph is an addition that covers the case where multiple responses are sent to a request, which is INVITE specific.
>> But, maybe to make it more clear, and based on your comment on section 5 (see further down), I could rewrite the 3rd paragraph:
>> "There might be multiple responses to an INVITE request.
>> When a SIP entity indicates willingness to receive keep-alives in a
>> response to an INVITE request, it MUST add a parameter value to the
>> "keep" parameter in at least one reliable response to the request. The SIP entity MAY
>> add identical parameter values  to the "keep" parameters in other responses to the
>> same request.  The SIP entity MUST NOT add different parameter value to the "keep"
>> parameters in responses to the same request. The SIP entity SHOULD indicate
>> the willingness to receive keep-alives as soon as possible."
>This text is better, but it uncovers another issue. For these keep-alives associated with
>a dialog, you need to adjust the text to reflect responses _in that dialog_. In the presence
>of forking, you may have multiple 183s from different branches (or multiple 200 OKs from
>different branches. If the keep-alive activity is intended to be associated with the dialogs
>(which is what I think the text is currently trying to do), you need to adjust to note that the
>element needs to include its keep value as early as possible on each dialog, and note that
>the keep-alive messages will be sent reflecting each dialog that was set up.
>An alternative is to negotiate one keepalive stream per 5-tuple, using a reference count
>(you stop when the last dialog using the 5-tuple terminates), but that seems pretty error-prone.

[CHH]  I suggest the following modification (<new>...</new>)

"The SIP entity MUST NOT add different parameter value to the "keep" parameters in responses
to the same request.  The SIP entity SHOULD indicate the willingness to receive keep-alives<new>, for 
each dialog on which it is willing the receive keep-alives,</new> as soon as possible."


>>>* Section 6's first paragraph says "Entities that want to
>>>reuse connections MUST use a another mechanism".
>>>(Note the spurious 'a'). Why is this a 2119 MUST? I
>>>suggest saying "would need to" instead.
>>[CHH] Done.
>>The reason behind the "MUST" was to clearly indicate that keep as such is not a connection reuse mechanism.
>That's an incorrect use of the 2119 term.
>I can't test implementation of that requirement - there's no way to account for it in an interoperability report, and there's
>no good reference to what an implementer would need to read in order to satisfy the requirement. You are really just
>trying to say this mechanism doesn't provide connection reuse. Just say that.

[CHH] Done.

"Entities that want to reuse connections need to use another mechanism to ensure
that security aspects associated with connection reuse are taken into consideration."