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

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Mon, 22 Mar 2010 00:24:39 +0200

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? 

>-----Original Message-----
>From: ext Ben Campbell [mailto:[email-masked]] 
>Sent: 21 March, 2010 18:23
>To: Thomson, Martin
>Cc: Tschofenig, Hannes (NSN - FI/Espoo); [email-masked]; 
>[email-masked]; [email-masked]; 
>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
>
>

---

From: Ben Campbell <[email-masked]>
Date: Sun, 21 Mar 2010 15:31:17 -0700

> just cannot send something.

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.

---

From: "Thomson, Martin" <[email-masked]>
Date: Mon, 22 Mar 2010 06:49:05 +0800

So, the rate control does recognize that the first notify message can be empty or might not contain all state:

   $3.2:  Thus, the first notification might be empty, or certain values might be absent.

The text that was originally quoted, that we're discussing is this:

   A compliant notifier MUST generate notifications whenever the time
   since the most recent notification exceeds the value in the "max-
   interval" parameter.  Depending on the event package and subscriber
   preferences indicated in the SUBSCRIBE request, the NOTIFY request
   MUST contain either the current full state or the partial state
   showing the difference between the current state and the last
   successfully communicated state.

The second sentence, taken out of context might be interpreted as Ben did - a blanket prohibition on empty notify messages.  Reading through again, with complete context, I'm not sure that I agree with this assessment.  If the rate-control editors are amenable to a clarification in this section, it would be nice, but I don't see it as necessary.

--Martin
________________________________________
From: Ben Campbell [[email-masked]]
Sent: Sunday, 21 March 2010 3:31 PM
To: Tschofenig, Hannes (NSN - FI/Espoo)
Cc: Thomson, Martin; [email-masked]; [email-masked]; [email-masked] Loreto; Cullen Jennings; Rohan Mahy; IETF-Discussion list; General Area Review Team; Hannes Tschofenig; [email-masked]; Adam Roach
Subject: Re: Gen-ART LC/Tekechat Review of draft-ietf-geopriv-loc-filters-10

---

From: Ben Campbell <[email-masked]>
Date: Sun, 21 Mar 2010 16:09:25 -0700

> The second sentence, taken out of context might be interpreted as Ben did - a blanket prohibition on empty notify messages.  Reading through again, with complete context, I'm not sure that I agree…

i did not take it to be blanket prohibition on empty NOTIFY requests. I took it to be a prohibition against empty NOTIFY requests sent as a result of the expiration of a max-interval parameter. The language I objected to in the location filter draft seemed to explicitly suggest empty notifies as a result of max-interval parameter.

Here's the language I refer to, in section 3.6, last sentence of paragraph 1 and first sentence of 2:

>    [...] Whenever the time since the
>    most recent notification exceeds the value in the "max-interval"
>    parameter, the current state would be sent in its entirety, just like
>    after a subscription refresh.
> 
>    If complete state is not immediately available, then an empty NOTIFY
>    is sent immediately and subsequently a separate NOTIFY containing
>    location is generated some time between the time included in 'min-
>    interval' and the time in 'max-interval'.  An important use case for
>    location based applications focuses on the behavior of the initial
>    NOTIFY message(s) and the information it returns, for example in case
>    of emergency call routing.  When an initial NOTIFY is transmitted it
>    might not include complete state.

Although the last couple of sentences talk about, I read the first part as suggesting that if state is not available when a max-interval expires, you should send an empty NOTIFY.

---

From: "Thomson, Martin" <[email-masked]>
Date: Sat, 27 Mar 2010 10:06:58 +0800

> OTOH, 3 occurrences of the word "immediately" in the same sentence
> might be a bit much :-) Maybe something like the following:
> 
> A notifier is required to send a NOTIFY request immediately after
> creation of a subscription. If state is not available at that time,
> then the NOTIFY request may be sent with no content. ... "

Quite right.  I'm just tired.  That should have been immediately obvious.

---

From: "Thomson, Martin" <[email-masked]>
Date: Sat, 27 Mar 2010 05:51:58 +0800

(dropping [email-masked])

So I'd like to close this, so I'll summarize and propose an action:

Question:  max-interval expires, is it permitted for a notifier to generate an empty notify?

Position:  This is NOT desirable behaviour.  A notifier has advance warning that it needs to generate state and can do so.  I don't actually see a need to support empty notifications once the subscription is established and the notifier is providing state.  It's only going to lead to unexplained holes.

Text: (for loc-filters, no change to rate-control)

OLD:
   If complete state is not immediately available, then an empty NOTIFY
   is sent immediately and subsequently a separate NOTIFY containing
   location is generated some time between the time included in 'min-
   interval' and the time in 'max-interval'.  An important use case for
NEW:
   Immediately after the creation of a subscription, 
   if complete state is not immediately available, then an empty NOTIFY
   is sent immediately.  A separate NOTIFY containing
   location is subsequently generated some time between the time included in 'min-
   interval' and the time in 'max-interval'.  An important use case for

I think that this addresses the problem.  Whether or not this was the original intent of the authors, we didn't really discuss this particular wrinkle.

--Martin

> From: Ben Campbell [mailto:[email-masked]]
> Sent: Sunday, 21 March 2010 4:09 PM
> To: Thomson, Martin
> [email-masked]; [email-masked] Loreto; Cullen
> Jennings; Rohan Mahy; IETF-Discussion list; General Area Review Team;
> Hannes Tschofenig; [email-masked]; Adam Roach
> > The second sentence, taken out of context might be interpreted as Ben
> did - a blanket prohibition on empty notify messages.  Reading through
> again, with complete context, I'm not sure that I agree with this
> assessment.  If the rate-control editors are amenable to a
> clarification in this section, it would be nice, but I don't see it as
> necessary.
> >
> 
> i did not take it to be blanket prohibition on empty NOTIFY requests. I
> took it to be a prohibition against empty NOTIFY requests sent as a
> result of the expiration of a max-interval parameter. The language I
> objected to in the location filter draft seemed to explicitly suggest
> empty notifies as a result of max-interval parameter.
> 
> Although the last couple of sentences talk about, I read the first part
> as suggesting that if state is not available when a max-interval
> expires, you should send an empty NOTIFY.
> 
> 
> 
> 
> 
> 
>

---

From: Ben Campbell <[email-masked]>
Date: Fri, 26 Mar 2010 15:06:41 -0700

I think it's almost there. The problem seems to come from the last sentence in the previous paragraph:

> Whenever the time since the

I was taking that to set the context for the problem paragraph, and your language breaks that connection. I _think_ that's the right thing, but I suggest interested parties look at both paragraphs together.

OTOH, 3 occurrences of the word "immediately" in the same sentence might be a bit much :-) Maybe something like the following:

A notifier is required to send a NOTIFY request immediately after creation of a subscription. If state is not available at that time, then the NOTIFY request may be sent with no content. ... "