Subject: [Geopriv] Lisa's DISCUSS on draft-ietf-geopriv-policy

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 21 Sep 2007 13:19:36 +0200

Hi Lisa,
Hi all,

Background: draft-ietf-geopriv-policy is currently in IESG Evaluation 
</idtracker/help/state/20/> and Lisa has put a DISCUSS on the document. 
Here are Lisa's comments and I would like to discuss them on the mailing 
list:
https://datatracker.ietf.org/idtracker/draft-ietf-geopriv-policy/comment/71788/?
https://datatracker.ietf.org/idtracker/draft-ietf-geopriv-policy/comment/71781/?

Lisa focused on the aspect of user interfaces in her feedback. Thank you 
Lisa for giving the document so much thought.

Here is a copy-and-paste from the comments from the tracker:

"
This is very complicated (too flexible) for a privacy extension.  I do 
not expect clients from different vendors to be able to interoperate 
very well over the same policy information.  I expect the end result of 
this to be cases where users believe they have privacy, or intend to 
have privacy, but do not achieve their goals due to difficulty of 
getting clients to interoperate with each other and with servers.
"

"
These mechanisms are too complicated and don't give enough thought to 
how different user-agents are going to interact.  In particular, one 
should imagine setting a privacy policy with one user agent and then 
trying to edit it with another.

It seems that geo-spatial policy creation requires some kind of user 
interface that includes a map.  Is that correct?  Are devices without 
maps then unable to modify or even read policies?

I am not sure that the polygons are as cut-and-dried as they appear.  
I'd like to understand better:
- how one knows what is the inside of the polygon, and what is the outside
- ... how that interacts with poles and other problems mapping 2D to a 
sphere
- how the altitude stuff works at all with client GUIs
- when is altitude known and unknown, independent of knowing a rough 
long/lat position
- whether you can define a polygon for "Alberta" and one for 
"Saskatchewan" and have any point be in one or the other or completely 
outside both -- but not *inside* both, and not stuck in-between

When it comes to users viewing policies created in the past, the lack of 
human-readable labels and comments is going to be a real usability problem.

What happens when a user or user-agent creates a non-sensical 
geo-political or geo-spatial location? 

Are all geo-political elements *really* allowed in conditions?  One 
possible non-sensical policy would be "Show my location unless I'm in 
seat 32A".  Aren't there any restrictions here?

How are user agents supposed to handle mixed geo-spatial and civic 
location conditions? How would that be displayed or represented in a 
list of policy elements?

With the dependency on geopriv-revised-civic-lo, this can't complete yet 
anyway.
"

Thoughts?

Ciao
Hannes

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 22 Sep 2007 20:09:34 +0200

Some quick comments inline. I appreciate the need to make the user  
interface manageable, and thus I'm in favor of dropping functionality  
if it is unlikely to be implemented consistently, or if users are  
likely to be confused by the decisions they have to make or the results.

On Sep 21, 2007, at 1:19 PM, Hannes Tschofenig wrote:

> Hi Lisa,
> Hi all,
>
> Background: draft-ietf-geopriv-policy is currently in IESG  
> Evaluation </idtracker/help/state/20/> and Lisa has put a DISCUSS  
> on the document. Here are Lisa's comments and I would like to  
> discuss them on the mailing list:
> It seems that geo-spatial policy creation requires some kind of  
> user interface that includes a map.  Is that correct?  Are devices  
> without maps then unable to modify or even read policies?
>

I don't think a map is required, although this is clearly helpful in  
some scenarios. For example, a reasonable user interface might  
provide the option "Hide my location if I'm within 50 miles from  
home",  and then translate this into a polygon. A separate user agent  
would best render this as a polygon on a map.

I'm not too concerned about the map issues. Maps are now widely  
available and geo coordinate information is, after all, best  
displayed on a map.

I'm not sure if there's a suggestion for an alternative here.  
Conditions such as "within 50 miles of home" are more user-friendly,  
but seem much harder to implement consistently and correctly.

> I am not sure that the polygons are as cut-and-dried as they  
> appear.  I'd like to understand better:
> - ... how that interacts with poles and other problems mapping 2D  
> to a sphere

My inclination would be to drop altitude altogether. The number of  
policies where altitude seems necessary seems rather small. "Only  
show my position if I'm not flying" seems cute, but not terribly likely.

> - when is altitude known and unknown, independent of knowing a  
> rough long/lat position
> "Saskatchewan" and have any point be in one or the other or  
> completely outside both -- but not *inside* both, and not stuck in- 
> between

I don't understand this particular item.

>
> When it comes to users viewing policies created in the past, the  
> lack of human-readable labels and comments is going to be a real  
> usability problem.

Comments are helpful, but I suspect they can easily mislead, where  
the comment says one thing and the rule really does something else. I  
do think a general rule comment would be helpful and we should have  
added this to common-policy.

>
> What happens when a user or user-agent creates a non-sensical geo- 
> political or geo-spatial location?

The UI should perform sanity checks.

> possible non-sensical policy would be "Show my location unless I'm  
> in seat 32A".  Aren't there any restrictions here?

I think we should drop combined civic and geo rules. Civic conditions  
should have higher-level elements. Unfortunately, we can't specify  
all conditions, since not every civic address will need, for example,  
all A* levels. This depends on the country being described. Thus, in  
some cases, I can't see a way to avoid specifying addresses that make  
syntactic sense, but are somewhat peculiar. (Example: Main Street in  
all cities within a county.)

> location conditions? How would that be displayed or represented in  
> a list of policy elements?
>

As I noted above, I would drop this. It does seem to generate  
artificial complexity.

Henning

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 24 Sep 2007 10:55:32 +0200

Hi Henning,

Henning Schulzrinne wrote:
>> </idtracker/help/state/20/> and Lisa has put a DISCUSS on the 
>> document. Here are Lisa's comments and I would like to discuss them 
>> on the mailing list:
> some scenarios. For example, a reasonable user interface might provide 
> the option "Hide my location if I'm within 50 miles from home",  and 
> then translate this into a polygon. A separate user agent would best 
> render this as a polygon on a map.
>
> available and geo coordinate information is, after all, best displayed 
> on a map.
>

Maybe the suggestion is to provide a mechanism to label a certain 
geographical region for later usage in policies. Assume that an end host 
would configure these policies then someone (like the enterprise 
administrator, the user with the help of a map tool, the operator) would 
provide pre-defined regions that are labeled.

Currently, the user interface could provide this functionality but there 
are no protocol features to enable them, i.e., the user interface at the 
Rule Maker would have to know what "home" means and then translate that 
to a polygon.

If I recall it correctly then GML provides these functionality even at a 
XML level.

>> - ... how that interacts with poles and other problems mapping 2D to 
>> a sphere
> policies where altitude seems necessary seems rather small. "Only show 
> my position if I'm not flying" seems cute, but not terribly likely.
That's fine for me as well.

>> completely outside both -- but not *inside* both, and not stuck 
>> in-between
>
Same for me.

>>
>> When it comes to users viewing policies created in the past, the lack 
>> of human-readable labels and comments is going to be a real usability 
>> problem.
>
> Comments are helpful, but I suspect they can easily mislead, where the 
> comment says one thing and the rule really does something else. I do 
> think a general rule comment would be helpful and we should have added 
> this to common-policy.

Sounds reasonable to me.
We could add an element to allow the Rule Maker to provide some 
human-readable text around the policy.

> should have higher-level elements. Unfortunately, we can't specify all 
> conditions, since not every civic address will need, for example, all 
> A* levels. This depends on the country being described. Thus, in some 
> cases, I can't see a way to avoid specifying addresses that make 

The document does not allow compound location to be specified. One can 
only specific a condition with civic location and another condition with 
geodetic location information. You cannot mix the two.

I also believe that we should not get rid of either the geodetic nor the 
civic location condition since both have their right to exist.
As mentioned in the response to Tim I believe we should
* clarify the usage of both in the document and
* allow the Rule Maker to indicate that the server should do the 
translation into the other format.

> As I noted above, I would drop this. It does seem to generate 
Let us try to be specific. There is no compound location information 
provided in the document. We deleted this part some time ago.
There is, however, the ability to specify a condition based on civic 
location information and another condition in geodetic format.

Is there the suggestion to delete either civic or geodetic location 
information conditions entirely?

Ciao
Hannes

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 24 Sep 2007 05:05:50 -0400

On Sep 24, 2007, at 4:55 AM, Hannes Tschofenig wrote:

> geographical region for later usage in policies. Assume that an end  
> host would configure these policies then someone (like the  
> enterprise administrator, the user with the help of a map tool, the  
> operator) would provide pre-defined regions that are labeled.
>
> Currently, the user interface could provide this functionality but  
> there are no protocol features to enable them, i.e., the user  
> interface at the Rule Maker would have to know what "home" means  
> and then translate that to a polygon.
>
> If I recall it correctly then GML provides these functionality even  
> at a XML level.

Labeling regions would require a separate data set, i.e., something  
outside the current common-policy framework. Also, this would have  
its own set of problems. If the operator changes such a region, the  
user would suddenly, and without notification, have a very different  
privacy policy. In addition, unless there is a guarantee that these  
regions are accessible by users and can be defined by users, it would  
be very difficult for one user to maintain the same set of privacy  
policies across multiple different service providers. Finally, I'm  
not sure how this would address the issue of having to have map  
displays. Almost all such regions would be either simple civic  
regions ("Bergen county") or would need a map to be unambiguous to  
most users ("New York metro area").

> human-readable text around the policy.

And maybe add a 'comment' attribute to the rule. This, however, seems  
more appropriate for the common-policy document, as a trivial  
extension, since it is by no means specific to geopriv-policy.

> information conditions entirely?

I'm not suggesting this, but I'm sure Lisa can clarify her concerns.

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 24 Sep 2007 11:35:56 +0200

Hi Henning,

Henning Schulzrinne wrote:
>> host would configure these policies then someone (like the enterprise 
>> administrator, the user with the help of a map tool, the operator) 
>> would provide pre-defined regions that are labeled.
>>
>> interface at the Rule Maker would have to know what "home" means and 
>> then translate that to a polygon.
>>
> outside the current common-policy framework. Also, this would have its 
> own set of problems. If the operator changes such a region, the user 
> would suddenly, and without notification, have a very different 
> policies across multiple different service providers. Finally, I'm not 
> sure how this would address the issue of having to have map displays. 
> Almost all such regions would be either simple civic regions ("Bergen 
> county") or would need a map to be unambiguous to most users ("New 
> York metro area").
>
>
I agree.

Hence, it seems that such a mechanism would actually require additional 
extensions and aspects that need to be brought into consideration. For 
the time being it might be better to deal with these aspects on a user 
interface level. Maybe that's something to investigate in the future...

> extension, since it is by no means specific to geopriv-policy.
True; thereby one would inherit it to the geolocation and presence 
document as well.

Ciao
Hannes

---

From: Lisa Dusseault <[email-masked]>
Date: Mon, 24 Sep 2007 13:05:06 -0700

On Sep 22, 2007, at 11:09 AM, Henning Schulzrinne wrote:

>
> I don't think a map is required, although this is clearly helpful  
> in some scenarios. For example, a reasonable user interface might  
> home",  and then translate this into a polygon. A separate user  
> agent would best render this as a polygon on a map.

Yes, but how does this work in the other direction?  If one user  
agent encourages me to draw a square (or more complicated polygon)   
around the location I'd like to keep private, how does the user agent  
without a map reasonably show me what my policy is when I'd like to  
check if I will have privacy?

> I don't understand this particular item.

I'm trying to understand how polygons work here, I'm not certain  
there's a problem.  Assuming we know what the inside of a polygon is  
(that's a separate discussion), is the exact location of a border  
dependent on where the inside of a polygon is?  If we define the  
border between Alberta and Saskatchewan as a straight line from A to  
B, and we use the same line in the definition of the Alberta polygon  
and the Saskatchewan polygon, then do the two polygons overlap or  
have a gap between them?  I could imagine that they might, depending  
on how a flat square is mapped to a sphere.   Will the border between  
Saskatchewan and the US necessarily follow the 49th parallel or might  
the line between the two south corners be interpreted as cutting into  
what's actually Saskatchewan?

If we show a map to a user on a flat screen, typically large  
"rectangular" regions like Saskatchewan actually show up as a shape  
with two straight lines and two curved lines. (It may also be  
tilted:  http://www.canadainfolink.ca/canada_fr.jpg).   A user trying  
to cover Saskatchewan on this map with a rectangle would have to  
cover pieces of Alberta, Northwest Territories, Manitoba and USA with  
the rectangle to do so, unless the GUI was pretty complicated. That's  
why I'm not sure that different user agents and servers will  
necessarily interpret what's inside a polygon the same way.

Lisa

---

From: Lisa Dusseault <[email-masked]>
Date: Tue, 25 Sep 2007 08:31:17 -0700

On Sep 24, 2007, at 2:05 AM, Henning Schulzrinne wrote:

>> geographical region for later usage in policies. Assume that an  
>> end host would configure these policies then someone (like the  
>> enterprise administrator, the user with the help of a map tool,  
>> the operator) would provide pre-defined regions that are labeled.
>>
> user would suddenly, and without notification, have a very  
> different privacy policy.

I think by "labels", Hannes & I meant what you call "comments"  
below.  Generally-understood region names are already part of the  
civic location stuff, right?

In the case of civic definitions, is it likely operators will go  
changing region definitions?  I agree that would be a problem.

> In addition, unless there is a guarantee that these regions are  
> accessible by users and can be defined by users, it would be very  
> difficult for one user to maintain the same set of privacy policies  
> across multiple different service providers. Finally, I'm not sure  
> how this would address the issue of having to have map displays.  
> Almost all such regions would be either simple civic regions  
> ("Bergen county") or would need a map to be unambiguous to most  
> users ("New York metro area").
>>
>> Sounds reasonable to me.
> And maybe add a 'comment' attribute to the rule. This, however,  
> seems more appropriate for the common-policy document, as a trivial  

Since one reasonable place to put a comment is in the "gp:location"  
element defined in this document, I'm not sure geopriv-policy is an  
inappropriate document to define a comment.

>>
>> Is there the suggestion to delete either civic or geodetic  
>> location information conditions entirely?
>>
>

I was not suggesting that either, but it would be one way to avoid  
the case where two user agents want to operate on the same privacy  
policy and one only understands civic and the other only geodetic.   
Another solution would be to require user agents to understand both.

Lisa

---

From: Lisa Dusseault <[email-masked]>
Date: Tue, 25 Sep 2007 08:33:28 -0700

On Sep 24, 2007, at 1:05 PM, Lisa Dusseault wrote:

> around the location I'd like to keep private, how does the user  
> agent without a map reasonably show me what my policy is when I'd  
> like to check if I will have privacy?
>

As long as we're talking about user agents here, are there any client  
developers in the room?  Anybody willing to talk about what they  
envision as an interface and what things are and are not requirements  
for that particular project?

thx,
Lisa

---

From: "Tschofenig, Hannes (NSN - DE/Germany - MiniMD)" <[email-masked]>
Date: Tue, 25 Sep 2007 17:52:04 +0200

Hi Lisa, 

> civic location stuff, right?

I am fine with the idea of adding comments to the rules. 

The civic location work 
http://www.ietf.org/rfc/rfc4119.txt
http://www.ietf.org/internet-drafts/draft-ietf-geopriv-revised-civic-lo-
05.txt
already provides XML elements with a semantic for commonly used civic
addresses.

For example: 

   +---------------+--------+----------------------------+-------------+
   | New Civic     | CAtype | Description                | Example     |
   | Field         |        |                            |             |
   +---------------+--------+----------------------------+-------------+
   | BLD           |   25   | Building (structure)       | Hope        |
   |               |        |                            | Theatre     |
                             ....

I see the labels as something different and I recall some concept in GML
(when it comes to the protocol aspects) that allows you to associate a
name to a specific geographical region. For example: I would would use
the name "my-home" as a replacement for the civic address describing
something I call my home. 

> changing region definitions?  I agree that would be a problem.

Difficult to say in advance. 

> inappropriate document to define a comment.

There is the possiblity to define it specifically for this document.
Alternatively, it is also possible to define it as an extension to
Common Policy and to make it available to all other extensions as well
since it might be of general usage. 

> Another solution would be to require user agents to understand both.

Need to think about it...

Ciao
Hannes

---

From: "Carl Reed OGC Account" <[email-masked]>
Date: Tue, 25 Sep 2007 12:59:22 -0600

I am not sure if this is germane - as I need to read the document being 
discussed - but just based on the discussion to date,  I might suggest 
taking a look at an emerging OGC standard for handling geospatially based 
authentication and authorization that is also a potential  profile of XACML 
. There may be some very useful hints in the OGC GeoXACML document that are 
relevant to location and privacy.

The most recent public version of the document can be downloaded from 
http://www.opengeospatial.org/standards/requests/41 . The candidate standard 
has been through a public comment period, has been reviewed by the Chair of 
the XACML TC in OASIS, and is currently in revision based on the comments 
received.

Regards

Carl

----- Original Message ----- 
From: "Hannes Tschofenig" <[email-masked]>
To: "GEOPRIV" <[email-masked]>
Sent: Friday, September 21, 2007 5:19 AM
Subject: [Geopriv] Lisa's DISCUSS on draft-ietf-geopriv-policy

> This is very complicated (too flexible) for a privacy extension.  I do not 
> expect clients from different vendors to be able to interoperate very well 
> over the same policy information.  I expect the end result of this to be 
> cases where users believe they have privacy, or intend to have privacy, 
> but do not achieve their goals due to difficulty of getting clients to 
> interoperate with each other and with servers.
> "
>
> "
> These mechanisms are too complicated and don't give enough thought to how 
> different user-agents are going to interact.  In particular, one should 
> imagine setting a privacy policy with one user agent and then trying to 
> edit it with another.
>
> interface that includes a map.  Is that correct?  Are devices without maps 
> then unable to modify or even read policies?
>
> I am not sure that the polygons are as cut-and-dried as they appear.  I'd 
> like to understand better:
> possible non-sensical policy would be "Show my location unless I'm in seat 
> 32A".  Aren't there any restrictions here?
>
> location conditions? How would that be displayed or represented in a list 
> of policy elements?
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 25 Sep 2007 15:11:13 -0400

> Need to think about it...

In the interest of simplicity, could we just drop both for now? The  
more I think about it, the more attractive this sounds...

Henning

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 25 Sep 2007 21:17:32 +0200

Hi Carl,
Hi all,

it is interesting that you mention that document. In fact we once had a 
proposal in the group that used XACML. Then, we switched to something 
simpler because of concerns regarding complexity.
This was obviously a long time before that work started.

I read through that document some time back and it is far more complex 
that what we proposed. Hence, it does not help us directly with the 
comments we received for our document. We can only use it as an argument 
for more complex solutions being already specified successfully by other 
SDOs.

The only feature that is not included is civic location information. 
That's not surprising given that OGC does not use civic location 
information in their standards (if I understood it correctly).

There is obviously no reference to our work although it started much 
earlier. We do, however, not reference their work either.

Ciao
Hannes

PS: I could imagine that the approach other SDOs follow is a bit 
different to the one in the IETF. When they think there is something 
useful then they just do it. There may be some disadvantages and open 
issues here and there but they just push a document out there for people 
to look at. Then, they collect the implementation feedback and revise 
their docs.

Carl Reed OGC Account wrote:
> I am not sure if this is germane - as I need to read the document 
> being discussed - but just based on the discussion to date,  I might 
> suggest taking a look at an emerging OGC standard for handling 
> geospatially based authentication and authorization that is also a 
> potential  profile of XACML . There may be some very useful hints in 
> the OGC GeoXACML document that are relevant to location and privacy.
>
> http://www.opengeospatial.org/standards/requests/41 . The candidate 
> standard has been through a public comment period, has been reviewed 
> by the Chair of the XACML TC in OASIS, and is currently in revision 
> based on the comments received.
>
> Regards
>
> Carl
>
> ----- Original Message ----- From: "Hannes Tschofenig" 
> <[email-masked]>
>> Lisa focused on the aspect of user interfaces in her feedback. Thank 
>> you Lisa for giving the document so much thought.
>>
>> This is very complicated (too flexible) for a privacy extension.  I 
>> do not expect clients from different vendors to be able to 
>> interoperate very well over the same policy information.  I expect 
>> the end result of this to be cases where users believe they have 
>> privacy, or intend to have privacy, but do not achieve their goals 
>> due to difficulty of getting clients to interoperate with each other 
>> and with servers.
>> "
>>
>> "
>> With the dependency on geopriv-revised-civic-lo, this can't complete 
>> yet anyway.
>> "
>>
>> Thoughts?
>>
>> Ciao
>> Hannes
>>
>>
>>