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

[Christer Holmberg <[e-mail]>]

Hi,

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

---------

Regards,

Christer