Subject: Re: [sipcore] I-D Action:draft-ietf-sipcore-event-rate-control-02.txt

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 04 Feb 2010 13:11:49 +0200

Hi,

per my email below, I am going to go ahead start this draft's WGLC.

Cheers,

Gonzalo

Gonzalo Camarillo wrote:
> Hi,
> 
>> The authors think this version is ready for WGLC.
> 
> you have received a few comments on this list. Additionally, we have 
> requested feedback from the Geopriv WG:
> 
> http://www.ietf.org/mail-archive/web/geopriv/current/msg08252.html
> 
> Regarding the WGLC, we will be able to start it when the WGLC on the 
> invfix draft is over. We are talking about February.
> 
> Cheers,
> 
> Gonzalo
> 
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: Salvatore Loreto <[email-masked]>
Date: Wed, 10 Feb 2010 12:52:16 +0200

Hi Michael,

while I agree with the fact that the formula can not be particularly 
good for various scenarios and
the notifier should have the freedom to achieve an average rate in the 
way it considers most effective,
I also believe that it is better have one defined formula in the draft 
that can be used as reference.

If people agree we can insert in the draft at the end of Section 6.3 
some text like the following:

    In some situation it may be beneficial for the Notifier to achieve
    an average rate
    in a different way than the algorithm detailed in this document allows.
    However, the Notifier MUST NOT be more aggressive that the
    "min-interval"
    parameter allows.

Cheers
/Sal

On 01/11/2010 12:46 PM, Michael Procter wrote:
> I have one comment left on this draft, which Sal asked me to raise on-list.
>
> Section 6.3 defines how a notifier will pace notifications to ensure
> they meet with the 'average-interval' specified by the subscriber.  I
> have two problems with defining this.  Firstly I don't think we need
> to define exactly how the average interval must be achieved, and
> secondly even if I did, I don't think the formula specified is
> particularly good for various scenarios.
>
> If a subscriber has specific timing requirements that it wishes to be
> met, it can advertise them with min-interval and max-interval.  The
> average-interval should be viewed as no more than a hint for the
> notifier.
>
> Consequently, the notifier should have freedom to achieve an average
> rate in the way it considers most effective, provided it meets the
> constraints of min-interval and max-interval.
>
> I would prefer that the mechanism for achieving a particular average
> interval was left to the notifier's discretion and not specified in
> this document.  I would be content if the given formula was described
> as one way to achieve this and that an implementation may choose a
> different approach if preferred.
>
> Best regards,
>
> Michael

---

From: Salvatore Loreto <[email-masked]>
Date: Wed, 10 Feb 2010 12:52:20 +0200

Hi Martin,

see my answers are included below

cheers
/sal

On 01/13/2010 12:59 AM, Thomson, Martin wrote:
> The document is fit to go to the IESG, with two minor exceptions.
>
> Section 6.3:
>        [OPEN ISSUE] Is the period value something we should be able to
>        tune, or we can simply specify a reasonable period?
>
> Should this issue be removed now?
>    
[Sal] yes, we will remove in the next version.

> Section 8.3: OLD:
>     response to a NOTIFY request.  Implementations supporting the
>     functionality to update the previously agreed minimum, maximum or
>     average rate of notifications in a 200-class response to the NOTIFY
>     request MUST support the inclusion of the Event header field.
> NEW:
>     response to a NOTIFY request.  A UA that wishes to update the value
>     for minimum, maximum or average rate of notifications can do so by
>     including all desired values for the rate control parameters in an
>     Event header in the 200-class response to a NOTIFY request.
>
> The changed text didn't include the most important aspect of this text - which is that the _parameters_ are included.  Note that there is no normative requirement in my replacement - interoperability is not harmed by the omission of the header, or even the parameters.
>    
[Sal] I also think it is better to be explicit about the parameters 
inclusion.

---

From: Adam Roach <[email-masked]>
Date: Wed, 10 Feb 2010 08:03:25 -0600

[as participant]

>     However, the Notifier MUST NOT be more aggressive that the

Sounds good to me.

/a

---

From: Michael Procter <[email-masked]>
Date: Wed, 10 Feb 2010 15:01:45 +0000

On 10 February 2010 10:52, Salvatore Loreto
<[email-masked]> wrote:
> If people agree we can insert in the draft at the end of Section 6.3 some
> text like the following:
>
>   In some situation it may be beneficial for the Notifier to achieve an
>   average rate
>   However, the Notifier MUST NOT be more aggressive that the "min-interval"
>   parameter allows.
>

I'm happy in principle, but I'll suggest the following wording instead:

  In some situations it may be beneficial for the Notifier to use a
different approach
  to achieve the average interval.  However, the Notifier MUST comply with any
  "min-interval" or "max-interval" parameters that have been negotiated.

Section 6.2 contains this text, which seems to mandate use of the
formula as an effective upper bound:

   A compliant notifier MUST generate notifications whenever the time
   since the most recent notification exceeds the value calculated using
   the formula defined in Section 6.3.

I'm not sure what this paragraph adds over the rest of the text in 6.2
and 6.3, so I think you can simply remove it.

Best regards,

Michael

---

From: Salvatore Loreto <[email-masked]>
Date: Thu, 11 Feb 2010 20:44:20 +0200

Hi Michael,

see my answers in line.

Cheers
Sal

>    "min-interval" or "max-interval" parameters that have been negotiated.
I have been thinking for a while about the "max-interval",
and I tend to agree about the need to specify also it in the text so
to avoid different possible interpretations.
So I propose the following text

   In some situation it may be beneficial for the Notifier to achieve an
   average rate   in a different way than the algorithm detailed in this
   document allows. However, the Notifier MUST comply with any
   "min-interval" or "max-interval" parameters that have been negotiated.

> and 6.3, so I think you can simply remove it.
I am to let the paragraph stay there, however to allow a divergence in
particular circumstances we will change the MUST in SHOULD

    A compliant notifier SHOULD generate notifications whenever the time
    since the most recent notification exceeds the value calculated using
    the formula defined in Section 6.3.

---

From: Michael Procter <[email-masked]>
Date: Tue, 16 Feb 2010 09:22:12 +0000

Hi Sal,

My overarching concern is to ensure that notifiers are not compelled
to use the formula described in 6.3.  I think this set of changes just
about permits that.  I think that your 'SHOULD' is still too strong,
but if that is as far as you are able to go, then so be it.

Regards,

Michael

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 18 Feb 2010 15:06:57 +0200

Hi,

this WGLC will end in a few days. I would like to ask the authors to
revise the draft addressing all the comments received as soon as the
WGLC is over so that we can move it forward.

Thanks,

Gonzalo