Subject: [sipcore] Event rate control and GEOPRIV requirements

From: "Thomson, Martin" <[email-masked]>
Date: Mon, 9 Nov 2009 11:51:52 +0800

Is the -00 version the latest issue of this draft?  I expected a -01 and so was under the impression that we were discussion changes already made.

The following two minor changes were requested out of the GEOPRIV use cases:

 - note that the rate control parameters can be updated in response messages (i.e. the 200 response to an initial NOTIFY); the notifier then indicates the agreed (and possibility modified) values in subsequent NOTIFYs

 - note that rate control parameters can be changed at any time by the notifier, based on policy- or implementation-determined constraints

This is what we discussed in the meeting.

I think that the second one is OK in the version -00 draft.  I could not find anywhere that mentioned updating event parameters in a response message.

--Martin

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Mon, 9 Nov 2009 14:24:06 +0900

I also assumed that a new version would become available by the draft
submission deadline. 
 
I have just re-submitted the location filters draft
(draft-ietf-geopriv-loc-filters-08.txt) and it has a normative dependency on
draft-ietf-sipcore-event-rate-control.

Ciao
Hannes

>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Thomson, Martin
>Sent: 09 November, 2009 12:52
>To: [email-masked]
>Subject: [sipcore] Event rate control and GEOPRIV requirements
>
>Is the -00 version the latest issue of this draft?  I expected 
>a -01 and so was under the impression that we were discussion 
>changes already made.
>
> - note that the rate control parameters can be updated in 
>response messages (i.e. the 200 response to an initial 
>NOTIFY); the notifier then indicates the agreed (and 
>possibility modified) values in subsequent NOTIFYs
>
> - note that rate control parameters can be changed at any 
>time by the notifier, based on policy- or 
>implementation-determined constraints
>
>I think that the second one is OK in the version -00 draft.  I 
>could not find anywhere that mentioned updating event 
>parameters in a response message.
>
>--Martin
>
>_______________________________________________
>sipcore mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: Salvatore Loreto <[email-masked]>
Date: Mon, 09 Nov 2009 07:25:11 +0200

Hi Martin,

an updated version of the event-rate-control draft was submitted two 
days after the IETF76 deadline,
for this reason it is not yet on the I-D repository, however it will be 
available soon

for the time being you can fetch a copy from 
http://krkiss.letolt.info/draft-ietf-sipcore-event-rate-control-01.txt

/Sal

---

From: "Thomson, Martin" <[email-masked]>
Date: Mon, 9 Nov 2009 13:34:35 +0800

Hi Sal,

Thanks for the pointer.

Regarding section 8.3, which addresses the requirement in question:

I'm not sure why you would make the Event header mandatory in the 2xx responses.  Optional seems to make more sense to me.  Existing implementations don't do this, after all.

> From: Salvatore Loreto [mailto:[email-masked]]
> Sent: Monday, 9 November 2009 2:25 PM
> To: Thomson, Martin
> Cc: [email-masked]
> Subject: Re: [sipcore] Event rate control and GEOPRIV requirements
> 
> Hi Martin,
> 
> > Is the -00 version the latest issue of this draft?  I expected a -01
> and so was under the impression that we were discussion changes already
> made.
> >
> >  - note that the rate control parameters can be updated in response
> messages (i.e. the 200 response to an initial NOTIFY); the notifier
> then indicates the agreed (and possibility modified) values in
> subsequent NOTIFYs
> >
> >  - note that rate control parameters can be changed at any time by
> the notifier, based on policy- or implementation-determined constraints
> >
> > I think that the second one is OK in the version -00 draft.  I could
> not find anywhere that mentioned updating event parameters in a
> response message.
> >
> > --Martin
> >

---

From: Salvatore Loreto <[email-masked]>
Date: Mon, 09 Nov 2009 07:49:14 +0200

Hi Martin,

good point, I think we can relax it to optional .

/Sal

Thomson, Martin wrote:
>>> The following two minor changes were requested out of the GEOPRIV use
>>>       
>> cases:
>>

---

From: <[email-masked]>
Date: Mon, 9 Nov 2009 07:49:48 +0100

Hi,

Making it optional may create a conflict with the following statement:

   A subscriber that wishes to remove the minimum rate control from
   notifications MUST indicate so by not including a "max-interval"
   Event header field parameter in a subsequent SUBSCRIBE request or a
   200-class response to the NOTIFY request.

An Event header field without the "max-interval" parameter means that the subscriber is deleting the "max-interval" feature from notifications. Should we now allocate a special meaning for the case when no Event header field exists in the 2xx response to the NOTIFY? Does that mean the "max-interval" parameter is not touched from the previous value? Or something else? I'd prefer the same behavior as for the SUBSCRIBE request, i.e. the "max-interval" parameter is always present reflecting the current value and the lack of the parameter means that the feature is deleted from notifications.

Existing implementations do not support Event header field in the 2xx responses to NOTIFY, however new implementations adding the rate-control feature to notifications will support adding the rate control parameters to the Event header field in SUBSCRIBE and 2xx to NOTIFY as well as the Subscription-State header field in NOTIFYs. As RFC 3265 did not define the Event header field to 2xx to NOTIFY, draft-ietf-sipcore-event-rate-control has to do this in order to have a placeholder for the new parameter.

Cheers,
Krisztian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Salvatore Loreto
Sent: Sunday, November 08, 2009 9:49 PM
To: Thomson, Martin
Cc: [email-masked]
Subject: Re: [sipcore] Event rate control and GEOPRIV requirements

Hi Martin,

/Sal

Thomson, Martin wrote:
>> days after the IETF76 deadline, for this reason it is not yet on the 
>> I-D repository, however it will be available soon
>>
>> and so was under the impression that we were discussion changes 
>> already made.
>>

---

From: "Thomson, Martin" <[email-masked]>
Date: Mon, 9 Nov 2009 14:58:36 +0800

I don't think that there is a conflict.

If the subscriber wishes to change details, then they can provide the header.  If they do not provide the header - as is the existing behaviour - the values do not change.

Of course, if the _header_ is present, then the parameter must be, but that is not what the text in the document says.

Making this mandatory also makes it mandatory for those who implement this feature but don't intend to use it.  Let's not break existing event package implementations.

--Martin

> From: [email-masked] [mailto:[email-masked]]
> Sent: Monday, 9 November 2009 3:50 PM
> To: [email-masked]; Thomson, Martin
> Cc: [email-masked]
> Subject: RE: [sipcore] Event rate control and GEOPRIV requirements
> 
> Hi,
> 
> An Event header field without the "max-interval" parameter means that
> the subscriber is deleting the "max-interval" feature from
> notifications. Should we now allocate a special meaning for the case
> when no Event header field exists in the 2xx response to the NOTIFY?
> Does that mean the "max-interval" parameter is not touched from the
> previous value? Or something else? I'd prefer the same behavior as for
> the SUBSCRIBE request, i.e. the "max-interval" parameter is always
> present reflecting the current value and the lack of the parameter
> means that the feature is deleted from notifications.
> 
> Existing implementations do not support Event header field in the 2xx
> responses to NOTIFY, however new implementations adding the rate-
> control feature to notifications will support adding the rate control
> parameters to the Event header field in SUBSCRIBE and 2xx to NOTIFY as
> well as the Subscription-State header field in NOTIFYs. As RFC 3265 did
> not define the Event header field to 2xx to NOTIFY, draft-ietf-sipcore-
> event-rate-control has to do this in order to have a placeholder for
> the new parameter.
> 
> Cheers,
> Krisztian
> 
> > I'm not sure why you would make the Event header mandatory in the 2xx
> responses.  Optional seems to make more sense to me.  Existing
> implementations don't do this, after all.
> >
> >
> >> http://krkiss.letolt.info/draft-ietf-sipcore-event-rate-control-
> 01.tx
> >> t
> >>
> >> /Sal
> >>
> >> Thomson, Martin wrote:
> >>
> could