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

From: "Carl Reed OGC" <[email-masked]>
Date: Fri, 22 Jul 2005 09:26:22 -0600

Brian -

Thank you for taking the time to answer my question. I now have clarity :-)

Also, you are correct about the network location servers supporting the 
geopriv privacy model. From what I understand, privacy is dealt with in 
another layer of the infrastructure - often at the consumer preferences 
level, perhaps as part of an opt-in/opt-out exercise. OMA/LIF does have a 
very extensive privacy manifesto document that has been approved by the OMA 
membership. As this document was written by an international set of members, 
it does abide by privacy concerns and legislation from many regions.

It is available on line at the OMA web site.

Cheers

Carl

----- Original Message ----- 
From: "Brian Rosen" <[email-masked]>
To: "'Carl Reed OGC'" <[email-masked]>; "'Peterson, Jon'" 
<[email-masked]>; "'John Schnizlein'" <[email-masked]>; 
"'James Winterbottom'" <[email-masked]>
Cc: "'GEOPRIV'" <[email-masked]>
Sent: Friday, July 22, 2005 6:51 AM
Subject: RE: [Geopriv] GeoPriv :- draft-winterbottom-location-uri

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

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