Subject: Re: [sipcore] draft-ietf-sipcore-event-rate-control-01

From: <[email-masked]>
Date: Sat, 7 Nov 2009 13:28:41 +0100

Hi Jeroen,

IMHO "controlling" publications is an interesting but distinct problem from the mechanisms presented in draft-ietf-sipcore-event-rate-control-01, it's mostly useful to control the volume of unnecessary publications taking into account the needs of the subscribers/watchers sitting on the other side of the notifier. Are you suggesting to extend the winfo package with rate control information in order to control the rate of publications? 

Cheers,
Krisztian

-----Original Message-----
From: ext Jeroen van Bemmel [mailto:[email-masked]] 
Sent: Saturday, October 31, 2009 03:51
To: Kiss Krisztian (Nokia-CIC/MtView)
Cc: [email-masked]
Subject: Re: [sipcore] draft-ietf-sipcore-event-rate-control-01

Krisztian,

As input for discussion:
- some years ago we submitted a similar draft, but focused on rate control for publications: 
http://tools.ietf.org/html/draft-brok-simple-regulate-publish-02
- did you consider passing on the rate control information in watcher info? (i.e. extend the winfo package of RFC3857)

Regards,
Jeroen

[email-masked] wrote:
> All,
>
> An updated version of the event-rate-control draft was recently 
> submitted (after the IETF76 deadline). Until it appears in the I-D 
> repository, you can fetch a copy from 
> http://krkiss.letolt.info/draft-ietf-sipcore-event-rate-control-01.txt
>
> The changes include:
> - All rate control parameters can now be updated in 200-class responses to a NOTIFY request (in addition to setting the parameters in the SUBSCRIBE request). See related discussion in GEOPRIV: http://www.ietf.org/mail-archive/web/geopriv/current/msg07766.html. This change also requires mandating the Event header field in 200-class responses to a NOTIFY request.
> - Emphasized that rate control parameters can be changed at any time by the notifier based on local policy or implementation-determined constraints.
> - In minimum rate mechanism, the NOTIFY request may contain partial or full state depending on what the event package specifies. Previously, a NOTIFY with full state was always pushed to the subscriber when the max-interval indicated, even if nothing has changed from the previous NOTIFY.
> - other minor wordsmithing changes.
>
> Cheers,
> Krisztian
>
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>
>