Session Initiation Protocol (SIP) Event Notification Extension for Notification Rate Control
draft-ietf-sipcore-event-rate-control-09

Just a few nits in a document I found otherwise to be very readable.

idnits points out...

  -- The document has a disclaimer for pre-RFC5378 work, but was first
     submitted on or after 10 November 2008.  Does it really need the
     disclaimer?

---

Section 1

   none of the event package specifications have defined such a
   mechanism.
                                                                              
s/have/has/

---

Section 3.4 Req 7
                                              
              For example, due to congestion reasons, local policy at

s/due/owing/

---

Section 4.1                                                                     

   In general, the way in which a subscriber generates SUBSCRIBE
   requests and processes NOTIFY requests is according to RFC 3265
   [RFC3265].

"In general"?

Similarly in section 4.2

   In general, the way in which a notifier processes SUBSCRIBE requests
   and generates NOTIFY requests is according to RFC 3265 [RFC3265].

I support the issues raised by David and Alexey in their DISCUSSes

I have reviewed this document and placed a no-objection vote, even if I do agree with most of the issues raised by Lars and David. I do think though that despite its problems and complexity, the document is understandable enough to be reviewed. I think the right path is to fix the specific issues in the document rather than to bring the document back to the working group. I do think that the document should stick to using either rate or frequency terminology, however.

Also, here are some review comments from Ari Keränen who I asked to take another look at the document:

The abstract should state that this document updates RFC 3265.


5.1.  Subscriber Behavior

    The value of
    this parameter is an integral number of seconds in decimal.

Should that be "decimal integer"? And probably negative values are not 
OK (should be stated), but how about zero? Same issue in sections 6.1. 
and 7.1.


7.3.  Calculating the Timeout

    timeout = (average-interval ^ 2) * count / period              (1)

It's not really immediately clear how this formula results in correct 
timeouts. Say, if one uses average-interval of 10s and period of 100s, 
based on quick calculation, it seems that the timeouts would be 
0,1,2,...,9 for the first 10 (batches of) messages (10*10*0/100, 
10*10*1/100, ...) resulting in all 10 messages being sent during the 
first 45 seconds (as opposed to 100 seconds); or didn't I get the 
formula right?

9.2.  Grammar

       min-interval-param =   "min-interval" EQUAL delta-seconds

The "delta-seconds" token is not defined.

Section 3.4., paragraph 7:
>            paremeters are adjusted from the value given by the

  Nit: s/paremeters/parameters/


Section 7.1., paragraph 4:
>    The main consequence for the subscriber when applying the adative

  Nit: s/adative/adaptive/


Section 7.3., paragraph 5:
>    period:  The rolling average period, in seconds.  The value of the
>       "period" parameter is chosen by the notifier, however the notifier
>       MUST choose a value greater than the value of the "average-
>       interval" parameter.

  Additionally, period should be several times larger than the
  average-interval, because otherwise, not much averaging will happen -
  the mechanism degrades to the non-adaptive variant.

I've cleared my Discuss.

There is something wrong with this phrase in the text from section 8
that I quoted above: "This combination allows to reduce [...]"