ietf
[Top] [All Lists]

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

2010-03-21 20:05:18
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:ben(_at_)estacado(_dot_)net] 
Sent: 21 March, 2010 18:23
To: Thomson, Martin
Cc: Tschofenig, Hannes (NSN - FI/Espoo); 
aki(_dot_)niemi(_at_)nokia(_dot_)com; 
krisztian(_dot_)kiss(_at_)nokia(_dot_)com; 
salvatore(_dot_)loreto(_at_)ericsson(_dot_)com; 
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



_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf