Subject: [Geopriv] WGLC: draft-ietf-geopriv-loc-filters-06

From: Alissa Cooper <[email-masked]>
Date: Mon, 12 Oct 2009 16:58:24 +0100

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.

---

From: "Carl Reed" <[email-masked]>
Date: Mon, 12 Oct 2009 12:21:27 -0600

One quick comment: "Notications" in the title should be "Notifications"

Cheers

Carl Reed
OGC

----- Original Message ----- 
From: "Alissa Cooper" <[email-masked]>
To: "GEOPRIV" <[email-masked]>
Sent: Monday, October 12, 2009 9:58 AM
Subject: [Geopriv] WGLC: draft-ietf-geopriv-loc-filters-06

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

---

From: "Thomson, Martin" <[email-masked]>
Date: Mon, 12 Oct 2009 22:01:10 -0500

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: [email-masked] [mailto:[email-masked]] On
> Behalf Of Alissa Cooper
> Sent: Tuesday, 13 October 2009 2:58 AM
> To: 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]

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Tue, 20 Oct 2009 19:49:40 +0300

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

>From: [email-masked] 
>[mailto:[email-masked]] 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
>
>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.
>
>   Filtering Location Notifications in Presence No need to 
>mention PIDF-LO.  There might be a need to mention SIP, in 
>which case it becomes
>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 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:
>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:
>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
>
>

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 21 Oct 2009 07:55:37 +0800

Hi Hannes,

> >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>

> From: Tschofenig, Hannes (NSN - FI/Espoo)
> [mailto:[email-masked]]
> 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,
>

---

From: Brian Rosen <[email-masked]>
Date: Wed, 21 Oct 2009 08:59:27 -0400

FWIW, I like this, including the note.

Brian

On 10/20/09 7:55 PM, "Thomson, Martin" <[email-masked]> wrote:

> 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.
> 
>    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.
> 
>    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>
> 
>

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Wed, 21 Oct 2009 17:25:34 +0300

Thanks for the quick feedback and I will put this text into the
document. 

>From: ext Thomson, Martin [mailto:[email-masked]] 
>Sent: 21 October, 2009 02:56
>To: Tschofenig, Hannes (NSN - FI/Espoo); Alissa Cooper; GEOPRIV
>> >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.
>
>   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.
>
>   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. 
>> further text to constraint the functionality in the document further 
>> to avoid interoperability problems.
>> 
>> >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.
>> >
>> >   Filtering Location Notifications in Presence No need to mention 
>> >PIDF-LO.  There might be a need to mention SIP, in which case it 
>> >becomes
>> >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 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:
>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
>> >
>> >
>[mailto:[email-masked]] On 
>> >> Behalf Of Alissa Cooper
>> >This message is for the designated recipient only and may contain 
>> >privileged, proprietary, or otherwise private information.
>> >immediately and delete the original.  Any unauthorized use of this 
>> >email is prohibited.

---

From: [email-masked]
Date: Wed, 21 Oct 2009 10:44:58 -0400 (EDT)

I also like the explanatory note.

Carl