RE: [Geopriv] Geopriv L7 LCP: New Requirement

From: Marc Linsner ^lt;mlinsner@cisco.com>
Date: Thu Feb 15 2007 - 11:26:21 EST

James, Martin,

No, I understand completely. For your convenience, I will copy Barbara's
statement (which happens to be the very first line of my message):

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

Unless you have changed the definition of 'VPC', I am characterizing this as
quite different from a wholesale relationship between an ISP and access
provider.

-Marc-

> -----Original Message-----
> From: Dawson, Martin [mailto:Martin.Dawson@andrew.com]
> Sent: Wednesday, February 14, 2007 6:21 PM
> To: Winterbottom, James; Marc Linsner; Stark, Barbara
> Cc: GEOPRIV WG
> Subject: RE: [Geopriv] Geopriv L7 LCP: New Requirement
>
> Just in case James is interpreting your comments too
> specifically, Marc, I'll respond from the general perspective.
>
> "On-behalf-of", as I think we all understand, means that an
> entity other than the target device is querying the LIS for
> the target location. This means the LIS is explicitly
> identifying the target by some identifier (including IP@ as a
> possibility) as opposed to using the source IP@ of the
> requestor to identify the target.
>
> A key scenario for this is where the target device does not
> have native location capability itself (e.g. a legacy regular
> phone form factor VoIP handset that can't speak an
> acquisition protocol). The applicability of this scenario is
> really limited to the situation where the entity that
> controls the application also controls the access network.
> This may be because it's one entity that owns the whole plot
> or because an independent trust relationship exists between
> multiple entities who, between them, own the whole plot. An
> example is an enterprise switched Ethernet network with an IP
> PABX, legacy VoIP handsets, and their own LIS. Another
> example is a DSL provider that provides an on-net VoIP
> service (not nomadic to third party access) for their DSL
> providers. As such, none of these are really pure Internet
> services model scenarios.
> In both these cases, it is reasonable and secure - and should
> be uncontentious - that the call servers can query the LIS
> on-behalf-of the legacy devices.
>
> Barbara was highlighting that regulators, who are often
> unsympathetic, will require DSL/VoIP provider as mentioned in
> the above scenario to provide full location capability
> according E911 requirements. They won't care if there is a
> problem with getting updates into an existing population of
> clients. For this carrier, the OBO mechanism is both
> technically possible and reliably implementable. Since an OBO
> type request requires strong trust coupling between the
> requestor and the LIS
> - which would involve the use of authentication/authorizatin
> mechanisms, trusted networks and the like, it's not really a
> generic Internet use case. However, it's still are real one
> for the acquisition protocol to accommodate.
>
> Cheers,
> Martin
>
> -----Original Message-----
> From: Winterbottom, James [mailto:James.Winterbottom@andrew.com]
> Sent: Thursday, 15 February 2007 9:58 AM
> To: Marc Linsner; Stark, Barbara
> Cc: GEOPRIV WG
> Subject: RE: [Geopriv] Geopriv L7 LCP: New Requirement
>
> 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 [mailto:mlinsner@cisco.com]
> > 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
> > Geopriv@ietf.org
> > https://www1.ietf.org/mailman/listinfo/geopriv
>
> --------------------------------------------------------------
> ----------
> ------------------------
> 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
> Geopriv@ietf.org
> https://www1.ietf.org/mailman/listinfo/geopriv
>
> --------------------------------------------------------------
> ----------------------------------
> 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
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv
Received on Thu, 15 Feb 2007 11:26:21 -0500

This archive was generated by hypermail 2.1.8 : Thu Feb 15 2007 - 11:25:49 EST