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

From: "Marc Linsner" <[email-masked]>
Date: Thu, 21 Jul 2005 16:07:03 -0400

In a quick read, I have one comment and the following questions.....

The draft never discusses the privacy issues as outlined in RFC3693 and the
GeoPriv charter.

1) "Similarly a query response mechanism of this nature moves towards
providing better location currency, and because the location is provided
directly from the location generator the dependability of the location is of
a higher degree also."

Does 'directly from the location generator' imply such a service at all
access port devices?  Could you explain the higher degree of dependability?

2) "Location references support session decoupling by allowing the end-point
to distribute the location reference to third parties so that they may
obtain the end-point's location without the end-point needing to maintain a
session with the third party."

How does this protect the privacy of the end-user in accordance with both
the GeoPriv charter and RFC-3693?

3) "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."

Same privacy issues as above.  Plus, please expand on the idea that a
location generator may withhold information pertaining to an end-point from
the end-point?  Business reason (holding location information hostage for
money)?

4) "Continually or periodically re-measuring the location of each end-point
and then notifying or pushing this new location to the end-point is
expensive and generally unnecessary."

To this point, I thought Location URI is a proposed conveyance mechanism.
Please explain how a 3rd party requesting an updated location via this
mechanism is more efficient than the end-device requesting an updated
location on it's own behalf.

5) "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."

Please provide pointers to 'by-value provisioning' mechanisms that provide
continual and probably unnecessary updates.
  
6) "In addition to access technologies having an impact on location, so too
network topologies have an impact on location determination and acquisition.
It is not uncommon for broadband services to be provided to end-consumers
through infrastructure owned and operated by several different
organizations.  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. An alternative approach is to provide a location
reference mechanism that can be common across all access configuration
protocols allowing   simplification and solution consolidation."

Please explain how this new conveyance mechanism will make life simpler at
the lower layers?  Are not access device port wire maps still utilized?
What protocols are going to deliver this data to this new magic box?

7) "Location not explicitly included in provisioning messages, but available
to authorized nodes (which may or may not include the provisioned
endpoint)."

Please expand on how these nodes are authorized?  Please explain failure
modes when authorization does not work?  Please provide guesstimate of added
SIP call setup latency.

8) "Smaller messages traverse much of the network, larger location
components only retrieved as required.  Less load on access network elements
as location is only generated and supplied as required."

Please explain the less load statement.  If the access network is involved
in location determination, then why is there less load when using a
different conveyance mechanism?

9) "End-devices do not need to maintain a trust relationship with the
location recipient in order for the location recipient to obtain the
end-device's location."

Explain how this meets RFC-3693 and the GeoPriv charter?

10) "Location consumers obtain location directly from the generator for a
given end-point increasing location dependability and reducing unnecessary
transitive trust (where recipients would have to trust the consumer
"through" a user-controlled endpoint)."

Explain how/why the consumer should trust the generator?  What if the
end-point and Location URI are the same entity?

11) "Location is determined at request time resulting in more current
locations being returned, especially in dynamic environments where location
might change over time."

Is it assumed that requesting a new location determination is restricted to
this Location URI mechanism?  I don't see the relevance to this statement
when discussing/contrasting location conveyance mechanisms.

12) "Can be easily integrated into existing presence architectures to make
use of existing privacy, authorization and authentication techniques."

Please expand on this.  I missed how the privacy rules are distributed in
this document.

13) "Compensates well for network-layer tunnels etc as location-reference
can be provided at the local level."

How does passing a Location URI change the difficulty for location when
tunnels are used?

-Marc-

Marc Linsner
Consulting Engineer - Corporate Development
Cisco Systems, Inc.
+1-239-272-2105

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