Hi Hisham, Thanks for the review! Regarding your comment: > - I think its a good idea to talk about how a notifier can suggest to > the client the throttling mechanism and throttle interval without the > client asking for it. At least the draft can talk about how if a > notifier has a policy to limit notifications according to admin > throttling settings, those can/cannot be applied without the client > requesting them. That's something that we need to decide, although it > is difficult to mandate that a notifier cannot apply throttles unless > it is asked to do so. [Sal] I agree that is something we need to discuss and decide how to proceed. I agree that the notifier can apply "hidden" throttling according to local policy. It could do it without even informing the subscriber. Now that we have a negotiation mechanism in place, we could perhaps use the Subscription-State throttle parameter to "inform" the subscriber about the existence of "hidden" throttling at the notifier (when the client does not request it). It is probably useful to let the client know what is going on at the notifier and can be done easily with this mechanism. What is your view? Cheers, Krisztian -----Original Message----- From: sipping-bounces@xxxxxxxx [mailto:sipping-bounces@xxxxxxxx] On Behalf Of ext Salvatore Loreto Sent: Tuesday, February 17, 2009 4:18 AM To: Hisham Khartabil Cc: sipping@xxxxxxxx Subject: Re: Comments on draft-niemi-sipping-event-throttle-07.txt Hi Hisham, thanks for the review. See my answers/comment below in line /Sal Hisham Khartabil wrote: > - Section 3 talks about presence, location and tracking applications. > I was confused reading those sections the first time thinking the > presence application sits on the server. Can you replace the word > "application" with "client"? [Sal] thanks I'll do in the next version of the document. > As a suggestion, I would say the whoel document needs to be updated > with this suggestion > > - Section 3.2 talks about filters. A reference is needed to filters RFC. [Sal] actually the right reference is to "Location Event Filters" draft. I'll add it. > Also, more text is needed around how this Force extention overrides a > filter criteria and why would someone set a filter only to override it > with a Force. [Sal] it is not that the Force override the filter criteria, but that the application is interested in receiving a periodic update even when the filter criteria does not satisfy any of the trigger criteria. For example you are interested to receive an update if someone or something has moved more then 10 meters (and you can set a location filter criteria for that) or if it has not moved more then 10 meters you still want a periodic update to check if it has been completely still or it has moved but less then 10 meters. Of course, the periodic update can be generalized and applied to all the possible filter criteria. > > - Figure 1 needs to be modified to show how filters are affected [Sal] Figure 1 only describes the Throttle mechanism that does not affect filters. > > - Section 4.3: Need to expand on how the client can reject the > notifier's adjusted intervals? [Sal] the client can not reject the notifier's adjusted intervals. The only things it can do is to perform an update subscription with a different value but that meet the constraints or subscription that does not contain the throttle parameter at all. > > - I think its a good idea to talk about how a notifier can suggest to > the client the throttling mechanism and throttle interval without the > client asking for it. At least the draft can talk about how if a > notifier has a policy to limit notifications according to admin > throttling settings, those can/cannot be applied without the client > requesting them. That's something that we need to decide, although it > is difficult to mandate that a notifier cannot apply throttles unless > it is asked to do so. [Sal] I agree that is something we need to discuss and decide how to proceed. > > - "average" I dont understand what that is? is it the average interval > between notifications sent so far? How is that value decided? is > average the wrong word to use here. More explanation is needed. [Sal] The average rate control is a statistical calculation which varies slowly over time, it allows the notifier to dynamically increase or decrease the Notification frequency. > > Regards, > Hisham > ---------------------------------------------------------------------- > -- > > _______________________________________________ > Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP Use > sip-implementors@xxxxxxxxxxxxxxx for questions on current sip Use > sip@xxxxxxxx for new developments of core SIP _______________________________________________ Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip Use sip@xxxxxxxx for new developments of core SIP _______________________________________________ Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip Use sip@xxxxxxxx for new developments of core SIP
