Re: [Geopriv] Gen-ART LC/Tekechat Review of draft-ietf-geopriv-loc-filters-10

[Ben Campbell <[e-mail]>]

On Mar 21, 2010, at 3:24 PM, Tschofenig, Hannes (NSN - FI/Espoo) wrote:

> If rate-control gives the impression that it disallows empty NOTIFYs to
> be sent then rate-control needs to change. If location is not available
> at the time when the SUBSCRIBE hits the location server then the server
> just cannot send something.
> 
> Do you agree with me? 
> 

We're not talking about NOTIFYs sent in response to a SUBSCRIBE. We're talking about NOTIFY's sent as a result of a max-interval expiration, when using the rate-control mechanism.  The rate-control draft requires content in that situation, and the geopriv-loc-filters draft recommends empty notifies in the same situation.



>> -----Original Message-----
>> From: ext Ben Campbell [mailto:[e-mail]] 
>> Sent: 21 March, 2010 18:23
>> To: Thomson, Martin
>> Cc: Tschofenig, Hannes (NSN - FI/Espoo); [e-mail]; 
>> [e-mail]; [e-mail]; 
>> Cullen Jennings; Rohan Mahy; IETF-Discussion list; General 
>> Area Review Team; Hannes Tschofenig
>> Subject: Re: Gen-ART LC/Tekechat Review of 
>> draft-ietf-geopriv-loc-filters-10
>> 
>> 
>> On Mar 21, 2010, at 3:12 PM, Thomson, Martin wrote:
>> 
>>> Ben wrote:
>>>> There's a few ways to handle that:
>>>> 
>>>> 1) Treat rate-control as an informative reference, and say 
>> you're doing something mostly like rate control, but not quite 
>> identical. That would require quite a bit more normative 
>> language to describe what you're actually doing.
>>>> 
>>>> 2) Make this draft update rate-control to allow for empty 
>> bodies when you don't have location info yet. Put some tightly 
>> constrained language around it. so that this doesn't become a 
>> _general_ udpate.
>>>> 
>>>> 3) Since rate-control has, to my knowledge, not been 
>> pubreq'd yet, try to get the authors to modify the language to 
>> allow for empty bodies for this use case.
>>>> 
>>>> I personally think 3 is the best path forward, as I think 
>> the empty notify is generally useful for rate-control, and 
>> implementor are likely to do it anyway.
>>> 
>>> I was not under the impression from reading rate-control 
>> that that document was modifying 3265 to prevent notifiers 
>> from sending an empty notify.  But, your suggestion is a 
>> reasonable one.  Reading the rate-control text you quoted 
>> earlier in the thread could lead to the impression that this 
>> is the case.  I've added the rate control authors to the thread.
>>> 
>> 
>> I don't think it modifies 3265 in general, but it does seem to 
>> normatively prevent empty NOTIFY requests as a result of a 
>> max-interval expiration.
>> 
>>> --Martin
>> 
>>