Re: [sipcore] AD review: draft-ietf-sipcore-event-rate-control-03

[<[e-mail]>]

Hi,

Both suggestions sound good to me. Once the I-D submission tool reopens, we can incorporate these changes in -05.

Thanks,
Krisztian

-----Original Message-----
From: ext Robert Sparks [mailto:[e-mail]] 
Sent: 2010. július 13. 15:23
To: Kiss Krisztian (Nokia-CD/MtView)
Cc: [e-mail]
Subject: Re: [sipcore] AD review: draft-ietf-sipcore-event-rate-control-03

A couple more observations inline (and I'm trimming away things I'm not replying to here):

On Jul 12, 2010, at 7:13 PM, [e-mail] wrote:

> Hi Robert,
> 
> I submitted the -04 version today addressing your comments: http://www.ietf.org/id/draft-ietf-sipcore-event-rate-control-04.txt 
> 
> Please find my answers in-line with [KK]:

<snip>

> 
> Is there text here that prevents a subscriber
> from generating Event headers in 200 OKs to NOTIFYs mid-subscription (when he
> didn't probe for support using the SUBSCRIBE?) How would they know the request
> got honored?  The possibility of running into implementations that break should
> be called out.  
> 
> [KK] I added text in -04 to address this: 
> Section 4.1: "If the Event header field of the SUBSCRIBE request did not include the "min-interval" parameter, the subscriber MUST NOT include an initial value of the "min-interval" Event header field parameter in a 200-class response to the NOTIFY request." 
> Section 4.2: "If the Event header field of the SUBSCRIBE request did not include the "min-interval" parameter, the notifier MUST ignore an initial value of the "min-interval" Event header field parameter in a 200-class response to the NOTIFY request, if present."
> ...and similar text covering max-interval and average-interval mechanisms.

These changes (and the associated changes in 5.1, 5.2, 6.1, and 6.2) are too granular and introduce the possibility of edge cases I don't think we should introduce.

It would be much simpler to say:
 
If the subscriber did not include at least one of the "min-interval, "max-interval", or "average-interval" header field parameters in the most recent SUBSCRIBE request in a given dialog, it MUST NOT include an Event header field with any of those parameters in a 200 OK to a NOTIFY in that dialog.

> 
> * Section 3.2 last paragraph: The sentence 'The "max-interval" parameter 
>      indicates ... complete state information' is difficult to parse. Could it
>      be simplified?

The new sentence you propose is even harder for me to read.

Here's some suggested text:

The "max-interval" parameter indicates to the notifier the maximum amount of time that should be allowed to elapse between NOTIFY requests containing complete state information.


RjS