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

From: "James Winterbottom" <[email-masked]>
Date: Thu, 21 Jul 2005 16:11:06 +1000

Hi,

This is a new draft describing the merits and rationale for supporting
location by-reference (location URI) mechanism.

Abstract

   This document motivates the provisioning of location by-reference
   within the GEOPRIV architecture.  Location by-reference takes the
   form of a URI in contrast to provisioning a static location.

http://www.ietf.org/internet-drafts/draft-winterbottom-location-uri-00.txt

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

---

From: John Schnizlein <[email-masked]>
Date: Thu, 21 Jul 2005 16:22:56 -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.

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.

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.

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.

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 benefits 
> of
>    the few that will ultimately require location-based services.

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.

John