Session Initiation Protocol (SIP) Event Notification Extension for Notification Rate Control
Summary: Needs a YES. Needs 9 more YES or NO OBJECTION positions to pass.
Note: This ballot was opened for revision 05 and is now closed.
( Robert Sparks ) Yes
Jari Arkko No Objection
Comment (2010-12-02 for -)
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.
( Ron Bonica ) No Objection
( Stewart Bryant ) No Objection
( Gonzalo Camarillo ) No Objection
( Ralph Droms ) (was Discuss) No Objection
Comment (2011-09-01 for -09)
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 [...]"
( Lars Eggert ) (was Discuss) No Objection
Comment (2010-11-30 for -09)
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.
( Adrian Farrel ) No Objection
Comment (2010-12-02 for -)
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].
( David Harrington ) (was Discuss) No Objection
( Russ Housley ) No Objection
( Alexey Melnikov ) (was Discuss) No Objection
( Tim Polk ) No Objection
( Dan Romascanu ) No Objection
Comment (2010-12-16 for -)
I support the issues raised by David and Alexey in their DISCUSSes