Subject: [Geopriv] Not-so-grand compromise on how to do endpoint centric LCP without giving away the store

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 13 Apr 2007 07:18:00 -0400

In the Emergency Services SDO Coordination workshop, a familiar
discussion took place: how does location get provided for emergency
calls?  The real issue is revenue.  Access networks have location.  They
may be willing to (or may be regulated to be required to) provide
location for emergency calls.  However, they are not willing to give it
away for free for other uses.  The issue with that is how we support
calling networks that don't have relationships with access networks,
i.e. the Skype situation.  How is location provided such that a Skype
emergency call can be placed, but the access network can restrict what
else may be done with the location it provides?

We have been wrapped around the axle on this for, dare I say, years.

So, I think Barbara Stark first described this, and it needs some work,
but suppose that, as an option, an access network could supply:

1. A reference to location

2. The results of a LoST query on the location value (viz, PSAP URI and
local dialstring)

With this, an endpoint could recognize an emergency call and start
routing it to the right PSAP.  The LIS would agree to dereference for
PSAPs, but could restrict other uses of location.

Hannes points out that we need one more thing: the calling network has
to be able to validate that the PSAP URI really is a PSAP URI so that
charging (emergency calls generally are free) is protected.  We need a
mechanism for them to do that.  

Perhaps we include in the LoST return a country code for a query with a
geo.  We add a new operation to LoST that takes a service, a country
code and a PSAP URI and returns yes/no validation ("Yes, that URI is a
valid URI for that service in that country").

What would we need to do to make this happen?

We need extensions to LCPs or some new protocol that returns an LbyR and
the LoST results.  I wonder if this is just more HELD work.

We need the PSAP URI validation.

Again, this is optional.  The access network may well give up an LbyV.
It may give up an LbyR that it will dereference for the endpoint.  The
access network may have a relationship with the calling network such
that the endpoint need not be involved.

The PSAP URI validation is actually useful without this idea, especially
when location is an LbyR.  Instead of having to have the calling network
dereference, and then do a LoST query to validate, it can just do this
PSAP URI validation.

Would this solve our problem?  Would access carriers concerned about
revenue issues with "giving away" location to it's subscribers be
willing to provide LbyR dereferenceable by PSAPs (again remembering that
the access network are local to the PSAPs) as well as LoST query
services to their endpoints?  Would this address the concerns raised by
Deutsche Telecom on this issue?

Let me be very clear that I think this is an ugly solution.  I think
that everyone will be much better off if endpoints knew where they were,
and apps could take advantage of that.  I think we'll get there.  I
think tying location configuration with the LoST query is a bad idea.  I
think using LbyR for emergency calls is a bad idea.

But I can live with it.

Brian

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

---

From: "Alexander Mayrhofer" <[email-masked]>
Date: Fri, 13 Apr 2007 13:33:44 +0200

> 2. The results of a LoST query on the location value (viz, 

Hi,

Without wanting to stir anything up (and, granted, without having
followed the discussion very closely), a third option comes to my mind:

Location-by-value, encrypted by the access network with a public key
corresponding to the desired application of the location data?

eg. for emergency services:

- PSAPs supply a public key for location encryption within their
coverage area (would need to be one key per area, though)
- Access providers serving a certain area would encrypt location
information with that key
- Location information could be decrypted only by the PSAPs which the
corresponding private key

(hence, would be useless for Joe's Pizza Delivery Services, or <insert
favourite name here>'s location advertisement service)

I would definitely like to avoid any overengineering here, though - that
is just a very rough idea i would like to share. Especially for
emergency services though, i am a little scared about information not
readable in case of catastrophic situations (imagining the frustration
of a PSAP agent looking at an encrypted location while handling the
call...)

any comments appreciated (including flames  :).

Alex

---

From: "Marc Berryman" <[email-masked]>
Date: Fri, 13 Apr 2007 06:41:48 -0500

Location-by-value with public encryption key
You would also have to consider when the calls are re-routed to a
different location and, oops, someone forgot to update or include the
key.

Marc B

Marc B

-----Original Message-----
From: Alexander Mayrhofer [mailto:[email-masked]] 
Sent: Friday, April 13, 2007 6:34 AM
To: Rosen, Brian; [email-masked]
Cc: [email-masked]
Subject: RE: [Geopriv] Not-so-grand compromise on how to do endpoint
centricLCPwithout giving away the store

Hi,

Alex

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 13 Apr 2007 16:43:15 +0200

Hi Brian,

thanks for posting this message.

When the end host is provided with LbyV and triggers the LoST lookup and 
routes the call via its VSP then the VSP (in some circumstances*) might 
want to verify that the PSAP URI in the message indeed corresponds to a 
PSAP. The idea that was mentioned a long time ago already was to let the 
VSP to use the location information for LoST and to compare the result 
with the content of the message.

The main goal here is that the VSP does not need to have a "business" 
contract to the ASP/ISP.

Since there is only a location reference that neither the end host nor 
the VSP can dereference it is necessary to enhance the existing 
procedures a bit (as Brian mentioned).

I see two ways todo so:

a) Enhance LoST
b) Enhance the dereferencing protocol

In both cases you want to have the LbyR as input and the PSAP URI (and 
potentially the service number) as output.

For (a) you would have to address the LoST query to the LoST server in 
the ASP/ISP network and the result would be a nomal LoST response.
For (b) you would have todo a dereferencing step with an additional 
parameter for "verify only". The response would be similar to the lookup 
by the end host -- just the identity that is being used for the lookup 
would be different.

Both approaches are possible and since the VSP has to support both 
protocols it does not make a big difference which one to use.

In both cases you would have to compare the result of the lookup with 
the content of the message.

Ciao
Hannes

*: It is only necessary when the VSP charges for individual calls or for 
specific calls (with the given call falling into this category).

Rosen, Brian wrote:
> Ecrit mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ecrit
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 13 Apr 2007 16:45:31 +0200

Hi Alex,

That's certainly an option. However, since many folks argued that they 
need location-by-reference anyway I wonder whether we can avoid signing 
& encrypting of location information. (You need signing as well to have 
the other security properties we are looking at.)

In some sense an encrypted message is very similar to a 
location-by-reference to the end host -- it is opaque. There is, 
however, the problem of provisioning the keys to the PSAPs. When we also 
consider the case of location based applications that are also in scope 
of GEOPRIV then this approach will obviously not work.

So, the main question therefore is: Do we see a problem with the 
dereferencing step to resolve the reference to location information?
So far, I haven't had the impression. This mechanism would only be 
justified in cases if there is a network connectivity problem between 
the Location Recipient and the LIS but not between the Target and the 
Location Recipient.

Ciao
Hannes

---

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 13 Apr 2007 10:51:56 -0400

Hannes

I am confused by your message.

The problem you describe, where a VSP is trying to validate that the
Request URI in what is claimed to be an emergency call is a bona fide
PSAP URI seems to be a valid concern.  My message described one way to
do this validation when what the VSP received (in a SIP Geolocation
header) is an LbyR.

Are you now wondering how you validate when you have an LbyV?  I would
think you do the same thing: send the country code (or the whole
location) and the PSAP URI to LoST and ask if the PSAP URI is valid.
This does not require any query by the VSP to the ASP/ISP.  The VSP
should be able to query its local LoST server and be referred to the
authoritative server for the location it proffers.

I'd rather not have to have the VSP try to dereference an LbyR, and if
you have an LbyV then you don't even know, necessarily, who the ASP/ISP
is.

Is there something else I'm missing here?

Brian
> From: Hannes Tschofenig [mailto:[email-masked]]
> Sent: Friday, April 13, 2007 10:43 AM
> To: Rosen, Brian
> Cc: [email-masked]; [email-masked]
> Subject: Re: [Ecrit] Not-so-grand compromise on how to do endpoint
centric
> LCP without giving away the store
> 
> Hi Brian,
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 13 Apr 2007 17:25:39 +0200

Hi Brian,

I only described a different way of doing the verification without 
returning a country code.
I also focus on LbyR only rather than LbyV.

Ciao
Hannes

Rosen, Brian wrote:
>> When the end host is provided with LbyV and triggers the LoST lookup
>>     
> and
>   
>> routes the call via its VSP then the VSP (in some circumstances*)
>>     
> might
>   
>> want to verify that the PSAP URI in the message indeed corresponds to
>>     
> a
>   
>> PSAP. The idea that was mentioned a long time ago already was to let
>>     
> the
>   
>> parameter for "verify only". The response would be similar to the
>>     
> lookup
>   
>> *: It is only necessary when the VSP charges for individual calls or
>>     
> for
>   
>>> calls?  The real issue is revenue.  Access networks have location.
>>>       
> They
>   
>>> location for emergency calls.  However, they are not willing to give
>>>       
> it
>   
>>> i.e. the Skype situation.  How is location provided such that a
>>>       
> Skype
>   
>>> emergency call can be placed, but the access network can restrict
>>>       
> what
>   
>>> So, I think Barbara Stark first described this, and it needs some
>>>       
> work,
>   
>>> 2. The results of a LoST query on the location value (viz, PSAP URI
>>>       
> and
>   
>>> local dialstring)
>>>
>>> routing it to the right PSAP.  The LIS would agree to dereference
>>>       
> for
>   
>>> Hannes points out that we need one more thing: the calling network
>>>       
> has
>   
>>> to be able to validate that the PSAP URI really is a PSAP URI so
>>>       
> that
>   
>>> charging (emergency calls generally are free) is protected.  We need
>>>       
> a
>   
>>> Perhaps we include in the LoST return a country code for a query
>>>       
> with a
>   
>>> code and a PSAP URI and returns yes/no validation ("Yes, that URI is
>>>       
> a
>   
>>> We need extensions to LCPs or some new protocol that returns an LbyR
>>>       
> and
>   
>>> Again, this is optional.  The access network may well give up an
>>>       
> LbyV.
>   
>>> It may give up an LbyR that it will dereference for the endpoint.
>>>       
> The
>   
>>> The PSAP URI validation is actually useful without this idea,
>>>       
> especially
>   
>>> when location is an LbyR.  Instead of having to have the calling
>>>       
> network
>   
>>> dereference, and then do a LoST query to validate, it can just do
>>>       
> this
>   
>>> PSAP URI validation.
>>>
>>> willing to provide LbyR dereferenceable by PSAPs (again remembering
>>>       
> that
>   
>>> services to their endpoints?  Would this address the concerns raised
>>>       
> by
>   
>>> that everyone will be much better off if endpoints knew where they
>>>       
> were,
>   
>>> think tying location configuration with the LoST query is a bad
>>>       
> idea.  I
>

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 13 Apr 2007 12:04:19 -0400

Huh, I didn't get that.

I'd like to eliminate the country code thing, because otherwise we need a
way to carry it in the SIP Geolocation.  However, I don't really want the
VSP having to ask the ASP/ISP for a dereference of any sort, and I'd like to
minimize the work of the ASP/ISP.  The notion that the ASP/ISP has to help
the VSP determine if what it has is a valid PSAP URI strikes me as a
problem.

Now, you may remember WAAAY WAAY back, I strongly suggested that the geo
form of location always include a country code.  I suggested this for
disputed areas.  The access network is in a very good position to tell you
how best to interpret which country actually is the on-the-ground
administrator of the location.  If you are connected to an Israeli access
network, and you ask LoST for a PSAP URI, you probably want an Israeli fire
brigade.  If you are on a Palestinian access network, then you probably want
a different answer.  So, having country code in a PIDF with an otherwise geo
location is actually helpful.

The current answer for this is some kind of manual configuration of the LoST
servers so you get the answer you want.  While that can work, I think
something more automatic might work better, and it fixes the problem.

Brian

> Sent: Friday, April 13, 2007 11:26 AM
> To: Rosen, Brian
> Subject: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to do
> endpoint centric LCP without giving away the store
> 
> Hi Brian,
>

---

From: Richard Barnes <[email-masked]>
Date: Fri, 13 Apr 2007 12:44:50 -0400

Brian,

I think that you're right that provision of location by reference is a 
use case we need to support.

URI validation will be useful in either case (LbyR or LbyV), and it 
seems like a natural extension to make to LoST:  Validating that a given 
URI is a PSAP URI is like a reverse DNS lookup. Normal DNS queries map 
names->addresses (A+ records); reverse DNS queries map addresses to 
names (*PTR records).  Likewise, LoST queries map locations (+service 
URNs) to URIs; a "reverse LoST" query could map a URI to a service area 
and a service URN.  There's probably even simpler approaches, maybe via 
some form of NAPTR or ENUM lookup.

As far as getting the endpoint the results of a LoST query based on an 
LbyR:  Your suggestion is good, but it has the problem that the access 
network doesn't really know what to fill in for the <service/> element 
of the LoST query.  It could request all of the services available, but 
that would require a second LoST request.

I would suggest that a more elegant solution (and one that deals better 
with the "unknown <service/>" problem) would be to extend LoST to handle 
location by reference.  It wouldn't be a complicated  change to LoST, 
just another location profile.  Realizing that this has been discussed 
in the past, I scanned through the archive and found two main arguments 
against LoST doing LbyR:

1. Dereference access control
In order to do the LoST lookup, a LoST server would have to be allowed 
to dereference the location reference.  Given that most of the LoST 
infrastructure (e.g. the trees) is pretty static, it doesn't seem 
difficult to provide authentication credentials for LoST servers and 
require that they be able to dereference (just like PSAPs).

2. Extra time/complication
It's correct that it would not be feasible for every LoST server 
involved in an LbyR-based query to dereference the location reference. 
However, this can be avoided if the resolver doing the recursive queries 
is allowed to do a dereference, since it can then just include the 
location by value in subsequent queries.  This may cover most cases, 
e.g., if a local LoST resolver is provided by the access network (as is 
often the case with DNS).

There's a lot of overlap between LoST/LbyR and what you propose.  If the 
access network provides a resolver, then the two are essentially the 
same, except that if LoST/LbyR is used, then the client sends an extra 
query.  However, extending LoST seems to maintain a better separation of 
the location configuration and mapping functions.

Humbly submitted,
--Richard

---

From: "Marc Linsner" <[email-masked]>
Date: Fri, 13 Apr 2007 13:22:52 -0400

Who is responsible for PSAP mis-routes?  I would think this transfers
liability for routing to the access-provider, are they willing to step up to
that?

-Marc-

> From: Rosen, Brian [mailto:[email-masked]] 
> Sent: Friday, April 13, 2007 7:18 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [Ecrit] Not-so-grand compromise on how to do 
> endpoint centric LCPwithout giving away the store
> 
> In the Emergency Services SDO Coordination workshop, a 
> familiar discussion took place: how does location get 
> provided for emergency calls?  The real issue is revenue.  
> Access networks have location.  They may be willing to (or 
> may be regulated to be required to) provide location for 
> emergency calls.  However, they are not willing to give it 
> away for free for other uses.  The issue with that is how we 
> support calling networks that don't have relationships with 
> access networks, i.e. the Skype situation.  How is location 
> provided such that a Skype emergency call can be placed, but 
> the access network can restrict what else may be done with 
> the location it provides?
> 
> So, I think Barbara Stark first described this, and it needs 
> some work, but suppose that, as an option, an access network 
> could supply:
> 
> 2. The results of a LoST query on the location value (viz, 
> PSAP URI and local dialstring)
> 
> With this, an endpoint could recognize an emergency call and 
> start routing it to the right PSAP.  The LIS would agree to 
> dereference for PSAPs, but could restrict other uses of location.
> 
> Hannes points out that we need one more thing: the calling 
> network has to be able to validate that the PSAP URI really 
> is a PSAP URI so that charging (emergency calls generally are 
> free) is protected.  We need a mechanism for them to do that.  
> 
> Perhaps we include in the LoST return a country code for a 
> query with a geo.  We add a new operation to LoST that takes 
> a service, a country code and a PSAP URI and returns yes/no 
> validation ("Yes, that URI is a valid URI for that service in 
> that country").
> 
> We need extensions to LCPs or some new protocol that returns 
> an LbyR and the LoST results.  I wonder if this is just more 
> HELD work.
> 
> It may give up an LbyR that it will dereference for the 
> endpoint.  The access network may have a relationship with 
> the calling network such that the endpoint need not be involved.
> 
> especially when location is an LbyR.  Instead of having to 
> have the calling network dereference, and then do a LoST 
> query to validate, it can just do this PSAP URI validation.
> 
> Would this solve our problem?  Would access carriers 
> concerned about revenue issues with "giving away" location to 
> it's subscribers be willing to provide LbyR dereferenceable 
> by PSAPs (again remembering that the access network are local 
> to the PSAPs) as well as LoST query services to their 
> endpoints?  Would this address the concerns raised by 
> Let me be very clear that I think this is an ugly solution.  
> I think that everyone will be much better off if endpoints 
> knew where they were, and apps could take advantage of that.  
> I think we'll get there.  I think tying location 
> configuration with the LoST query is a bad idea.  I think 
> using LbyR for emergency calls is a bad idea.
> 
> But I can live with it.
> 
> Brian
>

---

From: "Roger Marshall" <[email-masked]>
Date: Fri, 13 Apr 2007 10:58:17 -0700

3GPP approaches this in a different way - one which (I think) we could
parallel, as shown in the following diagrams:

Proposal: 

- Define a new function which handles location dereferencing and
supports lost queries (this seems to me to be somewhat similar to an LRF
in 3GPP, since an LRF goes and gets loc + routing).
- LoST doesn't need to change, (except maybe in the validation bits -
which I still don't understand).
- run by the Access Network (therefore Access Network has controls)

     +------+           +------+
     |  LS  |           | LoST |
     |      |           |      |
     |      |           |      |
     +------+           +------+
          \              /
           \ LCP (n/c)  / LoST Protocol (n/c)
            \          /
              +------+ 
              | ULS  |    New, URI-Loc-Server - logically in Access
Network
              |      |
              |      |
              +------+
             /        
            /          
           /            
     +------+           +------+
     |  UA  |           |  P1  |
     |      |-----------|      |
     |      |           |      |
     +------+           +------+

1. Endpoint accessed model

     +------+           +------+
     |  LS  |           | LoST |
     |      |           |      |
     |      |           |      |
     +------+           +------+
          \              /
           \ LCP (n/c)  / LoST Protocol (n/c)
            \          /
              +------+ 
              | ULS  |    New, URI-Loc-Server - logically in Access
Network
              |      |
              |      |
              +------+
                      \
                       \
                        \
     +------+           +------+
     |  UA  |           |  P1  |
     |      |-----------|      |
     |      |           |      |
     +------+           +------+

2. Proxy accessed model

Summary:
Neither of these scenarios preclude LbyV direct UA or Proxy interaction,
if desirable, and (in my mind) don't impact (much) existing protocols.

-roger marshall.

>From: Richard Barnes [mailto:[email-masked]] 
>Sent: Friday, April 13, 2007 9:45 AM
>To: Rosen, Brian
>Subject: Re: [Ecrit] Not-so-grand compromise on how to do 
>endpoint centricLCP without giving away the store
>
>Brian,
>
>I think that you're right that provision of location by 
>reference is a use case we need to support.
>
>URI validation will be useful in either case (LbyR or LbyV), 
>and it seems like a natural extension to make to LoST:  
>Validating that a given URI is a PSAP URI is like a reverse 
>DNS lookup. Normal DNS queries map 
>URNs) to URIs; a "reverse LoST" query could map a URI to a 
>service area and a service URN.  There's probably even simpler 
>approaches, maybe via some form of NAPTR or ENUM lookup.
>
>LbyR:  Your suggestion is good, but it has the problem that 
>the access network doesn't really know what to fill in for the 
><service/> element of the LoST query.  It could request all of 
>the services available, but that would require a second LoST request.
>
>I would suggest that a more elegant solution (and one that 
>deals better with the "unknown <service/>" problem) would be 
>to extend LoST to handle location by reference.  It wouldn't 
>be a complicated  change to LoST, just another location 
>profile.  Realizing that this has been discussed in the past, 
>I scanned through the archive and found two main arguments 
>against LoST doing LbyR:
>
>In order to do the LoST lookup, a LoST server would have to be 
>allowed to dereference the location reference.  Given that 
>most of the LoST infrastructure (e.g. the trees) is pretty 
>static, it doesn't seem difficult to provide authentication 
>credentials for LoST servers and require that they be able to 
>dereference (just like PSAPs).
>
>It's correct that it would not be feasible for every LoST 
>server involved in an LbyR-based query to dereference the 
>location reference. 
>However, this can be avoided if the resolver doing the 
>recursive queries is allowed to do a dereference, since it can 
>then just include the location by value in subsequent queries. 
> This may cover most cases, e.g., if a local LoST resolver is 
>provided by the access network (as is often the case with DNS).
>
>There's a lot of overlap between LoST/LbyR and what you 
>propose.  If the access network provides a resolver, then the 
>two are essentially the same, except that if LoST/LbyR is 
>used, then the client sends an extra query.  However, 
>extending LoST seems to maintain a better separation of the 
>location configuration and mapping functions.
>
>Humbly submitted,
>--Richard
>
>
>
>Rosen, Brian wrote:
>> They may be willing to (or may be regulated to be required 
>to) provide 
>> it away for free for other uses.  The issue with that is how we 
>> support calling networks that don't have relationships with access 
>> networks, i.e. the Skype situation.  How is location provided such 
>> that a Skype emergency call can be placed, but the access 
>network can 
>> restrict what else may be done with the location it provides?
>> 
>> work, but suppose that, as an option, an access network could supply:
>> 
>> and local dialstring)
>network has 
>query with 
>> a geo.  We add a new operation to LoST that takes a service, 
>a country 
>> and the LoST results.  I wonder if this is just more HELD work.
>> 
>endpoint.  The 
>> especially when location is an LbyR.  Instead of having to have the 
>> calling network dereference, and then do a LoST query to 
>validate, it 
>> can just do this PSAP URI validation.
>> 
>> that the access network are local to the PSAPs) as well as 
>LoST query 
>> by Deutsche Telecom on this issue?
>> 
>> were, and apps could take advantage of that.  I think we'll 
>get there.  
>> I think tying location configuration with the LoST query is a bad 
>> idea.  I think using LbyR for emergency calls is a bad idea.
>> 
>> But I can live with it.
>> 
>> Brian
>> 

The information contained in this message may be privileged and/or confidential. If you are not the intended recipient, or responsible for delivering this message to the intended recipient, any review, forwarding, dissemination, distribution or copying of this communication or any attachment(s) is strictly prohibited. If you have received this message in error, please so notify the sender immediately, and delete it and all attachments from your computer and network.

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 13 Apr 2007 20:33:12 +0200

How would the message exchange look like?

Roger Marshall wrote:
>>> routing it to the right PSAP.  The LIS would agree to 
>>>       
>> dereference for 
>>     
>>> to be able to validate that the PSAP URI really is a PSAP 
>>>       
>> URI so that 
>>     
>>> charging (emergency calls generally are free) is protected.  
>>>       
>> We need a 
>>     
>>> code and a PSAP URI and returns yes/no validation ("Yes, 
>>>       
>> that URI is a 
>>     
>>> Again, this is optional.  The access network may well give 
>>>       
>> up an LbyV.
>>

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 13 Apr 2007 20:34:29 +0200

Hi Laura,

in some sense your proposal is similar to use a SIP proxy in the access 
network (or someone that is closely related to it). Couldn't we just use 
the DHCP discovery technique for SIP proxies for that purpose?

Ciao
Hannes

Liess, Laura wrote:
> Brian, Hannes,
> thank you for bringing up this issue. 
> In principle, I like the option for the access network to supply the PSAP URI. A similar option could be for the AN to provide an ESRP URI.  The ESRP URI is for the AN a trusted party, so it has the necessary credentials to fetch the Location Info from the LIS. 
>
> I figured out how such a scenario could work
>
>
>
>                Configuration           VSP's         	            LoST
>        Alice      Servers      	  SIP proxy	    ESRP          Servers          PSAP
>
>      ***Alice gets IP-connectivity****        
>       [M1]   DHCP (with LbyR, country code and ESRP URI)
>          <---------
>
>      ***Some time later, Alice dials/initiates emergency call***
>       [M2] INVITE (sos URN or 911/112, contains LbyR, country code and ESRP URI)
>          ------------------------------->
>                                [M3] LoST Query (contains country code and ESRP URI)
>                                          --------------------------->
>                                [M4] LoST Response (contains a mark if ESRP URI is valid)
>                                         <----------------------------
>                                         [M5] INVITE (sos URN or 911/112, contains LbyR)
>                                          ------------->
>                          [M6] HTTPS(contains LbyR)
>                     <----------------------------------
>                           [M7] HTTPS(contains Location)
>                      --------------------------------->
>                                                   [M8] LoST Query (contains Location)
>                                                    --------------------->
>                       		            [M9] LoST Response (contains PSAP URI) 
>                                                   <----------------------
>                                                   [M10] INVITE (contains Location)
>                                                    ----------------------------------->
>                                                           200 OK
>          <-------------------------------------------------------------------------------
>                                     ACK
>          ------------------------------------------------------------------------------->
>
>
> I think if there is a local ESRP between the VSP's SIP Proxy and the PSAP we are more flexible to comply to country-specific regulations. 
> The ESRP could choose the PSAP based on a local LoST server which knows the capabilities of the local PSAPs. E.g. during a transition period we may have the old PSTN PSAPs and very few IP PSAPs with additional capabilities, e. g. emergency call takers speaking foreign languages or  emergency call takers for deaf people. The local LoST server would be able to choose the right PSAP (this is just an idea, I don't know whether or not it's realistic). 
>
>
> Thanks
> Laura
>
>          
>     
>
>    
>
>
>   
>> -----Ursprüngliche Nachricht-----
>> Von: Rosen, Brian [mailto:[email-masked]] 
>> Gesendet: Freitag, 13. April 2007 13:18
>> An: [email-masked]
>> Cc: [email-masked]
>> Betreff: [Ecrit] Not-so-grand compromise on how to do 
>> Again, this is optional.  The access network may well give up 
>> an LbyV. It may give up an LbyR that it will dereference for 
>> the endpoint.  The access network may have a relationship 
>> with the calling network such that the endpoint need not be involved.
>>

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 13 Apr 2007 20:45:52 +0200

Hi Brian,

sorry that I confused everything. Maybe I am still suffering from a 
post-SDO Emergency Service Workshop syndrome:

Let me describe the procedure in a message sequence:

Target => LIS: Request  LbyR

Target<= LIS: LbyR, PSAP URI, Service Number

Target=> VSP-Proxy: SIP message including LbyR, PSAP URI

VSP-Proxy=> LIS: Check PSAP URI at LbyR

VSP-Proxy<= LIS: OK or NOT OK (LIS checks whether the location 
information behind the LbyR translates to the PSAP URI presented by the 
VSP-Proxy)

DONE

Note that yo can replace LIS with LoST server in this example.

Does this make sense to you?

Ciao
Hannes

---

From: Richard Barnes <[email-masked]>
Date: Fri, 13 Apr 2007 14:55:03 -0400

What's the protocol between the UA/P1 and the ULS?  It needs to (1) 
carry LbyR to the ULS and a service URN to the ULS, and (2) return a 
LoST response to the UA/P1.  LoST would be the natural candidate for 
this, if it could carry LbyR.

That said, I don't think that this model has any different requirements 
in terms of protocols, it just shifts the whole show off the endpoint 
into the ULS.  And I thought the whole point of Brian/Barbara's 
suggestion was to allow for access-controlled location while keeping 
positioning local to the endpoint.

--Richard

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 13 Apr 2007 15:11:09 -0400

I think that is part of the tradeoff an access network makes.  If its
restricting access to location, and location is needed to route, then it has
to assume the liability for misroute, since it's providing the route in lieu
of providing location for the VSP to route.

If it doesn't want to assume that liability, then it has to give location to
someone who does the route, and we're back around that axle again.

So, I think it's reasonable that the access network deal with misroutes in
this case.

Brian

> From: Marc Linsner [mailto:[email-masked]]
> Sent: Friday, April 13, 2007 1:23 PM
> To: 'Rosen, Brian'; [email-masked]
> Cc: [email-masked]
> Subject: [Geopriv] RE: [Ecrit] Not-so-grand compromise on how to do
> endpointcentric LCPwithout giving away the store
>

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 13 Apr 2007 15:15:06 -0400

I'm not sure there is a whole lot of difference to extending the LCP to
supply the route data (or, if you like Richard's proposal, to allow the
route protocol to do the dereference) and inventing a new protocol to do
both.  I don't really care all that much, since the message sequences would
look the same (you send your identifiers in, like you would with an LCP, and
you get back the LbyR and the LoST result).

If you don't understand the validation bits (which allow a VSP, who cannot
dereference) to make sure that the PSAP URI which the endpoint is routing
towards, really is a PSAP URI, ask a question :)

Brian

> From: Roger Marshall [mailto:[email-masked]]
> Sent: Friday, April 13, 2007 1:58 PM
> To: Richard Barnes; Rosen, Brian
> The information contained in this message may be privileged and/or
> confidential. If you are not the intended recipient, or responsible for
> delivering this message to the intended recipient, any review, forwarding,
> dissemination, distribution or copying of this communication or any
> attachment(s) is strictly prohibited. If you have received this message in
> error, please so notify the sender immediately, and delete it and all
> attachments from your computer and network.
> 
>

---

From: Richard Barnes <[email-masked]>
Date: Fri, 13 Apr 2007 15:15:08 -0400

Hannes,

I think you're trying to enable the PSAP to answer the wrong question. 
There are two questions that one can ask about a call:
(1) Is this a valid PSAP URI for this Location (byR)?
(2) If this URI a valid PSAP URI?

It seems like answering question (2) provides enough information to make 
charging decisions, and it doesn't require dereferencing a location. 
Which is nice for several reasons, including that there's no interaction 
needed between the VSP and the ASP/ISP.

Also, note that for mobile targets, question (1) can become false while 
the call is being routed if the target crosses a PSAP boundary.

--Richard

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 13 Apr 2007 21:15:13 +0200

I also believe that this is reasonable assumption with regard to the 
split of responsibilities in this particular case.

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 13 Apr 2007 15:21:36 -0400

ESRPs URIs are just PSAP URIs as far as anyone outside the Emergency
Services IP Network is concerned.  What you get out of LoST is an ESRP URI
or a PSAP URI, and which you get depends on the local emergency authority's
wishes.   We don't need to know, and we don't do anything different.

Within the ESInet, the ESRP may well use LoST to do further routing.  In
North America, we imagine a common arrangement would be that a regular user
query to LoST would yield an ESRP URI that was roughly operated at the state
level -- all calls from Virginia go to a (replicated, load balanced) ESRP.
The ESRP may do a further LoST dip, and take into account local conditions,
like congestion and PSAP state, and time of day, and decide which PSAP will
actually get the call.

This is invisible to the endpoint, the access network and the VSP.  It's all
in what LoST returns.

So I don't think we need to specify how ESRPs work.  I think the important
part for you is that the access network would trust the ESRP for a
dereference the same as it would trust a PSAP.  In North America, they would
probably have similar credentials.

Brian

> From: Liess, Laura [mailto:[email-masked]]
> Sent: Friday, April 13, 2007 12:49 PM
> To: [email-masked]; [email-masked]
> Subject: AW: [Ecrit] Not-so-grand compromise on how to do endpoint
> In principle, I like the option for the access network to supply the PSAP
> URI. A similar option could be for the AN to provide an ESRP URI.  The
> ESRP URI is for the AN a trusted party, so it has the necessary
> credentials to fetch the Location Info from the LIS.
> 
>        Alice      Servers      	  SIP proxy	    ESRP
Servers
> PSAP
>                       		            [M9] LoST Response
(contains
> PSAP URI)
> I think if there is a local ESRP between the VSP's SIP Proxy and the PSAP
> we are more flexible to comply to country-specific regulations.
> The ESRP could choose the PSAP based on a local LoST server which knows
> the capabilities of the local PSAPs. E.g. during a transition period we
> may have the old PSTN PSAPs and very few IP PSAPs with additional
> capabilities, e. g. emergency call takers speaking foreign languages or
> emergency call takers for deaf people. The local LoST server would be able
> to choose the right PSAP (this is just an idea, I don't know whether or
> not it's realistic).
> 
> 
> Thanks
> Laura
> 
> 
> 
> 
> 
> 
>

---

From: Richard Barnes <[email-masked]>
Date: Fri, 13 Apr 2007 15:24:54 -0400

I would state things more generally: If you're going to restrict access 
to location information, then you bear liability for failures resulting 
from that restriction.

That way, if the AN provides routing, then it's responsible for routing 
working correctly.  If the AN wants to out-source mapping , then it's 
responsible for mapping failures caused by the mapping function not 
having access to location -- but NOT other mapping failures, like a bad 
cached mapping.

--Richard

---

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 13 Apr 2007 15:35:42 -0400

Deb

There is a tradeoff here between providing some kind of location when,
for whatever reason, you can't get current location at the time of the
call, and the cost of engaging the location determination mechanism.
Once at boot and periodically thereafter is not going to be a problem
for measurement systems that provide constant high quality measurements.
It's much more of a problem for the current crop of mobile networks that
can only provide a coarse location quick, and take much more time (and
expend more resources) to get an accurate location.

In such networks, what you get from the boot and periodically thereafter
queerly is the coarse location, which is by definition fast, and usually
low resource consumption.  Of course, it also could be a location
reference, which doesn't typically change, but even if it did (as it
might when changing visited networks), and it would be available
instantly, with no resource expenditure.  The visited network could
quite easily cache the LoST route for the coarse location, so that
wouldn't be much work either.

Brian

> From: Barclay, Deborah L (Deb) [mailto:[email-masked]]
> Sent: Friday, April 13, 2007 12:08 PM
> Subject: RE: [Ecrit] Not-so-grand compromise on how to do endpoint
centric
> LCPwithout giving away the store
> 
> Hi Brian,
> 
> The ecrit bcp recommends obtaining location on power-up/registration
and
> then refresh often/occasionally.
> 
> That means endpoints may obtain location frequently but never use it
for
> an emergency call.
> 
> I thought business models often worked on a pay per dip basis.
> 
> For cellular endpoints, network based and network assisted position
> determination are very complex and resource intensive - requiring
> auxiliary equipment for position determination.
> 
> Due to the impact on network resources, I'm not sure obtaining
position
> whenever requested and never being charged will be a viable model for
> some technologies.
> 
> Deb
> 
> Sent: Friday, April 13, 2007 6:18 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [Ecrit] Not-so-grand compromise on how to do endpoint centric
> LCPwithout giving away the store
> 
They
it
work,
and
and
especially
network
that
by
were,

---

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 14 Apr 2007 18:02:00 +0200

Hi Brian,

~snip~
> valid URI for that service in that country").

Please describe when the country code is returned and to whom.
Who triggers the validation step?

Ciao
Hannes

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 14 Apr 2007 12:18:35 -0400

I'll try to summarize some solutions and pick apart the problem.

There seem to be two basic approaches:

(1) Provide only location information that is sufficient for call  
routing or possibly for obtaining the service number, but not for  
dispatch. The latter is included by a PSAP-only LbyR. This would  
remove a large part of the value of the address to pizza parlors, but  
would not interfere with our standard architecture. It would provide  
the user with some ability to verify his own address, albeit only  
partially. (This is one of the reliability drawbacks of the withhold- 
location-information approaches, which is going to be a major cause  
of dispatch problems, I suspect.)

The biggest problem is determining this minimal address information,  
but this isn't too hard, given the availability of LoST service  
region information.

(2) Provide only the PSAP URL and LbyR resolvable by the PSAP.

Only (2) requires additional work. From what I can tell, the  
following solutions have been proposed:

(a) Include in configuration protocols, such as DHCP.

(b) Include in location configuration protocols, such as L7 LCP.

(c) Include in a special LoST response, e.g., if the client provides  
no location information.

All of these have problems:

- DHCP: Since this is configuration information, adding a lot of  
extra material to DHCP seems ill-advised, particularly since the  
likelihood that this information actually reaches residential users  
is slim. After all, this motivated the whole L7-LCP discussion. This  
also has problems if the URL needs to be changed since the INFORM  
request expiration doesn't seem to be tied to the IP address  
expiration. The number of URLs could be substantial, given that we  
need more than one emergency service URL and that we may need service  
testing URLs.

- L7 LCP: This subverts a location determination protocol into a  
general configuration protocol.

- LoST: This seems closest to our existing notion of returning a  
'default' PSAP if no other resolution is possible. Nothing prevents  
an ISP-provided LoST client from using whatever information it has  
available, such as client IP addresses, to make this information  
better than a national call center.

If we go down this route, I think a better solution is to use the on- 
going work for SIP configuration mechanisms. One of the sources of  
configuration information is the local access network, so it has all  
the right properties. After all, emergency calling URLs are not  
fundamentally different from other configuration information for  
special servers. Plus, the configuration protocol will likely have  
mechanism of dealing with conflicting information. The more protocols  
you add, the higher the likelihood that a device will get conflicting  
information, with no deterministic way to resolve it.

Henning

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 14 Apr 2007 10:58:25 -0400

The editorial out the way, I'll start by listing some requirements,  
some of which have been mentioned already:

- Hiding location should not make the PSAP behavior more costly and  
complicated or less reliable; in other words, just because an access  
provider choses, for business reasons, to withhold location  
information from customers should not impose a burden on tax payers.

- Hiding location information by one provider should not impose a  
burden on those access providers that offer location information to  
their customers.

I think the framework document needs to clearly spell out the  
reliability and security considerations of such a choice. If nothing  
else, this will prove valuable to the trial lawyer that gets called  
when the first person gets hurt when location information is  
erroneously withheld from a PSAP.

Henning

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 14 Apr 2007 13:55:37 -0400

Given that location information will have to be handed around to back- 
up PSAPs and first responders, I don't think a public key mechanism  
works well. After all, with a public key, all possible legitimate  
recipients would have to share a single private key. This goes  
against all standard recommendations for designing secure systems.  
(Since location information may need to reach federal authorities,  
for example, you may end up with essentially one nationwide private  
key. Not good.)

I suspect that the desire to hide location information will primarily  
afflict a few very large incumbent service providers. I don't see why  
a hotel or enterprise would want to hide the location from their  
visitors or employees, say, as the likelihood of monetizing this  
information is zero.

Thus, a simple shared secret between PSAP and the restrictive access  
provider will probably be sufficient. This still has all kinds of  
failure possibilities, e.g., if there are backup PSAPs somewhere  
across the country during a major disaster, but maybe these carriers  
can check their money making desires during KatrinaBis and turn off  
the access controls, as there likely won't be too many pizza parlors  
willing to pay for location information during such times any way.

Henning

On Apr 13, 2007, at 10:45 AM, Hannes Tschofenig wrote:

> Hi Alex,
>
> In some sense an encrypted message is very similar to a location-by- 
> reference to the end host -- it is opaque. There is, however, the  
> problem of provisioning the keys to the PSAPs. When we also  
> consider the case of location based applications that are also in  
> scope of GEOPRIV then this approach will obviously not work.
>
> justified in cases if there is a network connectivity problem  
> between the Location Recipient and the LIS but not between the  
> Target and the Location Recipient.
>
> Ciao
> Hannes
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 14 Apr 2007 16:55:57 -0400

> allowed to dereference the location reference.  Given that most of  
> the LoST infrastructure (e.g. the trees) is pretty static, it  
> doesn't seem difficult to provide authentication credentials for  
> LoST servers and require that they be able to dereference (just  
> like PSAPs).
>

Unfortunately, every resolver and forest guide would have to  
dereference. Resolvers and forest guides will be operated by numerous  
entities, including companies. There is no trust relationship between  
the Columbia LoST resolver (VSP, in my case) and the access provider.  
If any resolver can get the location information, you might as well  
hand it out to the client to begin with. Saves you the extra effort.

Thus, this is a non-starter.

> involved in an LbyR-based query to dereference the location  
> reference. However, this can be avoided if the resolver doing the  
> recursive queries is allowed to do a dereference, since it can then  
> just include the location by value in subsequent queries.  This may  
> cover most cases, e.g., if a local LoST resolver is provided by the  
> access network (as is often the case with DNS).

In many cases, the LoST resolver will be provided by the VSP,  
including non-traditional VSPs. Are you suggesting we restrict the  
LoST architecture to cater to this particular need?

I thought we agreed that the business practices of some ISPs should  
not burden the rest of the infrastructure?

>
> There's a lot of overlap between LoST/LbyR and what you propose.   
> If the access network provides a resolver, then the two are  
> essentially the same, except that if LoST/LbyR is used, then the  
> client sends an extra query.  However, extending LoST seems to  
> maintain a better separation of the location configuration and  
> mapping functions.
>
> Humbly submitted,
> --Richard

---

From: "Winterbottom, James" <[email-masked]>
Date: Sat, 14 Apr 2007 19:00:37 -0500

It is also not clear to me exactly who would do the encryption in this
case?
Would it be the ISP?
Would it be the ASP?

If it is the ISP, who is potentially national, that would be about 6000
keys just for the USA.

I like this solution less than Brian/Barbara's and I think it is
probably more problematic.

Cheers
James

> From: Marc Berryman [mailto:[email-masked]]
> Sent: Friday, 13 April 2007 9:42 PM
> To: Alexander Mayrhofer; Rosen, Brian; [email-masked]
> Cc: [email-masked]
> Subject: RE: [Geopriv] Not-so-grand compromise on how to do
> endpointcentricLCPwithout giving away the store
> 
> > some work,

------------------------------------------------------------------------------------------------
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: "Winterbottom, James" <[email-masked]>
Date: Sat, 14 Apr 2007 19:03:47 -0500

There is potentially one other thing that springs to mind, and that is a
specific sos domain. If that were done, then the resulting URI itself
would be explicit that it was for emergency services.

Just a thought.

Cheers
James

> Sent: Saturday, 14 April 2007 12:43 AM
> To: Rosen, Brian
> centricLCP without giving away the store
> 
> Hi Brian,
> 
and
might
a
the
lookup
for
They
it
Skype
what
work,
and
for
has
that
a
with a
a
and
LbyV.
The
especially
network
this
that
by
were,
idea.  I

---

From: "Winterbottom, James" <[email-masked]>
Date: Sat, 14 Apr 2007 19:14:14 -0500

I agree.

Indirectly the access network is already assuming this responsibility
since it is providing location to the end-point in any case, either
directly or indirectly.

> From: Brian Rosen [mailto:[email-masked]]
> Sent: Saturday, 14 April 2007 5:11 AM
> To: 'Marc Linsner'; Rosen, Brian; [email-masked]
> Cc: [email-masked]
> Subject: RE: [Geopriv] RE: [Ecrit] Not-so-grand compromise on how to
> doendpointcentric LCPwithout giving away the store
> 
> restricting access to location, and location is needed to route, then
it
> has
> to assume the liability for misroute, since it's providing the route
in
> lieu
> If it doesn't want to assume that liability, then it has to give
location
> to
> > liability for routing to the access-provider, are they willing to
step
> up
> > to
LbyV.

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 14 Apr 2007 20:21:26 -0400

Who would administer such a domain? At least in the US, there is no  
national authority for PSAPs. Given the PSAP-like semi-private  
emergency call centers on many corporate and university campuses,  
there is unlikely to be one.

(Yes, this particular solution was discussed, and dismissed, a few  
years ago. It might even have appeared in one of the early emergency  
I-Ds.)

Henning

---

From: "Winterbottom, James" <[email-masked]>
Date: Sat, 14 Apr 2007 19:23:21 -0500

I am fine with that, it was just a pie-in-the-sky.. ;)

> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Sunday, 15 April 2007 10:21 AM
> To: Winterbottom, James
> Cc: GEOPRIV; ECRIT

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 16 Apr 2007 09:41:46 -0400

Back from a weekend of no Internet access and lots of email to process:

The country code is returned from the L7 LCP query when an LbyR is returned.

The validation is done by the VSP when an emergency call is placed.

Brian

> Sent: Saturday, April 14, 2007 12:02 PM
> To: Rosen, Brian

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 16 Apr 2007 09:54:28 -0400

I will make sure that we have a discussion of this in -framework.  I do
intend to note that LbyR is more fragile for emergency calls because the
dereference may not work in a disaster.  

The VSP who wishes to validate takes on responsibility for failure to
progress a valid call that fails validation for whatever reason.  

Brian

> Sent: Saturday, April 14, 2007 10:58 AM
> To: Rosen, Brian
> endpointcentric LCP without giving away the store
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 16 Apr 2007 10:09:40 -0400

> progress a valid call that fails validation for whatever reason.

Wouldn't that typically be the ISP doing the authorization? (I don't  
want to use the term validation, since we seem to use that for a  
different operation.)

Henning

---

From: "Liess, Laura" <[email-masked]>
Date: Fri, 13 Apr 2007 18:48:48 +0200

Brian, Hannes,

               Configuration           VSP's         	            LoST

Thanks
Laura

---

From: "Barclay, Deborah L \(Deb\)" <[email-masked]>
Date: Fri, 13 Apr 2007 11:07:43 -0500

Hi Brian,

The ecrit bcp recommends obtaining location on power-up/registration and
then refresh often/occasionally.

That means endpoints may obtain location frequently but never use it for
an emergency call.

Due to the impact on network resources, I'm not sure obtaining position
whenever requested and never being charged will be a viable model for
some technologies.

Deb

-----Original Message-----
From: Rosen, Brian [mailto:[email-masked]] 
Sent: Friday, April 13, 2007 6:18 AM
To: [email-masked]
Cc: [email-masked]
Subject: [Ecrit] Not-so-grand compromise on how to do endpoint centric

But I can live with it.

Brian

---

From: "Liess, Laura" <[email-masked]>
Date: Fri, 13 Apr 2007 18:48:48 +0200

Brian, Hannes,

               Configuration           VSP's         	            LoST

Thanks
Laura

---

From: "Liess, Laura" <[email-masked]>
Date: Fri, 13 Apr 2007 23:17:03 +0200

Hannes,

I didn't mean the ERSP being in the access network, but rather what Brian describes in his answer, ESRPs operated at country or state level. Depending on the granularity of ESRPs, they could be configured into the access network data (e.g. if they are operated at country level)or the access network can do LoST queries. 

("Local ESRP" was probably quite misleading.) 

Laura

 -----Ursprüngliche Nachricht-----
> Von: Hannes Tschofenig [mailto:[email-masked]] 
> Gesendet: Freitag, 13. April 2007 20:34
> An: Liess, Laura
> Cc: [email-masked]; [email-masked]; [email-masked]
> Betreff: Re: AW: [Ecrit] Not-so-grand compromise on how to do 
> endpoint centricLCPwithout giving away the store
> 
> 
> Hi Laura,
> 
> > In principle, I like the option for the access network to 
> supply the PSAP URI. A similar option could be for the AN to 
> provide an ESRP URI.  The ESRP URI is for the AN a trusted 
> party, so it has the necessary credentials to fetch the 
> Location Info from the LIS. 
> >
> >                Configuration           VSP's         	
>             LoST
> > I think if there is a local ESRP between the VSP's SIP 
> Proxy and the 
> > PSAP we are more flexible to comply to country-specific regulations.
> > The ESRP could choose the PSAP based on a local LoST server 
> which knows the capabilities of the local PSAPs. E.g. during 
> a transition period we may have the old PSTN PSAPs and very 
> few IP PSAPs with additional capabilities, e. g. emergency 
> call takers speaking foreign languages or  emergency call 
> takers for deaf people. The local LoST server would be able 
> to choose the right PSAP (this is just an idea, I don't know 
> whether or not it's realistic). 
> >
> >
> > Thanks
> > Laura
> >
> >          
> >     
> >
> >    
> >
> >
> >

---

From: "Liess, Laura" <[email-masked]>
Date: Sat, 14 Apr 2007 00:04:08 +0200

Brian,

I agreee with you.  And I think this is a model that almost everyone can live with. We just need a way to convey the PSAP/ESRP URI from the access network to the client. 
Something like draft-polk-dhc-uri-03.txt? But the document is currently expired.  

Laura

> Von: Brian Rosen [mailto:[email-masked]] 
> Gesendet: Freitag, 13. April 2007 21:22
> An: Liess, Laura; Rosen, Brian; [email-masked]
> Betreff: RE: [Ecrit] Not-so-grand compromise on how to do 
> ESRPs URIs are just PSAP URIs as far as anyone outside the 
> Emergency Services IP Network is concerned.  What you get out 
> of LoST is an ESRP URI or a PSAP URI, and which you get 
> depends on the local emergency authority's
> Within the ESInet, the ESRP may well use LoST to do further 
> routing.  In North America, we imagine a common arrangement 
> would be that a regular user query to LoST would yield an 
> ESRP URI that was roughly operated at the state level -- all 
> calls from Virginia go to a (replicated, load balanced) ESRP. 
> The ESRP may do a further LoST dip, and take into account 
> local conditions, like congestion and PSAP state, and time of 
> day, and decide which PSAP will actually get the call.
> 
> This is invisible to the endpoint, the access network and the 
> VSP.  It's all in what LoST returns.
> 
> So I don't think we need to specify how ESRPs work.  I think 
> the important part for you is that the access network would 
> trust the ESRP for a dereference the same as it would trust a 
> PSAP.  In North America, they would probably have similar credentials.
> 
> Brian
> 
> supply the 
> > PSAP URI. A similar option could be for the AN to provide 
> an ESRP URI.  
> > The ESRP URI is for the AN a trusted party, so it has the necessary 
> >       [M2] INVITE (sos URN or 911/112, contains LbyR, 
> country code and 
> > ESRP URI)
> >                                [M3] LoST Query (contains 
> country code 
> > and ESRP URI)
> >                                          
> >                                [M4] LoST Response (contains 
> a mark if 
> > ESRP URI is valid)
> >                                         
> >                                                   [M10] INVITE 
> > Location)
> > The ESRP could choose the PSAP based on a local LoST server which 
> > knows the capabilities of the local PSAPs. E.g. during a transition 
> > period we may have the old PSTN PSAPs and very few IP PSAPs with 
> > additional capabilities, e. g. emergency call takers 
> speaking foreign 
> > languages or emergency call takers for deaf people. The local LoST 
> > server would be able to choose the right PSAP (this is just 
> an idea, I 
> > don't know whether or not it's realistic).
> > 
> > 
> > Thanks
> > Laura
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > > Betreff: [Ecrit] Not-so-grand compromise on how to do endpoint 
> > > centric LCPwithout giving away the store
> > >
> > >
> > > They may be willing to (or may be regulated to be required to) 
> > > provide location for emergency calls.  However, they are 
> not willing 
> > > to give it away for free for other uses.  The issue with 
> that is how 
> > > we support calling networks that don't have relationships with
> > > for PSAPs, but could restrict other uses of location.
> > >
> > > has to be able to validate that the PSAP URI really is a 
> PSAP URI so 
> > > that charging (emergency calls generally are
> > > with a geo.  We add a new operation to LoST that takes a 
> service, a 
> > > country code and a PSAP URI and returns yes/no validation ("Yes, 
> > > that URI is a valid URI for that service in that country").
> > >
> > > LbyV. It may give up an LbyR that it will dereference for the 
> > > endpoint.  The access network may have a relationship with the 
> > > calling network such that the endpoint need not be involved.
> > >
> validate, 
> > > it can just do this PSAP URI validation.
> > >
> concerned about 
> > > that the access network are local to the PSAPs) as well as LoST 
> > > query services to their endpoints?  Would this address 
> the concerns 
> > > raised by Deutsche Telecom on this issue?
> > >
> > > were, and apps could take advantage of that. I think we'll get 
> > > there.  I think tying location configuration with the 
> LoST query is 
> > > a bad idea.  I think using LbyR for emergency calls is a bad idea.
> > >
> > > But I can live with it.
> > >
> > > Brian
> > >

---

From: Andrew Newton <[email-masked]>
Date: Mon, 16 Apr 2007 10:27:04 -0400

On Apr 14, 2007, at 1:55 PM, Henning Schulzrinne wrote:

> I suspect that the desire to hide location information will  
> primarily afflict a few very large incumbent service providers. I  
> don't see why a hotel or enterprise would want to hide the location  
> from their visitors or employees, say, as the likelihood of  
> monetizing this information is zero.

There is a non-technical solution to this problem.  The access  
network could easily populate the note well section of the PIDF-LO  
with a copyright notice granting free use only for emergency call  
routing and dispatch purposes and requiring permission for all other  
uses.

-andy

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 16 Apr 2007 10:32:12 -0400

> Sent: Saturday, April 14, 2007 12:19 PM
> To: Rosen, Brian
> Subject: [Geopriv] Re: [Ecrit] Not-so-grand compromise [solutions]
> 
I think this is impossible for the U.S., where PSAP boundaries can be one
side of the street or another.

It works in many countries that don't have many PSAPs.

> need more than one emergency service URL and that we may need service
I think we all believe DHCP is only viable in fixed environments, but I use
the extreme example of a wired phone connected to a router with a wireless
access installed in an RV traveling down the highway as a counterexample.
Such situations exist, therefore it has to work, but they are unusual, so it
can be less than optimal.

In this case, we need DHCP responses that return LbyV and country code and
probably another that returns the LoST data.  I fail to see that as a major
deviation from what DHCP does.  The expiration is a red herring.  It won't
change much, and you do get it again at call time.

The number of URIs is an issue, and we may need to do something clever about
that.

However, I do suspect that the access network that does this will use the L7
LCP, and I don't think leaving DHCP out of this is a problem.

> general configuration protocol.
No it gives you information related to location (the PSAP URI associated
with this location.

> better than a national call center.
I think this is a poor choice because it has too many restrictions on who
operates the LoST server.  You would either require that the LoST server
operator be permitted to dereference, or the access network itself operates
the LoST server.  While that may be the case, it may not be and I don't see
why we should tie these together.

> information, with no deterministic way to resolve it.
Where did you make the leap that the Vonage configuration server knows
anything about the Comcast access network?

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 16 Apr 2007 10:54:23 -0400

No, this was Hannes' problem.

The VSP wants to make sure that the PSAP URI is valid.

Brian

> Sent: Monday, April 16, 2007 10:10 AM
> To: Brian Rosen
> Cc: Rosen, Brian; [email-masked]; [email-masked]
> Subject: Re: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to do

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 16 Apr 2007 11:01:20 -0400

I thought we were talking primarily about residential wireline?

I don't think anybody is proposing that a wireless device  
continuously query for its own location. In many cases of interest,  
this is unnecessary since handsets have GPS built in. (As a side  
note, since navigation will become standard functionality on  
handsets, I have a hard time imagining how per-dip systems are going  
to compete.)

A much better solution for systems where location needs to be  
conveyed to the end system is to have location triggers, namely the  
ability of the handset to tell the network "notify me if I'm leaving  
this polygon". We have the necessary tools to do this, via SIP presence.

Henning

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 16 Apr 2007 11:01:10 -0400

Okay, this is a "have your cake and eat it too" situation.

If you want to restrict location, you have to take on the burden of
providing the PSAP URI (the route) for an emergency call.  This would change
only when the user changed something like cell site.  You need to make sure
the endpoint has this when it changes.  You can either keep the update
frequency high, or force it when cell site changes (the endpoints know
this).

The IMS solution, because it couples the access network with the calling
network can avoid this because it uses proxy adding of location.  However,
the general packet interfaces have to support emergency calling too, and
here the L7 LCP would have to support the PSAP URI.

Brian

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 16 Apr 2007 11:03:03 -0400

Agree.  Barbara Stark and I discussed this a while ago.  Limiting use by
contract is quite useful.

Brian

> From: Andrew Newton [mailto:[email-masked]]
> Sent: Monday, April 16, 2007 10:27 AM
> To: Henning Schulzrinne
> Cc: [email-masked]; Rosen, Brian; [email-masked]
> Subject: Re: [Geopriv] Not-so-grand compromise on how to do endpoint

---

From: "Dawson, Martin" <[email-masked]>
Date: Mon, 16 Apr 2007 11:14:29 -0500

Correct - and, indeed, it's what happens for POTS and cellular
already...

Cheers,
Martin

-----Original Message-----
From: Winterbottom, James [mailto:[email-masked]] 
Sent: Sunday, 15 April 2007 10:14 AM
To: Brian Rosen; Marc Linsner; Rosen, Brian; [email-masked]
Cc: [email-masked]
Subject: RE: [Geopriv] RE: [Ecrit] Not-so-grand compromise on how
todoendpointcentric LCPwithout giving away the store

I agree.

it
in
location
step
LbyV.
> > > using LbyR for emergency calls is a bad idea.

------------------------------------------------------------------------
------------------------
------------------------------------------------------------------------
------------------------
[mf2]

---

From: "Dawson, Martin" <[email-masked]>
Date: Mon, 16 Apr 2007 11:27:12 -0500

And IMS (and preceding cellular networks) actually calculate location at
the time of call initiation. Quality of Service indicators are used to
indicate that a low-delay response is required. This does not introduce
a significant delay to call setup - and it won't to VoIP calls either
(which, in my experience already typically have a longer setup time than
even cellular). 

Location updates are used for more accurate location fixes - using a
delay-tolerant quality of service indicator. LbyR will be very useful
for this - particularly during the long interim period where the final
mile to the PSAPs will still be over conventional switched circuit
trunks (i.e. i2 architecture).

Working a BCP that initiates the location request at the time of
emergency call initiation would be a very good idea in my mind. Of
course, it requires the VoIP client to actually know it's doing an
emergency call - but I think that would be appropriate BCP as well.

Cheers,
Martin

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Tuesday, 17 April 2007 1:01 AM
To: 'Barclay, Deborah L (Deb)'; Rosen, Brian; [email-masked]
Cc: [email-masked]
Subject: RE: [Geopriv] RE: [Ecrit] Not-so-grand compromise on how to

If you want to restrict location, you have to take on the burden of
providing the PSAP URI (the route) for an emergency call.  This would
change
only when the user changed something like cell site.  You need to make
sure
the endpoint has this when it changes.  You can either keep the update
frequency high, or force it when cell site changes (the endpoints know
this).

The IMS solution, because it couples the access network with the calling
network can avoid this because it uses proxy adding of location.
However,
the general packet interfaces have to support emergency calling too, and
here the L7 LCP would have to support the PSAP URI.

Brian

and
for
position
They
it
work,
and
and
especially
network
that
by
were,

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 16 Apr 2007 21:52:40 -0400

[Removing items that we've beaten to death already.]

> change much, and you do get it again at call time.

I suspect you'll run into major objections, correctly, from the SIP  
community for replicating SIP configuration via DHCP. There are  
possible length issues, as one minor item, as you include a whole  
list of services. After all, this has to work for emergency and non- 
emergency LoST services. A bigger architectural issue is that if we  
do include PSAP URIs in the SIP configuration framework, we now have  
a fourth source of SIP-related configuration, which needs to be  
synchronized and conflict-tested.

> No it gives you information related to location (the PSAP URI  

By that token, *every* SIP configuration option is related to LCP and  
we might as well suggest that we replace the SIP configuration  
framework with LCP.

> why we should tie these together.

I'm not particularly fond of this choice, but others have proposed  
making the access provider LoST server "special" in that it can  
resolve LbyR location.

> anything about the Comcast access network?

I suspect you haven't been following this all that closely (which I  
sympathize with...), but consider taking a look at the configuration  
framework draft or review the recent SIPPING discussion on this  
topic. One of the sources of (SIP) configuration information is the  
access network.

Henning

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 17 Apr 2007 08:10:12 +0200

-- changed subject header

Hi Brian,

I just wanted to state that my proposal does not work (for deployment 
reasons) since the VSP would have a hard time figuring out whether the 
LIS is indeed at an access network. Demanding some relationship between 
the ASP/ISP and the VSP for authorization would make this solution to 
work but it would not be deployable anymore and that's what we do not want.

Ciao
Hannes

Hannes Tschofenig wrote:
> information behind the LbyR translates to the PSAP URI presented by 
> the VSP-Proxy)
>
> DONE
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 17 Apr 2007 08:20:05 +0200

Hence, it suffers from the same problems as the solution I proposed 
unless you assume a relationship between the VSP and the ISP/ASP.
Do you?

Ciao
Hannes

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 17 Apr 2007 16:03:07 -0400

No, I don't.

I assume that the LoST server the VSP consults to validate contains the same
URIs that the LoST server used by the access network LIS to determine the
URI.  The endpoint passes a URI to its VSP and claims it's a bona fide PSAP
URI from LoST.  As long as that URI is in the LoST server (directly or via a
referral) that the VSP uses, validation is possible.

If the attacker can insert bogus data into the global LoST database, then we
couldn't detect it, but that is not threat here.

The access network and the endpoint can collude all they want, but unless
the LoST server the VSP uses has bad data, it can determine if the PSAP URI
is a genuine PSAP URI.  

No relationship between the VSP and the access network is needed.

Brian

> Sent: Tuesday, April 17, 2007 2:20 AM
> To: Brian Rosen

---

From: "Dawson, Martin" <[email-masked]>
Date: Wed, 18 Apr 2007 03:09:14 -0500

No - I don't see a need for a relationship. As long as the information
is provided with the call.

In i2 it is the responsibility of the VSP to have access to the
necessary VPC and ESGW resources required to process the emergency call.
It has nothing to do with the ISP how they do this. It's quite likely
that many VSPs will just outsource this requirement to a service bureau
(like Intrado or TCS) - but that is just passing the responsibility on.

The VPC has two responsibilities in i2 - it has the equivalent routing
function as provided by LoST, and it also has the responsibility for
caching the location for retrieval by the local emergency authority (you
can't squeeze location information down switched circuit and, worse,
CAMA trunks). Similarly, in those jurisdictions that require some form
of authorization to dereference location, the request cannot come from
any arbitrary VPC anywhere in the world - it has to come from one
recognized by that jurisdiction.

Consequently, there is a good deal of local (national,
jurisdictional,...) knowledge and infrastructure at the VPC. They really
need to be co-located, in a jurisdictional sense, with the emergency
operator.

What I'm saying is that there needs to be some coarse routing
information available to select the correct VPC to be used - even if
only a location reference is provided. It doesn't mean there is only one
VPC - the VSP can still own their own, contract the service out, or it
may be a national public asset. The VSP has the responsibility of the
consulting its own table to determine the correct one for a given call
scenario. There are numerous possible solutions I think, but something
clean and efficient is desirable.

Cheers,
Martin

-----Original Message-----
From: Hannes Tschofenig [mailto:[email-masked]] 
Sent: Tuesday, 17 April 2007 4:20 PM
To: Brian Rosen
Cc: [email-masked]; Rosen, Brian; [email-masked]
Subject: Re: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to
doendpoint centric LCP without giving away the store

Ciao
Hannes

with a
a

---

From: "Dawson, Martin" <[email-masked]>
Date: Wed, 18 Apr 2007 03:12:18 -0500

Hi Brian

"The country code is returned with the reference" - was that your
suggestion...? I might not have all the thread.

I'm fine with that model - do we have conveyance support for this
information though? In SIP, where does the country code go? Does the
client construct a bare bones PIDF-LO?

Cheers,
Martin

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Wednesday, 18 April 2007 6:03 AM
To: 'Hannes Tschofenig'
Cc: [email-masked]; Rosen, Brian; [email-masked]
Subject: RE: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to

No, I don't.

I assume that the LoST server the VSP consults to validate contains the
same
URIs that the LoST server used by the access network LIS to determine
the
URI.  The endpoint passes a URI to its VSP and claims it's a bona fide
PSAP
URI from LoST.  As long as that URI is in the LoST server (directly or
via a
referral) that the VSP uses, validation is possible.

If the attacker can insert bogus data into the global LoST database,
then we
couldn't detect it, but that is not threat here.

The access network and the endpoint can collude all they want, but
unless
the LoST server the VSP uses has bad data, it can determine if the PSAP
URI
is a genuine PSAP URI.  

Brian

> Subject: Re: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to
do
> >>> Perhaps we include in the LoST return a country code for a query
with

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 18 Apr 2007 07:38:14 -0400

Well, there is no place yet.  We'd have to make one.  
Let's first get consensus if that's the approach we want, and then we can
discuss the best way to do it.

It would affect the LCP and -conveyance directly or indirectly, although
there are many ways to carry it from endpoint to the VSP.  

Brian

> From: Dawson, Martin [mailto:[email-masked]]
> Sent: Wednesday, April 18, 2007 4:12 AM
> To: Brian Rosen; Hannes Tschofenig

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 18 Apr 2007 08:23:13 -0400

PIDF-LO contains a country code, as does the DHCP civic format and  
thus LLDP-MED. Thus, I'm confused by your statement below.

Henning

---

From: "Tschofenig, Hannes" <[email-masked]>
Date: Wed, 18 Apr 2007 14:25:33 +0200

I don't see the impact either. 

Particularly with this solution approach nothing needs to be done. 
This is more a deployment consideration. 

> Von: Henning Schulzrinne [mailto:[email-masked]] 
> Gesendet: Mittwoch, 18. April 2007 14:23
> An: Brian Rosen
> Cc: GEOPRIV; Brian Rosen; ECRIT
> Betreff: Re: [Geopriv] Re: [Ecrit] Not-so-grand compromise on 
> how todoendpoint centric LCP without giving away the store
>

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 18 Apr 2007 09:01:06 -0400

Is it appropriate to require an LCP and -conveyance to carry two locations:
for example, a reference and a PIDF containing just a country code?  Would
it be more expedient to define a URI parameter that could be added to the
reference?

Either works, and clearly the former is less work.

What would you rather see:

  INVITE sip:[email-masked] SIP/2.0
...
   Geolocation: <sips:[email-masked]; countrycode=us>
     ;inserted-by=endpoint

or

  INVITE sip:[email-masked] SIP/2.0
...
   Geolocation: <sips:[email-masked]>
     ;inserted-by=endpoint
   Geolocation: <cid:[email-masked]>
     ;inserted-by=endpoint
   Supported: geolocation
   Accept: application/sdp, application/pidf+xml
...
   Content-Type: multipart/mixed; boundary=boundary1
   Content-Length: ...

   --boundary1

   Content-Type: application/sdp

   ...SDP here

   --boundary1

   Content-Type: application/pkcs7-mime;
      smime-type=enveloped-data; name=smime.p7m
   Content-ID: [email-masked]

$  Content-Type: application/pidf+xml
$
$  <?xml version="1.0" encoding="UTF-8"?>
$     <presence xmlns="urn:ietf:params:xml:ns:pidf"
$         xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
$         xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
$         xmlns:gs="urn:ietf:params:xml:ns:pidf:geopriv10:geoShape"
$         entity="pres:[email-masked]">
$       <tuple id="sg89ae">
$        <timestamp>2007-03-20T14:00:00Z</timestamp>
$        <status>
$         <gp:geopriv>
$           <gp:location-info>
$             <cl:civilAddress>
$               <cl:country>US</cl:country>
$             <cl:civilAddress>
$           </gp:location-info>
$           <gp:usage-rules>
$             <gp:retransmission-allowed>no</gp:retransmission-allowed>
$             <gp:retention-expiry>2007-03-24T18:00:00Z</gp:retention-
$                           expiry>
$             <gp:method>DHCP</gp:method>
$             <gp:provided-by>www.cisco.com</gp:provided-by>
$           </gp:usage-rules>
$         </gp:geopriv>
$        </status>
$       </tuple>
$      </presence>
   --boundary1--

> Sent: Wednesday, April 18, 2007 8:23 AM
> To: Brian Rosen

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 18 Apr 2007 09:08:42 -0400

I think two locations (of different resolution, whether they both be  
V or R, or some combination) is much cleaner and extends to other  
models, such as partial location. We don't want to encode state and  
community name in a URL parameter, for example.

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 18 Apr 2007 09:28:49 -0400

Let's keep our eye on the goal, which was to allow validation of a PSAP URI
by a downstream routing element.  You suggested that we may not need it at
all.  We aren't providing two locations at different resolutions, we're
providing a hint to minimize the reverse search space.

While having a community name could further reduce the search space, it's
not clear to me it helps enough to be worth it.  Our simplest solution in
this direction is to not send the country code, and just allow a reverse
search in the LoST database ("flooding").

Having a community name is NOT sufficient to choose a PSAP in every case,
and every case has to work.  If the boundary is irregular, which it is in
some circumstances, you would need street name and house number to know
which PSAP.  That would not be acceptable to an access network who is not
willing to provide location to a VSP (or any other entity except a PSAP).  I
hope we're clear on that point.  So, returning coarse location as an LbyVand
using that in a LoST query is NOT an acceptable alternative to returning an
LbyR that is not dereferenceable by the VSP.

Brian

> Sent: Wednesday, April 18, 2007 9:09 AM
> To: Brian Rosen
> Cc: GEOPRIV; ECRIT

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 18 Apr 2007 15:37:03 +0200

Hi Brian,

> providing a hint to minimize the reverse search space.
PSAP URI validation is not needed when the VSP provides a flat rate 
based charging scheme (since doing fraud with individual calls will not 
be possible).
There might, however, be other things to consider (e.g., QoS 
reservations for preferential treatment etc.) that play a role here.

> search in the LoST database ("flooding").

The brute force version to solve the problem is not "simple" either. If 
a PSAP does not flood its URI then it will get blocked = bad thing.

> LbyR that is not dereferenceable by the VSP.
It is true that the routing based on country level works only if you either
* use an ESRP for the entire country (whereby this ESRP subsequently can 
do more detailed routing based on the location information it obtains 
from the ISP/ASP)
OR
* there is  only a single PSAP  per country.

Ciao
Hannes

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 18 Apr 2007 09:52:27 -0400

Okay Hannes, I get that, but:

Are we, or are we not agreeing that SOME VSPs need to validate a proffered
PSAP URI?  Your comment indicates reasons other than charging that may
prompt VSPs to attempt validation.  I assume you are not arguing we don't
need the capability.

I agree that "flooding" would be a requirement.  The actual requirement is
for a reverse lookup.  Flooding is how you meet the requirement.

Are we, or are we not agreeing that we can't force ESRP per country or
single PSAP per country?  If we agree that irregular boundaries per ESRP are
possible, then coarse location is insufficient for a LoST query and we need
some other solution.

Brian

> Sent: Wednesday, April 18, 2007 9:37 AM
> To: Brian Rosen
> Cc: 'Henning Schulzrinne'; 'GEOPRIV'; 'ECRIT'

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 18 Apr 2007 11:09:04 -0400

> possible, then coarse location is insufficient for a LoST query and  

That's not true. It just means that coarse location can't be used  
everywhere. That's a very different statement. I'd rather have 5% of  
the population get their street address than have to add complexity  
to 100% of the UAs, with additional failure modes.

Henning

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 18 Apr 2007 11:33:20 -0400

I'm not sure I understand what you are saying.

I'll agree that coarse location may work some times.  I wouldn't care to
speculate how often it does or doesn't.  I don't think it matters.  It
doesn't sometimes.  Does that mean we should misroute in those cases where
you only get coarse location, and you have an irregular boundary that
"misses"?  I suspect that would not fly with the access networks that have
the hiding problem.  You are giving them an unacceptable choice: give up
accurate location to the endpoint or be responsible for misroute.  That may
meet your notion of endpoint simplicity, but it won't be deployed I think.

You also seem to be willing to accept that the client will have two
locations to deal with: coarse LbyV and fine LbyR.  Not a complication I
would want to have to deal with given my alternative.

Brian

> Sent: Wednesday, April 18, 2007 11:09 AM
> To: Brian Rosen
> Cc: 'Hannes Tschofenig'; 'GEOPRIV'; 'ECRIT'

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 18 Apr 2007 12:55:34 -0400

> speculate how often it does or doesn't.  I don't think it matters.  It

This seems to be very country-specific. Thus, in some countries, this  
will be quite viable, in others, less so.

For DT, for example, you could have a very simple architecture:

-  Use normal LCP, returning Gemeinde (city/town), Bundesstaat  
(state) and country (DE). This is sufficient for determining the PSAP  
and requires zero interaction with the OSS.

- Return an LbyR that is similar to what is used today as an  
identifier (phone number?), which resolves to the rough information  
above.

> "misses"?  I suspect that would not fly with the access networks  

Definitely not. It would be the responsibility of the ISP to deliver  
location information of sufficient granularity to prevent misroutes.  
In some small number of corner cases (typically, the one boundary  
street between PSAP regions), this would mean delivering a street  
address or a geo region. This is easy for the ISP to determine - they  
just query LoST and get the coverage regions.

If you don't want to do this, just return the *geo* boundary of the  
PSAP to the customer as location information via LCP, just like you'd  
return an imprecise mapping from a wireless system, as a polygon. By  
our mapping rules, LoST computes the centroid (trivial) and returns  
the PSAP URL. I think this is somewhat similar to what Andy is  
proposing, but requires no new effort.

This reveals zero additional information to the client, beyond the  
coverage region of the PSAP, but the UA behavior is exactly the same  
as in the no-hiding case.

> meet your notion of endpoint simplicity, but it won't be deployed I  

I don't see this as the alternative. All I require is that ISP give  
up a tiny fraction of its location information in some corner cases.  
In most communities, all of the customers will only get city-level or  
county-level information, which corresponds to what their phone  
number already tells them.

I think this is a fair bargain. I'd like to hear good reasons from  
real carriers as to why this is not acceptable. Shadow boxing,  
without talking to real customers, seems likely to lead us to design  
something that doesn't actually help. (Just as I believe that the  
whole architecture proposed doesn't actually address the don't-spend- 
money objective of DT.)

> would want to have to deal with given my alternative.

Not really. I advocate returning a single LbyR, which resolves to  
minimal information sufficient for routing for the general public  
and, with PSAP authentication, to precise location information for  
dispatch.

Henning

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 18 Apr 2007 14:02:07 -0400

I can live with this way out of the mess.

I rather like the idea of returning the PSAP service boundary polygon on the
endpoint's (or VSP's) dereference.  The latter (as well as coarse location
when it works) also fixes the validation problem; the VSP dereferences, gets
the polygon, queries LoST with it, and gets the PSAP URI. 

I agree that in lots of cases, a very coarse location return from the LbyR
is sufficient, and access networks ought to be able to take advantage of it
when it happens.

I guess we need to hear from carriers.  I think you already raised the point
that in most cases, an IP address yields city level location, albeit VPNs
often obscure that.

And while you brought it up, I do think a very nice user part of a location
reference is a hashed telephone number.  Most of the DSL networks, for
example, do have telephone numbers which actually are easy to turn into
service address in the existing databases.  I'd prefer it be hashed so that
we don't reveal extra user information.  I particularly think that idea will
be quite useful in dealing with legacy wireline systems, which already
associate TN with location.  Adding a (hash of) TN with a provisioned LIS
domain on a Geolocation header in, or near a PSTN to SIP gateway would be a
very painless way to get location from a legacy wireline system into a next
generation emergency call system.

Brian

> Sent: Wednesday, April 18, 2007 12:56 PM
> To: Brian Rosen

---

From: "Stark, Barbara" <[email-masked]>
Date: Wed, 18 Apr 2007 14:37:48 -0400

Brian said: 
> And while you brought it up, I do think a very nice user part of a
location reference is a hashed telephone number.  Most of the DSL
networks, for example, do have telephone numbers which actually are easy
to turn into service address in the existing databases.  I'd prefer it
be hashed so that we don't reveal extra user information.  I
particularly think that idea will be quite useful in dealing with legacy
wireline systems, which already associate TN with location.  Adding a
(hash of) TN with a provisioned LIS domain on a Geolocation header in,
or near a PSTN to SIP gateway would be a very painless way to get
location from a legacy wireline system into a next generation emergency
call system. <

Actually, given requirements for "naked" DSL, without an underlying POTS
phone number, we're moving to "Circuit ID". 
Barbara

*****

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

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 18 Apr 2007 14:48:57 -0400

That's fine, hash the circuit ID and make that the user part of the location
reference.

Of course, this is NOT a requirement; it's just one way to make the
implementation simpler.  It's totally within the access provider's domain,
and only it cares what the URI looks like, thus it's not subject to
standardization except insofar as it might optimize intra-carrier system
purchases (e.g. if there was an agreement on how to do it, the OSS guys and
the LIS guys may be able to make their sub-systems interoperate).

Brian

> From: Stark, Barbara [mailto:[email-masked]]
> Sent: Wednesday, April 18, 2007 2:38 PM
> To: Brian Rosen; Henning Schulzrinne
> Cc: GEOPRIV; ECRIT
> Subject: RE: [Geopriv] Re: [Ecrit] Not-so-grand compromise on howto
> 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. GA621

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 18 Apr 2007 15:01:07 -0400

Just out of curiosity, what does a circuit ID look like? Is that the  
NAS identifier used in RADIUS or where is it visible?

---

From: "Dawson, Martin" <[email-masked]>
Date: Thu, 19 Apr 2007 04:55:07 -0500

OK - that'd be nice. The main thing I was thinking was that it would be
good to be able to do it without another round of churn on the
conveyance specification. That's why I posited a BCP on reference
construction (something that embedded a country code in the string).
However, I'm certainly open to a more explicit mechanism being defined.

Cheers,
Martin

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Wednesday, 18 April 2007 9:38 PM
To: Dawson, Martin; 'Hannes Tschofenig'
Cc: [email-masked]; Rosen, Brian; [email-masked]
Subject: RE: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to

Well, there is no place yet.  We'd have to make one.  
Let's first get consensus if that's the approach we want, and then we
can
discuss the best way to do it.

Brian

> > >>> code and a PSAP URI and returns yes/no validation ("Yes, that
URI
> is a
--
> ----------------------
--
> ----------------------

---

From: "Dawson, Martin" <[email-masked]>
Date: Thu, 19 Apr 2007 05:00:05 -0500

It's just the question of what the convention should be of providing
this information. The LCP protocol can certainly be defined such that it
provides a country code even if the only other form of location result
is the reference. So what you may be suggesting Henning is that the
device construct a PIDF-LO just for the purpose of sending that country
code along with the reference. Alternatively the LCP could provide both
a reference and the bare bones PIDF-LO with just the country code...

"No place yet" referred to there being no explicit place in SIP
conveyance to send just the country code without it being in a
PIDF-LO... assuming I'm in synch with Brian.

Cheers,
Martin

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]] 
Sent: Wednesday, 18 April 2007 10:23 PM
To: Brian Rosen
Cc: GEOPRIV; Brian Rosen; ECRIT
Subject: Re: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how
todoendpoint centric LCP without giving away the store

Henning

---

From: "Dawson, Martin" <[email-masked]>
Date: Thu, 19 Apr 2007 05:25:27 -0500

Well... I just posted on an alternative thread - about preferring the
location request be made at the time of the call - where Henning seems
to be taking the position that this is a dangerous additional
transaction requirement. Yet, here we appear to be suggesting that a
location dereference be made to determine coarse routing...

I don't actually object to the additional transaction (per my previous
thread) though I will note that the VSP is inherently "further" from the
LIS than the device is. It just seems cleaner to me if the VSP has no
requirement to interact with the LIS and that, in the case of emergency
calls, all LIS interactions occur locally - either from the device or
jurisdictional entities such as the LoST server, VPC, and/or PSAPs. This
also obviates the need for the LIS to distinguish between "allowed"
versus "non-allowed" granularity.

Cheers,
Martin

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Thursday, 19 April 2007 4:02 AM
To: 'Henning Schulzrinne'
Cc: 'GEOPRIV'; 'ECRIT'
Subject: RE: [Geopriv] Re: [Ecrit] Not-so-grand compromise on howto

I rather like the idea of returning the PSAP service boundary polygon on
the
endpoint's (or VSP's) dereference.  The latter (as well as coarse
location
when it works) also fixes the validation problem; the VSP dereferences,
gets
the polygon, queries LoST with it, and gets the PSAP URI. 

I agree that in lots of cases, a very coarse location return from the
LbyR
is sufficient, and access networks ought to be able to take advantage of
it
when it happens.

I guess we need to hear from carriers.  I think you already raised the
point
that in most cases, an IP address yields city level location, albeit
VPNs
often obscure that.

And while you brought it up, I do think a very nice user part of a
location
reference is a hashed telephone number.  Most of the DSL networks, for
example, do have telephone numbers which actually are easy to turn into
service address in the existing databases.  I'd prefer it be hashed so
that
we don't reveal extra user information.  I particularly think that idea
will
be quite useful in dealing with legacy wireline systems, which already
associate TN with location.  Adding a (hash of) TN with a provisioned
LIS
domain on a Geolocation header in, or near a PSTN to SIP gateway would
be a
very painless way to get location from a legacy wireline system into a
next
generation emergency call system.

Brian

---

From: "Dawson, Martin" <[email-masked]>
Date: Thu, 19 Apr 2007 05:28:12 -0500

Yep - cool - that "accelerates" the dereferencing by removing the need
to dereference through some other set of parameters (such as ATM PVC id
etc.) - although I suppose the associated location could just be cached
against the reference at the time it is generated anyway...

In any case, hashing things won't permit the VSP to make any coarse
routing decisions - since the value is obfuscated.

Cheers,
Martin

-----Original Message-----
From: Stark, Barbara [mailto:[email-masked]] 
Sent: Thursday, 19 April 2007 4:38 AM
To: Brian Rosen; Henning Schulzrinne
Cc: GEOPRIV; ECRIT
Subject: RE: [Geopriv] Re: [Ecrit] Not-so-grand compromise on howto
doendpointcentric LCP without giving away the store

*****

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 19 Apr 2007 14:24:32 -0400

Okay, well, discussion has died down now, so I'd like to see if we have
consensus on how we allow access networks to hide location from endpoints
(and VSPs) and yet result in correct emergency call routing.

The proposal requires no changes to existing documents (other than
explanations in -framework and -phonebcp).

It requires no changes in endpoint, VSP, ESRP or PSAP behavior.  It is
confined to LIS behavior for LIS' that wish to hide location.

It works as follows:

1. The endpoint uses an LCP to request location.  The LIS returns an LbyR
2. The endpoint dereferences the LbyR.  
3. The LIS, noticing that the dereference request is from the endpoint (or
at least not from any entity that is entitled to get fine grained location),
takes the fine grained location and uses LoST to determine the PSAP that
serves that location.
4. The LIS returns to the endpoint a location which, if submitted to LoST,
would return the same PSAP URI the fine grained location would.  In some
circumstances, this could be a civic with only a country.  An alternative
that works for all circumstances is to return the polygon that defines the
service boundary of the PSAP (which LoST can return).  Is essential that the
PSAP URI returned from a LoST query with whatever the LIS gives the endpoint
would be the same PSAP URI any querier using the fine grained location would
get.
5. The endpoint uses the (coarse) location value it obtains to query LoST.
It gets the (correct) PSAP URI
6. This is repeated at call time.  The endpoint has a valid LbyR and a valid
PSAP URI, which it uses to construct the emergency call
7. A VSP wishing to validate the PSAP URI takes the LbyR and dereferences
it.  The result will be the same (coarse) location the endpoint got.  The
VSP does a LoST query with that location, and should get the same PSAP URI
that is in the Request URI on the call.  This validation works for coarse or
fine validation, and of course works for LbyV without the dereference step.
8. The PSAP (or ESRP) which is the target of the PSAP URI gets the call.  It
dereferences the LbyR but gets the fine grained location; the LIS must have
a relationship with the ESRP/PSAP to assure this.
9. Any succeeding ESRPs or PSAPs can also dereference and get fine grained
location.

Some observations:
a) The LIS probably ought to query LoST with its calculated coarse location
to assure that it gets the same PSAP URI as the fine grained location.  
b) The coarse LoST lookups can be cached.  For a given LIS, there is likely
only a few of them
c) The VSP can cache validated PSAP URIs and avoid LoST lookups in most
cases
d) The endpoint could send both the coarse location by value and the
reference, but this would really only help the VSP because the ESRP/PSAP is
going to want to dereference to get the fine grained location.
e) The LIS can identify ESRPs and PSAPs in a number of ways.  It could use
IP address filtering, VPNs, IPSEC tunnels or other address restrictive
mechanisms.  It could use TLS credentials of any form it finds acceptable.
It is essential that the mechanism work for any valid PSAP that could get
the call, and any ESRP that could handle the call, even when there are
failures.  

Now, do we have any objections to making this the answer to the problem
posed?  To be clear, I'm asking if you can live with it, not if you would
prefer another one of the proposals that have been made.

Brian 

> Sent: Thursday, April 19, 2007 6:25 AM

---

From: John Schnizlein <[email-masked]>
Date: Thu, 19 Apr 2007 14:59:07 -0400

This thread is an indication of how far we have strayed from the "key  
goal" of the GeoPriv effort "to facilitate the protection of privacy  
pursuant to Privacy Rules set by the 'user/owner of the Target' ".  
[RFC 3693 paragraph 1]  Now the privacy goal is to hide the location  
from the very person whose privacy was our original intent.

That this thread is about how to hide location information from the  
target rather than explicitly advocating this reversal of the  
intended controls of the GeoPriv purpose, is another recurring  
theme.  We avoid justification of some feature while focussing on the  
requirements to provide that feature - leaving an unstated  
implication that the "requirements" actually demand the feature.

Isn't it time to consider if the current efforts are so far removed  
from the purpose that GeoPriv should stop before it causes harm?

John

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 19 Apr 2007 21:44:02 +0200

Hi all,

I think it is good to solicit feedback from the group. Brian compiled 
text in a previous mail and I just changed the subject header and 
shorted the text a bit.

Note that the drawback of this architecture is the need to deploy a ESRP 
for a country, the need to establish a relationship between the ESRP and 
the LIS (in order for the ESRP to obtain more detailed location 
information) and the need to route emergency SIP messages through the ESRP.

So far we haven't received a lot of comments from operators.

Please find my questions below:

Brian Rosen wrote:
> 8. The PSAP (or ESRP) which is the target of the PSAP URI gets the SIP message.  It

Here are the questions:

1) Do you think that the problem statement is valid (i.e., the problem 
that some ASP/ISP do not reveal precise location information for free, 
for emergency services)?
2) Do you think we should investigate the proposed approach in more detail?
3) Do you understand the drawbacks?
4) Do you think it is necessary to solicit feedback from VoIP providers, 
PSAP operators, regulators and network operators on this issue?

Ciao
Hannes & Marc

---

From: "Stastny Richard" <[email-masked]>
Date: Thu, 19 Apr 2007 21:48:31 +0200

>for a country,

Where did you get this from? It could be, but it need not
 
Richard

________________________________

Von: Hannes Tschofenig [mailto:[email-masked]]
Gesendet: Do 19.04.2007 21:44
An: 'ECRIT'
Cc: GEOPRIV
Betreff: [Ecrit] Soliciting Feedback: (Partial) Location Hiding Emergency Services Architecture

Hi all,

Here are the questions:

Ciao
Hannes & Marc

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 19 Apr 2007 15:53:27 -0400

>
> 1) Do you think that the problem statement is valid (i.e., the  
> problem that some ASP/ISP do not reveal precise location  
> information for free, for emergency services)?

Fortunately, if it turns out that this is a non-issue in the  
immediate or further future, the cost to end systems is nil. It is  
rather unlikely that we'll get feedback from a representative sample  
of operators. Some future operators, such as WiMax operators, may not  
exist at this time.

> 4) Do you think it is necessary to solicit feedback from VoIP  
> providers, PSAP operators, regulators and network operators on this  
> issue?
>

I think feedback should be solicited for the whole architecture, not  
this specific aspect. I don't think we want to encourage people to  
hide location or to make that the default behavior, given the  
difficulty of end-user fault detection, say.

By the way, I think it would be helpful if the framework or phonebcp  
would recommend that PSAPs read back location information via text-to- 
speech when test calls are being placed.

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 19 Apr 2007 21:56:30 +0200

Hi Richard,

if the access networks returns only the country code (in the worst case) 
then LoST will return (in the worst case) an ESRP corresponding to that 
country.
The emergency call would then be routed to this ESRP and subsequently 
this ESRP would have to fetch more detailed location information for 
routing within this country.

Do I miss something?

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 19 Apr 2007 22:03:04 +0200

Hi Henning

Henning Schulzrinne wrote:
>> problem that some ASP/ISP do not reveal precise location information 
>> for free, for emergency services)?
>
> Fortunately, if it turns out that this is a non-issue in the immediate 
> or further future, the cost to end systems is nil. It is rather 
> unlikely that we'll get feedback from a representative sample of 
> operators. Some future operators, such as WiMax operators, may not 
> exist at this time.
>
>
We don't want to encourage people to hide location for various reasons.

You are right that we don't want to solicit feedback only on this issue.
On the other hand we are designing an "enhancement" based on the 
feedback we got from a few operators regarding partial location hiding. 
Shouldn't we get feedback from a number of stakeholders about the 
validity of this architectural facet?

> would recommend that PSAPs read back location information via 
> text-to-speech when test calls are being placed.
Sounds good to me.

Ciao
Hannes

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 19 Apr 2007 16:16:46 -0400

There clearly is a linkage here between the PSAP coverage region (or  
ESRP region and, conversely, the number of them) and the information  
returned. An ISP can't just say "sorry, I'm only going to give you  
country-level information and it's your problem to set up an ESRP,  
but I will only give location information to certain favored VSPs  
that might operate such a proxy".

I suspect regulators are smart enough to recognize any such  
hypothetical attempts at trying to restrain competition, but I doubt  
we can force this through technology design.

An ISP that is willing to release complete location information to  
the end user can essentially wash their hand of the whole emergency  
calling thing; an ISP wishing to hide such information needs to work  
more closely with local authorities and PSAPs, both in terms of  
architecture and in terms of access authorization. ISPs can then make  
business and technology choices, constrained by the local regulator,  
as to which mode they prefer to work in. This may well change over  
time; for example, future customer-facing and OSS systems may make  
location conveyance cheaper and easier, thus removing one incentive  
to hide this information. To some extent, this is a trade-off between  
capital and operational/lawyer expenses. I think the best we can do  
is to offer reasonable choices and hope that operators are both  
rational actors and have the life and safety of their customers at  
heart.

Henning

On Apr 19, 2007, at 3:56 PM, Hannes Tschofenig wrote:

> Hi Richard,
>
> if the access networks returns only the country code (in the worst  
> case) then LoST will return (in the worst case) an ESRP  
> corresponding to that country.
> The emergency call would then be routed to this ESRP and  
> subsequently this ESRP would have to fetch more detailed location  
> information for routing within this country.
>
> Do I miss something?

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 19 Apr 2007 16:18:38 -0400

> speech when test calls are being placed.
Uh, well, in a form suitable for the media offered in the first place.  That
may be text, it may be text to sign language.

Brian

---

From: "Stastny Richard" <[email-masked]>
Date: Thu, 19 Apr 2007 22:22:00 +0200

Hannes,
 
as you say, this is the worst case.
but you can go down to village level if you want

>> Note that the drawback of this architecture is the need to deploy a ESRP
 
this sounds like the worst case is the only option

Richard

Von: Hannes Tschofenig [mailto:[email-masked]]
Gesendet: Do 19.04.2007 21:56
An: Stastny Richard
Cc: ECRIT; GEOPRIV
Betreff: Re: [Ecrit] Soliciting Feedback: (Partial) Location Hiding Emergency Services Architecture

Hi Richard,

Do I miss something?

Ciao
Hannes

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 19 Apr 2007 16:28:57 -0400

Certainly; I'm getting infected with the voice-centric virus...

---

From: Ted Hardie <[email-masked]>
Date: Thu, 19 Apr 2007 13:29:08 -0700

>may be text, it may be text to sign language.

First off, I'm not sure why Geopriv is cc'ed on this message.  Isn't what is
in framework/phonebcp purely an ECRIT matter?

Second, why are the UI elements of test call responses in scope for an IETF
document?  If I understand this right, we're not talking about the protocol
elements returned when someone is validating a location prior to making
a call, this is about what happens if someone makes a test call to the actual
PSAP.  How is this within the IETF's scope/knowledge?

Confused,
			Ted

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 19 Apr 2007 22:30:17 +0200

Hi Richard,

> but you can go down to village level if you want
Correct.

> this sounds like the worst case is the only option
No. It really depends on the regulatory environment in a particular 
country. The remarks by Henning also apply.

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 19 Apr 2007 22:33:06 +0200

Hi Ted,

~snip~
> in framework/phonebcp purely an ECRIT matter?
I thought about that as well. With the previous discussions we came up 
with a couple of solutions that required changes to the GEOPRIV L7 LCP 
work. This particular proposal does not require changes (or introduces 
new requirements) but some of the GEOPRIV members might be interested in 
the different approach. I don't want to exclude them.

Ciao
Hannes

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 19 Apr 2007 16:39:10 -0400

Wait, we're spinning out of the universe.

What is required is ONLY that the PSAP URI returned from the coarse location
is the same PSAP URI returned from the fine location.  That is the only
constraint.

If country code satisfies that, because every location in some country
returns the same result from a LoST query, great.  If that isn't true, then
country code is insufficient.

What always works is the polygon representing the service boundary of the
(fine grained location) target PSAP.  If the LIS queries LoST with fine
grained location, it can get back a suitable polygon. 

Something between the two examples above MAY work, but the constraint has to
be satisfied: LoST(coarse location, service) == LoST(fine location, service)

We don't REQUIRE country level ESRPs.  You won't get that in North America.
In some cases you may get a state level ESRP, but you can't guarantee that.
If the service area of the LIS is a proper subset of the service area of the
ESRP/PSAP, which is very common, especially with any aggregation via an
ESRP, then the LIS' task is simple.

Also note that the LIS can't use a specially modified LoST server.  The
validation depends on a VSP being able to ask its LoST server what the PSAP
URI for the proffered location is.  

Brian

> From: Stastny Richard [mailto:[email-masked]]
> Sent: Thursday, April 19, 2007 4:22 PM
> To: Hannes Tschofenig
> Cc: GEOPRIV; ECRIT
> Subject: [Geopriv] Re: [Ecrit] Soliciting Feedback: (Partial)
> LocationHiding Emergency Services Architecture
> 
> Hannes,
>

---

From: "Stastny Richard" <[email-masked]>
Date: Thu, 19 Apr 2007 22:43:58 +0200

Fully agree
This is what I wanted to say
 
Richard

Von: Brian Rosen [mailto:[email-masked]]
Gesendet: Do 19.04.2007 22:39
An: Stastny Richard; 'Hannes Tschofenig'
Cc: 'GEOPRIV'; 'ECRIT'
Betreff: RE: [Geopriv] Re: [Ecrit] Soliciting Feedback: (Partial) LocationHiding Emergency Services Architecture

Brian

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 19 Apr 2007 16:58:20 -0400

Nothing in this changes the obligation of the LIS to abide by the privacy
instructions of the user.  Nothing changes the mechanisms for that.  Nothing
changes the actual threats, nor the mechanisms to protect privacy.

If the LIS is going to give location to another entity, it has to have a way
to get the user's privacy policy attached to the location, per geopriv
rules.  That doesn't change.  In fact NOTHING changes in this regard.

The coarse location is location.  If the endpoint gives it to someone else,
it must state its privacy policy.

Brian

> From: John Schnizlein [mailto:[email-masked]]
> Sent: Thursday, April 19, 2007 2:59 PM
> To: Brian Rosen
> Cc: Henning Schulzrinne; GEOPRIV WG
> Subject: Re: [Geopriv] Re: [Ecrit] Not-so-grand compromise on howto

---

From: Andrew Newton <[email-masked]>
Date: Thu, 19 Apr 2007 17:08:51 -0400

First, thanks for spelling this out.  This sounds more reasonable  
than all the other solutions.  And it touches little while solving  
the problem.

-andy

---

From: "Dawson, Martin" <[email-masked]>
Date: Thu, 19 Apr 2007 16:39:13 -0500

Well - I think it's awful but I could live with it. It seems like a long
winded way to avoid having the LoST server do a dereference.

Does anyone think that a LoST server for Portugal will be administered
by an entity anywhere other than Portugal? I don't. And in that case, I
don't see any issue for those jurisdictions that want to apply auth+auth
on the dereference. The LoST server in such a jurisdiction can
reasonably be expected to be authorised.

Cheers,
Martin

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Friday, 20 April 2007 4:25 AM
To: Dawson, Martin; 'Henning Schulzrinne'
Cc: 'GEOPRIV'; 'ECRIT'
Subject: RE: [Geopriv] Re: [Ecrit] Not-so-grand compromise on howto

Okay, well, discussion has died down now, so I'd like to see if we have
consensus on how we allow access networks to hide location from
endpoints
(and VSPs) and yet result in correct emergency call routing.

It works as follows:

1. The endpoint uses an LCP to request location.  The LIS returns an
LbyR
2. The endpoint dereferences the LbyR.  
3. The LIS, noticing that the dereference request is from the endpoint
(or
at least not from any entity that is entitled to get fine grained
location),
takes the fine grained location and uses LoST to determine the PSAP that
serves that location.
4. The LIS returns to the endpoint a location which, if submitted to
LoST,
would return the same PSAP URI the fine grained location would.  In some
circumstances, this could be a civic with only a country.  An
alternative
that works for all circumstances is to return the polygon that defines
the
service boundary of the PSAP (which LoST can return).  Is essential that
the
PSAP URI returned from a LoST query with whatever the LIS gives the
endpoint
would be the same PSAP URI any querier using the fine grained location
would
get.
5. The endpoint uses the (coarse) location value it obtains to query
LoST.
It gets the (correct) PSAP URI
6. This is repeated at call time.  The endpoint has a valid LbyR and a
valid
PSAP URI, which it uses to construct the emergency call
7. A VSP wishing to validate the PSAP URI takes the LbyR and
dereferences
it.  The result will be the same (coarse) location the endpoint got.
The
VSP does a LoST query with that location, and should get the same PSAP
URI
that is in the Request URI on the call.  This validation works for
coarse or
fine validation, and of course works for LbyV without the dereference
step.
8. The PSAP (or ESRP) which is the target of the PSAP URI gets the call.
It
dereferences the LbyR but gets the fine grained location; the LIS must
have
a relationship with the ESRP/PSAP to assure this.
9. Any succeeding ESRPs or PSAPs can also dereference and get fine
grained
location.

Some observations:
a) The LIS probably ought to query LoST with its calculated coarse
location
to assure that it gets the same PSAP URI as the fine grained location.  
b) The coarse LoST lookups can be cached.  For a given LIS, there is
likely
only a few of them
c) The VSP can cache validated PSAP URIs and avoid LoST lookups in most
cases
d) The endpoint could send both the coarse location by value and the
reference, but this would really only help the VSP because the ESRP/PSAP
is
going to want to dereference to get the fine grained location.
e) The LIS can identify ESRPs and PSAPs in a number of ways.  It could
use
IP address filtering, VPNs, IPSEC tunnels or other address restrictive
mechanisms.  It could use TLS credentials of any form it finds
acceptable.
It is essential that the mechanism work for any valid PSAP that could
get
the call, and any ESRP that could handle the call, even when there are
failures.  

Now, do we have any objections to making this the answer to the problem
posed?  To be clear, I'm asking if you can live with it, not if you
would
prefer another one of the proposals that have been made.

Brian 

> > > meet your notion of endpoint simplicity, but it won't be deployed
I
> > > think.

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 19 Apr 2007 17:52:18 -0400

We're talking about resolvers, i.e., not the authoritative servers.  
They can be administered by anybody, including the famous VSP in  
Sierra Leone that Brian subscribes to. The resolver has no business  
relationship with the ISP, but needs to dereference the location  
reference, as it otherwise has no idea what to do next. Thus, I'm  
afraid that your proposal is not workable given the current LoST  
architecture and design.

Henning

---

From: "Dawson, Martin" <[email-masked]>
Date: Thu, 19 Apr 2007 17:17:58 -0500

OK I see...

If we're talking about VSPs (which I didn't think were necessary for
ECRIT) then I agree. However, that's the same challenge that i2 has -
except it's not just a routing question, it has to go to the right VPC
so the PSAP can get the location information from it out of band.

If this is the only scenario we are talking about, then I still think
there are less convoluted solutions from the perspective of the device.

How about the "resolver" does a dereference and the LIS, realizing it's
not an authorized requestor, just returns a country code. Or there may
actually be standard HTTP (for example) error constructs that would
provide the equivalent information. Or, as I tentatively suggested, a
convention for the URL construction could indicate the jurisdiction - or
the LIS request could include a URL and a bare bones PIDF-LO (both of
which eliminate the additional transaction altogether). I don't think
any of those proposals require changes to existing specifications either
(apart from LoST doing the dereference).

Anyway, my response stands. I could live with the solution but it feels
unnecessarily convoluted.

Cheers,
Martin

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]] 
Sent: Friday, 20 April 2007 7:52 AM
To: Dawson, Martin
Cc: Brian Rosen; GEOPRIV; ECRIT
Subject: Re: [Geopriv] Re: [Ecrit] Not-so-grand compromise on howto

Henning

---

From: Richard Barnes <[email-masked]>
Date: Thu, 19 Apr 2007 18:33:32 -0400

John,

Providing authentication and authorization mechanisms for location 
requests (e.g., LbyR derefernces) is clearly within the scope of GEOPRIV 
group.  To quote from the GEOPRIV charter:

"
The primary task of this working group will be to assess the the
authorization, integrity and privacy requirements that must be met in
order to transfer such information, or authorize the release or
representation of such information through an agent.

...

Also to be considered will be:  authorization of requestors and
responders; ...

...

The combination of these elements should provide a service capable of
transferring geographic location information in a private and secure
fashion (including the option of denying transfer).
"

Correspondingly, it is within the domain of ECRIT to make 
recommendations to their protocols and architectures to either try to 
accomodate the use of these authorization mechnisms, or to try to 
prevent their application to emergency services.

IMHO, there's a general tendency in GEOPRIV to assume a particular 
world-view -- whether it's a focus on location being held by the target, 
or on location signing, or something else -- and get distracted from the 
breadth of the WG's charter.

--Richard

John Schnizlein wrote:
> pursuant to Privacy Rules set by the 'user/owner of the Target' ". [RFC 
> 3693 paragraph 1]  Now the privacy goal is to hide the location from the 
> very person whose privacy was our original intent.
> 
> target rather than explicitly advocating this reversal of the intended 
> controls of the GeoPriv purpose, is another recurring theme.  We avoid 
> justification of some feature while focussing on the requirements to 
> provide that feature - leaving an unstated implication that the 
> "requirements" actually demand the feature.
> 
> Isn't it time to consider if the current efforts are so far removed from 
> the purpose that GeoPriv should stop before it causes harm?
> 
> John
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 19 Apr 2007 20:04:27 -0400

> so the PSAP can get the location information from it out of band.

As per our definitions, VSPs could be something like a corporation or  
university campus, not necessarily an operator such as SunRocket,  
Verizon or Vonage. As noted before, a LoST server could also be  
operated by an independent party, just like STUN servers are today  
(e.g., http://www.stunserver.org/).

> not an authorized requestor, just returns a country code. Or there may

That's roughly what happens in the proposal, except that the query is  
done by the UA. But that doesn't solve the problem of finding the  
right PSAP and doesn't seem to change the problems leading to the  
currently-proposed solution.

> (apart from LoST doing the dereference).

My general perception is that encoding information into URLs (not  
URNs) is considered a hack, as they are supposed to be opaque to the  
HTTP client.

---

From: "Stark, Barbara" <[email-masked]>
Date: Fri, 20 Apr 2007 10:09:18 -0400

I see this as an attempt to get around the access provider's "hiding". I
can see people using the PSAP test call now as not only a means of
testing whether an unauthenticated phone works, but as a tool to figure
out their location, if the access provider won't give it to them. 

I'm against this recommendation. But I won't fight hard, since the
recommendation has no teeth.

I should point out, though, that phonebcp currently only describes the
UA doing automated testing, and not providing a user interface to
support user-initiated testing. And support of media (above and beyond
SIP signaling) appears to only be a "SHOULD". In my phonebcp comments, I
did object to the recommendation that PSAPs respond with the location
value in their SIP response, if a reference were sent in the request.
But again, I won't argue hard. This will ultimately be a matter of local
or national policy, independent of the IETF attempts to impact such
policy.
Barbara

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Thursday, April 19, 2007 4:19 PM
To: 'Henning Schulzrinne'; 'Hannes Tschofenig'
Cc: 'GEOPRIV'; 'ECRIT'
Subject: RE: [Ecrit] Re: [Geopriv] Soliciting Feedback:
(Partial)LocationHiding Emergency Services Architecture

> speech when test calls are being placed.
Uh, well, in a form suitable for the media offered in the first place.
That may be text, it may be text to sign language.

Brian

*****

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 20 Apr 2007 10:58:17 -0400

The IETF specs are mainly directed towards implementors and mainly  
read by them. Implementors need to be aware of the data coming back  
from a test call, so they MUST implement the necessary functionality.  
It is up to the regulator, as you hint at, whether to allow or force  
the PSAP to return the information. I see nothing wrong with  
documenting, however, operational considerations that indicate that  
this is a good thing for the customer, as it allows verification. It  
is then up to the lobbyists of the telcos to convince the regulators  
that their business interests trump the public safety interests; it's  
not the role of the IETF to hide our technical opinion simply because  
it's inconvenient to the lobbyists.

Henning

---

From: "Liess, Laura" <[email-masked]>
Date: Thu, 19 Apr 2007 23:05:01 +0200

Brian,

this is for us (DT) the prefered solution and, from the alternatives we had, the only one we can live with. 

Laura

> Gesendet: Donnerstag, 19. April 2007 20:25
> An: 'Dawson, Martin'; 'Henning Schulzrinne'
> Cc: 'GEOPRIV'; 'ECRIT'
> Betreff: RE: [Geopriv] Re: [Ecrit] Not-so-grand compromise on 
> howto doendpointcentric LCP without giving away the store
> 
> 
> Okay, well, discussion has died down now, so I'd like to see 
> if we have consensus on how we allow access networks to hide 
> location from endpoints (and VSPs) and yet result in correct 
> emergency call routing.
> 
> The proposal requires no changes to existing documents (other 
> than explanations in -framework and -phonebcp).
> 
> It requires no changes in endpoint, VSP, ESRP or PSAP 
> behavior.  It is confined to LIS behavior for LIS' that wish 
> to hide location.
> 
> It works as follows:
> 
> 1. The endpoint uses an LCP to request location.  The LIS 
> returns an LbyR 2. The endpoint dereferences the LbyR.  
> 3. The LIS, noticing that the dereference request is from the 
> endpoint (or at least not from any entity that is entitled to 
> get fine grained location), takes the fine grained location 
> and uses LoST to determine the PSAP that serves that 
> location. 4. The LIS returns to the endpoint a location 
> which, if submitted to LoST, would return the same PSAP URI 
> the fine grained location would.  In some circumstances, this 
> could be a civic with only a country.  An alternative that 
> works for all circumstances is to return the polygon that 
> defines the service boundary of the PSAP (which LoST can 
> return).  Is essential that the PSAP URI returned from a LoST 
> query with whatever the LIS gives the endpoint would be the 
> same PSAP URI any querier using the fine grained location 
> would get. 5. The endpoint uses the (coarse) location value 
> it obtains to query LoST. It gets the (correct) PSAP URI 6. 
> This is repeated at call time.  The endpoint has a valid LbyR 
> and a valid PSAP URI, which it uses to construct the 
> emergency call 7. A VSP wishing to validate the PSAP URI 
> takes the LbyR and dereferences it.  The result will be the 
> same (coarse) location the endpoint got.  The VSP does a LoST 
> query with that location, and should get the same PSAP URI 
> that is in the Request URI on the call.  This validation 
> works for coarse or fine validation, and of course works for 
> LbyV without the dereference step. 8. The PSAP (or ESRP) 
> which is the target of the PSAP URI gets the call.  It 
> dereferences the LbyR but gets the fine grained location; the 
> LIS must have a relationship with the ESRP/PSAP to assure 
> this. 9. Any succeeding ESRPs or PSAPs can also dereference 
> and get fine grained location.
> 
> Some observations:
> a) The LIS probably ought to query LoST with its calculated 
> coarse location to assure that it gets the same PSAP URI as 
> the fine grained location.  
> b) The coarse LoST lookups can be cached.  For a given LIS, 
> there is likely only a few of them
> c) The VSP can cache validated PSAP URIs and avoid LoST 
> lookups in most cases
> d) The endpoint could send both the coarse location by value 
> and the reference, but this would really only help the VSP 
> because the ESRP/PSAP is going to want to dereference to get 
> the fine grained location.
> e) The LIS can identify ESRPs and PSAPs in a number of ways.  
> It could use IP address filtering, VPNs, IPSEC tunnels or 
> other address restrictive mechanisms.  It could use TLS 
> credentials of any form it finds acceptable. It is essential 
> that the mechanism work for any valid PSAP that could get the 
> call, and any ESRP that could handle the call, even when 
> there are failures.  
> 
> Now, do we have any objections to making this the answer to 
> the problem posed?  To be clear, I'm asking if you can live 
> with it, not if you would prefer another one of the proposals 
> that have been made.
> 
> Brian 
> 
> > thread) though I will note that the VSP is inherently 
> "further" from 
> > the LIS than the device is. It just seems cleaner to me if 
> the VSP has 
> > no requirement to interact with the LIS and that, in the case of 
> > emergency calls, all LIS interactions occur locally - 
> either from the 
> > device or jurisdictional entities such as the LoST server, 
> VPC, and/or 
> > PSAPs. This also obviates the need for the LIS to 
> distinguish between 
> > "allowed" versus "non-allowed" granularity.
> > 
> > Cheers,
> > Martin
> > 
> > I rather like the idea of returning the PSAP service 
> boundary polygon 
> > on the endpoint's (or VSP's) dereference.  The latter (as well as 
> > coarse location
> > LbyR is sufficient, and access networks ought to be able to take 
> > advantage of it
> > when it happens.
> > 
> > point that in most cases, an IP address yields city level location, 
> > albeit VPNs
> > often obscure that.
> > 
> > networks, for example, do have telephone numbers which actually are 
> > easy to turn into service address in the existing databases.  I'd 
> > prefer it be hashed so that
> > > > I'll agree that coarse location may work some times.  I 
> wouldn't 
> > > > care to speculate how often it does or doesn't.  I 
> don't think it 
> > > > matters.
> > It
> > >
> > > This seems to be very country-specific. Thus, in some countries, 
> > > this will be quite viable, in others, less so.
> > >
> > > (state) and country (DE). This is sufficient for determining the 
> > > PSAP and requires zero interaction with the OSS.
> > >
> > > > doesn't sometimes.  Does that mean we should misroute in those 
> > > > cases where you only get coarse location, and you have an 
> > > > irregular boundary
> > that
> > > > "misses"?  I suspect that would not fly with the access 
> networks 
> > > > that have
> > >
> > > address or a geo region. This is easy for the ISP to determine - 
> > > they just query LoST and get the coverage regions.
> > >
> > > PSAP to the customer as location information via LCP, just like 
> > > you'd return an imprecise mapping from a wireless system, as a 
> > > polygon. By our mapping rules, LoST computes the centroid 
> (trivial) 
> > > and returns the PSAP URL. I think this is somewhat 
> similar to what 
> > > Andy is proposing, but requires no new effort.
> > >
> > > > the hiding problem.  You are giving them an 
> unacceptable choice: 
> > > > give up accurate location to the endpoint or be responsible for 
> > > > misroute. That may
> > > > meet your notion of endpoint simplicity, but it won't 
> be deployed I
> > > > think.
> > >
> > > In most communities, all of the customers will only get 
> city-level 
> > > or county-level information, which corresponds to what 
> their phone 
> > > whole architecture proposed doesn't actually address the 
> > > don't-spend- money objective of DT.)
> > >
> > >
> > > >
> > > > You also seem to be willing to accept that the client will have 
> > > > two locations to deal with: coarse LbyV and fine LbyR.  Not a 
> > > > complication I would want to have to deal with given my 
> > > > alternative.
> > >
> > [email-masked] https://www1.ietf.org/mailman/listinfo/geopriv
> > 
> > 
> ----------------------------------------------------------------------
> > ----
> > ----------------------
> --------------------------------------------------------------
> ------------
> > ----------------------
> > [mf2]
> 
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 21 Apr 2007 14:51:46 +0200

Hi John

let me also respond to your comments

>> from the very person whose privacy was our original intent.
You might have missed a few discussions in this context. For a long time 
we worked on the assumption that the end point will have precise 
location information information (by whatever definition of precise you 
want). This is indeed reasonable to assume in a number of environments 
(e.g., enterprise environments, WLAN hotspots). We have had many 
discussions with various stakeholders (also in other organizations) and 
we noticed that some network operators do not want to give away the end 
hosts precise location information since they believe it is a valuable 
asset. Since this aspect will ultimately be decided by the regulator we 
investigate the "what if" approach and try to design a sound story. We 
do the same for unauthenticated network access even though a number of 
people believe that it is not a good thing to have.

Do you at least agree that there potentially cases where the end host 
might not have access to its precise location information?

> "requirements" actually demand the feature.
The GEOPRIV architecture does not state that every network has to make 
location information available to the Target.
You mix technical aspects with business policies and deployment 
considerations. We develop the technical aspects rather than the 
business policies. For example, the work in ECRIT is useful for 
different environments that are different with respect to the way how 
the business models work. That's the reason why the 3GPP and other folks 
are able to reuse our building blocks for their emergency services 
architecture.

>> from the purpose that GeoPriv should stop before it causes harm?
Geopriv develops a number of different things and from the current 
solution we are discussing there is absolutely no impact for the work in 
Geopriv other than the fact that a PIDF-LO carries values in only a few 
elements rather than many.

Does this circumstance make you happy?

Ciao
Hannes

---

From: John Schnizlein <[email-masked]>
Date: Sun, 22 Apr 2007 18:58:54 -0400

I am only responding on a thread I think has hopelessly lost its way  
because you directed questions to me.

On Apr 21, 2007, at 8:51 AM, Hannes Tschofenig wrote:

>> This thread is an indication of how far we have strayed from the  
>> "key goal" of the GeoPriv effort "to facilitate the protection of  
>> privacy pursuant to Privacy Rules set by the 'user/owner of the  
>> Target' ". [RFC 3693 paragraph 1]  Now the privacy goal is to hide  
>> the location from the very person whose privacy was our original  
>> intent.

> You might have missed a few discussions in this context. For a long  
> time we worked on the assumption that the end point will have  
> precise location information information (by whatever definition of  
> precise you want). This is indeed reasonable to assume in a number  
> of environments (e.g., enterprise environments, WLAN hotspots). We  
> have had many discussions with various stakeholders (also in other  
> organizations) and we noticed that some network operators do not  
> want to give away the end hosts precise location information since  
> they believe it is a valuable asset. Since this aspect will  
> ultimately be decided by the regulator we investigate the "what if"  
> approach and try to design a sound story. We do the same for  
> unauthenticated network access even though a number of people  
> believe that it is not a good thing to have.
>
> Do you at least agree that there potentially cases where the end  
> host might not have access to its precise location information?

The purpose of the GeoPriv WG is to enable hosts to control  
information about their locations.  It seems to me that would mean  
solving the technical problems that interfere with a host having  
access to its location, not designing complex "solutions" that  
incorporate the problem.

In other words, such a case is a problem to be solved, not a  
condition to support.  Observing that this problem is associated with  
mobile host suggests that GPS or Galileo is an appropriate technical  
solution to the problem.

>> That this thread is about how to hide location information from  
>> the target rather than explicitly advocating this reversal of the  
>> theme.  We avoid justification of some feature while focussing on  
>> the requirements to provide that feature - leaving an unstated  

> The GEOPRIV architecture does not state that every network has to  
> make location information available to the Target.
> considerations.

I am trying to remain faithful to the original goals from before the  
"business policy" of telephone network operators who appear to be  
looking to create a mechanism to extract revenue from users.

> We develop the technical aspects rather than the business policies.  
> For example, the work in ECRIT is useful for different environments  
> that are different with respect to the way how the business models  
> work. That's the reason why the 3GPP and other folks are able to  
> reuse our building blocks for their emergency services architecture.
>
>> Isn't it time to consider if the current efforts are so far  
>> removed from the purpose that GeoPriv should stop before it causes  
>> harm?

> solution we are discussing there is absolutely no impact for the  
> work in Geopriv other than the fact that a PIDF-LO carries values  
> in only a few elements rather than many.
>

I would think it is clear that the way the GeoPriv WG has changed its  
goals to support creation of a business selling users' locations  
while hiding their own location information from them has not made me  
happy.  I expect that most IETF participants would prefer to enable  
hosts with information from the network rather than create new  
location-selling business.

John

---

From: "Stark, Barbara" <[email-masked]>
Date: Wed, 25 Apr 2007 11:28:19 -0400

Circuit IDs have nothing to do with RADIUS, that I'm aware of.
"Circuit ID" format is defined by whatever system an access company uses
to manage its inventory of circuits. The most common such system in the
US is TIRKS(R), which is now developed by Telcordia. It was initially
developed by AT&T Bell Labs in the late 1970's. Fortunately, it has
managed to evolve a bit since then. Most of the baby Bells continue to
use it, I think.
There's a really short Wikipedia description of TIRKS at
http://en.wikipedia.org/wiki/TIRKS
In short, a Circuit ID uniquely identifies a circuit within an access
provider's operations systems. Many different types of circuits exist
(POTS, T1, DS3, SONET, etc.). Different types use different formats.
Barbara

-----Original Message-----
From: Clive D.W. Feather [mailto:[email-masked]] 
Sent: Wednesday, April 25, 2007 4:37 AM
To: Henning Schulzrinne
Cc: Stark, Barbara; GEOPRIV; ECRIT
Subject: Re: [Ecrit] Circuit ID

> NAS identifier used in RADIUS or where is it visible?

In the UK it's not currently standardised, though we're looking at it. I
would *expect* it to end up something like BT-EA12345678 or
001-EA12345678 where the first part identifies the circuit owner (either
a short name or a
CUPID) and the second half is decided by the provider; BT appear to use
a two letter region code followed by an 8 digit number).

>> Actually, given requirements for "naked" DSL, without an underlying 
>> POTS phone number, we're moving to "Circuit ID".

That's not the only scenario - the UK is looking at an arrangement
whereby one telco (Openreach, part of BT) provides the circuit and
another telco provides the call server and thus the number; Openreach
and BT will have no visibility of the number - if any - allocated to the
line.

-- 
Clive D.W. Feather  | Work:  <[email-masked]>   | Tel:    +44 20 8495
6138
Internet Expert     | Home:  <[email-masked]>  | Fax:    +44 870 051
9937
Demon Internet      | WWW: http://www.davros.org | Mobile: +44 7973
377646
THUS plc            |                            |

*****

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

---

From: "Stark, Barbara" <[email-masked]>
Date: Thu, 26 Apr 2007 11:20:15 -0400

It turns out I was wrong about the Circuit ID and RADIUS. I just can't
seem to keep up with the architecture changes going on.
Yes, in newer equipment, the Access Node (DSLAM) adds the Circuit ID to
both DHCP and PPP protocols. This is copied into the message sent to
RADIUS.
Barbara 

-----Original Message-----
From: Clive D.W. Feather [mailto:[email-masked]]
Sent: Wednesday, April 25, 2007 4:37 AM
To: Henning Schulzrinne
Cc: Stark, Barbara; GEOPRIV; ECRIT
Subject: Re: [Ecrit] Circuit ID

*****

material from all computers. GA623