Note: This ballot was opened for revision 05 and is now closed.
Summary: Needs a YES. Needs 8 more YES or NO OBJECTION positions to pass.
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
none of the event package specifications have defined such a
Section 3.4 Req 7
For example, due to congestion reasons, local policy at
In general, the way in which a subscriber generates SUBSCRIBE
requests and processes NOTIFY requests is according to RFC 3265
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].
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
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.
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
min-interval-param = "min-interval" EQUAL delta-seconds
The "delta-seconds" token is not defined.
Comment (2010-12-16 for -)
I support the issues raised by David and Alexey in their DISCUSSes
Comment (2010-11-30 for -09)
Section 3.4., paragraph 7:
> paremeters are adjusted from the value given by the
Section 7.1., paragraph 4:
> The main consequence for the subscriber when applying the adative
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.
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 [...]"