Subject: [Ecrit] Location Hiding -- State of the Art

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 01 Dec 2007 21:34:20 +0100

I thought that the following article would be of interest for you:
http://googleblog.blogspot.com/2007/11/lost-no-found.html

Here is text from 
http://googlemobile.blogspot.com/2007/11/new-magical-blue-circle-on-your-map.html
"
My Location is a new beta technology from Google that uses cell tower 
identification to provide you with approximate location information, so 
it will work on phones without GPS.
"
Note that this stuff is not really new technology. It existed already 
for some time but the availability of GPS devices made it possible to 
setup the database in a more efficient way.

Anyway, this mechanism allows you to obtain location information with 
your cell phone (using the cell id) without interacting with the 
cellular operator.
In short: operator cannot charge for location

While the location information is not really useful for first responders 
it is still good enough for finding the closest PSAP.

Is this the dead of location hiding?

Ciao
Hannes

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

---

From: "Brian Rosen" <[email-masked]>
Date: Sun, 2 Dec 2007 20:09:15 -0500

No.

First of all, please do no repeat the myth that tower location is good
enough for finding the closest PSAP.  First of all "closest" is not
"correct", and tower location is NOT good enough to find the correct PSAP.
It may be all there is, and if it is, then that's what is used, but it
causes a lot of misrouted calls, which delays response.  There are many
aspects of location which aren't really good enough to meet the requirements
but we deal with because it's the only practical answer.

I think this is a form of location hiding, and not the beginning of the end.

Brian

> -----Original Message-----
> From: Hannes Tschofenig [mailto:[email-masked]]
> Sent: Saturday, December 01, 2007 3:34 PM
> To: ECRIT
> Subject: [Ecrit] Location Hiding -- State of the Art
>

---

From: "Dawson, Martin" <[email-masked]>
Date: Sun, 2 Dec 2007 22:57:54 -0600

Hi Hannes,

I think it's important to lay some of the salient points about "location
hiding" out. BTW, I agree with Brian - this service doesn't mean
location hiding is dead. Warning - opinions ahead.

There are a lot of ways that location can be determined - GPS, Skyhook,
this Google service just being some examples. These are all offered and
operating independently of the provider of the access network (I've got
a suspicion that Google are surveying cell tower names at the same time
that they are doing their street-views photos). I don't see the Google
service as being the death knell of location hiding as a concept.

In the context of location as part of an Internet communications
context, however, there is synergy between the provision of the
communication function and the provision of the location function. After
all, if the location is needed in a communications context, you can
largely guarantee that the coverage for both services is coincident.

You don't *have* to rely on the access network provider to determine
location but it's *likely* that if anyone is required to provide the
location service it will be the access network provider. While I dare
say Google would be happy to have their service used to support
emergency calls, I doubt they'd be happy to be told that it has to be
ubiquitous and meet rigorous availability and accuracy constraints for
which they'll be responsible. This is the sort of requirement, however,
that public broadband providers and ISPs may face.

If these providers do end up being required to invest in the
infrastructure to provide reliable and accurate location for emergency
services then they will likely feel entitled to recoup the investment
somehow. Barring direct public subsidy or other tax-based cost-recovery,
they will want to reserve the right to restrict access to the facility
for emergency-only scenarios. They will quite likely want to reserve the
option to charge an additional $X per month premium to access
subscribers who want open-slather access to the location service for
arbitrary applications.

Despite the demonizing that access providers are subject to over this
functionality, I can certainly sympathize with the viewpoint. I do
believe that the location service will eventually be absorbed into the
general access subscription anyway (just IMHO). In the first instance,
however, I can also see that not supporting a standard location-hiding
mechanism is likely to lead to more resistance to deployment (i.e.
lobbying against regulation) and a slower realization of a ubiquitous
and reliable VoIP emergency service than is necessary.

Cheers,
Martin

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Monday, 3 December 2007 12:09 PM
To: 'Hannes Tschofenig'; 'ECRIT'
Subject: RE: [Ecrit] Location Hiding -- State of the Art

No.

First of all, please do no repeat the myth that tower location is good
enough for finding the closest PSAP.  First of all "closest" is not
"correct", and tower location is NOT good enough to find the correct
PSAP.
It may be all there is, and if it is, then that's what is used, but it
causes a lot of misrouted calls, which delays response.  There are many
aspects of location which aren't really good enough to meet the
requirements
but we deal with because it's the only practical answer.

I think this is a form of location hiding, and not the beginning of the
end.

Brian

> http://googleblog.blogspot.com/2007/11/lost-no-found.html
http://googlemobile.blogspot.com/2007/11/new-magical-blue-circle-on-your
-
> map.html

------------------------------------------------------------------------------------------------
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]

---

From: "Stark, Barbara" <[email-masked]>
Date: Mon, 3 Dec 2007 08:23:21 -0500

If people felt this was good enough so that access providers would not
need to be required to build the infrastructure to provide location
(because people could use this method instead of getting location from
access providers), then location hiding would be dead. If people still
want to place a requirement on access providers to provide location,
then location hiding is not dead.
Barbara

-----Original Message-----
From: Hannes Tschofenig [mailto:[email-masked]] 
Sent: Saturday, December 01, 2007 3:34 PM
To: ECRIT
Subject: [Ecrit] Location Hiding -- State of the Art

Here is text from 
-map.html

Ciao
Hannes

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 03 Dec 2007 18:36:53 -0600

Currently, the WG (and document editors!) should be operating under 
the consensus direction that Location Hiding *not* be in PhoneBCP or 
Framework.  This was a clear consensus call in Chicago - and not by 
default, but by most people voicing actively against having this 
Hiding in either core ECRIT documents, and I haven't yet talked to 
anyone here in Vancouver that thinks otherwise.

Location Hiding is something that needs to be addressed BY ITSELF 
(i.e., in its own doc) so everyone can focus on the singular topic, 
and work towards not talking past each other (not like that's 
happened before in ECRIT....  :-/

Who disagrees with this?

BTW - if someone thinks Location Hiding should be put back into 
PhoneBCP or Framework, then they can attempt to gain WG consensus on 
that, but that's different than a direction of this inevitability or 
that there is not consensus on this.

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 3 Dec 2007 20:47:34 -0500

It's fine with me if there is a separate doc, but framework and phonebcp
have to reference it.

I think it can be solved with a one paragraph description of the problem in
framework and a one paragraph solution in phonebcp, but if there is a
separate doc and a reference, I will be happy.

Brian

> From: James M. Polk [mailto:[email-masked]]
> Sent: Monday, December 03, 2007 7:37 PM
> To: Stark, Barbara; Hannes Tschofenig; ECRIT

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 03 Dec 2007 19:38:24 +0100

Hi Brian,

> It's fine with me if there is a separate doc, but framework and phonebcp
Are we talking about informative or normative references?
> separate doc and a reference, I will be happy.
That does not make sense.
The solution is not one paragraph and the text in phone bcp is normative.

Ciao
Hannes

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 4 Dec 2007 10:37:28 -0500

Proposed text for framework

Some access networks wish to restrict who can get a high quality location,
possibly based on a payment arrangement.  For emergency calls, high quality
location must be provided.  An access network can reasonably be expected to
have a relationship with the PSAPs in its catchment area, so giving location
to the PSAP will be straightforward.  However, an endpoint may need location
for routing, and a proxy may need to verify that a purported emergency call
is targeted at a bona fide PSAP.  To do so, it may take the location passed
with the call and query LoST to confirm that the URI is genuine.  "Hiding"
location interferes with this check.  To achieve location hiding, the LIS
can return a coarse location which is good enough to elicit the same
response from LoST as the actual location would.  The endpoint and the proxy
can use this location to route and verify.  A suitable location for a geo is
a polygon calculated by intersecting the service boundaries of all of the
emergency services that respond to the actual location.  A suitable location
for a civic is any civic location within the intersection of the service
boundaries of emergency services.  In a great many cases, a country code is
sufficient.  In others a state/province or a city name is sufficient.  Of
course, the LIS would always return a location reference, which would return
high quality location for a PSAP and coarse location to the endpoint or any
proxy unknown to the LIS.

Proposed text for phonebcp:

A LIS who wishes to hide location returns a location reference.  When
dereferenced by the endpoint or proxy:
1. For LIS's returning geo:
    For each location served by the LIS, compute the intersection of the
    service boundaries for all emergency services known to LoST for the 
    location. Return the resulting polygon, or any point in the polygon as
    the value during a dereference 
2. For LIS's returning civic:
    Determine a civic location which is within the service boundary of all
    emergency services known to LoST for the location.  In a great many
    cases, this will be a country code, province/state or city. Return this
    coarse civic location as the value during a dereference
Note that the service boundaries returned from LoST have a TTL, the
intersections MUST recalculated if the service boundary changes.  The LIS
MUST return high quality location to a PSAP or ESRP.

Brian

> Sent: Monday, December 03, 2007 1:38 PM
> To: Brian Rosen
> Cc: 'James M. Polk'; 'Stark, Barbara'; 'ECRIT'
> Subject: Re: [Ecrit] Location Hiding -- State of the Art
> 
> Hi Brian,
> 
> Brian Rosen wrote:

---

From: "Liess, Laura" <[email-masked]>
Date: Tue, 4 Dec 2007 16:53:44 +0100

I like this proposal. Thanks, Brian.

Laura 

-----Ursprüngliche Nachricht-----
Von: Brian Rosen [mailto:[email-masked]] 
Gesendet: Dienstag, 4. Dezember 2007 16:37
An: 'Hannes Tschofenig'
Cc: 'ECRIT'
Betreff: RE: [Ecrit] Location Hiding -- State of the Art

Brian

---

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 4 Dec 2007 11:53:34 -0600

Brian,

This text describes a solution that has not been agreed by either
GEOPRIV or ECRIT at this point. This solution places a very significant
additional burden on location providers that will already have the
considerable cost of installing and maintaining this infrastructure. I
also believe that the proposed solution simply does not work for
controlling access to selected value-added services, something that is a
very obvious extension to the existing requirement set.

Large scale LISes will have several million location records, requiring
a LIS to perform polygon service boundary intersection checks against
each one of these is unreasonable.

As has been described on more than occasion there are two distinct
billing issues here. The first is right of the location provider to
charge for location, and the second is the right of the downstream VSP
to charge for calls to non-emergency destinations. The solutions you
prescribe place all of the burden on the location provider, and none on
the VSP. I will also stress that the problem comes about because our
selected architecture requires routing of emergency calls back through a
remote (home) VSP. An architecture with a more localized, not
necessarily in the local access network, emergency only VSP could go a
long way to addressing many of these issues.

I propose that an equally good solution is one where the PSAP URI,
service URN and a location URI are supplied directly to the end-point.
This would then require a separate solution to address the billing
concerns of the VSPs, without pushing all the management and
computational load described above onto the location provider. The
advantage of this solution is that it also permits to the location
provider to selectively turn on access to location information for other
services with which it has established a relationship. I cannot see how
the solution text you have proposed will allow this.

Cheers
James

> Sent: Wednesday, 5 December 2007 2:37 AM
> To: 'Hannes Tschofenig'
> Cc: 'ECRIT'
> location must be provided.  An access network can reasonably be
expected
> to
> can use this location to route and verify.  A suitable location for a
geo
> is
> boundaries of emergency services.  In a great many cases, a country
code
> is
> high quality location for a PSAP and coarse location to the endpoint
or
> any
> > > I think it can be solved with a one paragraph description of the
> problem
> > in
> > >>> If people felt this was good enough so that access providers
would
> not
> > >>> (because people could use this method instead of getting
location
> from
http://googlemobile.blogspot.com/2007/11/new-magical-blue-circle-on-
> > your
> > >>> identification to provide you with approximate location
information,
> > so
> > >>> for some time but the availability of GPS devices made it
possible
> to

---

From: "Liess, Laura" <[email-masked]>
Date: Fri, 7 Dec 2007 04:10:52 +0100

Brian,

I checked with my company and we need LH for both civic and geo for fixed and mobile access. Only DSL and civic is not an option. 

I would support sending the ESRP/PSAP URI to the UA, as proposed by Barbara and James some weeks ago. 

Laura

-----Ursprüngliche Nachricht-----
Von: Brian Rosen [mailto:[email-masked]] 
Gesendet: Dienstag, 4. Dezember 2007 16:37
An: 'Hannes Tschofenig'
Cc: 'ECRIT'
Betreff: RE: [Ecrit] Location Hiding -- State of the Art

to the PSAP will be straightforward

However, an endpoint may need location

Brian

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 7 Dec 2007 12:13:27 -0500

Laura,

just because somebody says "we need it" doesn't make it an IETF  
requirement. Please justify why mobile access cannot provide locations  
to end users.

Henning

On Dec 6, 2007, at 10:10 PM, Liess, Laura wrote:

> Brian,
>
> I checked with my company and we need LH for both civic and geo for  
> fixed and mobile access. Only DSL and civic is not an option.
>
> expected to
> code is
> or any
>>>>> would not
>>>>> location from
>>>>> possible to

---

From: "Stark, Barbara" <[email-masked]>
Date: Fri, 7 Dec 2007 16:24:52 -0500

[The following statements are my opinion, and should not be attributed to the company I work for.]

Henning,
It's true that the IETF doesn't have to do something just because someone wants it. It's also true that the IETF has no authority or ability to force implementation of RFCs by companies who refuse to implement them. You cannot shove a solution down the throats of access providers that they are unwilling to buy in to. In my opinion, even attempting to do so would be, well, unethical.

So, you have a choice: 
1) create a solution that you like that major stakeholders are unwilling to implement
2) create a solution that you don't quite like, but that's better than what we have today, and which major stakeholders are willing to implement

Believe it or not, major telecom companies in the US and Europe put a lot of effort into lobbying regulatory bodies, to achieve desirable outcomes. The IETF doesn't put in such effort. If you want to make a go at pushing through a solution that stakeholders in these regions are set against, and see if you can get regulatory agencies to bless it, then go for it. I think the odds are stacked against you, though. Especially since there are workable solutions that these companies have said they would be willing to accept.

Here is why mobile access providers "cannot" provide the best available location directly to end user devices: They don't want to. At this point in time, it's their network, their data, and their choice.

In free market economies, you generally have to be able to *prove* (and not just say it without proof) massive benefit or massive harm before you can force companies to do what they don't want to do, through regulation. Again, if you think you can take on that battle and win, go for it.

I, for one, believe that not providing the "real" location value to end devices would not cause such benefit or harm. If users want to know what location PSAPs get on their behalf, and regulators believe such a capability is needed, then we can let the phonebcp-described test mechanism voice it back over the voice medium (this would only work for civic), or return a JPEG map with a dot on it. This would provide location in a format that's usable by a human being, but not an application. Or maybe, in some countries, the regulators do require access providers to give out the best possible location values to end devices. But it's really improbable that you could force the regulators of all countries to see things your way.

But, this is all just my opinion.
Barbara

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]] 
Sent: Friday, December 07, 2007 12:13 PM
To: Liess, Laura
Cc: [email-masked]
Subject: Re: AW: [Ecrit] Location Hiding -- State of the Art

Laura,

Henning

*****

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA622

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 7 Dec 2007 16:55:46 -0500

Translation: You have more lobbyists than I (or the IETF), so give me.  
Thanks for clarifying that.

Henning

On Dec 7, 2007, at 4:24 PM, Stark, Barbara wrote:

> It's true that the IETF doesn't have to do something just because  
> someone wants it. It's also true that the IETF has no authority or  
> ability to force implementation of RFCs by companies who refuse to  
> implement them. You cannot shove a solution down the throats of  
> access providers that they are unwilling to buy in to. In my  
> opinion, even attempting to do so would be, well, unethical.
>
> So, you have a choice:
> 2) create a solution that you don't quite like, but that's better  
> than what we have today, and which major stakeholders are willing to  
> implement
>
> Believe it or not, major telecom companies in the US and Europe put  
> a lot of effort into lobbying regulatory bodies, to achieve  
> desirable outcomes. The IETF doesn't put in such effort. If you want  
> to make a go at pushing through a solution that stakeholders in  
> these regions are set against, and see if you can get regulatory  
> agencies to bless it, then go for it. I think the odds are stacked  
> against you, though. Especially since there are workable solutions  
> that these companies have said they would be willing to accept.
>
> Here is why mobile access providers "cannot" provide the best  
> available location directly to end user devices: They don't want to.  
> At this point in time, it's their network, their data, and their  
> choice.
>
> In free market economies, you generally have to be able to *prove*  
> (and not just say it without proof) massive benefit or massive harm  
> before you can force companies to do what they don't want to do,  
> through regulation. Again, if you think you can take on that battle  
> and win, go for it.
>
> I, for one, believe that not providing the "real" location value to  
> end devices would not cause such benefit or harm. If users want to  
> know what location PSAPs get on their behalf, and regulators believe  
> such a capability is needed, then we can let the phonebcp-described  
> test mechanism voice it back over the voice medium (this would only  
> work for civic), or return a JPEG map with a dot on it. This would  
> provide location in a format that's usable by a human being, but not  
> an application. Or maybe, in some countries, the regulators do  
> require access providers to give out the best possible location  
> values to end devices. But it's really improbable that you could  
> force the regulators of all countries to see things your way.
>
> The information transmitted is intended only for the person or  
> entity to which it is addressed and may contain confidential,  
> proprietary, and/or privileged material. Any review, retransmission,  
> dissemination or other use of, or taking of any action in reliance  
> upon this information by persons or entities other than the intended  
> recipient is prohibited. If you received this in error, please  
> contact the sender and delete the material from all computers. GA622
>
>

---

From: "Dawson, Martin" <[email-masked]>
Date: Sat, 8 Dec 2007 17:39:24 -0600

Hi all,

Everything is qualified on what ultimately gets regulated. But it's probably time to discuss real world implications of this topic.

I expect that, if access operators are required to provide location, it is only going to be for the purpose of emergency services. I doubt that regulators will even consider mandating that they provide it for all users for all purposes. There'll be no sledgehammer to force access providers to give everyone a free location service - so it won't happen until operators have their own reasons to do so.

Since access providers can't control what client devices actually use location information for, they will only implement a system that permits a recognised emergency entity to retrieve the actual location value. They'll only give the end subscriber location information if that's already paid for as part of the subscription.

The fundamental problem with the "do location hiding by providing location" proposal is exactly that. It fails to hide location. This is particularly the case in the US (which is a difficult market to ignore). The intersection of every possible service area - also called an ESN or ESZ - in the US is a quite granular area; certainly good for quite a lot of services. For a mobile access provider, in particular, a considerable amount of capital equipment is going to be invoked to provide this quite good location information.

On the other hand, in many other countries (e.g. the UK and Australia) this technique is probably not problematic for the carrier, because they are just going to return the country code. That's as granular as you need to be for emergency services.

So here's what will happen if this is the official IETF recommendation. It may get adopted but operators will limit the provided location information to just the country indicator. They'll do this in the US as well (they'll refuse to process all the LoST boundary data and take responsibility for consequent routing outcome). This means that VSPs dealing with calls originating in the US will need to use i2. This is because the V2 interface in i2 does support a location reference while LoST is unable to do this. The country information will certainly be useful for arbitrating which VPC to use though - so that's good. It will mean that direct to PSAP calls won't be able to be made in the US. That's a shame. Other jurisdictions that only have a single PSAP route will be able to support this. OTOH, it might force the US to provide a federal level URI with proxies that can subsequently do the dereference and lower level routing - so maybe it's not such a shame. It won't result in access providers giving free location information until they are ready to do so however.

Editorial and a genuine question:

IMO, supporting the services URI extension in HELD or adding location reference support to LoST are both superior engineering solutions. They just aren't driven by the punitive motivations of the "hide by not hiding" proposal. Arguments that they are inferior because they require protocol changes are specious and self-fulfilling. That's why the "reference query" mechanism for LoST was "postponed" in the interest of getting LoST finalized. It continues to be used as a prop for this particular hiding proposal. By this line of argument, we would never add or modify protocols for anything.

It's very difficult not to lapse into sarcasm in this area (I feel like saying it's OK not to have location hiding because Columbia University and Cisco are going to underwrite the cost of providing a 5x9s reliable ubiquitous location service in all public access networks out of pure philanthropy.... but I won't :) ).

Insisting on providing location for all applications is like insisting that cellular operators let users call anyone just to ensure that they can also make emergency calls. In this hypothetical situation, refusing to define protocol mechanisms that permit them to distinguish between the scenarios would only result in there being no cellular service - or just publicly funded cellular services. It's a counter-productive attitude.

This provides the opportunity for me to once more ask a question that hasn't been responded to in the past. Why is ECRIT describing a solution that has the VSP involved in the emergency call at all? Why would the VSP want to be involved in emergency calls - and why would the caller want them involved? It seems to be not in the interest of either party. There's already an interim architecture for the non "end-to-end IP" scenario called i2. In any circumstance where any of the device, the network, or emergency operator are not ECRIT-capable, then the VSP does need to be involved and i2 is a valid fallback.

Cheers,
Martin

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]] 
Sent: Saturday, 8 December 2007 8:56 AM
To: Stark, Barbara
Cc: [email-masked]; Liess, Laura
Subject: Re: AW: [Ecrit] Location Hiding -- State of the Art

Henning

---

From: "Liess, Laura" <[email-masked]>
Date: Mon, 10 Dec 2007 15:03:41 +0100

Henning,

There are at least two reasons for it:

1) Different from US, DT can not just charge every access customer an additional fee for providing the Location Info for Emergency Calling. The regulator will not let us to do it. We probably can charge an additional fee if customers "buy" the Location Info or Location Services from us. As we do not get the hard-/software for the whole EC and Location stuff for free and, on the other side, the profit margin for access is currently very low (at least in Germany), we need to sell the Location Info in some form and can not afford to just give it out for free. 

2) Many of our customers just want to use their phone as they use it today. They don't want to deal with additional security or configuration issues to be able to call 112. DT can not just "push" the Location Info to the end device and write into the General Terms and Conditions that the user is responsible for its misuse. (A lot of people buy the AVM FritzBox DSL-Router because it has a simple switch to turn-off the WLAN without any software configuration.) I expect regulatory requirements in Germany asking the access providers to be able to do location hiding for 112.   

Laura   

-----Ursprüngliche Nachricht-----
Von: Henning Schulzrinne [mailto:[email-masked]] 
Gesendet: Freitag, 7. Dezember 2007 18:13
An: Liess, Laura
Cc: [email-masked]
Betreff: Re: AW: [Ecrit] Location Hiding -- State of the Art

Laura,

Henning

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 10 Dec 2007 09:56:33 -0500

The only emergency service in the U.S. is urn:service:sos.  There is only
one boundary and if it changes (which LoST tells you via the TTL of the
service boundary), you may have to find those locations affected by the
change when they request a new location URI.  

In the countries where there are multiple services, there are only a few
(sometimes one) ESRPs.

There could be some theoretic case of lots of ESRPs and lots of services, in
which case there are more intersections, but the calculation is simple,
fairly quick, and the TTLs make it easy to determine when a change is made,
and several pretty straightforward strategies are available to minimize the
work on the LIS.

Brian

> From: Dawson, Martin [mailto:[email-masked]]
> Sent: Saturday, December 08, 2007 6:39 PM
> To: Henning Schulzrinne; Stark, Barbara
> Subject: RE: AW: [Ecrit] Location Hiding -- State of the Art
> 
> Hi all,
> 
> Everything is qualified on what ultimately gets regulated. But it's
> probably time to discuss real world implications of this topic.
> 
> I expect that, if access operators are required to provide location, it is
> only going to be for the purpose of emergency services. I doubt that
> regulators will even consider mandating that they provide it for all users
> for all purposes. There'll be no sledgehammer to force access providers to
> give everyone a free location service - so it won't happen until operators
> have their own reasons to do so.
> 
> Since access providers can't control what client devices actually use
> location information for, they will only implement a system that permits a
> recognised emergency entity to retrieve the actual location value. They'll
> only give the end subscriber location information if that's already paid
> for as part of the subscription.
> 
> The fundamental problem with the "do location hiding by providing
> location" proposal is exactly that. It fails to hide location. This is
> particularly the case in the US (which is a difficult market to ignore).
> The intersection of every possible service area - also called an ESN or
> ESZ - in the US is a quite granular area; certainly good for quite a lot
> of services. For a mobile access provider, in particular, a considerable
> amount of capital equipment is going to be invoked to provide this quite
> good location information.
> 
> On the other hand, in many other countries (e.g. the UK and Australia)
> this technique is probably not problematic for the carrier, because they
> are just going to return the country code. That's as granular as you need
> to be for emergency services.
> 
> So here's what will happen if this is the official IETF recommendation. It
> may get adopted but operators will limit the provided location information
> to just the country indicator. They'll do this in the US as well (they'll
> refuse to process all the LoST boundary data and take responsibility for
> consequent routing outcome). This means that VSPs dealing with calls
> originating in the US will need to use i2. This is because the V2
> interface in i2 does support a location reference while LoST is unable to
> do this. The country information will certainly be useful for arbitrating
> which VPC to use though - so that's good. It will mean that direct to PSAP
> calls won't be able to be made in the US. That's a shame. Other
> jurisdictions that only have a single PSAP route will be able to support
> this. OTOH, it might force the US to provide a federal level URI with
> proxies that can subsequently do the dereference and lower level routing -
> so maybe it's not such a shame. It won't result in access providers giving
> free location information until they are ready to do so however.
> 
> IMO, supporting the services URI extension in HELD or adding location
> reference support to LoST are both superior engineering solutions. They
> just aren't driven by the punitive motivations of the "hide by not hiding"
> proposal. Arguments that they are inferior because they require protocol
> changes are specious and self-fulfilling. That's why the "reference query"
> mechanism for LoST was "postponed" in the interest of getting LoST
> finalized. It continues to be used as a prop for this particular hiding
> proposal. By this line of argument, we would never add or modify protocols
> for anything.
> 
> It's very difficult not to lapse into sarcasm in this area (I feel like
> saying it's OK not to have location hiding because Columbia University and
> Cisco are going to underwrite the cost of providing a 5x9s reliable
> ubiquitous location service in all public access networks out of pure
> philanthropy.... but I won't :) ).
> 
> Insisting on providing location for all applications is like insisting
> that cellular operators let users call anyone just to ensure that they can
> also make emergency calls. In this hypothetical situation, refusing to
> define protocol mechanisms that permit them to distinguish between the
> scenarios would only result in there being no cellular service - or just
> publicly funded cellular services. It's a counter-productive attitude.
> 
> This provides the opportunity for me to once more ask a question that
> hasn't been responded to in the past. Why is ECRIT describing a solution
> that has the VSP involved in the emergency call at all? Why would the VSP
> want to be involved in emergency calls - and why would the caller want
> them involved? It seems to be not in the interest of either party. There's
> already an interim architecture for the non "end-to-end IP" scenario
> called i2. In any circumstance where any of the device, the network, or
> emergency operator are not ECRIT-capable, then the VSP does need to be
> involved and i2 is a valid fallback.
> 
> Cheers,
> Martin
>

---

From: "Winterbottom, James" <[email-masked]>
Date: Mon, 10 Dec 2007 09:38:08 -0600

Brian,

The primary aim for hiding location is not to make it hard for emergency services, but to enable the ability to charge for value added services. Can you please explain how this solution (other than through a one off charge for location) supports this requirement.

Cheers
James

> Sent: Tuesday, 11 December 2007 1:57 AM
> To: Dawson, Martin; 'Henning Schulzrinne'; 'Stark, Barbara'
> Cc: [email-masked]; 'Liess, Laura'
> > ------------------------------------------------------------------------
> --
> > ----------------------
> > ------------------------------------------------------------------------
> --
> > ----------------------
> > [mf2]
> >
> >

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 10 Dec 2007 10:50:58 -0500

We are talking about location-by-reference.

An endpoint or VSP dereferencing this URI will get coarse location, as
described.

A PSAP or ESRP dereferencing will have credentials, and will get high
resolution data

An authorized entity (i.e. one paying for it) will have credentials and will
get high resolution data.

Where is the problem?

> From: Winterbottom, James [mailto:[email-masked]]
> Sent: Monday, December 10, 2007 10:38 AM
> To: Brian Rosen; Dawson, Martin; Henning Schulzrinne; Stark, Barbara
> The primary aim for hiding location is not to make it hard for emergency
> services, but to enable the ability to charge for value added services.
> Can you please explain how this solution (other than through a one off
> charge for location) supports this requirement.
> 
> Cheers
> James
> 
> 
> > There could be some theoretic case of lots of ESRPs and lots of
> services,
> > in
> > > I expect that, if access operators are required to provide location,
> it
> > is
> > > for all purposes. There'll be no sledgehammer to force access
> providers
> > to
> > > location information for, they will only implement a system that
> permits
> > a
> > > So here's what will happen if this is the official IETF
> recommendation.
> > It
> > > proxies that can subsequently do the dereference and lower level
> routing
> > -
> > > >> is targeted at a bona fide PSAP.  To do so, it may take the
> location
> > > >> passed
> > > >>>>> the consensus direction that Location Hiding *not* be in
> PhoneBCP
> > > >>>>> or
> > > >>>>> PhoneBCP or Framework, then they can attempt to gain WG
> consensus
> > > >>>>> on
> > > >>>>> that, but that's different than a direction of this
> inevitability
> > > >>>>> or
> > > >>>>>> access providers), then location hiding would be dead. If
> people
> > > >>>>>> still
> > > >>>>>> http://googlemobile.blogspot.com/2007/11/new-magical-blue-
> circle-
> > > on-
> > > >>> your
> > > >>>>>> -map.html
> > > >>>>>> "
> > > >>>>>> Anyway, this mechanism allows you to obtain location
> information
> > > >>>>>> with

---

From: "Winterbottom, James" <[email-masked]>
Date: Mon, 10 Dec 2007 09:57:18 -0600

If I get coarse location good enough to route to my local pizza delivery facility then I have gotten my value added service for free.

I rest my case!

> Sent: Tuesday, 11 December 2007 2:51 AM
> To: Winterbottom, James; Dawson, Martin; 'Henning Schulzrinne'; 'Stark,
> Barbara'
> > > and several pretty straightforward strategies are available to
> minimize
> > > the
> > > work on the LIS.
> > >
> > > Brian
> > >
> > > > interface in i2 does support a location reference while LoST is
> unable
> > > to
> > > > which VPC to use though - so that's good. It will mean that direct
> to
> > > PSAP
> > > > saying it's OK not to have location hiding because Columbia
> University
> > > and
> > > > that cellular operators let users call anyone just to ensure that
> they
> > > can
> > > > that has the VSP involved in the emergency call at all? Why would
> the
> > > VSP
> > > > >> I would support sending the ESRP/PSAP URI to the UA, as proposed
> by
> > > > >> Barbara and James some weeks ago.
> > > > >>
> > > > >> Laura
> > > > >>
> > > > >>
> > > > >>
> > > > >> possibly based on a payment arrangement.  For emergency calls,
> high
> > > > >> quality
> > > > >> have a relationship with the PSAPs in its catchment area, so
> giving
> > > > >> location
> > > > >> response from LoST as the actual location would.  The endpoint
> and
> > > > >> the proxy
> > > > >> can use this location to route and verify.  A suitable location
> for
> > > > >> a geo is
> > > > >> a polygon calculated by intersecting the service boundaries of
> all
> > > > >> of the
> > > > >> emergency services that respond to the actual location.  A
> suitable
> > > > >> location
> > > > >>   For each location served by the LIS, compute the intersection
> of
> > > > >> the
> > > > >>>> framework and a one paragraph solution in phonebcp, but if
> there
> > > > >>>> is a
> > > > >>>>> Framework.  This was a clear consensus call in Chicago - and
> not
> > > > >>>>> by
> > > > >>>>> Hiding in either core ECRIT documents, and I haven't yet
> talked
> > to
> > > > >>>>>> My Location is a new beta technology from Google that uses
> cell
> > > > >>>>>> tower
> > > > --------------------------------------------------------------------
> --
> > --
> > > --
> > > > ----------------------
> > > > --------------------------------------------------------------------
> --
> > --
> > > --
> > > > ----------------------
> > > > [mf2]
> > > >
> > > >

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 10 Dec 2007 11:08:01 -0500

Yes, that is true.

If your pizza delivery service provider's service boundary matches your
ESRPs boundary, you are in luck.

In my conversations with carriers who want to do location hiding, this is
not seen as a problem.

Brian

> Sent: Monday, December 10, 2007 10:57 AM
> If I get coarse location good enough to route to my local pizza delivery
> facility then I have gotten my value added service for free.
> 
> I rest my case!
> 
> 
> > > > fairly quick, and the TTLs make it easy to determine when a change
> is
> > > > made,
> > > > > regulators will even consider mandating that they provide it for
> all
> > > > users
> > > > > only give the end subscriber location information if that's
> already
> > > paid
> > > > > location" proposal is exactly that. It fails to hide location.
> This
> > is
> > > > > The intersection of every possible service area - also called an
> ESN
> > > or
> > > > > ESZ - in the US is a quite granular area; certainly good for quite
> a
> > > lot
> > > > > this technique is probably not problematic for the carrier,
> because
> > > they
> > > > > are just going to return the country code. That's as granular as
> you
> > > > need
> > > > > refuse to process all the LoST boundary data and take
> responsibility
> > > for
> > > > > so maybe it's not such a shame. It won't result in access
> providers
> > > > giving
> > > > > changes are specious and self-fulfilling. That's why the
> "reference
> > > > query"
> > > > > also make emergency calls. In this hypothetical situation,
> refusing
> > to
> > > > > scenarios would only result in there being no cellular service -
> or
> > > just
> > > > > called i2. In any circumstance where any of the device, the
> network,
> > > or
> > > > > emergency operator are not ECRIT-capable, then the VSP does need
> to
> > be
> > > > > > than what we have today, and which major stakeholders are
> willing
> > to
> > > > > > implement
> > > > > >
> > > > > >> Some access networks wish to restrict who can get a high
> quality
> > > > > >> location,
> > > > > >> with the call and query LoST to confirm that the URI is
> genuine.
> > > > > >> "Hiding"
> > > > > >> location interferes with this check.  To achieve location
> hiding,
> > > > > >> the LIS
> > > > > >> for a civic is any civic location within the intersection of
> the
> > > > > >> service
> > > > > >>   service boundaries for all emergency services known to LoST
> for
> > > the
> > > > > >>   Determine a civic location which is within the service
> boundary
> > > > > >> of all
> > > > > >>   emergency services known to LoST for the location.  In a
> great
> > > many
> > > > > >> intersections MUST recalculated if the service boundary
> changes.
> > > > > >> The LIS
> > > > > >>>> It's fine with me if there is a separate doc, but framework
> and
> > > > > >>>> phonebcp
> > > > > >>>> have to reference it.
> > > > > >>>>
> > > > > >>>>> Currently, the WG (and document editors!) should be
> operating
> > > > > >>>>> under
> > > > > >>>>>> I thought that the following article would be of interest
> for
> > > > > >>>>>> you:
> > > > > >>>>>> Note that this stuff is not really new technology. It
> existed
> > > > > >>>>>> already
> > > > > >>>>>> your cell phone (using the cell id) without interacting
> with
> > > the
> > > > > >>>>>> cellular operator.
> > > > > >>>>>> While the location information is not really useful for
> first
> > > > > >>> responders
> > > > > >>>>>>

---

From: "Winterbottom, James" <[email-masked]>
Date: Mon, 10 Dec 2007 10:14:32 -0600

Brian my point is this.

A location hiding mechanism that ONLY provides the boundary map of the ESRP is pretty much useless in that it won't enable them to support the value added case period. Since the only reason that anyone would pay for it is so that they can support value added services I don't see how you address the requirement.

Franchise boundaries are unlikely to match ESRP boundaries. Further more, not all value added service may be permitted, so the Target still needs to know what services for a given location provider will be permitted to obtain location information. I think the view of providing a coarse location is driven by a particular business model you have in mind that does not seem to match the model that people I have talked to have in mind.

Cheers
James

> Sent: Tuesday, 11 December 2007 3:08 AM
> > > An authorized entity (i.e. one paying for it) will have credentials
> and
> > > will
> > > > > The only emergency service in the U.S. is urn:service:sos.  There
> is
> > > > only
> > > > > one boundary and if it changes (which LoST tells you via the TTL
> of
> > > the
> > > > > service boundary), you may have to find those locations affected
> by
> > > the
> > > > > In the countries where there are multiple services, there are only
> a
> > > few
> > > > > (sometimes one) ESRPs.
> > > > >
> > > > > > Since access providers can't control what client devices
> actually
> > > use
> > > > > > recognised emergency entity to retrieve the actual location
> value.
> > > > > They'll
> > > > > > amount of capital equipment is going to be invoked to provide
> this
> > > > quite
> > > > > > reference support to LoST are both superior engineering
> solutions.
> > > > They
> > > > > > just aren't driven by the punitive motivations of the "hide by
> not
> > > > > hiding"
> > > > > > It's very difficult not to lapse into sarcasm in this area (I
> feel
> > > > like
> > > > > > define protocol mechanisms that permit them to distinguish
> between
> > > the
> > > > > > want to be involved in emergency calls - and why would the
> caller
> > > want
> > > > > > them involved? It seems to be not in the interest of either
> party.
> > > > > There's
> > > > > > Translation: You have more lobbyists than I (or the IETF), so
> give
> > > me.
> > > > > > > someone wants it. It's also true that the IETF has no
> authority
> > or
> > > > > > > ability to force implementation of RFCs by companies who
> refuse
> > to
> > > > > > > Believe it or not, major telecom companies in the US and
> Europe
> > > put
> > > > > > > desirable outcomes. The IETF doesn't put in such effort. If
> you
> > > want
> > > > > > > available location directly to end user devices: They don't
> want
> > > to.
> > > > > > > I, for one, believe that not providing the "real" location
> value
> > > to
> > > > > > > end devices would not cause such benefit or harm. If users
> want
> > to
> > > > > > > provide location in a format that's usable by a human being,
> but
> > > not
> > > > > > >> I checked with my company and we need LH for both civic and
> geo
> > > for
> > > > > > >> can return a coarse location which is good enough to elicit
> the
> > > > same
> > > > > > >> course, the LIS would always return a location reference,
> which
> > > > > > >> would return
> > > > > > >> A LIS who wishes to hide location returns a location
> reference.
> > > > When
> > > > > > >> Note that the service boundaries returned from LoST have a
> TTL,
> > > the
> > > > > > >>>> I think it can be solved with a one paragraph description
> of
> > > the
> > > > > > >>>> problem
> > > > > > >>> in
> > > > > > >>> The solution is not one paragraph and the text in phone bcp
> is
> > > > > > >>> normative.
> > > > > > >>>
> > > > > > >>> Ciao
> > > > > > >>> Hannes
> > > > > > >>>
> > > > > > >>>> Brian
> > > > > > >>>>
> > > > > > >>>>
> > > > > > >>>>> default, but by most people voicing actively against
> having
> > > this
> > > > > > >>>>> (i.e., in its own doc) so everyone can focus on the
> singular
> > > > > > >>>>> topic,
> > > > > > >>>>>> need to be required to build the infrastructure to
> provide
> > > > > > >>>>>> location
> > > > > > >>>>>> want to place a requirement on access providers to
> provide
> > > > > > >>>>>> location,
> > > > > > ----------------------------------------------------------------
> --
> > --
> > > --
> > > > --
> > > > > --
> > > > > > ----------------------
> > > > > > ----------------------------------------------------------------
> --
> > --
> > > --
> > > > --
> > > > > --
> > > > > > ----------------------
> > > > > > [mf2]
> > > > > >
> > > > > >

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 10 Dec 2007 11:26:29 -0500

James, we're not communicating.

Coarse location is only given to entities who the LIS doesn't want to give
real location.  It's good enough to route and validate emergency calls, and
not good for anything else.  It's not supposed to be useful for anything
else.

The LIS can give high quality location to anyone it wishes to, which will
work for "real" location based services.  Specifically, if it wishes some
entity to be able to route other services, it can give it high quality
location.   That entity can control which services get routed under whatever
terms the LIS is willing to give it high quality location.

No one, so far, has created a requirement that some non-authorized entity
has to be able to provide some form of location based service (such as
routing based on location) without having some kind of authorization or
credentials from the LIS for such purposes.  The LIS is free to give
location to anyone it wants, for any purpose, subject to the privacy
limitations in the PIDF-LO.  The LIS MUST allow any entity to route an
emergency call.

Brian

> Sent: Monday, December 10, 2007 11:15 AM
> A location hiding mechanism that ONLY provides the boundary map of the
> ESRP is pretty much useless in that it won't enable them to support the
> value added case period. Since the only reason that anyone would pay for
> it is so that they can support value added services I don't see how you
> address the requirement.
> 
> Franchise boundaries are unlikely to match ESRP boundaries. Further more,
> not all value added service may be permitted, so the Target still needs to
> know what services for a given location provider will be permitted to
> obtain location information. I think the view of providing a coarse
> location is driven by a particular business model you have in mind that
> does not seem to match the model that people I have talked to have in
> mind.
> 
> Cheers
> James
> 
> 
> > > > > > > only going to be for the purpose of emergency services. I
> doubt
> > > that
> > > > > > > give everyone a free location service - so it won't happen
> until
> > > > > > operators
> > > > > > > particularly the case in the US (which is a difficult market
> to
> > > > > ignore).
> > > > > > > to just the country indicator. They'll do this in the US as
> well
> > > > > > (they'll
> > > > > > > jurisdictions that only have a single PSAP route will be able
> to
> > > > > support
> > > > > > > this. OTOH, it might force the US to provide a federal level
> URI
> > > > with
> > > > > > > proposal. Arguments that they are inferior because they
> require
> > > > > protocol
> > > > > > > finalized. It continues to be used as a prop for this
> particular
> > > > > hiding
> > > > > > > proposal. By this line of argument, we would never add or
> modify
> > > > > > protocols
> > > > > > > for anything.
> > > > > > >
> > > > > > > ubiquitous location service in all public access networks out
> of
> > > > pure
> > > > > > > This provides the opportunity for me to once more ask a
> question
> > > > that
> > > > > > > hasn't been responded to in the past. Why is ECRIT describing
> a
> > > > > solution
> > > > > > > > 1) create a solution that you like that major stakeholders
> are
> > > > > > > > unwilling to implement
> > > > > > > > (and not just say it without proof) massive benefit or
> massive
> > > > harm
> > > > > > > > test mechanism voice it back over the voice medium (this
> would
> > > > only
> > > > > > > >> location must be provided.  An access network can
> reasonably
> > be
> > > > > > > >> expected to
> > > > > > > >> for routing, and a proxy may need to verify that a
> purported
> > > > > > > >> emergency call
> > > > > > > >>   location. Return the resulting polygon, or any point in
> the
> > > > > > > >> polygon as
> > > > > > > >>   cases, this will be a country code, province/state or
> city.
> > > > > > > >> Return this
> > > > > > > >>>>> Location Hiding is something that needs to be addressed
> BY
> > > > > ITSELF
> > > > > > > >>>>> BTW - if someone thinks Location Hiding should be put
> back
> > > > into
> > > > > > > > contact the sender and delete the material from all
> computers.
> > > > GA622
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >

---

From: "Stark, Barbara" <[email-masked]>
Date: Mon, 10 Dec 2007 12:52:44 -0500

I think I understand what James is saying.

Let's say that a VSP has contracted with an access provider to be allowed to dereference location for its subscribers.

A device gets a location reference from the access provider, publishes it to the VSP's presence server; and the VSP dereferences the location. 

The VSP would like to contract with a pizza delivery business to allow its subscribers to easily order pizza, from anywhere, by telling the device the URL associated with a pizza service, based on the device location.

The VSP has all the info it needs to provide this service, since it was able to dereference the LbyR. But there's no standard way for the VSP to tell the device what that pizza service URL is, for the device's location. And the VSP isn't allowed to tell the device what the device's real location value is, because that's not allowed under the agreement with the access provider.

Or it could be that an access provider would like to contract with various companies to provide routing information for specific service URNs. The access provider wants to provide the routing info, but not the location to devices. Again, there's no protocol for this.

Admittedly, this is outside the scope of ecrit. But, since LoST was made into a generic service URN to URI translator, it would be nice if somehow the LoST protocol could be used to provide devices with URIs, even when the device doesn't have its precise location.

I think that getting this capability would be very useful and desirable, but don't think it's as high a priority as getting the emergency services architecture worked out.
Barbara

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Monday, December 10, 2007 11:26 AM
To: 'Winterbottom, James'; 'Dawson, Martin'; 'Henning Schulzrinne'; Stark, Barbara
Cc: [email-masked]; 'Liess, Laura'
Subject: RE: AW: [Ecrit] Location Hiding -- State of the Art

Brian

---

From: Ted Hardie <[email-masked]>
Date: Mon, 10 Dec 2007 10:11:39 -0800

>I think that getting this capability would be very useful and desirable, but don't think it's as high a priority as getting the emergency services architecture worked out.

Let me strongly support the notion that getting into this before finishing the
emergency services work is not desirable.  There are several potential issues
here (the most prominent being whether re-using the service urn namespace
for services will work for non-jurisdictionally derived catchement areas).
I think it is far enough outside the realm of ECRIT that boffing the work
as a Lost extensions wg would be desirable.

In the short term, doing location hiding sufficient for emergency services
is the item under discussion.  Does anyone believe Brian's text does not
work for this point?

			regards,
				Ted

---

From: "Winterbottom, James" <[email-masked]>
Date: Mon, 10 Dec 2007 12:12:15 -0600

You hit the nail on the head Barbara, and I believe that if we do this, then the emergency solution falls out in the wash.

Cheers
James

> From: Stark, Barbara [mailto:[email-masked]]
> Sent: Tuesday, 11 December 2007 4:53 AM
> To: Brian Rosen; Winterbottom, James; Dawson, Martin; Henning Schulzrinne
> Let's say that a VSP has contracted with an access provider to be allowed
> to dereference location for its subscribers.
> 
> A device gets a location reference from the access provider, publishes it
> to the VSP's presence server; and the VSP dereferences the location.
> 
> The VSP would like to contract with a pizza delivery business to allow its
> subscribers to easily order pizza, from anywhere, by telling the device
> the URL associated with a pizza service, based on the device location.
> 
> The VSP has all the info it needs to provide this service, since it was
> able to dereference the LbyR. But there's no standard way for the VSP to
> tell the device what that pizza service URL is, for the device's location.
> And the VSP isn't allowed to tell the device what the device's real
> location value is, because that's not allowed under the agreement with the
> access provider.
> 
> Or it could be that an access provider would like to contract with various
> companies to provide routing information for specific service URNs. The
> access provider wants to provide the routing info, but not the location to
> devices. Again, there's no protocol for this.
> 
> Admittedly, this is outside the scope of ecrit. But, since LoST was made
> into a generic service URN to URI translator, it would be nice if somehow
> the LoST protocol could be used to provide devices with URIs, even when
> the device doesn't have its precise location.
> 
> I think that getting this capability would be very useful and desirable,
> but don't think it's as high a priority as getting the emergency services
> architecture worked out.
> Barbara
> 
> > > > > An endpoint or VSP dereferencing this URI will get coarse
> location,
> > as
> > > > > described.
> > > > >
> > > > > > Can you please explain how this solution (other than through a
> one
> > > off
> > > > > > > which case there are more intersections, but the calculation
> is
> > > > > simple,
> > > > > > > > Everything is qualified on what ultimately gets regulated.
> But
> > > > it's
> > > > > > > > The intersection of every possible service area - also
> called
> > an
> > > > ESN
> > > > > > or
> > > > > > > > are just going to return the country code. That's as
> granular
> > as
> > > > you
> > > > > > > need
> > > > > > > > may get adopted but operators will limit the provided
> location
> > > > > > > information
> > > > > > > > consequent routing outcome). This means that VSPs dealing
> with
> > > > calls
> > > > > > > > originating in the US will need to use i2. This is because
> the
> > > V2
> > > > > > > > do this. The country information will certainly be useful
> for
> > > > > > > arbitrating
> > > > > > > > mechanism for LoST was "postponed" in the interest of
> getting
> > > LoST
> > > > > > > > scenarios would only result in there being no cellular
> service
> > -
> > > > or
> > > > > > just
> > > > > > > > > [The following statements are my opinion, and should not
> be
> > > > > > > > > attributed to the company I work for.]
> > > > > > > > >
> > > > > > > > > Henning,
> > > > > > > > > implement them. You cannot shove a solution down the
> throats
> > > of
> > > > > > > > > to make a go at pushing through a solution that
> stakeholders
> > > in
> > > > > > > > > before you can force companies to do what they don't want
> to
> > > do,
> > > > > > > > > through regulation. Again, if you think you can take on
> that
> > > > > battle
> > > > > > > > > and win, go for it.
> > > > > > > > >
> > > > > > > > > know what location PSAPs get on their behalf, and
> regulators
> > > > > believe
> > > > > > > > > work for civic), or return a JPEG map with a dot on it.
> This
> > > > would
> > > > > > > > > an application. Or maybe, in some countries, the
> regulators
> > do
> > > > > > > > > requirement. Please justify why mobile access cannot
> provide
> > > > > > locations
> > > > > > > > > to end users.
> > > > > > > > >
> > > > > > > > > Henning
> > > > > > > > >
> > > > > > > > >> a polygon calculated by intersecting the service
> boundaries
> > > of
> > > > > all
> > > > > > > > >> of the
> > > > > > > > >> boundaries of emergency services.  In a great many cases,
> a
> > > > > country
> > > > > > > > >> code is
> > > > > > > > >> high quality location for a PSAP and coarse location to
> the
> > > > > > endpoint
> > > > > > > > >> or any
> > > > > > > > >>>>> Framework.  This was a clear consensus call in Chicago
> -
> > > and
> > > > > not
> > > > > > > > >>>>> by
> > > > > > > > >>>>>> access providers), then location hiding would be
> dead.
> > If
> > > > > > people
> > > > > > > > >>>>>> still
> > > > > > > > >>>>>> for some time but the availability of GPS devices
> made
> > it
> > > > > > > > >>>>>> possible to
> > > > > > > > > The information transmitted is intended only for the
> person
> > or
> > > > > > > > > upon this information by persons or entities other than
> the
> > > > > intended
> > > > > > > > ------------------------------------------------------------
> --
> > --
> > > --
> > > > --
> > > > > --
> > > > > > --
> > > > > > > --
> > > > > > > > ----------------------
> > > > > > > > ------------------------------------------------------------
> --
> > --
> > > --
> > > > --
> > > > > --
> > > > > > --
> > > > > > > --
> > > > > > > > ----------------------
> > > > > > > > [mf2]
> > > > > > > >
> > > > > > > >

---

From: "Winterbottom, James" <[email-masked]>
Date: Mon, 10 Dec 2007 12:31:37 -0600

Ted,

My concern here is that we need one solution for location hiding. The
proposal that has been tabled in the current ECRIT document is a
solution that does not work for the main requirement of location hiding,
which is the enablement of value added services. The solution that I
have proposed works for both, the only issue that has been flagged with
it is a billing issue at the VSP concerning emergency calls, this I
believe can be worked out later.

So in short answer, I am very unhappy with any solution that requires
the LIS to do service boundary mappings on-platform.

Cheers
James

> From: Ted Hardie [mailto:[email-masked]]
> Sent: Tuesday, 11 December 2007 5:12 AM
> To: Stark, Barbara; Brian Rosen; Winterbottom, James; Dawson, Martin;
> Henning Schulzrinne
> Let me strongly support the notion that getting into this before
finishing

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 10 Dec 2007 13:38:06 -0500

You mean that the VSP wants to route a call to urn:service:pizza.pizza-hut?

He gives that urn to his customer.  His customer doesn't directly use LoST
(he can't use the emergency LoST server, and in any event, the LoST server
known to the access provider isn't going to necessarily get him to the VSP).

So the URN is sent in Request URI along with the location reference.  The
VSP fields it, dereferences it, routes it, and sends the call onward.
Pizza-Hut may have to be authorized separately to get a dispatch location.

Brian

> Sent: Monday, December 10, 2007 12:53 PM

---

From: Ted Hardie <[email-masked]>
Date: Mon, 10 Dec 2007 11:05:44 -0800

At 12:31 PM -0600 12/10/07, Winterbottom, James wrote:
>Ted,
>
>My concern here is that we need one solution for location hiding

I really don't think you do need that.  It may be handy, but the billing
problem is really quiet different.  In case one, you want something
that can be handed back to a phone with no per-dip charge.  I've
already mentioned some ways of dealing with that at a billing level,
and I'm trying to suggest that if those don't work going to Brian's
method does.  The location delivered will not be sufficient for
anything other than discovering the right PSAP.

For non-emergency cases, you are dealing instead with the
case where you have a concern that selling someone location
for purpose X gets them location for purpose Y.  That's both
a different problem and it falls into an area where there are
enough other problems that it is, honestly, probably the least
of your worries.  It's also way out of the charter of this group.

>the LIS to do service boundary mappings on-platform.

Some warm cocoa may help with your unhappiness.  But I'm not too
happy when people raise issues and then reject solutions which
require them to spend effort; especially when their proposals are
fundamentally more fragile for delivery of critical services.

			regards,
				Ted

---

From: "Winterbottom, James" <[email-masked]>
Date: Mon, 10 Dec 2007 13:25:52 -0600

Ted inline.

> anything other than discovering the right PSAP.

If the device is simply given a PSAP URI, a service URN, and a location
URI, what more does it need?

> of your worries.  It's also way out of the charter of this group.

I would argue that location hiding is not in the charter of this WG at
all. How to route to a PSAP is the current charter, so if the end-point
is given all it needs to route to the PSAP then we are done aren't we?

> fundamentally more fragile for delivery of critical services.
Umm, how is providing the end point with where it needs to go more
fragile than giving it a bodgey location?

Cheers
James

---

From: Ted Hardie <[email-masked]>
Date: Mon, 10 Dec 2007 13:37:53 -0800

>URI, what more does it need?

As several people have pointed out, it needs/could use the ability to sanity
check the location.  You've argued it doesn't need that as much as
the operators need to be paid for location infrastructure deployed,
which set up the whole apples to oranges discussion that has been
going so far.

Past that, you're introducing a mechanism that combines two services
(receiving a location and associating that location with a psap URI).  If you gave
that data to a device which has a different LoST server configured, what
do you expect to happen?  Is it going to pass that location URI to its
own LoST server to confirm it gets the same PSAP URI?  The current
system allows a user/device to request service boundaries and to
make reasonable choices about when to refresh URI mappings.  How
are you replicating that functionality?  The service boundaries are,
after all, pretty much at the level of Brian's proposal.  

>is given all it needs to route to the PSAP then we are done aren't we?

I agree that location hiding is not in the charter of this working group.
You've been among those saying it had to be considered.  What you're
proposing goes in a different design direction to the one the
working group has had so far and it goes against some base principles
of location in GeoPRIV contexts as well (see:  the user controls access to
his/her location)

If what you were providing were as robust as the other methods being
offered we might be done, despite the design difference.  But there is
no consensus that this is the case.  At least Henning and I feel it is more
fragile.  I believe there are others as well.

>fragile than giving it a bodgey location?

It can check the location it is provided.  You can be working off a bodgey
location, and it would never know.
	
Really, try the cocoa.  It's quite nice.
				Ted

---

From: "Dawson, Martin" <[email-masked]>
Date: Mon, 10 Dec 2007 17:01:29 -0600

Sorry to rewind the thread - somebody said something about "ordering drinks" at the beginning of the conversation (HG2G).

> The only emergency service in the U.S. is urn:service:sos.

Can you elaborate on this? Explicitly, then, what boundary would the LIS provide for a call originating in a typical US ESZ? It sounds like you're saying it just needs to provide "the US"? What do you mean by this boundary "changing" in this context? How does the boundary of the US change?

When was this decided - and which agency, ESP, or authority has taken responsibility for administering the single national URN and routing boundary? It's good news, but I hadn't heard it had occured.

Cheers,
Martin

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Tuesday, 11 December 2007 1:57 AM
To: Dawson, Martin; 'Henning Schulzrinne'; 'Stark, Barbara'
Cc: [email-masked]; 'Liess, Laura'
Subject: RE: AW: [Ecrit] Location Hiding -- State of the Art

Brian

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 11 Dec 2007 08:52:39 -0500

Speaking only about the U.S.:
There is one emergency service (urn:service:sos).  That’s the only URN, and
thus for any location, you only need one service boundary; the one that
urn:service:sos returns for a given location.

There will be on the order of 50 ESRPs, roughly state level.  There may be
some areas that are smaller than a state, there may be some areas covering
more than a state.  That means a LoST server covering the entire U.S. would
have roughly 50 service boundaries that don't overlap.  We see a local 9-1-1
authority (which is most often at roughly county level) will provide LoST
services in its service area.  All the locations in that service area would
point to the state level ESRP for an endpoint, access network or VSP query.

In those areas, it would be sufficient to return, for example, the state
name as the civic address.  Even where the actual service boundary doesn't
cover the state precisely, returning the state level will get the correct
route.

That won't work everywhere.  For example, it's pretty likely that New York
City would run its own ESRP.  In that case, returning the city name (and
state) would be needed.

There clearly WILL be exceptions to this; I'm just describing how NENA
believes the provisioning of ESRPs will be done.  It's likely, for example,
that as we start deploying, it's somewhat more complex.

Brian

> Sent: Monday, December 10, 2007 6:01 PM
> To: Brian Rosen; Henning Schulzrinne; Stark, Barbara
> Sorry to rewind the thread - somebody said something about "ordering
> drinks" at the beginning of the conversation (HG2G).
> 
> Can you elaborate on this? Explicitly, then, what boundary would the LIS
> provide for a call originating in a typical US ESZ? It sounds like you're
> saying it just needs to provide "the US"? What do you mean by this
> boundary "changing" in this context? How does the boundary of the US
> change?
> 
> When was this decided - and which agency, ESP, or authority has taken
> responsibility for administering the single national URN and routing
> boundary? It's good news, but I hadn't heard it had occured.
> 
> Cheers,
> Martin
>

---

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 11 Dec 2007 08:37:41 -0600

Hi Ted,

I think you mischaracterize my position, which is that I don't want to
do location hiding, but if some people, namely those that need to deploy
location in access network, say that we need it, then I want it done
properly and not with a half-baked solution that doesn't really serve
anyone.

To that end, if we insist upon completing the framework and phone BCP
documents quickly, the documents need to say that this issue, along with
unauthenticated access are work in progress and not propose ANY
solution.

Cheers
James

> Sent: Tuesday, 11 December 2007 8:38 AM
> To: Winterbottom, James; Stark, Barbara; Brian Rosen; Dawson, Martin;
> Henning Schulzrinne
> (receiving a location and associating that location with a psap URI).
If
> you gave
>-----------------------------------------------------------------------
--
> -----------------------
>-----------------------------------------------------------------------
--
> -----------------------

---

From: "Liess, Laura" <[email-masked]>
Date: Tue, 11 Dec 2007 21:58:01 +0100

I see two advantages with James URI proposal:

1) It's simple. People (also product managers) understand it within 2 minutes and like it exactly for this reason. The chance to get it implemented soon is probably quite high. 

2) The ISP provider is responsible for most EC functionality. The VSP is just "transport". (Marc pointed out this aspect to me last week.) Probably the regulators would like this because they can control the ISPs better than the VSPs.  
The chance for this solution to work, at lest at the beginning, is probably higher than if 3 different providers (the ISP, the VSP and the LOST provider), with eventually conflicting economical interests, have to cooperate to provide the EC functionality. 

What if we have both options, coarse location and ESRP/PSAP URI? Does this mean too high implementation effort for clients? 
 
Laura

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 11 Dec 2007 16:21:02 -0500

Yeah, my problem with this is that every client has to implement two
mechanisms.  They need to implement the LCP then dereference then LoST
lookup AND they have to implement the HELD+LoST mechanism. 

I think this mechanism requires the reverse LoST lookup for VSPs, so more
work for LoST servers.  I think James wants to ignore that problem
(something about letting VSPs charge for emergency calls and working it out
later).

BTW, the HELD return would have to supply ALL of the service URNs,
dialstrings, and boundaries that the LoST server knows about.  I'm not quite
sure how the HELD server figures that out.  If there are commercial services
using LoST, all of them would have to be returned.  I think the VSP wants to
get into the "Location Based Routing" act (they do route calls after all,
and ISPs don't).  I'm not sure how it would do so with this proposal.  

If the device is mobile, what happens?  The way we specified it so far, the
endpoint would subscribe to a location update service and get location
updates.  It would have the service boundary from LoST, and it would requery
if it moved beyond the service boundary.  That works, and makes sense to me.
I'm not sure what James proposes.

If we're going to go beyond the basic location hiding idea, using what I
proposed, which takes no standards changes and puts the burden on the LIS
who is hiding location, then I think Richard's idea of allowing LoST to
dereference is a better one.  I don't like that idea; we've talked about why
it's not a great idea in the past, but it's better than James'.

Brian 

> From: Liess, Laura [mailto:[email-masked]]
> Sent: Tuesday, December 11, 2007 3:58 PM
> To: [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: AW: AW: [Ecrit] Location Hiding -- State of the Art
> 
> 
> 1) It's simple. People (also product managers) understand it within 2
> minutes and like it exactly for this reason. The chance to get it
> implemented soon is probably quite high.
> 
> 2) The ISP provider is responsible for most EC functionality. The VSP is
> just "transport". (Marc pointed out this aspect to me last week.) Probably
> the regulators would like this because they can control the ISPs better
> than the VSPs.
> The chance for this solution to work, at lest at the beginning, is
> probably higher than if 3 different providers (the ISP, the VSP and the
> LOST provider), with eventually conflicting economical interests, have to
> cooperate to provide the EC functionality.
> 
> What if we have both options, coarse location and ESRP/PSAP URI? Does this
> mean too high implementation effort for clients?
> 
> Laura
>

---

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 11 Dec 2007 15:42:55 -0600

I will reply to this in more detail later Brian, when my brain is a little less fried.

The basis of my proposal is that the Location provider knows what services etc that it will grant access to. There is no way for the VSP to know this unless they are also the access provider. So while the VSPs may want to get into the location dependent routing game, I think that this is actually a very good value-add that access providers will have dominance over for some time.

Cheers
James

> Sent: Wednesday, 12 December 2007 8:21 AM
> To: 'Liess, Laura'; [email-masked]; Winterbottom, James;
> [email-masked]; Dawson, Martin
> Cc: [email-masked]

---

From: Ted Hardie <[email-masked]>
Date: Tue, 11 Dec 2007 13:55:16 -0800

At 3:42 PM -0600 12/11/07, Winterbottom, James wrote:
>The basis of my proposal is that the Location provider knows what services etc that it will grant access to.

Huh?  This sounds like you mean an access provider/doubling as a location provider,
might block access to specific emergency services.  That can't be what you mean,
so maybe you mean to specific non-emergency services.  Since these will
often be expressed in the form of fairly typical URIs (like SIP URIs, XMPP URIs,
etc.), you're either implying that blocking access to location blocks all access
to those services (it doesn't) or that they will otherwise block it unless they've
sold you your location (which they theoretically could do with deep packet
inspection, but seem likely to pull out of quickly if they tried).

>There is no way for the VSP to know this unless they are also the access provider. So while the VSPs may want to get into the location dependent routing game, I think that this is actually a very good value-add that access providers will have dominance over for some time.
>

As stated, this doesn't make sense, at least to me.  A VSP with access to location
can provide exactly the same location-based-routing as the originator of that location.
If it cannot, some other manipulation of the packet flow must be present to prevent
it.
					Ted

---

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 11 Dec 2007 16:16:47 -0600

Hi ted,

Comments inline.

Given some of your response I think we are talking past each other.

> >
> >The basis of my proposal is that the Location provider knows what
> services etc that it will grant access to.
> 
> Huh?  This sounds like you mean an access provider/doubling as a
location
> provider,
> might block access to specific emergency services.  That can't be what
you
> mean,
> often be expressed in the form of fairly typical URIs (like SIP URIs,
XMPP
> URIs,
> etc.), you're either implying that blocking access to location blocks
all
> access
> to those services (it doesn't) or that they will otherwise block it
unless
> they've

[AJW] Perhaps I should have been consistent in my terminology, I used
access and location provider inter-changeably. I see location always
being provided to emergency service providers.

On the other front, a location provider can form trust relationships
with service vendors, for example the local pizza parlor, or the AAA, or
whatever. This would require the recipient of a location URI to
authenticate with the LIS prior to location being handed out. This
allows the location provider to gain revenue, either per dip, or by a
monthly fee. I am not sure why you are talking about deep packet
inspection in this model. 

> 
> 
> >There is no way for the VSP to know this unless they are also the
access
> provider. So while the VSPs may want to get into the location
dependent
> routing game, I think that this is actually a very good value-add that
> access providers will have dominance over for some time.
> >
> 
> As stated, this doesn't make sense, at least to me.  A VSP with access
to
> location
> can provide exactly the same location-based-routing as the originator
of
> that location.
> If it cannot, some other manipulation of the packet flow must be
present
> to prevent

[AJW] If all you give the end point is the service URN (+ dial string),
a destination URI and a location URI, where the latter requires
authentication to dereference, how does the VSP get location?

---

From: Richard Barnes <[email-masked]>
Date: Tue, 11 Dec 2007 17:24:09 -0500

Maybe I can clarify...

>> The basis of my proposal is that the Location provider knows what services etc that it will grant access to.

I believe James is referring here to non-emergency location-based 
services.  If you try to invoke these location-based services using a 
location URI that the service can't dereference (because he hasn't 
paid), the request will fail.  James's point is that location provider 
is the only entity that knows which providers of location-based services 
it has agreements with.  The user can find out by trying and failing, 
but the provider giving him a "whitelist" is a short-cut.

As I said to James in Vancouver, though, this is just an optimization 
for the case when an access-controlled LbyR is used to obtain 
value-added services, namely ALL of the location hiding solutions.  It's 
not a differentiator for one solution over another.

--Richard

---

From: Ted Hardie <[email-masked]>
Date: Tue, 11 Dec 2007 14:33:47 -0800

>Given some of your response I think we are talking past each other.
<snip>

>being provided to emergency service providers.

Yes, this was a source of confusion.

>authenticate with the LIS prior to location being handed out.

In this model, the location provider chooses not to provide location
to the end users  at all, since they could then hand it out as they please,
but to sell it only to those with whom it has business relationships.  That's not really
a location hiding problem; it's entirely a business one.   It's difficult
to get the end user to support this with subscription revenue, so
the relationships have to be broad enough that selling them pays
for the infrastructure.  This really is well outside the problem space
of this working group, though, and I don't see much use in going down
into this rathole here.

The point I was making before is that eliminating access to the location
doesn't eliminate access to the service; I can still call Pizza Igloo even
if you will provide a location URI dereference only to Pizza Leanto.
You're not doing anything to stop access to Pizza Leanto's service,
which was what your initial formulation sounded like.

>authentication to dereference, how does the VSP get location?

The point I was making is that there is no necessary coupling here;
if the  VSP gets location (say, from a form entry by a customer with
a static line), they can do  the same location-based routing
that an access network can.   The access network's knowledge of
that location does not give it any advantages over *any other entity
which has the location*, unless it is willing to couple its knowledge
of location with deep-packet based inspection (think of the parental
controls done via proxy in some family-oriented networks).

I'm increasingly skeptical of the value of protocol changes here.
Going down this road now seems to involve requiring trust relationships
between every ESRP/PSAP and the location-providing access networks.
We've talked about this in the past, and that just doesn't scale to
the enterprise, so there is no way this mechanism can become truly
general.  The truly general mechanism is always going to be to pass
the location through the one common relationship (with the end user),
so we'd be stuck with two systems that everyone would have to
implement.  That's all kinds of bad.

My personal opinion, of course,
				Ted

---

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 11 Dec 2007 16:50:44 -0600

Hi Ted,

> Yes, this was a source of confusion.

[AJW] I am glad that this cleared up, I shall try to be more consistent
in my terminology from now on.

> of this working group, though, and I don't see much use in going down

[AJW] Actually I think that this is crux of the reason why location
hiding is important, ECRIT merely highlights that hiding location has
other implications.

> which was what your initial formulation sounded like.

[AJW] What you say is true, and where location dependent routing is not
required, either because you have the address of the local franchise, or
because you are only local anyway, then there isn't a problem. If Pizza
Leanto has a central office in San Francisco though, and you are calling
from Washington DC, then things may not go where you expect them to.

> that an access network can.

[AJW] This is true, but it requires the user to do something, where they
don't have to do anything if the location provider provides them with
everything they need. I would wager that for many people if Domino's is
in the preferred service list and Pizza hut isn't, then they will just
call Domino's rather than entering their location through a form so that
they can route to the local Pizza Hut.

   The access network's knowledge of
> controls done via proxy in some family-oriented networks).

[AJW] This is absolutely true. The difference that the location provider
has is that it is potentially easier for them to obtain and do things
with the location, and as I hinted before most users of these types of
services will go with the easiest option.
 
> My personal opinion, of course,

[AJW] I am not sure the problem is so large, or that the bad is so bad.
I do agree however that not trying to hide location at all would be the
best solution.

Cheers
James

---

From: "Dawson, Martin" <[email-masked]>
Date: Tue, 11 Dec 2007 17:37:43 -0600

Hi Ted,

> implement.  That's all kinds of bad.

They are two different models for location based service - there's also
a third type of location query based on user-identity and made to a
presence service. Location queries to a LIS are largely anonymous.

In keeping with the "nothing new under the sun" principle, these models
already have a precedent.

3GPP defines three categories of location request:

MO-LR - "mobile originated location request". The device requests
location from the access network and obtains it for its own purpose.

NI-LR - "network initiated location request". The network queries the
location server for some network based application (emergency calling be
the classic case).

MT-LR - "mobile terminated location request". Some application external
to the network request the location of the device based on the
subscriber identity (phone number).

A device-initiated LbyV request is really the MO-LR case. LbyR is
different primarily because of the more fundamental access-service split
that occurs in the Internet but, for the types of services being
discussed, it's very like the NI-LR in some cases and the MT-LR in
others. A query for location to a presence service is the MT-LR case.

As opposed to being "all kinds of bad", I'd posit that these models will
inevitably emerge and, in fact, they live together quite comfortably.
While ever we have protocol specifications that don't support all these
models there will be somebody who is experiencing frustration and
discontent with the specifications.

Cheers,
Martin

-----Original Message-----
From: Ted Hardie [mailto:[email-masked]] 
Sent: Wednesday, 12 December 2007 9:34 AM
To: Winterbottom, James; Brian Rosen; Liess, Laura; [email-masked];
Dawson, Martin
Cc: [email-masked]

<snip>

In this model, the location provider chooses not to provide location
to the end users  at all, since they could then hand it out as they
please,
but to sell it only to those with whom it has business relationships.
That's not really
a location hiding problem; it's entirely a business one.   It's
difficult
to get the end user to support this with subscription revenue, so
the relationships have to be broad enough that selling them pays
for the infrastructure.  This really is well outside the problem space
of this working group, though, and I don't see much use in going down
into this rathole here.

doesn't eliminate access to the service; I can still call Pizza Igloo
even

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 11 Dec 2007 18:57:52 -0500

Access providers don’t route calls, so it's impossible for them to provide a
call routing service (unless of course the VSP and the ASP are the same
entity).  The LIS controls access always.  It can authorize a VSP to get
location and provide location based routing, and it can do so for any set of
services it wishes to.  It could even provide the LoST server for such
services.  

Brian

> Sent: Tuesday, December 11, 2007 4:43 PM
> To: Brian Rosen; Liess, Laura; [email-masked]; [email-masked];
> Dawson, Martin
> Cc: [email-masked]
> The basis of my proposal is that the Location provider knows what services
> etc that it will grant access to. There is no way for the VSP to know this
> unless they are also the access provider. So while the VSPs may want to
> get into the location dependent routing game, I think that this is
> actually a very good value-add that access providers will have dominance
> over for some time.
> 
> Cheers
> James
> 
> > using LoST, all of them would have to be returned.  I think the VSP
> wants
> > to
> > > of location in GeoPRIV contexts as well (see:  the user controls
> access
> > to
> > > his/her location)
> > >

---

From: "Dawson, Martin" <[email-masked]>
Date: Tue, 11 Dec 2007 19:03:25 -0600

I like Leisa's suggestion and she just beat me to the proposal. My question as to why it's a good idea to involve VSPs at all still hasn't really been answered. My *opinion* is that the VSP should only be involved if the calling device can't call directly to the PSAP. This would lead to the following logic for a device (assuming the LIS response would contain any one or more of coarse location, location-URI, PSAP-URI):

1. Request location
2. PSAP URI provided with loc-URI and device is ECRIT-capable?
	2 a. Route call to PSAP with Loc-URI and preferred callback details
	2.b. End
3. PSAP URI not provided and device is ECRIT-capable?
	3.a. Do LoST procedure to obtain PSAP URI using coarse location
	3.b. Successful LoST lookup?
		3.b.i Route call to PSAP with preferred callback details
		3.b.ii End
4. Either device is not ECRIT-capable or the local jurisdiction or access network are not ECRIT-capable (e.g. No LoST service or no successful lookup)
5. Send coarse location and location reference to VSP
4. VSP invokes proxy emergency support using i2 or other solution
5. End

The definition of "ECRIT-capable" in the above is my own - and it means "permitting emergency services to be located and called with just an Internet connection". In other words, anything that happens once the call is sent to a VSP can be out of scope for ECRIT. I figure that's probably contentious but I think it's a more pure position - given there are already interim architectures that utilize VSPs.

This supports jurisdictions that aren't ECRIT-capable - i.e. the LIS won't provide a PSAP URI or there is no LoST service or mapping for that location.

It supports devices that aren't ECRIT-capable - i.e. they only know how to ask for location and initiate calls through the VSP.

In my *opinion* the VSP should not be involved unless there is a reason the call can't be made directly to the PSAP. I don't accept the "authenticated" argument (if that's what it's about). You can't guarantee somebody has a VSP or, indeed, that the VSP's authentication means anything to the PSAP. If authentication is important at all, it's only going to be the authentication that occurs at the access. Signed location, I believe, is actually more important than access authentication in any case. It would bring ECRIT up to par with emergency calls made from public pay phones.

My suggestion is that we pool resources to make an open-source reference implementation of an ECRIT emergency client that embodies the above procedure. Brian says below that he doesn't want devices to implement two mechanisms. I agree it's not ideal in the long term but it's impossible not to recognise this situation in the interim. A reference client implementation would mitigate this issue.

Bearing in mind that a given device may have no VSP client or multiple VSP clients, I believe it would be preferable to have a relatively independent and standard emergency client implementation that independent open-source and commercial VoIP client implementers could integrate.

Cheers,
Martin

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Wednesday, 12 December 2007 8:21 AM
To: 'Liess, Laura'; [email-masked]; Winterbottom, James; [email-masked]; Dawson, Martin
Cc: [email-masked]
Subject: RE: AW: [Ecrit] Location Hiding -- State of the Art

Brian

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 11 Dec 2007 20:35:40 -0500

Although we need to permit emergency calls that don't come from a carrier,
we really don't want to encourage them.  Carriers provide quite a few things
that PSAPs want, not the least of which is someone to call for help when
things go wrong.  Consider, for example, call-backs.  Given NATs, you can't
call a bare device back; you can't get a signaling message to it.  You need
an incoming proxy that is reachable.  Further, many devices won't accept
calls from arbitrary callers; calls come from their incoming proxy.
You also don't get P-A-I or Identity.  You don't get additional information
about the call (subscriber name and address for example).  You don't get
most forms of default routing.  So, please, let's not bypass carriers for
emergency calls.

We've been around the notion that access networks provide emergency proxies.
That doesn't work either.  Similar problems, plus the problem that while a
PSAP can restrict calls to be SIP based (and maybe one or two others), lots
of services actually use proprietary protocols, or extensions, between the
device and the service provider.  The access network can't deal with that.

I don't think it helps to try to redefine the basics here.

Brian

> Sent: Tuesday, December 11, 2007 8:03 PM
> To: Brian Rosen; Liess, Laura; [email-masked]; Winterbottom, James;
> [email-masked]
> Cc: [email-masked]
> I like Leisa's suggestion and she just beat me to the proposal. My
> question as to why it's a good idea to involve VSPs at all still hasn't
> really been answered. My *opinion* is that the VSP should only be involved
> if the calling device can't call directly to the PSAP. This would lead to
> the following logic for a device (assuming the LIS response would contain
> any one or more of coarse location, location-URI, PSAP-URI):
> 
> 1. Request location
> 4. Either device is not ECRIT-capable or the local jurisdiction or access
> network are not ECRIT-capable (e.g. No LoST service or no successful
> lookup)
> The definition of "ECRIT-capable" in the above is my own - and it means
> "permitting emergency services to be located and called with just an
> Internet connection". In other words, anything that happens once the call
> is sent to a VSP can be out of scope for ECRIT. I figure that's probably
> contentious but I think it's a more pure position - given there are
> already interim architectures that utilize VSPs.
> 
> This supports jurisdictions that aren't ECRIT-capable - i.e. the LIS won't
> provide a PSAP URI or there is no LoST service or mapping for that
> location.
> 
> It supports devices that aren't ECRIT-capable - i.e. they only know how to
> ask for location and initiate calls through the VSP.
> 
> In my *opinion* the VSP should not be involved unless there is a reason
> the call can't be made directly to the PSAP. I don't accept the
> "authenticated" argument (if that's what it's about). You can't guarantee
> somebody has a VSP or, indeed, that the VSP's authentication means
> anything to the PSAP. If authentication is important at all, it's only
> going to be the authentication that occurs at the access. Signed location,
> I believe, is actually more important than access authentication in any
> case. It would bring ECRIT up to par with emergency calls made from public
> pay phones.
> 
> My suggestion is that we pool resources to make an open-source reference
> implementation of an ECRIT emergency client that embodies the above
> procedure. Brian says below that he doesn't want devices to implement two
> mechanisms. I agree it's not ideal in the long term but it's impossible
> not to recognise this situation in the interim. A reference client
> implementation would mitigate this issue.
> 
> Bearing in mind that a given device may have no VSP client or multiple VSP
> clients, I believe it would be preferable to have a relatively independent
> and standard emergency client implementation that independent open-source
> and commercial VoIP client implementers could integrate.
> 
> Cheers,
> Martin
>

---

From: "Dawson, Martin" <[email-masked]>
Date: Tue, 11 Dec 2007 19:47:39 -0600

I'm going to assume you mean "VoIP provider" by carrier.

Yet we are defining a system that allows emergency calls to be made without them. We can't have our cake and eat it too. The guarantee of this sort of relationship with a "voice carrier" was thrown out the window at the outset.

It's not the same as the PSTN days. The voice service provider, by definition, was part of the local jurisdiction. It simply doesn't apply for VoIP. The value of this "carrier" proposition has been diluted out of existence.

In addition, there's a new "carrier" - the access provider. Unlike VSPs, this particular carrier does maintain the same characteristic of being part of the local jurisdiction by definition. It would be more fruitful to concentrate on getting "authentication" information from them. Similarly, I think the callback issue could be more robustly addressed by focussing on the transient device-PSAP relationship than the very brittle assumptions that are made about VSPs. Has any creativity been applied to this at all? I don't believe it does need a proxy in the access network.

I've asked about these basics a number of times and generally have not been answered.

The incredible number of complications that have arisen out of VSP use cases has certainly been enough for me to conclude that a serious rethink is required.

Cheers,
Martin

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Wednesday, 12 December 2007 12:36 PM
To: Dawson, Martin; 'Liess, Laura'; [email-masked]; Winterbottom, James; [email-masked]
Cc: [email-masked]
Subject: RE: AW: [Ecrit] Location Hiding -- State of the Art

Brian

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 11 Dec 2007 20:55:39 -0500

I don't agree.  Probably 99.999% of emergency calls will come through some
form of carrier, be they VoIP carrier, mobile carrier or legacy wireline
carrier, IM service provider, video service provider, ....
That's what the PSAPs want.  Generally, that's what the regulators want.
It has to be possible to place a call without a carrier.  That is the
reality of the Internet.  However, we can, and should let the major
responsibility for handling emergency calls rest with the service provider
who provides session establishment services for the user.  That's the
carrier, and not the access network, which generally is a bit pipe, and
which we have to deal with solely because they are in the best position to
supply location.  I have no desire to burden access networks with any more
responsibility.

Brian

> Sent: Tuesday, December 11, 2007 8:48 PM
> Yet we are defining a system that allows emergency calls to be made
> without them. We can't have our cake and eat it too. The guarantee of this
> sort of relationship with a "voice carrier" was thrown out the window at
> the outset.
> 
> It's not the same as the PSTN days. The voice service provider, by
> definition, was part of the local jurisdiction. It simply doesn't apply
> for VoIP. The value of this "carrier" proposition has been diluted out of
> existence.
> 
> In addition, there's a new "carrier" - the access provider. Unlike VSPs,
> this particular carrier does maintain the same characteristic of being
> part of the local jurisdiction by definition. It would be more fruitful to
> concentrate on getting "authentication" information from them. Similarly,
> I think the callback issue could be more robustly addressed by focussing
> on the transient device-PSAP relationship than the very brittle
> assumptions that are made about VSPs. Has any creativity been applied to
> this at all? I don't believe it does need a proxy in the access network.
> 
> The incredible number of complications that have arisen out of VSP use
> cases has certainly been enough for me to conclude that a serious rethink
> is required.
> 
> Cheers,
> Martin
> 
> 
>

---

From: "Dawson, Martin" <[email-masked]>
Date: Tue, 11 Dec 2007 20:23:38 -0600

That's tautological - that proportion of calls will only come through VSPs if that's they way you define the architecture. In the long term it could be possible that zero percent of calls come through VSPs.

All of those other systems already have infrastructure, architecture, and protocols for delivering emergency calls. Trying to reinvent it all in the IETF as opposed to just focussing on the long term goal of end-to-end Internet emergency telephony is only serving to confuse all parties - in my view. It feels like the concepts of having an IP-enabled call centre and Internet delivered emergency calls have been unnecessarily conflated.

I simply don't accept the statement "it's what PSAPs want" at face value. My VoIP provider is an Australian company called MyNetFone. How does it add any value for them, me, or the PSAP for them to be involved in an emergency call I initiate from a WiFi hotspot in Dallas? My cellular provider is an Australian operator called Optus. They certainly aren't involved if I make an emergency call from a cellular network in Dallas - all they see is the roaming partner who provides access in that area. It's easy to put words into the mouths of PSAPs; you know that perceptions are much more complicated than that.

As I say, I don't think there's any need to add additional burden to the access provider - none that hasn't already been mooted in any case.

Cheers,
Martin

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Wednesday, 12 December 2007 12:56 PM
To: Dawson, Martin; 'Liess, Laura'; [email-masked]; Winterbottom, James; [email-masked]
Cc: [email-masked]
Subject: RE: AW: [Ecrit] Location Hiding -- State of the Art

Brian