Subject: RE: [Geopriv] GeoPriv :- draft-winterbottom-location-uri

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 21 Jul 2005 17:19:10 -0400

> 1)  This draft advocates location by reference, a URI that when 
> accessed will provide the location of the end-point, instead of 
> enabling a host to determine its own location.  Why these methods are 
> portrayed as competing is not clear.  A host that learns its own 
> location might send that location to a Location Server in order to be 
> able to send references rather than its location to others.

This draft draws a distinction, one that I think we all should be drawing, between location provisioning and location conveyance. This draft is only concerned with provisioning. No doubt location can also be conveyed by-reference as you describe if the location is provisioned by-value.

> 2)  By not involving a host in the generation of its own location 
> information, the proposal "begs the question" of how location is first 
> determined. [http://en.wikipedia.org/wiki/Beg_the_question]  The 
> generator is presumed to be able to locate the host without its 
> assistance or approval.

This assumes cases where a host is unable to determine its own location, yes. Clearly, there are cases (like where a host has imbedded GPS, or something) where a host can determine its own location). I believe that DHCP-LCI relies on a similar assumption of the location-uri draft; a host does not know its own location, but is provisioned with location information by some network server (in that instance, a DHCP server). Said DHCP server locates the host without the host's assistance or approval as well. Where does the DHCP server learn this location information? Presumably it is provisioned with it. Similar cases could prevail for any by-reference location provisioning system. Cellular tower triangulation would be another notable example.

> 3)  Possibly worse than lacking the fundamental of original location 
> determination, the draft appears to suggest that it is to support a 
> situation in which the host is not informed of its location while 
> others are.  This sort of surreptitious surveillance appears to be the 
> antithesis of the goal of protecting the privacy and security of 
> Internet users.
> 
> >    [section 3 page 5]  ...   Furthermore, some
> >    generators of location information might not want to disclose this
> >    information directly to endpoints for various business-model reasons,
> >    but might be perfectly willing to give this information to trusted
> >    requestors.

I believe that my current cellular provider has a relatively good idea of where my handsets are. I also believe that they will not share this information with me unless I pay additional money for a premium service. So this isn't exactly science-fiction. Is it surreptitious surveillance? Maybe, it does make me nervous. Maybe I should also be nervous if a DHCP server knows my location information and is capable of sharing it with parties outside of my sphere of influence. Of course, the whole reason for working on something like GEOPRIV is to give me the capability to publish privacy policies that govern how location information is distributed. I don't even have to have access to location information in order to craft those sorts of policies.

In any event, the deployment realities are not the only reason to study location by-reference. Mobile handsets whose location changes are a good argument for not statically provisioning location information at the moment a device autoconfigures on a network.

> 4)  The draft seems to criticize RFC 3825 in its contrast of high 
> mobility and the mechanism provided for wired hosts.  Not only is RFC 
> 3825 not proposed as a universal solution, it is not clear that a 
> universal solution is possible or desirable.  There is no reason to 
> believe that highly mobile hosts will not have other direct methods of 
> learning their locations, for example though combinations of GPS and 
> inertial integration.
> 
> >    [section 4, page 7] ...   Coupling the provisioning of static location
> >    information with network-layer autoconfiguration (e.g., DHCP) is
> >    therefore applicable to only certain environments, and other
> >    environments require a different solution.

I would not consider the text in this draft to be a "criticism" of RFC3825, which performs the task it set out to do admirably. I agree totally that RFC3825 has a clear applicability statement and that it does not pose as a universal solution. I simply that since RFC3825 is not a universal solution, it is worth studying some possible mechanisms that would cover architectures outside of RFC3825's applicability.

As for the question of whether or not highly mobile hosts will have "direct" methods of learning their locations, well, I own a few highly mobile hosts, and none of them do. I think that is a good reason to believe that at least some such devices will not have that capability.

> 5)  The implication that by-reference somehow resolves the challenge of 
> locating highly mobile hosts is not supported. The implication that 
> highly mobile hosts would require constant updates to determine their 
> own locations is not supported.  Why could a mobile host not generate 
> its own location only when it wants to tell it to someone?
> 
> >    Maintaining accurate and current locations for highly mobile end-
> >    points in a network is challenging...  By contrast, by-value
> >    provisioning in these sorts of environments would result in continual
> >    and probably unnecessary updates to all endpoints for the benefit of
> >    the few that will ultimately require location-based services.

Simply because it doesn't have the capability to generate its own location.

One could argue that every SIP phone will necessarily have GPS because one can just unplug them somewhere and plug them in somewhere else, and thus it needs to have it. Just because it would be nice if all mobile hosts could generate their own location information doesn't mean that they do, or will.

> 6)  RFC 3825 does not propose that DHCP is the only way that an 
> Internet host could obtain its location.  Where PPP is used to assign 
> parameters for network attachment such as IP address, the same location 
> information as in RFC 3825 could be delivered through PPP.  It should 
> be noted that the RADIUS client is the network access server (NAS) not 
> the attached host.
> 
> >   [section 5, page 8] ... Such networks generally do not
> >    comprise of single DHCP servers, but rather use AAA and RADIUS
> >    devices, often in proxy configurations, to obtain and distribute
> >    configuration information.  Modifying such systems to include native
> >    support for location acquisition proliferates a problem that is
> >    already starting to take hold in a number of layer 2 based protocols.

I'm sure the cited text did not mean to put words in the mouth of RFC3825, but rather to illustrate the diversity of systems that contribute to host autoconfiguration.

Jon Peterson
NeuStar, Inc.

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

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

---

From: "Carl Reed OGC" <[email-masked]>
Date: Thu, 21 Jul 2005 17:49:11 -0600

Jon, James, and John -

Have been following this discussion (as best I can!).

I was wondering how this (DHCP, PIDF, Location URI) all relates to the 
existing payload structures of the APIs used by the mobile network 
infrastructure that currently exist between the location server and the 
location based application. I am thinking in particular of the JSR 179 and 
OMA MLP 3.x APIs. An example might be that Nokia uses the MLP API for 
communication between their location server infrastructure and their mobile 
location applications to the consumer. As MLP was originally designed with 
Emergency Response as a key design requirement, there is the potential for 
interoperability touch points with location enabled DHCP. I am guessing that 
this is the crux of the discussion WRT provisioning: Who is providing the 
location, what are its characteristics, and how do we insure that the 
original source content can be accessed by some end user application.

I do not want to sidetrack this conversation but am seeking clarity :-)

Regards

Carl
OGC

----- Original Message ----- 
From: "Peterson, Jon" <[email-masked]>
To: "John Schnizlein" <[email-masked]>; "James Winterbottom" 
<[email-masked]>
Cc: "GEOPRIV" <[email-masked]>
Sent: Thursday, July 21, 2005 3:19 PM
Subject: RE: [Geopriv] GeoPriv :- draft-winterbottom-location-uri

> This draft draws a distinction, one that I think we all should be drawing, 
> between location provisioning and location conveyance. This draft is only 
> concerned with provisioning. No doubt location can also be conveyed 
> by-reference as you describe if the location is provisioned by-value.
>
> This assumes cases where a host is unable to determine its own location, 
> yes. Clearly, there are cases (like where a host has imbedded GPS, or 
> something) where a host can determine its own location). I believe that 
> DHCP-LCI relies on a similar assumption of the location-uri draft; a host 
> does not know its own location, but is provisioned with location 
> information by some network server (in that instance, a DHCP server). Said 
> DHCP server locates the host without the host's assistance or approval as 
> well. Where does the DHCP server learn this location information? 
> Presumably it is provisioned with it. Similar cases could prevail for any 
> by-reference location provisioning system. Cellular tower triangulation 
> would be another notable example.
>
> I believe that my current cellular provider has a relatively good idea of 
> where my handsets are. I also believe that they will not share this 
> information with me unless I pay additional money for a premium service. 
> So this isn't exactly science-fiction. Is it surreptitious surveillance? 
> Maybe, it does make me nervous. Maybe I should also be nervous if a DHCP 
> server knows my location information and is capable of sharing it with 
> parties outside of my sphere of influence. Of course, the whole reason for 
> working on something like GEOPRIV is to give me the capability to publish 
> privacy policies that govern how location information is distributed. I 
> don't even have to have access to location information in order to craft 
> those sorts of policies.
>
> In any event, the deployment realities are not the only reason to study 
> location by-reference. Mobile handsets whose location changes are a good 
> argument for not statically provisioning location information at the 
> moment a device autoconfigures on a network.
>
> I would not consider the text in this draft to be a "criticism" of 
> RFC3825, which performs the task it set out to do admirably. I agree 
> totally that RFC3825 has a clear applicability statement and that it does 
> not pose as a universal solution. I simply that since RFC3825 is not a 
> universal solution, it is worth studying some possible mechanisms that 
> would cover architectures outside of RFC3825's applicability.
>
> As for the question of whether or not highly mobile hosts will have 
> "direct" methods of learning their locations, well, I own a few highly 
> mobile hosts, and none of them do. I think that is a good reason to 
> believe that at least some such devices will not have that capability.
>
> One could argue that every SIP phone will necessarily have GPS because one 
> can just unplug them somewhere and plug them in somewhere else, and thus 
> it needs to have it. Just because it would be nice if all mobile hosts 
> could generate their own location information doesn't mean that they do, 
> or will.
>
> I'm sure the cited text did not mean to put words in the mouth of RFC3825, 
> but rather to illustrate the diversity of systems that contribute to host 
> autoconfiguration.
>
> Jon Peterson
> NeuStar, Inc.
>
>> John
>>

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 22 Jul 2005 08:51:46 -0400

I'll take a stab at answering this.

Some mobile networks have an existing API for location.  Most of those have
a mechanism for populating the location and making it available with the
api.  If you were writing an application for these platforms, you might use
those apis.  I am not sure those apis take into account the geopriv privacy
model, nor do they use the data representation of any of our work.  What we
require from them is enough information to construct a PIDF-LO.  If they
can't do that, we're going to have to get some changes made.  We have to do
something about a ruleset also.

If you were writing the code for a VoIP phone that has an Ethernet
connector, which probably has some kind of basic embedded os, it wont have
any location api, but it will have a dhcp client, and may have an lldp
client.  Some of those embedded os folks may see what we're doing here and
make an api, but probably most of the VoIP endpoints will have to code
directly to the dhcp and lldp clients.

If you were writing a softclient on a windows base, it would be real nice to
have a standard api to pick up location, which might be implemented using
the dhcp/lldp protocols on the back side.  I've tried a couple of times to
find the right folks in MS to deal with this, so far with no luck.

We'll probably work out a linux api for this ourselves.

In general, the dhcp/lldp mechanisms are designed for clients on LANs, where
you have no idea what the access network beyond the LAN looks like.  When
you have a specialized access network, as you would in something like a 3GPP
network, the network can specify any mechanism it likes to provide location,
because all of the endpoints have to be built for that access network.
That's the rule of thumb I use; if the network spec controls all the
endpoints, you can use any mechanism, and any api, you like.  If the access
network can't control the spec of the endpoints, then you have to deploy
dhcp or lldp for the endpoints to use.  Within a given platform, we can
expect to see api's developed that give one interface to any of the
protocols.

If we get another access protocol (like HELD), that would have to be added
to the back end of the apis.  Every endpoint has to implement every protocol
if we give network operators freedom to choose.  An api helps that because
all the apps use the same api; only the provider of the api has to deal with
all the protocols.

Brian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Carl Reed OGC
Sent: Thursday, July 21, 2005 7:49 PM
To: Peterson, Jon; John Schnizlein; James Winterbottom
Cc: GEOPRIV
Subject: Re: [Geopriv] GeoPriv :- draft-winterbottom-location-uri

Jon, James, and John -

Regards

Carl
OGC

----- Original Message ----- 
From: "Peterson, Jon" <[email-masked]>
To: "John Schnizlein" <[email-masked]>; "James Winterbottom" 
<[email-masked]>

---

From: John Schnizlein <[email-masked]>
Date: Fri, 22 Jul 2005 12:30:40 -0400

Discussion embedded in context:

On Jul 21, 2005, at 5:19 PM, Peterson, Jon wrote:
> This draft draws a distinction, one that I think we all should be 
> drawing, between location provisioning and location conveyance. This 
> draft is only concerned with provisioning. No doubt location can also 
> be conveyed by-reference as you describe if the location is 
> provisioned by-value.

That distinction might be made clearer in the text.  References to 
location not disclosed to endpoints suggest that someone other than the 
target is getting the location.  Also, the way the HELD draft refers to 
the URI suggests that the URI is part of a GeoPriv "using protocol", 
which is not limited to provisioning the target.

Indeed, much of the rationale for by-reference appears to rely on the 
idea that de-referencing the reference occurs at some different time 
and/or place than the target, which could avoid unnecessarily 
traversing of a level of indirection by getting just its location 
rather than a reference to its location.

> This assumes cases where a host is unable to determine its own 
> location, yes. Clearly, there are cases (like where a host has 
> imbedded GPS, or something) where a host can determine its own 
> location).

Then maybe the text should say explicitly that the proposal is (only) 
for those cases where the host is unable to determine its own location.

>  I believe that DHCP-LCI relies on a similar assumption of the 
> location-uri draft; a host does not know its own location, but is 
> provisioned with location information by some network server (in that 
> instance, a DHCP server). Said DHCP server locates the host without 
> the host's assistance or approval as well.

This is a distortion of what RFC 3825 proposes.  RFC 3825 provides a 
mechanism through which the network (and its associated dynamic 
configuration system) provide a host with location information based on 
the network (jack) attachment point.  The transfer of information about 
the network (jack) point of attachment to the host is what establishes 
the essential association IN THE HOST.  The host then has complete 
control over to whom it gives the location information.

> Where does the DHCP server learn this location information? Presumably 
> it is provisioned with it. Similar cases could prevail for any 
> by-reference location provisioning system. Cellular tower 
> triangulation would be another notable example.

While cell-tower triangulation might associate a geographic location 
with a cell-phone identifier, how this location is associated with an 
Internet host is not clear.  Some unspecified mechanism, which appears 
to be beyond the control of the host, is necessary to establish the 
essential association between the host and the location.  How a 
Location Server at some arbitrary location in the Internet would have 
access to the local location information is the critical question.  
Simply asserting that a Location Server can do this (location 
generation) without specifying the essential association is "begging 
the question".

> I believe that my current cellular provider has a relatively good idea 
> of where my handsets are. I also believe that they will not share this 

I would hope that the goal of GeoPriv is more generally to protect the 
privacy of the location of Internet hosts, rather than creating a niche 
for payment for premium services.

> So this isn't exactly science-fiction. Is it surreptitious 
> surveillance? Maybe, it does make me nervous.

In the case of cellular telephony, controls over how your privacy is 
protected is presumably regulated as with other aspects of that 
regulated telecommunication service.  I don't know those details.

I thought the point of the GeoPriv WG of the IETF was to find ways to 
assist with protecting privacy of locations of Internet hosts, which 
involve some protocol distinctions from cellular telephony.

> Maybe I should also be nervous if a DHCP server knows my location 
> information and is capable of sharing it with parties outside of my 
> sphere of influence.

Nervousness aside, you should note that the proposed standard protocol 
is not for sharing the location of a DHCP client with parties outside 
of my sphere of influence, which adheres to the WG's goal of privacy.  
I would hope that the WG would not endorse a protocol specification for 
DHCP servers sharing the location information they handle to outside 
parties (without clarity as to how that would protect users' privacy.

> Of course, the whole reason for working on something like GEOPRIV is 
> to give me the capability to publish privacy policies that govern how 
> location information is distributed. I don't even have to have access 
> to location information in order to craft those sorts of policies.

Crafting location privacy privacy is only part of the challenge.  
Another part of it is designing (the protocols that compose) the system 
so that the policies are enforceable.

> In any event, the deployment realities are not the only reason to 
> study location by-reference. Mobile handsets whose location changes 
> are a good argument for not statically provisioning location 
> information at the moment a device autoconfigures on a network.

Of course this is true.  I have not heard anyone advocate that the only 
time a package of geographic information like the one specified in RFC 
3825 should be transmitted to an Internet host would be when it gets it 
IP address.  The timing of when a host requests its location seems to 
me a different question from the indirection of an intervening 
reference.

> totally that RFC3825 has a clear applicability statement and that it 
> does not pose as a universal solution. I simply that since RFC3825 is 
> not a universal solution, it is worth studying some possible 
> mechanisms that would cover architectures outside of RFC3825's 
> applicability.

I guess the criticism, through the politically-correct term: 
"challenges", is more clearly stated in section 1: "This document 
describes real network configurations that pose challenges to 
pre-configured location solutions", in section 3: "Such a mechanism 
provides a number of advantages that are not achievable through 
existing by-value location provisioning solutions."  However, the only 
circumstances in which by-reference appears to have advantages are 
those in which someone other than the target uses the reference - not 
the provisioning case.  And there is no visible mechanism to enforce 
location privacy policy when the other party uses the reference.

> believe that at least some such devices will not have that capability.

My guess is that none of them have PIDF-LO methods either - doesn't 
hinder that design.

> Simply because it doesn't have the capability to generate its own 

So an alternative to Location Servers that might give your location to 
an unauthorized party, would be to provide those mobile hosts with 
simple Internet mechanisms to get their locations from the party 
closest to the best information.  What is asserted but not clear is why 
getting a reference is better for the mobile host.  And what about not 
having a piece of information implies that constant updates would be 
required to get that information when the mobile host wants it?

> One could argue that every SIP phone will necessarily have GPS because 
> one can just unplug them somewhere and plug them in somewhere else, 
> and thus it needs to have it. Just because it would be nice if all 
> mobile hosts could generate their own location information doesn't 
> mean that they do, or will.
>
> I'm sure the cited text did not mean to put words in the mouth of 
> RFC3825, but rather to illustrate the diversity of systems that 
> contribute to host autoconfiguration.

It is a strawman argument to suggest that the only alternatives are 1) 
host gets location through DHCP with IP address, and 2) host gets a 
reference that some Location Server can de-reference to provide 
location.  Getting location through PPP with an IP address is a simple 
and direct solution for the situations identified in the cited text.  
This text does not indicate any connection between the cited case and 
by-reference, and "proliferates a problem that is already starting to 
take hold" is pure FUD without definition of the alleged "problem".

John