Subject: [Geopriv] Long review of draft-ietf-geopriv-loc-filters-07

From: "James M. Polk" <[email-masked]>
Date: Mon, 02 Nov 2009 19:17:46 -0600

I have attached my review of draft-ietf-geopriv-loc-filters-07.

It is a PDF of my marked up version.  It has enough comments and 
suggestions that putting this in email would be very difficult - but 
I will if the chairs believe that's best.

Some of the comments are nits, some of the comments were where a 
topic or sentence didn't make sense (perhaps with its placement were 
it was in the paragraph), and some of the comments were technical.  I 
hope they are obvious when anyone reads them.

I can send the MS WORD version with the active track changes to the 
authors if they want that version.

If there are any questions or comments about my review comments, 
please don't hesitate to send me a note.

James

---

From: Brian Rosen <[email-masked]>
Date: Tue, 03 Nov 2009 09:10:44 -0400

Thank you for your review.  The co-authors will probably have some more
comments as we actually edit the document, but I wanted to respond to some
of your more important comments now.

Your comment that '"Alternative" makes it seem like Conveyance doesn't need
to be used at all -- which is absolutely false. The only want a NOTIFY can
contain a PIDF-LO is through understanding of SIP Location Conveyance. This
forces Conveyance to be moved from an Informative reference to a Normative
reference.  If anything, this doc is a formal update to Location Conveyance
because it specifies how to augment Conveyance by doing additional
functions/capabilities not found in Conveyance.'

is incorrect.  Sending location via a presence service was the initial way,
and until -conveyance, the only way to send location using the SIP protocol.
The appearance of -conveyence in no way diminishes, or alters, use of
presence to send location.  Presence IS an alternative way to use SIP to
send location.  It uses NOTIFY without a Geolocation header.  This document
discusses presence, and is not related to -conveyence, and this document in
no way updates -conveyence.

Your comment 'Does this accurately describe an extension (to 4661)?'
confuses me.  I did check, 4661 describes 'extensions'.  We do extend the
schema in a way that I think conforms to section 4 of 4661.  What were you
concerned about?

When you say 'What about leaving a room into a hallway? Neither are a circle
or a polygon (that's been allowed into the Geopriv WG to date - though a
couple of IDs have tried to have the WG include these).
This might be covered by #4, but want to be sure.'  were you asking about
leaving a room described using the civic form of location?  If so, then yes,
#4 is how you describe that.  One could describe the room as a polygon of
course.

Your concern about #5 (type of information) is answered in section 3.5.  The
filter allows you to ask for geo, civic or any.

Yes, you would need four <changed> filters to express an 'OR'.  The current
syntax has implied 'AND'.  I think that is okay.  I would like to hear from
others who may have an opinion on that.  It would be a large syntax change
to come up with a reasonable way to have AND/OR syntax included within this
element, and I don't think it's worth it.  The alternative of having a flag
that was set to either "AND" or "OR" doesn't strike me as reasonable.

I think it probably is a mistake to use "LIS".  Rather, I think PS is
appropriate, or maybe just Notifier.

You said "It should be possible for the subscriber to be told - if the
'exact' attribute is set - that is has location, but not in the format the
subscriber wants it in."

Could you suggest a reasonable syntax?  I thought about this for a while,
and while I'm somewhat sympathetic to the problem you raise, there is no
similar syntax in any other filter: if you filter away the data, you aren't
told that there was data, but your filter made it appear as if there is no
data (you don't get a NOTIFY). I would think that if we did something on
this, it would have to be generalized.

In 3.6, I don't think the text that refers to "immediately available" is
talking about something relating to the initial NOTIFY.  Rather,  it's
talking about location update in the context of partial state availability.
If the filter says to, you get a partial state update in a time determined
by rate-control.

While I think we can reword the text you are objecting to below Figure 8,
which discusses changing the rate after the first update, your final comment
'Where does this doc say that getting location for the emergency case MUST
NOT have a one-time only subscription (because of just what is in the
paragraph above?' is confusing.  The text is talking about a circumstance
where the emergency service wants TWO locations: one which is available
quickly, and is good enough to route the call, and then another, subsequent
location, which is more accurate, and good enough to dispatch to.  However,
getting both of them is optional.  Some elements (such as the routing
elements) will need only the first.  Some elements (the dispatcher) only
needs the second.  Some need both.

Brian

On 11/2/09 9:17 PM, "James Polk" <[email-masked]> wrote:

> _______________________________________________
> Geopriv mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/geopriv

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Tue, 3 Nov 2009 16:29:54 -0800

Hi James, 

Thanks for your detailed review. I am in the process of updating it and have
comments here and there. 

Here is one:

Draft Text:

--------

<?xml version="1.0" encoding="UTF-8"?>
<filter-set xmlns="urn:ietf:params:xml:ns:simple-filter">
    <ns-bindings>
        <ns-binding prefix="dyn" 
            urn="urn:ietf:params:xml:schema:pidf:dynamic"/>        
    </ns-bindings>
    <filter id="123" uri="sip:[email-masked]">
        <trigger>
            <changed by="3"> [<---James]
              //dyn:speed
            </changed>
        </trigger>
    </filter>
</filter-set>

------

[James] 

I get the XML,
but I don't see what the speed now is of
the device/target?
What if this device is moving at 200kmph,
where would that be placed in the XML?
Of, is this left for the application at the
subscriber to calculate?
If the latter is true, something needs to be
said about this expectation.

------

The filter would not tell you what the current speed is. 

The current document only supports 'by' and hence you cannot say something
like 'tell me when he goes faster than 100kmph'. 

Ciao
Hannes

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Tue, 3 Nov 2009 16:36:24 -0800

Here is another one: 

Draft Text:

-----

3.3. Element Value Changes
Changes in values, for example related to civic location information,
is provided by the base functionality offered with RFC 4661 utilizing
the <changed> element.
Figure 3 shows an example where a notification is sent when the civic
address tokens A1, A2, A3, or PC change (all 4 must change in order
to let the <trigger> element evaluate to TRUE).

------

Wow do I not
want that limitation. I want to be able to
tell when the device has crossed a city
boundary (into another city) while still
looking to see it the device has changed
states/territories yet.
I understand that PC changes might be
too often (but not always).
Is the alternative to have 4 separate
<changes> filters to get what I'm
describing here?
That seems clumbersome.

-----

This is how RFC 4661 works. Telling whether more than one PC changed
independently requires multiple <changes> filters. 

Ciao
Hannes

>-----Original Message-----
>From: Hannes Tschofenig [mailto:[email-masked]] 
>Sent: 03 November, 2009 16:30
>To: 'Brian Rosen'; 'James Polk'; [email-masked]'
>Subject: RE: [Geopriv] Long review of draft-ietf-geopriv-loc-filters-07
>
>Hi James, 
>
>Thanks for your detailed review. I am in the process of 
>updating it and have comments here and there. 
>
>Here is one:
>
>Draft Text:
>
>--------
>
>but I don't see what the speed now is of the device/target?
>What if this device is moving at 200kmph, where would that be 
>placed in the XML?
>Of, is this left for the application at the subscriber to calculate?
>If the latter is true, something needs to be said about this 
>expectation.
>
>------
>
>The current document only supports 'by' and hence you cannot 
>say something like 'tell me when he goes faster than 100kmph'. 
>
>Ciao
>Hannes
>

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 4 Nov 2009 08:45:08 +0800

Hi James,

It's good to see that you're putting time in reviewing this.  There are a lot of useful comments here.

It's hard to line comments up with the text that they correspond to.  Can you share the commented word doc as well?

I'll use your numbers...

[JMP3+; edit] I don't think that you meant to use this discreet:

  discreet, adj, marked by prudence or modesty and wise self-restraint
  discrete, adj, constituting a separate entity or part

I tend to use continuous-valued and discrete-valued when talking about the difference between location and other presence data.  I had no problem understanding the intent of "continuous gradient".

[JMP7] I actually think that this is not necessary information for the introduction.  It could be removed.

[JMP26] regarding the trigger matching ALL, this is an RFC 4661 requirement.  If you want to trigger on changes in any of the referenced elements, then you have to specify multiple filters with a trigger on each element.  Yeah, it's verbose, but that's the way that 4661 is.

[JMP32] no need for labels

[JMP35] that should be notifier/PA

[JMP39] (on error messages) I had the same comment - I believe that if exact is true and the location type cannot be provided, then no location is included.  That's probably the only option available to the notifier.

[JMP41] (regarding the comparison to HELD) This comment is useful for establishing context.  The function described in this section can be difficult to understand

[JMP43] (regarding the notify) This doesn't remove the requirement that the initial notify (absent of state) be provided immediately.  This just establishes when the first _useful_ notify arrives.

[JMP48] (regarding snide comments about suitability of just referencing some policy documents) This document can be vague because it does not rely on these documents, these are information pointers only.  Informational references do not need to be as rigorously tested as the normative references required of the DHCP location URI work.

[JMP51] I think that Brian answered this adequately.

--Martin

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of James M. Polk
> Sent: Tuesday, 3 November 2009 12:18 PM
> To: [email-masked]
> Subject: [Geopriv] Long review of draft-ietf-geopriv-loc-filters-07
>

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Tue, 3 Nov 2009 16:54:34 -0800

Another one: 

------

          The Notifier SHOULD return the requested location type or types.
The location types the
          Notifier returns also depends on the setting of the optional
"exact" attribute. If the
          'exact' attribute is set to "true" then the Notifier MUST return
either the requested
          location type or no location information. The 'exact' attribute
does not apply (is
          ignored) for a request for a location type of "any".
------

It should be
possible for the subscriber to be told - if
the 'exact' attribute is set - that is has
location, but not in the format the
subscriber wants it in.

------

The text is intentionally in line with the HELD specification. 

Ciao
Hannes

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Tue, 3 Nov 2009 17:31:55 -0800

Another response: 

---- Draft Text --- 

Each of these documents listed above comes with a security
consideration section but the security and privacy aspects are best
covered by the SIP presence event package, see Section 9 of
[RFC3856], and with the GEOPRIV architectural description found in
[I-D.ietf-geopriv-arch]. The functionality for uploading
authorization policies and other information that limit access to
location information are provided by other protocols, such Common
Policy [RFC4745], Geolocation Policy [I-D.ietf-geopriv-policy] or
more recent work around HELD context
[I-D.winterbottom-geopriv-held-context]. The functionality described
in this document extends the filter framework with location specific
filters. Local policies might be associated with the usage of
certain filter constructs and with the amount of notifications
specific filter settings might cause.

------

I find it curious
why these references work for this
document - knowing there is no defined
transport for loading such policies - but
the ID creating a DHCP Option for
Location URIs requires a policy transport
defined. why is that?

-------

The security consideration section essentially says two tings: 

* these location filters are just an extension in a larger system. Hence,
the security of these other building blocks are applicable. 

* this document does not define any new security mechanisms for
location-specific filters. 

Ciao
Hannes

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 4 Nov 2009 12:52:54 +0800

RFC 4661 allows you to request a notification if a value changes _to_ a value, _from_ a value, or _by_ a certain amount.  For speed, you could specify <changed to="360">  to request notification if the speed changes to 100 km/h, however there's a good chance that it goes straight past the value you are interested in.

It's impossible to specify every possible target value for something continuous like speed or position.  You could cover 341, 342, 343, ..., 368, 369, 370, but when the value comes up at 364.3, you still miss the notification.

The <changed by="x"> element can be used for most use cases, although some complications are inevitable.  The advantage is that this is pretty simple and, for those with a 4661 implementation, zero cost.  Think of it as an opportunity for other specifications to define better filters.

--Martin

> Behalf Of Hannes Tschofenig
> Sent: Wednesday, 4 November 2009 11:30 AM
> To: 'Brian Rosen'; 'James Polk'; [email-masked]
> Subject: Re: [Geopriv] Long review of draft-ietf-geopriv-loc-filters-07
> 
> Hi James,
>

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 04 Nov 2009 01:01:20 -0600

Hannes

in-line below

>The filter would not tell you what the current speed is.

ok, I get that now (though it isn't exactly stated this way explicitly).

Let me pose a scenario for you and see if there is just one NOTIFY or 
there are many:

Alice is the target.  Initially she isn't moving.  her device accepts 
a subscription with a <changed by="3"> element in it.  She starts to 
accelerate (linear or not) until se reaches 100mps.  How many NOTIFYs are sent?

1 because she crossed the by="3" attribute, or each time she 
accelerates more than 3mps faster since the last NOTIFY.

I'm guessing the latter, but want to be sure.

Again, this isn't exactly explicitly stated in the -07 rev.

James

BTW -- I think Alice sending a NOTIFY every time she accelerates or 
decelerates by="3" would be useful information, especially in the 
emergency case.

It's toobad we cannot have a "is moving" but less than by="3" 
indication.  This would tell us it is in a stationary position or 
not. Again, for a device/inventory tracking application, this would 
seem like very useful information to have.

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 04 Nov 2009 01:05:34 -0600

Hannes

in-line

>independently requires multiple <changes> filters.

ah -- but this is something I don't see in the XML schema, but I may 
have missed it.

Can you verify that the text says that it is possible to have 
multiple <changes> filters.

This could be a short paragraph saying something like:

         In times where you want to know if individual CAtypes change,
         put them into separate <changes> filters to ensure you are
         notified when any of the element values change.

James

---

From: [email-masked]
Date: Wed, 4 Nov 2009 09:06:38 -0500 (EST)

I believe that months ago I mentioned the work being done in Europe on
event alerting, filtering, etc. This work is part of a much larger
European initiative for pan European spatial data infrastructure
(INSPIRE), Risk and Disaster Management (ORCHESTRA), and Sensors Anywhere
(SANY).

Specifically, those communities have defined an event pattern markup
language that has been submitted to the OGC. From the document forward:

The patterns and functionality described in this document can be applied
to create filters that operate on event streams / clouds. Therefore, it
can be regarded as an enhancement of the OGC Filter Encoding Standard
(FES). The discussion in this document is related to all services that
store or process data, because there are lots of events generated or
received by these services (e.g. whenever a new objects is created /
inserted at the service). Applying the techniques described in this
specification to those events enables on-the-fly filtering of data and
derivation of higher-level information. This work was supported by the
OSIRIS project. OSIRIS is an Integrated Project (contract number 0033475)
co-funded by the Information Society and Media DG of the European
Commission within the RTD activities of the Thematic Priority Information
Society Technologies.

The work is Europe is accelerating and the Asian IT community is now also
involved.

My reason for bringing this up again is that I am concerned that the
GeoPRIV community is creating another pattern for location based event
filtering that is inconsistent with the work  being done in Europe and
Asia. I should also add that elements used in EML, such as Observations
and Measurements and Filter, are soon to be ISO International Standards.

If anyone is interested, the document is here:

http://portal.opengeospatial.org/files/?artifact_id=29566

Regards

Carl

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Wed, 04 Nov 2009 19:34:27 +0100

Exactly. 

The current specification settles for the 'by' only and does not require you to implement anything else because that was the requirement in the previous spec. 

I tend to agree that defining a new purpose-built filter would probably more powerful. 

-------- Original-Nachricht --------
> Datum: Wed, 4 Nov 2009 12:52:54 +0800
> Von: "Thomson, Martin" <[email-masked]>
> An: Hannes Tschofenig <[email-masked]>, \'Brian Rosen\' <[email-masked]>, \'James Polk\' <[email-masked]>, "[email-masked]" <[email-masked]>
> Betreff: RE: [Geopriv] Long review of draft-ietf-geopriv-loc-filters-07

> RFC 4661 allows you to request a notification if a value changes _to_ a
> value, _from_ a value, or _by_ a certain amount.  For speed, you could
> specify <changed to="360">  to request notification if the speed changes to 100
> km/h, however there's a good chance that it goes straight past the value you
> are interested in.
> 
> It's impossible to specify every possible target value for something
> continuous like speed or position.  You could cover 341, 342, 343, ..., 368,
> 369, 370, but when the value comes up at 364.3, you still miss the
> notification.
> 
> The <changed by="x"> element can be used for most use cases, although some
> complications are inevitable.  The advantage is that this is pretty simple
> and, for those with a 4661 implementation, zero cost.  Think of it as an
> opportunity for other specifications to define better filters.
> 
> --Martin
>

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Wed, 04 Nov 2009 19:40:51 +0100

I agree with you that there are useful cases where one would want to state something like "please send me a notification when the target moves faster than XYZ kmph."

We would have to define a custom filter for doing that since just applying the filter RFC does not give us all we want. 

Ciao
Hannes

-------- Original-Nachricht --------
> Datum: Wed, 04 Nov 2009 01:01:20 -0600
> Von: "James M. Polk" <[email-masked]>
> An: "Hannes Tschofenig" <[email-masked]>, "\'Brian Rosen\'" <[email-masked]>, [email-masked]
> Betreff: Re: [Geopriv] Long review of draft-ietf-geopriv-loc-filters-07

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Wed, 04 Nov 2009 19:51:56 +0100

That's a useful addition. I added the paragraph. 
-------- Original-Nachricht --------
> Datum: Wed, 04 Nov 2009 01:05:34 -0600
> An: "Hannes Tschofenig" <[email-masked]>, "\'Hannes Tschofenig\'" <[email-masked]>, "\'Brian Rosen\'" <[email-masked]>, [email-masked]

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Wed, 04 Nov 2009 20:03:13 +0100

Hi Carl, 

it would be nice to re-use something out there already. In some sense we do that by re-using the filters RFCs and we only define extensions to that RFC. 

Now, the problem with that approach was that it is already fairly complex and I therefore suggested to the group that we profile it to make the implementation simpler. I still believe that we are far away from that today given that we build on a fairly undeployed SIP presence mechanism but anyway... 

Now to your proposal. I like that there are these EU funded projects producing research results. The problem is that they always come up with super complex mechanisms that even they loose interest in when their research project is over. 

If you just look at the unreadable specification (and this includes the unreadable examples). I am not sure whether we do not make the work on this specification even worse by adding support for this event filtering mechanism.  

Why cannot these guys write some easy to understand, and easy to implement solution that does not pretend to solve all the problems of event filtering? 

I am not convinced anymore of the value of extremely generic solutions. From my experience it is more helpful to start small and to get some implementations/deployment and then, if the implementer/deployment feedback arrives, to extend and fix the spec. 

Ciao
Hannes

-------- Original-Nachricht --------
> Datum: Wed, 4 Nov 2009 09:06:38 -0500 (EST)
> Von: [email-masked]
> An: "James M. Polk" <[email-masked]>
> CC: "Hannes Tschofenig" <[email-masked]>, "\'Brian Rosen\'" <[email-masked]>, [email-masked]
> Betreff: Re: [Geopriv] Long review of draft-ietf-geopriv-loc-filters-07 -      OGC Event Patter Markup

> > accelerate (linear or not) until se reaches 100mps.  How many NOTIFYs
> are
> > sent?
> >

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Wed, 04 Nov 2009 20:30:11 +0100

Another mail on the same subject. 

I am actually wondering whether a generic approach shouldn't better go for just uploading PL/SQL code instead some XML document. Maybe that would be more flexible.

Maybe someone could, for the fun of it, try to replicate the functionality of the existing specifications in PL/SQL. 

Ciao
Hannes

---

From: Alissa Cooper <[email-masked]>
Date: Sun, 8 Nov 2009 16:35:53 +0900

To James' point, though, I think replacing the word "uploading" with  
the word "specifying" would more precisely describe what you get out  
of common policy and geolocation policy (and is still accurate for  
held-context).

Alissa