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

[Ballot discuss]
1) The document defines max-rate, but never specifies the acceptable range of the values.

"The value of this parameter is a positive real number given by a finite decimal representation."
No (reasonable) range is specified in the document, like 0 .. 5, or 0 .. 65535.
So, can I specify a min-rate of 123456789012345678901234567890.33333333333333333333333333 per second?
It appears to comply with the definition you provide.
I'm not sure how many bits are in that number. Are all compliant implementations REQUIRED to be able to support a value of  this size, and this level of precision? and even larger numbers?

[Ballot discuss]
1) The document defines max-rate, but never specifies the acceptable range of the values.

"The value of this parameter is a positive real number given by a finite decimal representation."
No (reasonable) range is specified in the document, like 0 .. 5, or 0 .. 65535.
So, can I specify a min-rate of 123456789012345678901234567890.33333333333333333333333333 per second?
It appears to comply with the definition you provide.
I'm not sure how many bits are in that number. Are all compliant implementations REQUIRED to be able to support a value of  this size, and this level of precision? and even larger numbers?

[Ballot comment]
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 [...]"

[Ballot discuss]
Updated based on rev -08


The definitions of the various rate parameters are now stated as a
number of events per second, which is consistent with the intuitive
interpretation of the parameters as rates.

However, I'm concerned that there is not a definition of the way in
which the rates, expressed as notfications per second, would be
measured.  How would compliance with a specification for "1.5
notifications per second" or "0.05 notifications per second be
measured?  Would the transmission of exactly 1 notification over any
twenty second interval be equivalent to 0.05 notifications per second
for compliance purposes?  Or 5 notifications over any 100 second
interval?

This note in section 5 still appears to refer to an interval rather
than a rate.

5.1.  Subscriber Behavior

    A subscriber that wishes to apply a maximum rate to notifications in
    a subscription MUST construct a SUBSCRIBE request that includes the
    "max-rate" Event header field parameter.  This parameter specifies
    the requested maximum number of notifications per second.  The value
    of this parameter is a positive real number given by a finite decimal
    representation.

      Note that the witnessed time between two consecutive received
      notifications may not conform to the "max-rate" value for a number
      of reasons.  For example, network jitter and retransmissions may
      result in the subscriber receiving the notifications more frequent
      than the "max-rate" value recommends.

There are other instances of text that appear to refer to an interval
rather than a rate; e.g., the last sentence in this paragraph from
section 5.2:

    A compliant notifier MUST NOT generate notifications more frequently
    than the maximum rate allows for, except when generating the
    notification either upon receipt of a SUBSCRIBE request (the first
    notification), when the subscription state is changing from "pending"
    to "active" state or upon termination of the subscription (the last
    notification).  Such notifications reset the timer for the next
    notification.

Would this text correctly replace the last sentence:

    Such notifications reset the measurement interval for maximum rate
    measurement.

This text from section 8 also refers to an interval:

    maximum rate and minimum rate:  This combination allows to reduce the
      notification rate, but at the same time assures the reception of a
      notification every time the most recent notification exceeds a
      specified interval.

Without a definition of how a rate of 0.05 notifications per second
translates to a maximum interval, I don't think the combination of a
maximum rate and a minimum rate can lead to the assertion.

[Ballot discuss]
updated to -08-

1) The document defines max-rate, but never specifies the acceptable range of the values.

"The value of this parameter is a positive real number given by a finite decimal representation."
No (reasonable) range is specified in the document, like 0 .. 5, or 0 .. 65535.
So, can I specify a min-rate of 123456789012345678901234567890.33333333333333333333333333 per second?
It appears to comply with the definition you provide.
I'm not sure how many bits are in that number. Are all compliant implementations REQUIRED to be able to support a value of  this size, and this level of precision? and even larger numbers?

2) I support Ralph's discuss concerning the problems of using a fraction to specify rate, rather than using integers to specify intervals.

I think using decimal numbers, rather than integers, is equally problematic.
I think this specification allows me to set a minimum rate of 1.5 per second, and a maximum of 1.7 per second. I know how to send the 1.0; how do I send the other 0.5? As Ralph pointed out, how do you test compliance?

Would it make sense to use a max-rate of one per  per 1 second?

[Ballot discuss]
updated to -07- (including numbering)

1) The document defines max-rate, but never specifies the acceptable range of the values.

2) I support Ralph's discuss concerning the problems of using a fraction to specify rate, rather than using integers to specify intervals.

[Ballot discuss]
Updated based on rev -07

In my opinion, the changes in rev -07 correct the issues related to
"rate" versus "interval", but introduce an important new problem: the
"rate" is specified as a fraction of messages per second, and the
descriptive text explains the parameter as an interval rather than a
rate.

For example, in section 5.1:

  This parameter specifies
  the requested maximum number of notifications per second that is
  equivalent to the reciprocal value of the minimum time interval
  between two consecutive notifications.  The value of this parameter
  is a positive decimal fraction measured in 1/seconds.  For example,
  when the subscriber wants to receive notifications no more frequently
  than once in every seven seconds, then it sets the value of the "max-
  rate" parameter to 1/7.

I don't know how I would determine conformance to this spec by
measuring a maximum rate of 1/7 of a message per second.  And, I don't
think it's possible to set the maximum rate to more than 1 message per
second with this encoding.

If the desired behavior is a minimum or maximum interval - which is
likely easier to implement and test - why not define the parameters as
minimum and maximum intervals and refer to those itnervals throughout
the spec?

[Ballot discuss]
updated to -06- (including numbering)

A number of changes were made to the document, but a number of issues have not been addressed yet.

1) The document defines max-rate, min-rate, and adaptive-min-rate parameters, but the text refers to the "max-interval parameter" and "min-interval parameter" multiple times.

2) The document defines max-rate, but never specifies the acceptable range or format of the values.

3) section 1 defines max-rate, and equates it to min-interval:
  max-rate:  specifies a maximum rate of notifications (a minimum time
      period between two notifications).
This is incorrect; max-rate does not specify the minimum time period between two notifications. Max-rate refers to the ratio of the number of notifications per minimum time period. - maximum rate refers to a numerator/denominator ratio, while minimum time period refers only to the denominator.

the same problem exists for the other two definitions as well.

4) in 5.5.1, how does one determine the relative sizes of the partial and full state notifications? Is there a specification that defines the size of a full state notification? The partial state contains values that are differences between two full states. Can the size of the partial state be greater than the size of the full state, when the partial contains only the differences between two full states - the current full state and the last successfully communicated full state? And I note that section 5.6 says explicitly "However, even in the worst case scenario, where each partial update is to a different part of the full state, a rate controlled notification merging all of these n partial states together should at a maximum be the size of a full-state update." So why SHOULD implementations check whether the partial state notification is smaller than the full state notification?

5) As with all SHOULDs, what is the acceptable exception to not checking this? What are the full implications if a notifier sends a partial notification instead of a full notification when the partial and full are the same size? (If the partial can never be bigger than the full, and the only time you would substitute a full for a partial is when the partial is not smaller than the full, then they must be the same size) I assume the subsequent baseline would be changed when the full was sent, and not when the partial was sent. Is there a significant operational impact from this happening, that doesn't occur using "accumulated" partials anyway? If there are implications, why is this not a MUST?

6) What is an accumulated partial state notification? where is this defined? It is mentioned in 5.5.1, but never defined.
Can an accumlated partial state notification contain multiple instances of the same item sampled at different times within the rate window?

7) With partial notifications, the notifier needs to maintain a separate buffer for each subscriber since each subscriber may have a different value for the maximum rate of notifications. How large a buffer is required of compliant implementations? How many subscriptions must a compliant implementation support? What happens if an implementation runs out of buffer space? (note that this partial-notification requirement is not discussed in terms of operational considerations, or in terms of possible DoS under security considerations, including those of RFC 5263)

[Ballot discuss]
updated to -06- (including numbering)

A number of changes were made to the document, but a number of issues have not been addressed.

1) The document defines max-rate, min-rate, and adaptive-min-rate parameters, but the text refers to the "max-interval parameter" and "min-interval parameter" multiple times.

2) The document defines max-rate, but never specifies the acceptable range or format of the values.

3) section 1 defines max-rate, and equates it to min-interval:
  max-rate:  specifies a maximum rate of notifications (a minimum time
      period between two notifications).
This is incorrect; max-rate does not specify the minimum time period between two notifications. Max-rate refers to the ratio of the number of notifications per minimum time period. - maximum rate refers to a numerator/denominator ratio, while minimum time period refers only to the denominator.

the same problem exists for the other twio definitions as well.


4) in 5.5.1, how does one determine the relative sizes of the partial and full state notifications? Is there a specification that defines the size of a full state notification? The partial state contains values that are differences between two full states. Can the size of the partial state be greater than the size of the full state, when the partial contains only the differences between two full states - the current full state and the last successfully communicated full state? And I note that section 5.6 says explicitly "However, even in the worst case scenario, where each partial update is to a different part of the full state, a rate controlled notification merging all of these n partial states together should at a maximum be the size of a full-state update." So why SHOULD implementations check whether the partial state notification is smaller than the full state notification?

dbh: update to -06- to be continued

5) As with all SHOULDs, what is the acceptable exception to not checking this? What are the full implications if a notifier sends a partial notification instead of a full notification when the partial and full are the same size? (If the partial can never be bigger than the full, and the only time you would substitute a full for a partial is when the partial is not smaller than the full, then they must be the same size) I assume the subsequent baseline would be changed when the full was sent, and not when the partial was sent. Is there a significant operational impact from this happening, that doesn't occur using "accumulated" partials anyway? If there are implications, why is this not a MUST?

6) What is an accumulated partial state notification? where is this defined? It is mentioned in 5.5.1, but never defined.
Can an accumlated partial state notification contain multiple instances of the same item sampled at different times within the rate window?

7) With partial notifications, the notifier needs to maintain a separate buffer for each subscriber since each subscriber may have a different value for the maximum rate of notifications. How large a buffer is required of compliant implementations? How many subscriptions must a compliant implementation support? What happens if an implementation runs out of buffer space? (note that this partial-notification requirement is not discussed in terms of operational considerations, or in terms of possible DoS under security considerations, including those of RFC 5263)

[Ballot discuss]
updated to -06- (including numbering)

1) The document defines max-rate, min-rate, and adaptive-min-rate parameters, but the text refers to the "max-interval parameter" and "min-interval parameter" multiple times.

2) The document defines max-rate, but never specifies the acceptable range or format of the values.

3) section 1 defines max-rate, and equates it to min-interval:
  max-rate:  specifies a maximum rate of notifications (a minimum time
      period between two notifications).
This is incorrect; max-rate does not specify the minimum time period between two notifications. Max-rate refers to the ratio of the number of notifications per minimum time period. - maximum rate refers to a numerator/denominator ratio, while minimum time period refers only to the denominator.

the same problem exists for the other twio definitnons as well.

dbh: update to -06- to be continued

10) in 5.5.1, how does one determine the relative sizes of the partial and full state notifications? Is there a specification that defines the size of a full state notification? The partial state contains values that are differences between two full states. Can the size of the partial state be greater than the size of the full state, when the partial contains only the differences between two full states - the current full state and the last successfully communicated full state? And I note that section 5.6 says explicitly "However, even in the worst case scenario, where each partial update is to a different part of the full state, a rate controlled notification merging all of these n partial states together should at a maximum be the size of a full-state update." So why SHOULD implementations check whether the partial state notification is smaller than the full state notification?
11) Is it true that the maximum size should never exceed the size of a full state notification? For example, could the size vary depending on the encoding language, or the compression algorithm?
12) As with all SHOULDs, what is the acceptable exception to not checking this? What are the full implications if a notifier sends a partial notification instead of a full notification when the partial and full are the same size? (If the partial can never be bigger than the full, and the only time you would substitute a full for a partial is when the partial is not smaller than the full, then they must be the same size) I assume the subsequent baseline would be changed when the full was sent, and not when the partial was sent. Is there a significant operational impact from this happening, that doesn't occur using "accumulated" partials anyway? If there are implications, why is this not a MUST?
13) Is there a specification that defines the datatypes supported for calculating differences? (Note that SMIv2 defines Counter64 datatypes, but failed to define an unsigned64 datatype, which would be necessary for representing the difference between two Counter64s.
14) What is an accumulated partial state notification? where is this defined?
15) With partial notifications, the notifier needs to maintain a separate buffer for each subscriber since each subscriber may have a different value for the maximum rate of notifications. How large a buffer is required of compliant implementations? How many subscriptions must a compliant implementation support? What happens if an implementation runs out of buffer space? (note that this partial-notification requirement is not discussed in terms of operational considerations, or in terms of possible DoS under security considerations, including those of RFC 5263)

[Ballot discuss]
Taking over a DISCUSS from Alexey...

In 9.2:

      event-param    =/  min-interval-param
      subexp-params  =/  min-interval-param
      min-interval-param =  "min-interval" EQUAL delta-seconds

      event-param    =/  max-interval-param
      subexp-params  =/  max-interval-param
      max-interval-param =  "max-interval" EQUAL delta-seconds

      event-param    =/  average-interval-param
      subexp-params  =/  average-interval-param
      average-interval-param =  "average-interval" EQUAL delta-seconds

delta-seconds is not defined in the document. I think it is coming from RFC
3261, but this needs to be stated explicitly.

[Ballot discuss]
1) The document continually refers to both rate and interval - two sides of the same coin. I find the current approach to handling this very distracting. I think the document would be clearer if you chose one perspective, explained in the terminology section how it relates to the other perspective, and then used the one perspective consistently. Maybe you should rename the parameters to reflect the rate perspective - e.g., change "min-interval" to "max-rate".

section 1 defines min-interval, and equates it to maximum rate:
"min-interval: specifies a minimum notification time period (maximum rate) between two notifications, in seconds. "
This is incorrect; min-interval does not specify the maximum rate between two notifications; min-interval refers only to the time period. Maximum rate refers to the ratio of the number of notifications per min-interval. - min-interval is only the denominator; maximum rate refers to the numerator/denominator ratio.
section 3.1 says, "The maximum rate applies to the overall resource list, which means that there is a hard cap imposed by the maximum rate to the number of notifications the presence client can expect to receive."
This sentence is inaccurate on at least two points -
a) the sentence does not stipulate that the rate is a function of the time period; there is no time period specified here, so it could be interpreted as the number of notifications received for the lifetime of the client.
b) maximum rate only indirectly imposes a cap on the number of notifications - i.e., the numerator is ALWAYS 1. The hard cap per period is imposed by the min-interval, i.e., the cap is 1/min-interval. The attribute that varies to establish the cap is the min-interval, never the number of notifications.
The repeated mixing of the interval and rate leads to inaccuracies in the spec. The spec would be more accurate if the relation of rate to interval was defined in the termonology, and then the specification were written from the interval perspective (since this spec is about standardizing the settings for the interval parameters.)

2) 3.1 talks about "notifications that do not comply with the maximum rate". I'm not sure quite what that means - I assume it means notifications are generated faster than they are allowed to be sent. Why not say that?
3) 3.1 says the RLS will "batch all    of the buffered state changes together in a single notification only
  when allowed by the maximum rate." - I don't uinderstand "when allowed by the maximum rate". The maximum rate is a number. How does that number "allow" batching?
In addition, section 1 says "it is strictly an implementation decision whether batching of notifications is
  supported, and by what means." So I don't understand what "allowed by the maximum rate" means relative to the implementation decision. My impression is that "maximum rate" is being used to refer to an abstraction of the whole process, and that does not lead to clear and unambiguous standards specification.
4) 3.1 says "The presence client can also modify the "min-interval" parameter during the lifetime of the subscription.  For example, if the User Interface (UI) of the application shows inactivity for a period of time, it can simply pause the notifications by setting the "min-interval" parameter to the subscription expiration time, while still keeping the subscription alive.  When the user becomes active again, the presence client can resume the stream of notifications by re-subscribing with a "min-interval" parameter set to the earlier used value."
This text conflates the application, the UI, the user, and the presence client. These are potentially different entities - an application's database of activity might be a totally different process than its UI. I assume the presence client is an abstract fucntionality supported by an application - possibly implemented in a totally different process. and the user obviously is neither the application, nor the UI, nor the presence client. Is the presence client supposed to have a mechanism to watch the UI to see whether there is UI activity? or does it detect inactivity by monitoring protocol acivity? How exactly does it detect this- which protocols should be watched?
5) in 3.2, "In order to control the actual state, the location application sets a minimum rate ("max-interval" parameter), i.e. a maximum time interval between two notifications." Again, this approach of "here, let me say this three different ways" is distracting. More important, should this text say that it sends the parameter to the RLS? or does it just set an internal parameter paid attention to at the presence client?
6) 3.3 says "The "average-interval" parameter value is used by the notifier to dynamically calculate the actual maximum time ("timeout" parameter) between two notifications."  timeout is used before being defined - you might need a forward reference here.
7) 4.1 says "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 2xx response to a NOTIFY request in that dialog." The "it" in thsi sentence should be replaced by a named "actor". Is this the server that MUST NOT include things in the response?
8) 4.2 says "A notifier that supports the different rate control mechanisms will comply with the value given in "min-interval", "max-interval" and "average-interval" parameters and adjust its rate of notification accordingly.  However, if the notifier needs to lower the subscription expiration value or if a local policy or other implementation-determined constraint at the notifier can not satisfy the rate control request, then the notifier can adjust (i.e. increase or decrease) appropriately the subscriber requested rate control." How do I comply with a value? I know how to comply weith a standard, but not with a value. The "will comply" seems to call for a RFC2119 keyword. "will comply" seems to call for a MUST, but the next sentence discusses the exceptions, so I guess "will comply" needs to tbe replaced by a SHOULD.
9) 5.1 says "Note that the witnessed time between two consecutive received notifications may not conform to  the "min-interval" value for a number of reasons.  For example, network jitter and retransmissions may result in the subscriber receiving the notifications with smaller intervals than the "min-interval" value recommends." Hmmm. Doesn't min-interval mean do not send notifications more fequently than every X seconds?  Am I missing somethign in my interprwetation? Doesn't this text say that the receiver might receive the notifications at a rate faster than the rate they are sent?

10) in 5.5.1, how does one determine the relative sizes of the partial and full state notifications? Is there a specification that defines the size of a full state notification? The partial state contains values that are differences between two full states. Can the size of the partial state be greater than the size of the full state, when the partial contains only the differences between two full states - the current full state and the last successfully communicated full state? And I note that section 5.6 says explicitly "However, even in the worst case scenario, where each partial update is to a different part of the full state, a rate controlled notification merging all of these n partial states together should at a maximum be the size of a full-state update." So why SHOULD implementations check whether the partial state notification is smaller than the full state notification?
11) Is it true that the maximum size should never exceed the size of a full state notification? For example, could the size vary depending on the encoding language, or the compression algorithm?
12) As with all SHOULDs, what is the acceptable exception to not checking this? What are the full implications if a notifier sends a partial notification instead of a full notification when the partial and full are the same size? (If the partial can never be bigger than the full, and the only time you would substitute a full for a partial is when the partial is not smaller than the full, then they must be the same size) I assume the subsequent baseline would be changed when the full was sent, and not when the partial was sent. Is there a significant operational impact from this happening, that doesn't occur using "accumulated" partials anyway? If there are implications, why is this not a MUST?
13) Is there a specification that defines the datatypes supported for calculating differences? (Note that SMIv2 defines Counter64 datatypes, but failed to define an unsigned64 datatype, which would be necessary for representing the difference between two Counter64s.
14) What is an accumulated partial state notification? where is this defined?
15) With partial notifications, the notifier needs to maintain a separate buffer for each subscriber since each subscriber may have a different value for the maximum rate of notifications. How large a buffer is required of compliant implementations? How many subscriptions must a compliant implementation support? What happens if an implementation runs out of buffer space? (note that this partial-notification requirement is not discussed in terms of operational considerations, or in terms of possible DoS under security considerations, including those of RFC 5263)
16) in 6.2, "A compliant notifier MUST generate notifications when state changes occur or when the time since the most recent notification exceeds the value in the "max-interval" parameter. Depending on the event package and subscriber preferences indicated in the SUBSCRIBE request, the NOTIFY request sent as a result of a max-interval expiration MUST contain either the current full state or the partial state showing the difference between the current state and the last successfully communicated state.",  Section 6.1 mentions sending an etag in the ntoification, presumably instead of a full or partial state. Wouldn't this violate the MUST in section 6.2?
17) in section 9.3, it states "A subscriber that wishes to update the value for maximum, minimum or adaptive minimum rate of notifications can do so by including all desired values for the "min-interval", "max-interval" and "average- interval" parameters in an Event header field of the 2xx response to a NOTIFY request." Shouldn't "can do so by including all desired" be "MUST include all desired", since not including a value shuts off that specific feature?

[Ballot discuss]
I fall somewhere between Jari and David regarding the use of "rate"
"frequencey" and "interval" terminology.  I agree with Jari that the
document can be reviewed and fixed with editorial updates.  However,
this text from section 5.2 is an example of what I think needs to be
fixed, not just improved:

  A compliant notifier MUST NOT generate notifications more frequently
  than the maximum rate allows for [...]

The specific parameter is a minimum interval, not a maximum rate.
To ensure accurate compliance with the specification, the requirement must
be stated in terms of the parameter, not the inverse of the parameter
(which, speaking pedantically, is not as precise):

  A compliant notifier MUST NOT generate notifications with an
  interval between notifications less than the currently allowed
  minimum interval [...]

Text such as this excerpt from the next paragraph is OK, but could be
improved:

  When a local policy dictates a maximum rate for notifications, a
  notifier will not generate notifications more frequently than the
  local policy maximum rate

which mixes frequency and rate but is still understandable and has no
normative requirements langauge.  I think this text would be more
accurate:

  When a local policy dictates a minimum interval for notifications,
  a notifier will not generate notifications more frequently than the
  local policy minimum interval [...]

[Ballot discuss]
In 9.2:

      event-param    =/  min-interval-param
      subexp-params  =/  min-interval-param
      min-interval-param =  "min-interval" EQUAL delta-seconds

      event-param    =/  max-interval-param
      subexp-params  =/  max-interval-param
      max-interval-param =  "max-interval" EQUAL delta-seconds

      event-param    =/  average-interval-param
      subexp-params  =/  average-interval-param
      average-interval-param =  "average-interval" EQUAL delta-seconds

delta-seconds is not defined in the document. I think it is coming from RFC 3261, but this needs to be stated explicitly.

[Ballot comment]
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.

[Ballot comment]
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].

[Ballot comment]
1. In Section 3.4, the parameter names do not belong in the requirement definitions because they are implementations of the requirements. Thus I suggest:

  REQ1:  The subscriber must be able to set a maximum rate
          of notifications in a specific subscription.

  REQ2:  The subscriber must be able to set a minimum rate
          of notifications in a specific subscription.

  REQ3:  The subscriber must be able to set an adaptive
          minimum rate, which adjusts the minimum rate of
          notifications based on a moving average.

  REQ7:  The notifier must be allowed to use a policy in which
          the maximum rate, minimum rate, and adaptive minimum
          rate are adjusted from the value given by the subscriber.

2. In Sections 5.1, 6.1, and 7.1, what is "an integral number of seconds in decimal"? An integral number sounds like an integer, i.e., a whole number, i.e., not a decimal number. Please clarify.

[Ballot discuss]
1. In Section 5.3, the notifier is allowed to modify the "min-interval" value:

  If the subscriber requests a "min-interval" value greater than the
  subscription expiration, the notifier MUST lower the "min-interval"
  value and set it to the expiration time left.

However, that could have unintended consequences. Imagine subscription period is 3600 seconds but that the subscriber requests a maximum rate ("min-interval" parameter) when the expiration time left is 10 seconds. Now the subscriber might receive one notification every 10 seconds just because of the timing of its max rate request. Did the WG foresee such a scenario?

[Ballot discuss]
Section 6., paragraph 0:
> 6.  Operation of the Minimum Rate Mechanism

  DISCUSS: Assuming that you disallow max_interval := 0, this mechanism
  can still be used to get the notifier to generate a notification once
  per second. This can put some stress on the network as well as on the
  notifier. It's also questionable from the example use cases that a
  notification rate that is that aggressive can be useful. Can we define
  a useful max_interval that is larger than 1 second? If not, can we add
  some strong language here to caution implementers to use the lowest
  possible useful rate here? (This also applies to the "adaptive"
  variant.)

[Ballot comment]
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.

[Ballot discuss]
Section 6., paragraph 0:
> 6.  Operation of the Minimum Rate Mechanism

  DISCUSS: Assuming that you disallow max_interval := 0, this mechanism
  can still be used to get the notifier to generate a notifications once
  per second. This can put some stress on the network as well as on the
  notifier. It's also questionable from the example use cases that a
  notification rate that is that aggressive can be useful. Can we define
  a useful max_interval that is larger than 1 second? If not, can we add
  some strong language here to caution implementers to use the lowest
  possible useful rate here? (This also applies to the "adaptive"
  variant.)

[Ballot discuss]
1) The document continually refers to both rate and interval - two sides of the same coin. I find the current approach to handling this very distracting. I think the document would be clearer if you chose one perspective, explained in the terminology section how it relates to the other perspective, and then used the one perspective consistently. Maybe you should rename the parameters to reflect the rate perspective - e.g., change "min-interval" to "max-rate".
2) 3.1 talks about "notifications that do not comply with the maximum rate". I'm not sure quite what that means - I assume it means notifications are generated faster than they are allowed to be sent. Why not say that?
3) 3.1 says the RLS will "batch all    of the buffered state changes together in a single notification only
  when allowed by the maximum rate." - I don't uinderstand "when allowed by the maximum rate". The maximum rate is a number. How does that number "allow" batching?
In addition, section 1 says "it is strictly an implementation decision whether batching of notifications is
  supported, and by what means." So I don't understand what "allowed by the maximum rate" means relative to the implementation decision. My impression is that "maximum rate" is being used to refer to an abstraction of the whole process, and that does not lead to clear and unambiguous standards specification.
4) 3.1 says "The presence client can also modify the "min-interval" parameter during the lifetime of the subscription.  For example, if the User Interface (UI) of the application shows inactivity for a period of time, it can simply pause the notifications by setting the "min-interval" parameter to the subscription expiration time, while still keeping the subscription alive.  When the user becomes active again, the presence client can resume the stream of notifications by re-subscribing with a "min-interval" parameter set to the earlier used value."
This text conflates the application, the UI, the user, and the presence client. These are potentially different entities - an application's database of activity might be a totally different process than its UI. I assume the presence client is an abstract fucntionality supported by an application - possibly implemented in a totally different process. and the user obviously is neither the application, nor the UI, nor the presence client. Is the presence client supposed to have a mechanism to watch the UI to see whether there is UI activity? or does it detect inactivity by monitoring protocol acivity? How exactly does it detect this- which protocols should be watched?
5) in 3.2, "In order to control the actual state, the location application sets a minimum rate ("max-interval" parameter), i.e. a maximum time interval between two notifications." Again, this approach of "here, let me say this three different ways" is distracting. More important, should this text say that it sends the parameter to the RLS? or does it just set an internal parameter paid attention to at the presence client?
6) 3.3 says "The "average-interval" parameter value is used by the notifier to dynamically calculate the actual maximum time ("timeout" parameter) between two notifications." Is the maximum time "timeout" parameter the same parameter called "max-interval" in section 1? Is"actual maximum time" the same as the configured max-interval? Or is the actual maximum time an imperical measurement value about the "actual" maximum time in practice?
7) 4.1 says "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 2xx response to a NOTIFY request in that dialog." The "it" in thsi sentence should be replaced by a named "actor". Is this the server that MUST NOT include things in the response?
8) 4.2 says "A notifier that supports the different rate control mechanisms will comply with the value given in "min-interval", "max-interval" and "average-interval" parameters and adjust its rate of notification accordingly.  However, if the notifier needs to lower the subscription expiration value or if a local policy or other implementation-determined constraint at the notifier can not satisfy the rate control request, then the notifier can adjust (i.e. increase or decrease) appropriately the subscriber requested rate control." How do I comply with a value? I know how to comply weith a standard, but not with a value. The "will comply" seems to call for a RFC2119 keyword. "will comply" seems to call for a MUST, but the next sentence discusses the exceptions, so I guess "will comply" needs to tbe replaced by a SHOULD.
9) 5.1 says "Note that the witnessed time between two consecutive received notifications may not conform to  the "min-interval" value for a number of reasons.  For example, network jitter and retransmissions may result in the subscriber receiving the notifications with smaller intervals than the "min-interval" value recommends." Hmmm. Doesn't min-interval mean do not send notifications more fequently than every X seconds?  Am I missing somethign in my interprwetation? Doesn't this text say that the receiver might receive the notifications at a rate faster than the rate they are sent?

I stopped reviewing the document at section 5.1. I find the loose terminology used in this document makes this document not ready for publication as a standard. the language must be clear and unambiguous. I think this document should go back to the WG for tightening, and be resubmitted only after it has been tightened up.

Upon approval of this document, IANA understand that there are two IANA
actions that must be completed.

First, in the Header Field Parameters and Parameter Values subregistry
in the Session Initiation Protocol (SIP) Parameters registry located at:

http://www.iana.org/assignments/sip-parameters

the following registrations will be added:

Predefined
Header Field Parameter Name Values Reference
-------------------- --------------- ---------- ---------
Event min-interval No [RFC-to-be]
Subscription-State min-interval No [RFC-to-be]
Event max-interval No [RFC-to-be]
Subscription-State max-interval No [RFC-to-be]
Event average-interval No [RFC-to-be]
Subscription-State average-interval No [RFC-to-be]

Second, in the Header Fields subregistry in the Session Initiation
Protocol (SIP) Parameters registry located at:

http://www.iana.org/assignments/sip-parameters

the reference for the Event header field will be updated to include the
newly approved document as a reference.s/sip-parameters.

Header Name compact Reference
----------- ------- ---------
Event o [RFC3265][RFC-to-be]

IANA understands that these two actions are all that need to be
completed upon approval of the document.

PROTO writeup for draft-ietf-sipcore-event-rate-control-03

  (1.a) Who is the Document Shepherd for this document? Has the
        Document Shepherd personally reviewed this version of the
        document and, in particular, does he or she believe this
        version is ready for forwarding to the IESG for publication?

Adam Roach is the document shepherd. He has reviewed this version
of the document, and believes that it is ready for publication.

  (1.b) Has the document had adequate review both from key WG members
        and from key non-WG members? Does the Document Shepherd have
        any concerns about the depth or breadth of the reviews that
        have been performed?

The document has received significant review during its tenure in the
SIPPING working group, and moderate review within SIPCORE. It has
also received review by key members of the GEOPRIV working group.
GEOPRIV needs the mechanism defined by this draft for conveying
location information according to their requirements.

The document underwent a last call in February of 2010. There were
minor comments during that period that resulted in the formula
used for average notification rate becoming exemplary rather than
mandatory.

  (1.c) Does the Document Shepherd have concerns that the document
        needs more review from a particular or broader perspective,
        e.g., security, operational complexity, someone familiar with
        AAA, internationalization or XML?

The shepherd has no such concerns.

  (1.d) Does the Document Shepherd have any specific concerns or
        issues with this document that the Responsible Area Director
        and/or the IESG should be aware of? For example, perhaps he
        or she is uncomfortable with certain parts of the document, or
        has concerns whether there really is a need for it. In any
        event, if the WG has discussed those issues and has indicated
        that it still wishes to advance the document, detail those
        concerns here. Has an IPR disclosure related to this document
        been filed? If so, please include a reference to the
        disclosure and summarize the WG discussion and conclusion on
        this issue.

The shepherd has no such concerns. The shepherd is not aware of any
IPR assertions associated with this document.

  (1.e) How solid is the WG consensus behind this document? Does it
        represent the strong concurrence of a few individuals, with
        others being silent, or does the WG as a whole understand and
        agree with it?

The document represents agreement across a broad range of participants
in the SIPCORE working group (and the now defunct SIPPING working group).
Further, it has strong support from key members of GEOPRIV.

  (1.f) Has anyone threatened an appeal or otherwise indicated extreme
        discontent? If so, please summarise the areas of conflict in
        separate email messages to the Responsible Area Director. (It
        should be in a separate email because this questionnaire is
        entered into the ID Tracker.)

No appeal has been threatened, nor has extreme discontent been
expressed.

  (1.g) Has the Document Shepherd personally verified that the
        document satisfies all ID nits? (See the Internet-Drafts Checklist
        and http://tools.ietf.org/tools/idnits/). Boilerplate checks are
        not enough; this check needs to be thorough. Has the document
        met all formal review criteria it needs to, such as the MIB
        Doctor, media type and URI type reviews?

The shepherd has checked ID nits.

The document is using an older template for its license notice. The
authors are willing to use the newer license for the final published
document.

Some drafts in the references section have been updated or published
as RFCs. These are addressed in the RFC Editor's Note, at the end
of this writeup.

  (1.h) Has the document split its references into normative and
        informative? Are there normative references to documents that
        are not ready for advancement or are otherwise in an unclear
        state? If such normative references exist, what is the
        strategy for their completion? Are there normative references
        that are downward references, as described in [RFC3967]? If
        so, list these downward references to support the Area
        Director in the Last Call procedure for them [RFC3967].

The document properly splits references into normative and informative.
No normative references are at a level of maturity or on a track that
would preclude their being cited in this document.

  (1.i) Has the Document Shepherd verified that the document IANA
        consideration section exists and is consistent with the body
        of the document? If the document specifies protocol
        extensions, are reservations requested in appropriate IANA
        registries? Are the IANA registries clearly identified? If
        the document creates a new registry, does it define the
        proposed initial contents of the registry and an allocation
        procedure for future registrations? Does it suggest a
        reasonable name for the new registry? See [RFC5226]. If the
        document describes an Expert Review process has Shepherd
        conferred with the Responsible Area Director so that the IESG
        can appoint the needed Expert during the IESG Evaluation?

The IANA Consideration section properly registers the SIP header
field parameters that are created by this document, and clearly
cites the proper registry.

  (1.j) Has the Document Shepherd verified that sections of the
        document that are written in a formal language, such as XML
        code, BNF rules, MIB definitions, etc., validate correctly in
        an automated checker?

The syntax additions, defined in ABNF, are trivial. They are
correct by casual inspection. No formal validation has been
performed.

  (1.k) The IESG approval announcement includes a Document
        Announcement Write-Up. Please provide such a Document
        Announcement Write-Up? Recent examples can be found in the
        "Action" announcements for approved documents. The approval
        announcement contains the following sections:

      Technical Summary
        This document specifies mechanisms for adjusting the rate
        of Session Initiation Protocol (SIP) event notifications.
        These mechanisms can be applied in subscriptions to all SIP
        event packages.

      Working Group Summary
        Many working group members tended to express mild confusion
        or bewilderment upon first encountering the behavior described
        in section 5 (minimum notification rate). It is worth noting
        that this is the exact behavior that is required by the
        GEOPRIV work. This confusion is typically ameliorated when
        they are presented with use cases similar to those being
        considered by GEOPRIV.

      Document Quality
        Martin Thompson provided significant input to the document
        on behalf of the GEOPRIV working group, who is an immediate
        customer for this document. Brian Rosen identified the
        suitability of this mechanism in satisfying GEOPRIV's
        requirements, and made the initial proposal for the minimum
        rate mechanism for that purpose.

====================
RFC EDITOR'S NOTES
====================

Please remove the reference to RFC3261, as it is no longer cited
in this version of the document.

Please replace the reference [draft-ietf-sipcore-subnot-etags]
with [RFC5839], and update references to it as follows:

  Section 3.1, final paragraph
  OLD:
      carrying the latest resource state.  There is work
      [I-D.ietf-sipcore-subnot-etags] ongoing to solve these
      inefficiencies.
  NEW:
      carrying the latest resource state.  Application of the
      mechanism defined by [RFC5839] can eliminate these
      inefficiencies.

  Section 5.1, final paragraph
  OLD:
    There is work [I-D.ietf-sipcore-subnot-etags] ongoing to only send a
    reference in a notification if nothing has changed.
  NEW:
    [RFC5839] defines a mechanism that allows sending only
    an etag instead of the full resource state in a notification
    if the state has not changed.

  Section 6.1, final paragraph
  OLD:
    There is work [I-D.ietf-sipcore-subnot-etags] ongoing to only send a
    reference in a notification if nothing has changed.
  NEW:
    [RFC5839] defines a mechanism that allows sending only
    an etag instead of the full resource state in a notification
    if the state has not changed.