Re: [sipcore] draft-ietf-sipcore-keep - Peter's comments

[Christer Holmberg <[e-mail]>]

Hi Peter, 

Some proposed new/modified text based on your comments.

>>I have read draft-ietf-sipcore-keep in detail for the first time.
>>
>>I have one questions and some Nits.
>>
>>Question: 7.3 Should the TRYING (not shown) from P1 to Alice have 
>>keep=30 in it? What if the 200 OK takes e.g. longer than 30sec and the 
>>NAT pinhole closes?
> 
>It is true that the flow only shows the 200 OK, but the text 
>in section 4.4 responses in general.
> 
>I guess we could add some text that points out that the keep 
>value should be sent as soon as possible, as it may take a 
>while before the final response is sent.

What about the following new text in section 4.4.

	"In the case of an INVITE request, if a SIP entity sends or forwards multiple responses (provisional and final) associated with the 
	request, and it indicates willingness to receive keep-alives, it only needs to insert a "keep" parameter value in one of the responses. The
	SIP entity SHOULD indicate the willingess to receive keep-alives as soon as possible."

--------------
 
>Nits
>1. s/Eventhough/Even though/
>
>1.3 "As specified in [RFC5626], usage keep-alives is not implicitly 
>negotiated for such flows, why usage needs to be explicitly 
>negotiated." Re-phrase?
>
>4.2.1 s/The section/This section/
>
>4.4 para 2. This paragraph is one sentence. I read it many 
>times - I gave up.

I tried to make the paragraph more readable. It still contain a long sentence, but please let me know if it's easier to understand now:

	"When a SIP entity creates or receives a response, and the adjacent downstream SIP entity that sent the associated request indicated 
	willingness to send keep-alives, if the SIP entity is willing to receive keep-alives associated with the registration (in case of 
	a REGISTER response), or the dialog (in case of a response to an initial request for a dialog, or a response to a mid-dialog 
	target refresh request), from the adjacent downstream SIP entity it MUST add a parameter value to the "keep" parameter, before sending 
	or forwarding the response. The parameter can contain a recommended keep-alive frequency, or a zero value."

Regards,

Christer