Thanks for the update. It looks like you got all the comments, bar this one:
> >Section 3.4: It's unclear what the effect of uncertainty is on
> >this. An implementation is asked to make a Boolean decision,
> >but not given the necessary tools to ensure that the decision
> >it makes is the one that is expected.
This is one of the issues I thought worth looking at. Is it necessary for interoperability that we define how a notifier/PA determines that a location containing uncertainty is inside or outside a particular region.
I'd like to see a simple statement to the effect:
If the Target was previously outside the region, the notifier sends a notification when the Target's location is within the region with at least 50% confidence. Similarly, when a Target starts within the region, a notification is sent when the Target's location moves outside the region with at least 50% confidence.
I'll let you decide if you want to include this extra explanatory information:
Note that having 50% confidence that the Target is inside the area does not correspond to 50% outside. Confidence that the location is within the region, plus confidence that the location is outside the region cannot be 100%. The total confidence depends on the confidence in the original location, which is always less than 100% (95% is recommended in [RFC5491]). The benefit of this is that notifications are naturally limited: small movements at the borders of the region do not trigger notifications.
c.f. <http://tools.ietf.org/html/draft-thomson-geopriv-uncertainty-03#section-4.3>
> -----Original Message-----
> From: Tschofenig, Hannes (NSN - FI/Espoo)
> [mailto:hannes.tschofenig@nsn.com]
> Sent: Wednesday, 21 October 2009 3:50 AM
> To: Thomson, Martin; Alissa Cooper; GEOPRIV
> Subject: RE: [Geopriv] WGLC: draft-ietf-geopriv-loc-filters-06
>
> Hi Martin,
>
> I believe I have addressed your comments and I have also added some
> further text to constraint the functionality in the document further to
> avoid interoperability problems.
>
> Here is the latest version that I plan to submit:
> http://www.tschofenig.priv.at/svn/Filters/draft-ietf-geopriv-loc-
> filters
> -07.txt
>
> Ciao
> Hannes
>
> >-----Original Message-----
> >From: geopriv-bounces@ietf.org
> >[mailto:geopriv-bounces@ietf.org] On Behalf Of ext Thomson, Martin
> >Sent: 13 October, 2009 06:01
> >To: Alissa Cooper; GEOPRIV
> >Subject: Re: [Geopriv] WGLC: draft-ietf-geopriv-loc-filters-06
> >
> >In my opinion, this document is ready for publication.
> >
> >I have a few very minor issues, and a bunch of nits. None of
> >these are so important that they need to be fixed immediately.
> >
> >I'm sure that Rohan's affiliation has changed. Last time I
> >saw him it certainly wasn't Plantronics.
> >
> >Title: The "reporting" aspect was long ago removed. I'd
> >propose simply:
> > Filtering Location Notifications in Presence No need to
> >mention PIDF-LO. There might be a need to mention SIP, in
> >which case it becomes
> > Filtering Location Notifications in Session Initiation
> >Protocol (SIP) Presence
> >
> >Section 1, OLD:
> > RFC 3265 can be used with so-called 'filters'...
> >NEW:
> > SIP events [RFC3265] can be used with filters...
> >
> >Q: what is "so-called" about them? Is the term not defined in
> >RFC 4660? This phrase has negative connotations. (I suspect
> >that this is symptomatic of Rohan's views on the filtering
> >docs. Not undeserved, but also unnecessary.)
> >
> >Section 1: Is it worth stating in the introduction that this
> >document mixes new mechanisms with documentation of existing
> >mechanisms?
> >
> >Section 1: wayward apostrophe: s/presence event
> >package'/presence event package/
> >
> >Section 3.*: Suggest a better namespace prefix to use in
> >examples might be "lf:" rather than the generic "ext:".
> >
> >Section 3.4: It's unclear what the effect of uncertainty is on
> >this. An implementation is asked to make a Boolean decision,
> >but not given the necessary tools to ensure that the decision
> >it makes is the one that is expected.
> >
> >Section 3.5:
> > For the example above, if the 'exact' attribute was "true", then
> the
> > only possible response is either a "civic" location or an error
> > message.
> >What does it mean to provide an "error message" in the context
> >of being unable to provide the requested location type? In
> >this case, I'd suggest:
> > s/or an error message./or no location information./
> >
> >Section 3.6: (This is recent text, so this is actually the
> >first time that I've read it.) No specific comment here
> >(aside from a wayward period.). However, the example does
> >look a little like a wall of text. I can see several
> >paragraphs there. Perhaps if this "example" was split into a
> >sub-section, there wouldn't be a tendency to try to create the
> >ultimate paragraph.
> >
> >Section 5: I don't think that the third bullet is necessarily
> >true. This document doesn't really build in PIDF-LO, but it
> >does depend on its format. If, in that fact, there are
> >security considerations, I'm not aware of them.
> >
> >Section 5: Is it worth noting that there are no policies that
> >dictate what filters may be used? I tend to object to live
> >tracking as a general rule, but am offered no means to control
> >this behaviour by watchers (I can tell them not to get
> >location, even black out certain areas, but not limit rates).
> >Are we satisfied that this document leans on the "local
> >policy" crutch in this area?
> >
> >--Martin
> >
> >
> >> -----Original Message-----
> >> From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On
> >> Behalf Of Alissa Cooper
> >> Sent: Tuesday, 13 October 2009 2:58 AM
> >> To: GEOPRIV
> >> Subject: [Geopriv] WGLC: draft-ietf-geopriv-loc-filters-06
> >>
> >> This is a GEOPRIV Working Group Last Call for comments on
> >> draft-ietf-geopriv-loc-filters-06
> >> (http://tools.ietf.org/html/draft-ietf-geopriv-loc-filters-06)
> >>
> >> Please send your comments no later than Monday, November 2, 2009.
> >>
> >>
> >>
> >> _______________________________________________
> >> Geopriv mailing list
> >> Geopriv@ietf.org
> >> https://www.ietf.org/mailman/listinfo/geopriv
> >
> >---------------------------------------------------------------
> >---------------------------------
> >This message is for the designated recipient only and may
> >contain privileged, proprietary, or otherwise private information.
> >If you have received it in error, please notify the sender
> >immediately and delete the original. Any unauthorized use of
> >this email is prohibited.
> >---------------------------------------------------------------
> >---------------------------------
> >[mf2]
> >_______________________________________________
> >Geopriv mailing list
> >Geopriv@ietf.org
> >https://www.ietf.org/mailman/listinfo/geopriv
> >
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
