Ballot for draft-ietf-sipcore-event-rate-control-09

Session Initiation Protocol (SIP) Event Notification Extension for Notification Rate Control
RFC 6446

Note: This ballot was opened for revision 05 and is now closed.

Summary: Needs a YES. Has enough positions to pass.

Adrian Farrel

Comment (2010-12-02)

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

Jari Arkko

Comment (2010-12-02)

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.

[Dan Romascanu]

Comment (2010-12-16)

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

[Lars Eggert]

Comment (2010-11-30)

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.

[Ralph Droms]

Comment (2011-09-01)