Re: Comments on draft-niemi-sipping-event-throttle-07.txt

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [IETF Announce]     [IETF Discussion]     [Linux SCSI]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Big List of Linux Books]

  Powered by Linux