Subject: [Geopriv] Geolocation Policy Draft Update

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 02 Oct 2007 15:53:10 +0200

Hi all,

Henning and I worked on the draft update to reflect the comments 
received by the IESG, Gen-Art reviewer, and SecDir reviewer.

Here is what we did to produce -13:
* Removed the location-specific conditions from the document.
* Added text to the security consideration section
* Addressed comments by Russ & Jon regarding location transformation.

Obviously, this is a major change to the draft.

Here is the new draft:
http://www.ietf.org/internet-drafts/draft-ietf-geopriv-policy-13.txt

We haven't added an element that is able to contain a description of the 
rule. I will post a separate mail on this issue. [This refers to one of 
Lisa's comments.]

We believe that this update reflects the comments (expect for the 
comment about the rule description):
Tim: http://www1.ietf.org/mail-archive/web/geopriv/current/msg04354.html
Sam: http://www1.ietf.org/mail-archive/web/geopriv/current/msg04354.html
Lisa: http://www1.ietf.org/mail-archive/web/geopriv/current/msg04356.html
Russ: 
https://datatracker.ietf.org/idtracker/draft-ietf-geopriv-policy/comment/71948/
https://datatracker.ietf.org/idtracker/draft-ietf-geopriv-policy/comment/71949/
Jari: 
https://datatracker.ietf.org/idtracker/draft-ietf-geopriv-policy/comment/71837/
Chris: 
https://datatracker.ietf.org/idtracker/draft-ietf-geopriv-policy/comment/71973/
Jon: 
http://www.nabble.com/COMMENT-on-draft-ietf-geopriv-policy-(Jon-Peterson)-t4514841.html
Eric Gray: 
http://www1.ietf.org/mail-archive/web/gen-art/current/msg02245.html

Ciao
Hannes

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

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 02 Oct 2007 16:31:24 +0200

Here is the diff version:
http://tools.ietf.org/rfcdiff?url1=http://www.ietf.org/internet-drafts/draft-ietf-geopriv-policy-12.txt&url2=http://www.ietf.org/internet-drafts/draft-ietf-geopriv-policy-13.txt
or
http://tinyurl.com/ywusrb

Ciao
Hannes

Hannes Tschofenig wrote:
> We haven't added an element that is able to contain a description of 
> the rule. I will post a separate mail on this issue. [This refers to 
> one of Lisa's comments.]
>

---

From: Sam Hartman <[email-masked]>
Date: Tue, 02 Oct 2007 11:23:29 -0400

Does the WG actually have consensus to remove location-specific
conditions?

---

From: "Tschofenig, Hannes (NSN - DE/Munich)" <[email-masked]>
Date: Tue, 2 Oct 2007 17:30:17 +0200

I am waiting for the group to provide us some feedback on the proposed change ...

Ciao
Hannes

> -----Ursprüngliche Nachricht-----
> Von: ext Sam Hartman [mailto:[email-masked]] 
> Gesendet: Dienstag, 2. Oktober 2007 17:23
> An: Hannes Tschofenig
> Cc: GEOPRIV; Tim Polk; Russ Housley; 'Chris Newman'; 
> [email-masked]
> Betreff: [Geopriv] Re: Geolocation Policy Draft Update
>

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 3 Oct 2007 18:22:06 -0500

I was going to disagree with the change, because I always thought that the condition was the best part of the draft.  I changed my mind.  The condition isn’t ready.  Lisa's points on usability uncovered deeper concerns about determinism.

One point I'd like to clear up was over the maintainability of the condition.  I'd like to think that for users who are managing geospatial data, assumed access to a map is reasonable.

That aside, the polygon shape is somewhat restrictive and quite clumsy.  Speaking from experience, user interface for polygons is a pain.  A circle would be better.  In the spirit of extensibility, allowing any shape but making one particular shape mandatory would be better.  A circle is easier to manage and understand - 100m from this point.  It also avoids some of the determinism concerns.

This leads straight to the heart issue.  The draft makes a central assumption about the nature of location data.  There is a clear assumption that the location of the Target is a point, with no uncertainty.

I'd argue that the assumption is bad.  In the location business, you need to be comfortable with a degree of uncertainty.  Virtually all results are some sort of probability distribution, usually with uncertainty that is significant enough to cause trouble.  50 metres 67% of the time is pretty vague by many standards - and that's actually pretty good in the overall spectrum of results for mobile networks.  Ignoring uncertainty just leads to bad results.

That leads to two approaches, both equally valid, but both requiring additional work.  In the first, you strive for determinism and you specify rigid rules for the handling of uncertainty.  This means documenting algorithms and requiring strict adherence.  Alternatively, you could start caring less about guaranteeing results and build tolerances in wherever the data is used.

From this perspective, the group needs to reconsider how such things are done.  This also applies to loc-filters, where a similar function is defined.

On a related note - the assumption made in the draft means that the transformations described can seriously damage a location that includes uncertainty.  A polygon that is transformed, point by point, can actually be totally invalid.  Furthermore, a receiver can no longer assume that circle and similar results are accurate to any degree of confidence, since the uncertainty is not appropriately modified.

Cheers,
Martin

> -----Original Message-----
> From: Tschofenig, Hannes (NSN - DE/Munich)
> [mailto:[email-masked]]
> Sent: Wednesday, 3 October 2007 1:30 AM
> To: ext Sam Hartman; Hannes Tschofenig
> Cc: GEOPRIV; Tim Polk; Russ Housley; Chris Newman; [email-masked]
> Subject: AW: [Geopriv] Re: Geolocation Policy Draft Update
> 

------------------------------------------------------------------------------------------------
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
[email-masked]
https://www1.ietf.org/mailman/listinfo/geopriv

---

From: Sam Hartman <[email-masked]>
Date: Thu, 04 Oct 2007 09:43:57 -0400

Hmm.
I thought the draft assumed the location of the target was a polygon.

---

From: "Tschofenig, Hannes (NSN - DE/Munich)" <[email-masked]>
Date: Thu, 4 Oct 2007 16:02:35 +0200

Hi Sam, 

The draft, as Martin, mentiones assumes that the location of the Target is a point. If the Location Server receives the location in a different form, such as an arc band, then the location needs to be reduced to a point before applying the transformation. 

Ciao
Hannes 

> Gesendet: Donnerstag, 4. Oktober 2007 15:44
> An: Thomson, Martin
> Cc: GEOPRIV; Tim Polk; Russ Housley; Tschofenig, Hannes (NSN 
> - DE/Munich); Chris Newman; [email-masked]
> Betreff: Re: [Geopriv] Re: Geolocation Policy Draft Update
> 
> Hmm.

---

From: "Tschofenig, Hannes (NSN - DE/Munich)" <[email-masked]>
Date: Thu, 4 Oct 2007 16:32:07 +0200

Hi Martin, 

> I was going to disagree with the change, because I always 
> thought that the condition was the best part of the draft.  I 
> changed my mind.  The condition isn't ready.  Lisa's points 
> on usability uncovered deeper concerns about determinism.

That's the impression I got as well. 

I am just curious why none of these concerns have surfaced by other organizations working on similar concepts.
Carl Reed provided us pointer to documents. Maybe we should get in touch with these guys and figure out whether they have spend some thoughts on these issues or to check their implementation experience. 

> 
> One point I'd like to clear up was over the maintainability 
> of the condition.  I'd like to think that for users who are 
> managing geospatial data, assumed access to a map is reasonable.
> 
> That aside, the polygon shape is somewhat restrictive and 
> quite clumsy.  Speaking from experience, user interface for 
> polygons is a pain.  A circle would be better.  In the spirit 
> of extensibility, allowing any shape but making one 
> particular shape mandatory would be better.  A circle is 
> easier to manage and understand - 100m from this point.  It 
> also avoids some of the determinism concerns.

OK. 

> 
> This leads straight to the heart issue.  The draft makes a 
> central assumption about the nature of location data.  There 
> is a clear assumption that the location of the Target is a 
> point, with no uncertainty.

True. Please also note that the work on the document started at a time where the PIDF-LO profile document was not there. 

I believe that the location shape aspect is more an issue for the condition than for the transformation. 

> 
> I'd argue that the assumption is bad.  In the location 
> business, you need to be comfortable with a degree of 
> uncertainty.  Virtually all results are some sort of 
> probability distribution, usually with uncertainty that is 
> significant enough to cause trouble.  50 metres 67% of the 
> time is pretty vague by many standards - and that's actually 
> pretty good in the overall spectrum of results for mobile 
> networks.  Ignoring uncertainty just leads to bad results.

Please note that PIDF-LO does not have an explicit way to express uncertainty. 

> 
> That leads to two approaches, both equally valid, but both 
> requiring additional work.  In the first, you strive for 
> determinism and you specify rigid rules for the handling of 
> uncertainty.  This means documenting algorithms and requiring 
> strict adherence.  Alternatively, you could start caring less 
> about guaranteeing results and build tolerances in wherever 
> the data is used.
> 
> From this perspective, the group needs to reconsider how such 
> things are done.  This also applies to loc-filters, where a 
> similar function is defined.

Interesting that you mention the Location Filters document. In some sense one could see location-based conditions and the location filters draft as very similar things. Hence, all the comments we received for the Geolocation Policy draft are actually relevant for the Location Filter draft as well. One could also argue that the concepts in the two drafts could be aligned better.

> 
> On a related note - the assumption made in the draft means 
> that the transformations described can seriously damage a 
> location that includes uncertainty.  A polygon that is 
> transformed, point by point, can actually be totally invalid. 
>  Furthermore, a receiver can no longer assume that circle and 
> similar results are accurate to any degree of confidence, 
> since the uncertainty is not appropriately modified.

If the draft does not state explicitly that the input to the transformation step is assumed to be a point then we should do so. When you reduce location information then it does not really matter whether the shape describing the location of the Target is an arc band, a circle or anything else. We could, however, discuss this topic in the draft. 

Ciao
Hannes

> > I am waiting for the group to provide us some feedback on 
> the proposed
> > change ...
> > 
> > Ciao
> > Hannes
> >

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 04 Oct 2007 14:10:08 -0500

>Please note that PIDF-LO does not have an explicit way to express 

This is on purpose, because there are many ways of expressing 
location without a means to determine uncertainty (at the end of a 
wire, for example, or connected to a specific AP at a known location 
as another).  Forcing "uncertainty" where it doesn't belong (PIDF-LO 
is *not_only* for cellular networks) does more harm than good - 
because it starts to make techs guess what is the right percentage of 
uncertainty. Further, the idea that uncertainty applies only to 
coordinate representations is wrong. For example, I can give you a 
linear ring of the 5 points of my house's property, with my 
property's boundary being straight lines between each point (which is 
true BTW) - and claim that is the same as my civic 
address.  Therefore, if there is uncertainty in my polygon of my 
house, there is uncertainty in my civic street address I can give out 
as well - yet time and time again this has been said to be untrue.

James

---

From: "Dawson, Martin" <[email-masked]>
Date: Thu, 4 Oct 2007 14:41:34 -0500

Any polygon is a representation of uncertainty iff the intent is to
communicate that the location of the *subject* of the application is
somewhere within that polygon. Of course a civic address is conveying
the same uncertainty information with respect to the point if the intent
is that the location is somewhere within that civic address. The only
difference is that one quantifies the geographic extent of the
uncertainty explicitly and the other only implicitly.

Actually, I think it's only true that a PIDF-LO doesn't communicate
uncertainty if you're using it in an application that says that the
communicated shape exactly represents the actual subject of the
communication. I think the more common use case is the one described
above.

It's silly to say that the communication of uncertainty is a cellular
thing. If I provide a polygon that represents the boundary of my
property with the intent of saying that the actual subject of the
exchange is somewhere (and anywhere) within that property, then I have
just communicated an uncertainty. The polygon clearly didn't have to be
determined in the context of cellular communications.

I think there may be - not sure - some confusion with confidence; which
would actually apply a percentage value to the probability that the
subject is within the boundary of the provided polygon and not outside
it. Indeed, PIDF-LO does not provide a mechanism to communicate
confidence. But, also, I don't think that confidence need only apply to
cellular. For example, you might provide a more constrained polygon in a
property boundary scenario because 95% of the time the subject occupies
a 10% subset of the larger polygon. Again, this is nothing to do with
whether it's a cellular context or not.

Cheers,
Martin

-----Original Message-----
From: James M. Polk [mailto:[email-masked]] 
Sent: Friday, 5 October 2007 5:10 AM
To: Tschofenig, Hannes (NSN - DE/Munich); Thomson, Martin; ext Sam
Hartman; Hannes Tschofenig
Cc: GEOPRIV; Tim Polk; Russ Housley; Chris Newman;
[email-masked]
Subject: Re: AW: [Geopriv] Re: Geolocation Policy Draft Update

James

---

From: "Carl Reed OGC Account" <[email-masked]>
Date: Thu, 4 Oct 2007 14:49:43 -0600

There is a huge amount of literature in the Geography/photogrammetry 
community about uncertainty and confidence in mapped data. One of the world 
experts on this topic lives a mile or so from me here in Colorado. I would 
look to that community if we are seeking a general solution and not one 
specific to cellular.

Regards

Carl

----- Original Message ----- 
From: "Dawson, Martin" <[email-masked]>
To: "GEOPRIV" <[email-masked]>
Cc: "Tim Polk" <[email-masked]>; "Russ Housley" <[email-masked]>; 
"ext Sam Hartman" <[email-masked]>; "Chris Newman" 
<[email-masked]>; <[email-masked]>
Sent: Thursday, October 04, 2007 1:41 PM
Subject: RE: AW: [Geopriv] Re: Geolocation Policy Draft Update

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 04 Oct 2007 23:24:46 +0200

It would be helpful to get in touch with these experts since we are 
discussing this topic now for years.
An outsider could help us to move the work in the right direction -- and 
I am not really focusing on this document alone.

This issue needs to get resolved asap.

Ciao
Hannes

Carl Reed OGC Account wrote:
> community about uncertainty and confidence in mapped data. One of the 
> world experts on this topic lives a mile or so from me here in 
> Colorado. I would look to that community if we are seeking a general 
> solution and not one specific to cellular.
>
> Regards
>
> Carl
>
> ----- Original Message ----- From: "Dawson, Martin" 
> <[email-masked]>
> Cc: "Tim Polk" <[email-masked]>; "Russ Housley" 
> <[email-masked]>; "ext Sam Hartman" <[email-masked]>; 
> "Chris Newman" <[email-masked]>; <[email-masked]>

---

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 4 Oct 2007 20:36:38 -0500

(taking IESG members off the CC)

I have already begun an attempt to better define Uncertainty and Confidence.  The draft is in very early days so far, so, given the current discussion, I'm keen to solicit input.  I'd definitely be interested in any assistance Carl and his contacts can provide.

I have several goals for the draft.  The first is to resolve the definitions of Uncertainty and Confidence and to deprecate the usage of Precision and Accuracy.  Precision and Accuracy have myriad meanings and while the 3693 definitions are good, they aren't concrete enough terms for our purposes.

(Originally, I had hoped that the definitions in GeoShape would suffice, but it's clear that those haven't done the job, or at least people haven't read it.)

The second goal is to define some guidelines on how to apply uncertainty in determining if a Target is within a given region.  This applies directly to the geopriv-policy and loc-filters work.

The third goal, potentially the most controversial one, is to formalize the addition of Confidence to the PIDF-LO representation and to define a default value that can be assumed when none is present.

I think that if those goals can be achieved, and the group can find consensus on those issues, the problem will be solved.  However, you might need to be a little flexible on your definition of ASAP.

Cheers,
Martin

> From: Hannes Tschofenig [mailto:[email-masked]]
> Sent: Friday, 5 October 2007 7:25 AM
> To: Carl Reed OGC Account
> Cc: GEOPRIV; Dawson, Martin; Chris Newman; Russ Housley; Tim Polk; ext Sam
> Hartman; [email-masked]