RE: [Geopriv] Message Flow, again

From: Brian Rosen ^lt;br@brianrosen.net>
Date: Fri Nov 23 2007 - 12:36:16 EST

> -----Original Message-----
> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]
> Sent: Friday, November 23, 2007 3:02 AM
> To: Brian Rosen
> Cc: 'Winterbottom, James'; geopriv@ietf.org
> Subject: Re: [Geopriv] Message Flow, again
>
> Hi Brian
>
> Brian Rosen wrote:
> > Reminder that this only works in lots of possible, but generally hard to
> > achieve circumstances (which IMS in a mobile environment, for an
> emergency
> > call, with the E-CSCF in the visited network manages to get right).
> >
> > 1. The IP address seen by the proxy has to actually relate to the
> location
> > of the endpoint. At a proxy, this is VERY hard to assure.
> Not if the proxy is in the access network.
That is the IMS mobile case, but there are few other proxies that know they
are in the access network. In general, with a VPN, you can't tell. Note
that it does NOT work with an IMS wireline case where nomadic use is
permitted.

>
> > All the text
> > about no VPNs or NATs applies,
> You know that the NAT case is not a problem.
Sure it is, depending on where the NAT is. A great example is a NAT in a
multi-site enterprise. Depending on where the NAT is in relation to the
LIS, the NAT can be very problematic. It's often not a problem in a
residential broadband deployment until you get to the point where you want
interior building location data. Then it is problem.

> The VPN aspect is not a problem either in the deployment environments
> where people are going to use this.
If we restrict the use of proxy insertion to a situation where the proxy is
in the access network, fine, but we have no such restriction.

>
> > and you usually don't even know if the device
> > is on an access network that stands a chance of making it happen.
> In the environments we are looking at this is the case.
Only in an IMS mobile deployment. We aren't restricting to such a case.

>
> > This
> > means it wouldn't work, for example, on the Internet, or in an IMS
> wireline
> > network without a guaranteed relationship with the access network.
> >
> In the IMS there is an association with the access network.
Yes. IMS in a mobile network works. I said that up front.

> > 2. There has to be a relation between the proxy and the LIS. The LIS
> should
> > not hand out location unless it really knows who is asking
> >
> That's true. The HELD identity document states this assumption.
> The SIP Location Conveyance document does not call this out explicitly
> since it is only about "conveyance" (as I got told by you and James when
> I raised these issues).
Yes. Probably need more text in phonebcp and framework

>
> > 3. The proxy has to know when to do this. In the example given, there
> is no
> > indication that the proxy should insert location. Generally, a proxy
> > shouldn't add location except under some conditions that warrant it.
> >
> That's completely true. I omitted the "emergency services" related
> components. This was another one of my comments to the SIP Location
> Conveyance document and both of you were happy with my suggestion to
> provide an explicit indication in the SIP SAML document since it is
> needed there anyway.When we consider cases outside the emergency
> services use case then this explicit marking would be used.
The emergency case is covered. The non-emergency case is not.

>
> In summary, I am totally surprised about your comments. The
> functionality of the proxy adding LbyRs is in the SIP Location
> Conveyance specification for a long time already. We know how some
> deployments are going to use this type of emergency services architecture.
> In the past I have stated that we should capture some of the
> architectural issues since everyone was so extremely keen on documenting
> them for HELD as well. This proposal was rejected. I was fine with it.
We can have text in phonebcp that covers this. It's not really a conveyance
problem.

>
> Now, after years it looks like that this would be something entirely
> new. In another mail you want to delay the Phone BCP work to incorporate
> Location Hiding because "otherwise the emergency services architecture
> will not get deployed". With this work you are suddenly totally
> unrealistic. The functionality of allowing a proxy to retrieve location
> information is essentially all over the place for emergency services and
> also documented in the Phone BCP / ECRIT framework document. Are you
> expecting this to be changed?
We probably need more text in phonebcp and framework for the emergency case.

I'm not sure we need it somewhere else, unless there was some more general
location architecture work. There isn't any, and this item probably doesn't
rise to the level where we need a new document just for that.

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv
Received on Fri, 23 Nov 2007 12:36:16 -0500

This archive was generated by hypermail 2.1.8 : Fri Nov 23 2007 - 12:36:28 EST