Friday, March 26, 2010

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

(dropping ietf@ietf.org)

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


> -----Original Message-----
> From: Ben Campbell [mailto:ben@estacado.net]
> Sent: Sunday, 21 March 2010 4:09 PM
> To: Thomson, Martin
> Cc: Tschofenig, Hannes (NSN - FI/Espoo); aki.niemi@nokia.com;
> krisztian.kiss@nokia.com; salvatore.loreto@ericsson.com Loreto; Cullen
> Jennings; Rohan Mahy; IETF-Discussion list; General Area Review Team;
> Hannes Tschofenig; geopriv@ietf.org; Adam Roach
> Subject: Re: Gen-ART LC/Tekechat Review of draft-ietf-geopriv-loc-
> filters-10
>
>
> On Mar 21, 2010, at 3:49 PM, Thomson, Martin wrote:
>
> > 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.
> >
>
> 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.
>
>
>
>
>
>
>

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv