RE: [Geopriv] Geopriv L7 LCP: New Requirement

From: Winterbottom, James ^lt;>
Date: Wed Feb 14 2007 - 17:57:43 EST

Marc, Your statements demonstrate a clear misinterpretation of the problem in so far as the way in which Barbara, Guy, Otmar and others are trying to stating it. A user is asking the ISP, "Where am I?" He has the right do this, doesn't he? Has he granted the ISP permission therefore to have his location? Of course he has, because he is expecting the ISP to know. The ISP doesn't know where the user is, but the ISP does know who to ask. The thing the ISP is going to ask does know where the User is, but doesn't call the user by that name. This is fact, and it is NOT OBO as has been described with relation to a proxy requesting location on-behalf-of an end-point that is not location capable. It is describing how a location request can be proxied to a node that actually knows where location is. Indeed, the LIS to LIS mechanisms is no more OBO than the DHCP server requesting location from a wiremap database because a DHCP client has requested one of the location options. The LIS to LIS requirement is similar to other relay concepts that the IETF readily endorses when they are proposed. This is NO DIFFERENT to the DHCP relay concept on which a number of existing proposals are heavily dependent. In fact, DHCP relay is a very analogy, since the relay agent essentially uses the same protocol but adds additional identifiers to provide the DHCP server with additional information. Cheers James > -----Original Message----- > From: Marc Linsner [] > Sent: Thursday, 15 February 2007 9:34 AM > To: 'Stark, Barbara' > Cc: 'GEOPRIV WG' > Subject: RE: [Geopriv] Geopriv L7 LCP: New Requirement > > Barbara, > > > > > Furthermore, people have expressed the belief in other venues (other > > than the IETF) that legislative and/or regulatory bodies in some > > countries may require true "On Behalf Of" > > querying by a VPC (VoIP Position Center), when an emergency call > > arrives without a location. It's believed that this could make for a > > smoother transition from non-location-capable to location-capable > > devices. That should be the job of that national entity to legislate > > this (or not), and not of the IETF to simply prevent it (by refusing > > to allow a protocol to support this function). Furthermore, it should > > be the job of these same national legislative/regulatory bodies to > > determine and police privacy > > laws/regulations, and not the IETF. > > > > 1) The IETF is very interested in maintaining the current Internet > architecture as these attributes directly contribute to the Internet's > success. The attributes I'm referring to include the separation of > application from the network. Of particular concern to your proposal is > to > create an application that requires low layer information from the far > side > of the Internet as implementation experience tells us that limits are > created when doing such. It appears some accept these limitations, it > appears some aspire for these limitations. > > 2) The GeoPriv work group is charged with protecting the privacy and > security of an Internet user's location information. When highly > sensitive > information is passed around 'On Behalf Of', it raises large concerns to > the > GeoPriv community. > > 3) Regulators will make rules, regulators are not capable of inventing > technology. Regulators will do what they do regardless of what the IETF > does. > > _______________________________________________ > Geopriv mailing list > > ------------------------------------------------------------------------------------------------ This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ------------------------------------------------------------------------------------------------ [mf2]

Geopriv mailing list
Received on Wed, 14 Feb 2007 16:57:43 -0600

This archive was generated by hypermail 2.1.8 : Wed Feb 14 2007 - 17:57:14 EST