Rate control is able to provide a virtually equivalent function to that provided by the HELD 'responseTime' parameter. The 'max-interval' parameter indicates to a notifier/PA the time that it has before it MUST generate a NOTIFY containing state.
If complete state is not immediately available, a NOTIFY containing state (i.e. location) is generated some time between the time included in 'min-interval' and the time in 'max-interval'.
An important use case is placing constraints on when complete state should be provided after creating the subscription. An initial NOTIFY might not include complete state.
Constraints on when complete state is provided are placed using 'max-interval' in the initial SUBSCRIBE. Then, once state is acquired, the subscriber updates or changes 'max-interval' back to a more sensible value. This update can be performed in the 200 response to the NOTIFY that contains state (which will be either the first or second).
A notifier is likely to need policy that permits this. It might be that 'max-interval' for this first request is much lower than a notifier would like to allow thereafter. Thus, policy regarding 'max-interval' on the second NOTIFY might be different to the rest of the subscription, depending on whether complete state could be provided in the first.
There are a number of corner cases that need clarification. Here are the points we agreed upon (A) and points that might still be contentious (C):
(A) - event-rate-control to 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
(C) - event-rate-control to note that rate control parameters can be changed at any time by the notifier, based on policy- or implementation-determined constraints
- contention here is that this statement is unnecessary - it is implied and therefore redundant; whereas I tend to favour occasional pieces of redundancy
(A) - 3265bis to note that resource state polling only results in state that the notifier has immediately available; if state is incomplete when the request is made, incomplete state is provided
(A) - loc-filters does not need any _mechanism_; however we would still like to include guidelines on use: i.e. how the subscriber sets 'max-interval' on initial SUBSCRIBE and in the 200 response to the NOTIFY; then what policy the notifier sets in relation to 'max-interval'
(C) - (ECRIT) phone-bcp might need guidance on how this affects their application a routing proxy might use 'max-interval'
- I've had another look and this might not be necessary since phone-bcp relies on location-by-value
(A) - GEOPRIV needs to discuss quality in more detail. Since I'm going on leave next week, I'm hoping to leave this until our interim call.
Thanks,
Martin
------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.
If you have received it in error, please notify the sender
immediately and delete the original. Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
