Subject: [Ecrit] draft-winterbottom-ecrit-priv-loc-00

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 10 Jul 2012 19:09:17 +0300

Hi all, 

years ago the ECRIT working group discussed the topic of 'location hiding'  and this lead to the publication of RFC 6444 (http://datatracker.ietf.org/doc/rfc6444/). Consequently, a solution was developed (and is still work in progress) called "Rough Location", see http://tools.ietf.org/id/draft-ietf-ecrit-rough-loc.

It looked like we solved that problem. Right? 

You may think. Early 2011, about 4 years after the first location hiding draft was published, the European Commission (EC) comes along and published mandate 493. Without going into the details of the mandate the European Commission had the impression that there are no specifications available. 

The Internet Architecture Board (IAB) provided a response to that mandate, which you can find here: http://www.iab.org/documents/correspondence-reports-documents/2011-2/letter-to-the-european-commission-on-global-interoperability-in-emergency-services/.

Unfortunately, the IAB interaction with the EC did not lead to the desired outcome, i.e., to look at our documents carefully enough and to realize that we have a solution already. 

In any case, a new standards group in ETSI was created to work on this topic: the M493 group. This group is supposed to develop an emergency services architecture in fulfillment of the location hiding requirement (the mandate phrases it differently, of course but the requirements that are discussed flow in that direction).

To provide feedback into that process James Winterbottom and myself had decided to write an Internet draft for an architecture that we believe could meet their requirements and, at the same time, re-uses some of our earlier standardization work.

You can find the document here:
http://tools.ietf.org/html/draft-winterbottom-ecrit-priv-loc-00

Feedback is welcome. 

Ciao
Hannes

PS: Marc, can we get an agenda slot to discuss this topic?

---

From: "Richard L. Barnes" <[email-masked]>
Date: Tue, 10 Jul 2012 12:31:09 -0400

Hey Hannes, James,

I agree that -rough-loc seems not to be meeting some stakeholders' needs.  It does like we need a little more protocol revision.

I think that this document goes about it in the wrong way.  Using the DNS for LIS discovery is fragile, as we've discussed often in the past.  And from the perspective of client implementation, this document completely screws up the normal location->LoST->call flow.

It would be better to allow location by reference in LoST queries.  The major challenge in that regard was that the LoST server might not be able to dereference the URI, but that can be mitigated with local LoST server discovery, which -phonebcp requires to be preferred over configured LoST servers.

I'm going to take a first past at LbyR-in-LoST in a rev of rough-loc in time for the draft deadline, so that we can have a basis for discussion in Vancouver.

Thanks for getting this conversation started,
--Richard

On Jul 10, 2012, at 12:09 PM, Hannes Tschofenig wrote:

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

---

From: Brian Rosen <[email-masked]>
Date: Tue, 10 Jul 2012 13:35:35 -0400

Tell me more about why DNS for LIS discovery is fragile - not that I particularly like it.

There was good reason that LoST didn't allow LbyR -- it makes the whole transaction more fragile.  Local LoST server discovery is the same issue as DNS reverse lookup - the ISP has to do it right.  Hard to see how you win with LbyR.

Brian

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Tue, 10 Jul 2012 20:42:31 +0300

Brian, Richard, 

the discovery of the LIS or LoST server isn't the important part of the
document. This is just the stuff we had developed in ECRIT/GEOPRIV.
Nothing new there. 
So, don't get distracted. 

The core story is that the LoST lookup is triggered by the lookup for
location to the HELD server. Since the location server is local it can
initiate a regular LoST lookup and channel the response back to the end
device. 

Ciao
Hannes

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of ext Brian Rosen
> Sent: Tuesday, July 10, 2012 8:36 PM
> To: Richard L. Barnes
> Cc: [email-masked] Org
> Subject: Re: [Ecrit] draft-winterbottom-ecrit-priv-loc-00
> 
> There was good reason that LoST didn't allow LbyR -- it makes the
whole
> transaction more fragile.  Local LoST server discovery is the same
issue
> as DNS reverse lookup - the ISP has to do it right.  Hard to see how
you
> win with LbyR.
> > I agree that -rough-loc seems not to be meeting some stakeholders'
> needs.  It does like we need a little more protocol revision.
> >
> > I think that this document goes about it in the wrong way.  Using
the
> DNS for LIS discovery is fragile, as we've discussed often in the
past.
> And from the perspective of client implementation, this document
> completely screws up the normal location->LoST->call flow.
> >
> > It would be better to allow location by reference in LoST queries.
> The major challenge in that regard was that the LoST server might not
be
> able to dereference the URI, but that can be mitigated with local LoST
> server discovery, which -phonebcp requires to be preferred over
> configured LoST servers.
> >
> > I'm going to take a first past at LbyR-in-LoST in a rev of rough-loc
> in time for the draft deadline, so that we can have a basis for
> discussion in Vancouver.
> >
> >> years ago the ECRIT working group discussed the topic of 'location
> hiding'  and this lead to the publication of RFC 6444
> (http://datatracker.ietf.org/doc/rfc6444/). Consequently, a solution
was
> developed (and is still work in progress) called "Rough Location", see
> http://tools.ietf.org/id/draft-ietf-ecrit-rough-loc.
> >>
> >> You may think. Early 2011, about 4 years after the first location
> hiding draft was published, the European Commission (EC) comes along
and
> published mandate 493. Without going into the details of the mandate
the
> European Commission had the impression that there are no
specifications
> available.
> >>
> >> The Internet Architecture Board (IAB) provided a response to that
> mandate, which you can find here:
> http://www.iab.org/documents/correspondence-reports-documents/2011-
> 2/letter-to-the-european-commission-on-global-interoperability-in-
> emergency-services/.
> >>
> >> Unfortunately, the IAB interaction with the EC did not lead to the
> desired outcome, i.e., to look at our documents carefully enough and
to
> realize that we have a solution already.
> >>
> >> In any case, a new standards group in ETSI was created to work on
> this topic: the M493 group. This group is supposed to develop an
> emergency services architecture in fulfillment of the location hiding
> requirement (the mandate phrases it differently, of course but the
> requirements that are discussed flow in that direction).
> >>
> >> To provide feedback into that process James Winterbottom and myself
> had decided to write an Internet draft for an architecture that we
> believe could meet their requirements and, at the same time, re-uses
> some of our earlier standardization work.
> >>

---

From: "Richard L. Barnes" <[email-masked]>
Date: Tue, 10 Jul 2012 14:40:49 -0400

> Tell me more about why DNS for LIS discovery is fragile - not that I particularly like it.

Well, not the DNS per se, but rather the reverse DNS, done remotely.  Gets screwed up by things like CGNs, VPNs, etc.  

I had in mind Figure 5 in the document, which shows the VSP proxy using the DNS to look up the caller's LIS, which I inferred was done using the caller's IP address.  That has the fragility properties above.

> There was good reason that LoST didn't allow LbyR -- it makes the whole transaction more fragile.  Local LoST server discovery is the same issue as DNS reverse lookup - the ISP has to do it right.…

The only reason it makes the transaction more fragile is if the request can make its way (through the LoST hierarchy) to a server that can access the LbyR.  You can mitigate this through LoST discovery, and by having the rough location (if any) sent along with the LoST query, so that the LbyV can be used even if the LbyR can't.  So, for example, maybe my ISP is willing to at least say "You're in Virginia", which would get me to a VA-level LoST server, who could dereference the LbyR and forward the request on.

Local LoST discovery is more robust than remote LIS discovery using the DNS.  It can be done without an reverse DNS at all (if there's DHCP information).  If it does fall back to reverse DNS, then things are more fragile, but I would think still less fragile than from remote, since the DNS resolver could take things like CGN into account.

--Richard

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Tue, 10 Jul 2012 22:41:11 +0300

Hi Richard, Hi Brian, 

> The only reason it makes the transaction more fragile is if the
request
> can make its way (through the LoST hierarchy) to a server that can
> access the LbyR.  You can mitigate this through LoST discovery, and by
> having the rough location (if any) sent along with the LoST query, so
> that the LbyV can be used even if the LbyR can't.  

We have a document for the LoST server discover using DHCP:
http://tools.ietf.org/html/rfc5223

There was an issue raised a little while ago when we found out that HP
had been using the same DHCP code point for some of their thin client
provisioning systems (of course without registering the code point with
IANA)....

> So, for example,
> maybe my ISP is willing to at least say "You're in Virginia", which
> would get me to a VA-level LoST server, who could dereference the LbyR
> and forward the request on.

If that's the case then we wouldn't have to discuss this issue at all
since then the currently described rough location solution would work. 

Ciao
Hannes

---

From: Brian Rosen <[email-masked]>
Date: Tue, 10 Jul 2012 15:42:02 -0400

> Well, not the DNS per se, but rather the reverse DNS, done remotely.  Gets screwed up by things like CGNs, VPNs, etc.  
The LIS discovery gets screwed up in exactly the same way and we're not fixing that.  LIS discovery and LoST discovery are two peas in the same pod.

> I had in mind Figure 5 in the document, which shows the VSP proxy using the DNS to look up the caller's LIS, which I inferred was done using the caller's IP address.  That has the fragility propert…
Yes, of course - 3rd party lookup is always an issue using IP addresses.
The regulators can force connections, but that only works if you don't have any nomading.

> The only reason it makes the transaction more fragile is if the request can make its way (through the LoST hierarchy) to a server that can access the LbyR.  You can mitigate this through LoST disco…
But you don't need any rough loc stuff to do that.  If the LIS is willing to give you a location good enough to route to the right ESInet, you are done.

Even in the US, with 6000 PSAPs, we're not going to have 6000 ESInets.  Most of the access points will be state ESInets.  In Europe, it's almost always easier than that.

We've discouraged sending two locations, including LbyV and LbyR because of the problems when they aren't the same - what do you do?

Another reason it's fragile is that the LoST server needs credentials for the LIS, and we may have lots of LoST servers that are not actually run by the emergency authorities.  Your VPN gets you in trouble again if the right LbyR goes to the wrong LoST server.  The LoST server may not have credentials to get the dereference.

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Tue, 10 Jul 2012 22:47:33 +0300

Hi Brian, 

> Even in the US, with 6000 PSAPs, we're not going to have 6000 ESInets.
> Most of the access points will be state ESInets.  In Europe, it's
almost
> always easier than that.
> 
> We've discouraged sending two locations, including LbyV and LbyR
because
> of the problems when they aren't the same - what do you do?

It is true that in most countries it is pretty trivial. 

However, the problem is that some European countries want to stick with
their existing PSAP infrastructure. For example, Germany is such a case
and they have a number of PSAPs. 
They also do not want to introduce an ESRP either. 

Why they have managed to come up with a different view in case of eCall
is a mystery to me but that's what I had been told. 

So, in some sense you could call it a legacy deployment. 

Ciao
Hannes

---

From: Brian Rosen <[email-masked]>
Date: Tue, 10 Jul 2012 15:52:18 -0400

Okay, but where are the boundaries?  Do they equate to U.S. state boundaries or equivalent?
Where is the actual problem?  I can get you a whole lot closer to a state given an IP address right now.  Who is hiding what?

Brian

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 10 Jul 2012 23:06:58 +0300

I will ask for the precise number of PSAPs in some European countries and whether their service boundaries are available.

---

From: Marc Linsner <[email-masked]>
Date: Wed, 11 Jul 2012 12:57:25 -0400

Richard,

>
>I'm going to take a first past at LbyR-in-LoST in a rev of rough-loc in
>time for the draft deadline, so that we can have a basis for discussion
>in Vancouver.
>

Rough-loc is a WG document that's been through wglc.  New ideas need to be
in a new draft.

-Marc-

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 11 Jul 2012 20:05:26 +0300

That's a good point, Marc. 

The document has good content even though it does not meet the needs of everyone.

---

From: "Richard L. Barnes" <[email-masked]>
Date: Thu, 12 Jul 2012 15:45:34 -0400

> provisioning systems (of course without registering the code point with

I had gotten in touch with some HP guys on this, but I forget where that conversation ended up.  I'll see if I can find the messages.

> since then the currently described rough location solution would work. 

Only if there's a VA PSAP.  If there's any finer granularity (and there is), then "You're in Virginia" is not good enough to get me to a PSAP.

--Richard

---

From: "Richard L. Barnes" <[email-masked]>
Date: Thu, 12 Jul 2012 15:51:18 -0400

> The LIS discovery gets screwed up in exactly the same way and we're not fixing that.  LIS discovery and LoST discovery are two peas in the same pod.

By the same token, if LIS discovery works (as required by -priv-loc), then LoST discovery should too.  So there's no incremental fragility.

> Another reason it's fragile is that the LoST server needs credentials for the LIS, and we may have lots of LoST servers that are not actually run by the emergency authorities.  Your VPN gets you in…

That last point is why you want the captive LoST server and the rough loc.  If the client uses the captive LoST server, then you're good; the ISP can arrange everything so it works.  If the client uses some other server, then the rough loc can get him to an authorized server.

Note that this is a different degree of "roughness" / precision than we've talked about before: Not precise enough to get you to a PSAP, just precise enough to get you to an authorized LoST server.

--Richard

---

From: "Richard L. Barnes" <[email-masked]>
Date: Thu, 12 Jul 2012 15:54:56 -0400

> Rough-loc is a WG document that's been through wglc.  New ideas need to be

I'm not sure I agree.  Doesn't the current conversation demonstrate that rough-loc doesn't solve the problem it was intended to solve?  I was taking this thread as very late WGLC comments -- or early IETF LC comments :)

If you still want me to hold off, let me know and I will.

--Richard

---

From: "Richard L. Barnes" <[email-masked]>
Date: Thu, 12 Jul 2012 15:56:21 -0400

We shouldn't publish the document if it doesn't solve a problem.  I'm happy to adapt it so that it does.  We can always re-WGLC.

--Richard

---

From: Marc Linsner <[email-masked]>
Date: Thu, 12 Jul 2012 16:05:30 -0400

I would rather the WG agree to add/erase text from the document.  Post the
proposed text to the list for discussion vs. changing the document.

-Marc-

-----Original Message-----
From: "Richard L. Barnes" <[email-masked]>
Date: Thu, 12 Jul 2012 15:54:56 -0400
To: Marc Linsner <[email-masked]>
Cc: Hannes Tschofenig <[email-masked]>, "[email-masked] Org"
<[email-masked]>

>I'm not sure I agree.  Doesn't the current conversation demonstrate that
>rough-loc doesn't solve the problem it was intended to solve?  I was
>taking this thread as very late WGLC comments -- or early IETF LC
>comments :)
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 13 Jul 2012 10:48:44 +0300

Rough location does not solve the routing issues of certain countries but that does not mean it does not offer a solution for many others. 

The challenge is that countries have PSAP deployments that differ quite a bit and they are even changing over time. The best solution for addressing the location based routing depends a bit on the deployment they have. 

Here are two examples. I doubt that UK or Sweden need the solution we have described in draft-winterbottom-ecrit-priv-loc. In the UK there are stage 1 PSAPs with replicated routing information and you can send it to any one of them to get the call routed correctly to the stage 2 PSAP. So, if you know that you are in the UK you are already good to go. 

In Sweden there is no separation between stage 1 and stage 2 PSAPs. Nevertheless, they have a couple of PSAPs that are interconnected. Reaching any one of them is sufficient. So, you only need to know that you are in Sweden.

Finally, I believe that many countries will in their transition story have to rely on an ESRP (like some of the countries plan to do for eCall). 

Ciao
Hannes

---

From: Laura Liess <[email-masked]>
Date: Fri, 13 Jul 2012 12:31:26 +0200

Hannes, James,

Thank you for submitting this draft.  The architecture and interfaces
described in the draft is in principle what we intend to implement in
Germany. (I think most countries which do not have dedicated emergency
calling telecomunication infrastructure will do that.) For Germany, a
very similar architecture has already been agreed between DT and the
German regulator (BNetzA).  DT already submitted this architecture to
ETSI as a solution proposal for the European Commission (EC) mandate
493.

The only difference between the architecture proposed in the draft and
the architecture already proposed by DT in ETSI is that the second
does currently not contain the LIS interface to LOST, the LIS was
supposed to get the EcrfURI using an internal proprietary interface. I
think the LIS interface to LOST shown in Figure 5 is a very good idea.
It makes the architecture more general and more flexible. I think if
the draft is agreed in ECRIT without significant architecture changes,
it would make sense that ETSI adopts the architecture described in the
draft.

Kind regards
Laura

---

From: Laura Liess <[email-masked]>
Date: Fri, 13 Jul 2012 15:44:57 +0200

Richard,

My understanding is that rough location and the LOST query from the
LIS are two different alternatives for two different use cases and
both are useful.   Please let me know if I am wrong.

Rough location is a good choice in countries with dedicated emergency
calling telecommunication infrastructure (and budget dedicated to
develop this infrastructure) as ESInet. ESRPs and the LOST-tree are
developped by organizations responsible for this infrastructure. A VSP
queries the LIS with the IP-address and gets the rough location and
the LbyR, then makes a LOST query with the rough location and gets the
ESRP/PSAP. The ESRP/PSAP queries the LIS with the LbyR and gets the
LbyV. The ISP will trust any ESRP/PSAP because they are parts of the
emergency service infrastructure. The ISP do not care about LOST.

 In Germany, without dedicated emergency calling telecommunication
infrastructure, ESRPs will be provided by some (large) national
carriers. Because they are not paid for this in any way, they are not
willing to provide LOST trees accessible from the Internet or ESRPs
which have to query the LISs for every possible ISP. On the other
side, small ISPs will not want to have trust relationships with more
than one ESRP provider, in general they have an SLA with some large
carrier for IP-access anyway. So it is important that the ESRP URI in
the LOST response is ISP-specific. ISPs which are DT customers will
get a different LOST response than the Vodafone customers for the same
location in the query.
In Germany, I could imagine that a so-called carrier LOST will be
developped on the long term. At the beginning ISPs will configure one
ESRP URI and that's it. There is no chance for the development of an
open LOST infrastructure accessible from the Internet because there is
nobody there to pay for it. In the current aggreement with the
regulator, there is no LOST at all, the LIS is responsible for
returning an ESRP URI which is able to query the location.

Kind regards
Laura

---

From: "Richard L. Barnes" <[email-masked]>
Date: Fri, 13 Jul 2012 12:32:33 -0400

Hi Laura,

Thank you for this clarification.  It is very useful in helping to understand the problem.

I love your phrase "carrier LoST".  That seems to me to be the best solution here.  It is cheap to deploy (a very simple CGI script), and meets two important goals:
(1) Allowing ISPs to specify particular ESRPs, and
(2) Not requiring significant modifications to the end client interface.

This solution doesn't actually require any modification to ECRIT at all.  Clients are already required to support LoST discovery, so the carrier LoST server can send them to whatever ESRP the carrier desires.  

There's still a need for the LIS to provide *something*, though, so that clients don't say "I don't have any location, so I can't do LoST".  But DT's LIS, for example, could just return either a URI or <country>DE</country>, which doesn't seem like it would cost them anything.

So I'm a little puzzled as to why we're talking about protocol changes.

--Richard

---

From: Laura Liess <[email-masked]>
Date: Mon, 16 Jul 2012 14:24:12 +0200

Hi Richard,

please see inline.

> Thank you for this clarification.  It is very useful in helping to understand the problem.

[LL] There are two possible solutios described in Section 6. My
comments are restricted to the second approach  because this is the
model we follow in Germany.  Maybe there are countries where the first
approach is prefered.
> (2) Not requiring significant modifications to the end client interface.

[LL] Another aspect the German regulator brought up is he wants keep
the dependencies on functionalities which are outside his
country/jurisdiction as low as possible.
> So I'm a little puzzled as to why we're talking about protocol changes.

[LL] We need an extenssion to HELD, which enable us to return the ESRP URI.
Returning  <country>DE</country> would mean, if I understood correctly
your intention, that the VSP queries the DT LOST with
<country>DE</country>. DT has no intention to allow access to the
"carrier LOST" from the Internet. At least at the beginning, the
"carrier LOST" will be just the existing functionality doing the
mapping between the location and the ESRP,  accessed from the LIS via
already existing proprietary interface. There is no new LOST
implementation planed. I can imagine this existing functionality
evolving in time towards a real LOST when the emergency calling
scenarios become more general.  E.g. for emergency calling from a
distributed enterprise ( e.g. the local offices of a a bank) it makes
sense that the enterprise does not have its own LOST but the
enterprise LIS queries the DT LOST via the standardized LOST protocol,
but still the access to LOST will be restricted to DT customers.

Thanks a lot
Laura

---

From: Brian Rosen <[email-masked]>
Date: Mon, 16 Jul 2012 09:20:45 -0400

You could easily restrict your carrier LoST server to only serve DT customers.

Wouldn't that work?

You are asking for a change that would affect every endpoint (they would have to understand the ESRP return from a HELD query).  If there is a less drastic way of handling the problem, given that you admit you may evolve to something closer to the current model, would that be acceptable?

Your LoST return could even be nonsense, as long as the carrier LoST server recognized the nonsense.  I wouldn't recommend it, but it would work.

Brian

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Tue, 17 Jul 2012 13:00:53 +0200

> country/jurisdiction as low as possible.

This cannot possibly mean non-existent. For example, my understanding is that the German regulator is moving (at least in mobile) from a regime were there is no requirement to authenticate the calling device to one where there is a need. For a roaming user, that at least involves an out of country transaction. Given that this is to reduce the number of false calls, I assume it would apply to other technologies other than mobile.

Regards

Keith

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Laura Liess
> Sent: 16 July 2012 13:24
> To: Richard L. Barnes
> Cc: [email-masked]; [email-masked] Org
> > I love your phrase "carrier LoST".  That seems to me to be the best
> solution here.  It is cheap to deploy (a very simple CGI script),
> > and meets two important goals:
> > This solution doesn't actually require any modification to ECRIT at all.
> Clients are already required to support LoST discovery, so the carrier
> LoST server can send them to whatever ESRP the carrier desires.
> >
> > There's still a need for the LIS to provide *something*, though, so that
> clients don't say "I don't have any location, so I can't do LoST".  But
> DT's LIS, for example, could just return either a URI or
> <country>DE</country>, which doesn't seem like it would cost them anything.
> >
> in
> >>> I'm not sure I agree.  Doesn't the current conversation demonstrate
> that rough-loc doesn't solve the problem it was intended to solve?  I was

---

From: Laura Liess <[email-masked]>
Date: Tue, 17 Jul 2012 16:41:13 +0200

Hi Brian,

> You could easily restrict your carrier LoST server to only serve DT customers.
I am not sure I understand exactly the scenario you talk about. It
seems to me that you have in mind a  scenario where the end device
requires the location. This is not the case in the scenario I am
talking about, where the end device is not EC enabled and just
initiates an emergency call. This scenario is described in Figure 5 in
the draft. The ESRP URI is returned by LIS to the VSP, ot to the end
device.

I am aware that there are scenarios where this model does not work,
especialy in connection with emergency calls from the enterprises and
VPNs. Here the end device must query the LIS for the LbyR, otherwise
the EC does not work properly.  Also in this case, we could keep the
HELD query done by the end device unchanged (returning the LbyR)  and
the VSP to query the LIS for the ESRP URI (using extended HELD or
whatever protocol).

And if you mean restricting the carrier LOST queries to end devices of
DT customers: yes, this is possible. The reasons we prefer the LIS to
query the LOST are:

- The regulator very clearly requires to keep the functionalities and
interfaces for end devices and networlk elements outside his country
at a minimum. What if some guy is nomadic in the DT IP-network and our
LOST and the end device LOST are different versions and do not
interop? It was not just a call, but an emergency call ....  We do not
control the end devices and are not responsible if the guy dies. The
regulator wants us to be responsible, not the dead guy with his old
end device.

- DT does not intend to implement the standardised LOST in the first
stage. Today, we have one software component, for both. The
standardized LOST will come later (at least I hope so), and DT will
operate a real LOST server which is  queried its enterprise dcustomers
and smaler ISPs with their own LIS.

> You are asking for a change that would affect every endpoint (they would have to understand the ESRP return from a HELD query).  If there is a less drastic way of handling the problem, given that y…

[LL] I am not sure I understand exactly the scenario you talk about.
It seems to me that you have in mind a  scenario where the end device
requires the location. This is not the case in the scenario I am
talking about, where the end device is not EC enabled and just
initiates an emergency call. This scenario is described in Figure 5 in
the draft. The ESRP URI is returned by LIS to the VSP, ot to the end
device.

I am aware that there are scenarios where this model does not work,
especialy in connection with emergency calls from the enterprises and
VPNs. Here the end device must query the LIS for the LbyR, otherwise
the EC does not work properly.  Also in this case, we could keep the
HELD query done by the end device unchanged (returning the LbyR)  and
the VSP to query the LIS for the ESRP URI (using extended HELD or
whatever protocol).

And if you mean restricting the carrier LOST queries to end devices of
DT customers: yes, this is possible. The reasons we prefer the LIS to
query the LOST are:

- The regulator very clearly requires to keep the functionalities and
interfaces for end devices and networlk elements outside his country
at a minimum. What if some guy is nomadic in the DT IP-network and our
LOST and the end device LOST are different versions and do not
interop? It was not just a call, but an emergency call ....  We do not
control the end devices and are not responsible if the guy dies. For
DT this is OK; but the regulator wants us to be responsible, not the
dead guy with his old end device.

- DT does not intend to implement the standardised LOST in the first
stage. Today, we have one software component, for both. The
standardized LOST will come later (at least I hope so), and DT will
operate a real LOST server which is  queried its enterprise dcustomers
and smaler ISPs with their own LIS.

Thank you
Laura

---

From: Brian Rosen <[email-masked]>
Date: Tue, 17 Jul 2012 11:14:15 -0400

See inline

> the draft. The ESRP URI is returned by LIS to the VSP, ot to the end
You have a LIS, you are proposing to have a "carrier LoST server" of some sort at some stage.
You want a single LIS query that returns ESRP URI.   I'm suggesting you query LIS to get something from the LIS, query LoST with that something and get ESRP URI.  Two queries to two boxes that gets the same result instead of one query.

> the EC does not work properly.  
So the LIS has to return some form of location.  That's what I propose you do, just like the current model.  I'm suggesting that when a VSP does the query, it gets some location that routes properly, but is not the location of the caller.  It's the VSP doing the query, so we don't have a problem with obscuring for privacy, we only have a problem of theft of service by the VSP (if you actually worry about that), and the way around it is to have a single location per ESRP that is returned to the VSP by the LIS.

> Also in this case, we could keep the
And again I suggest this is dereference by VSP to the per-ESRP location and a LoST query.

> regulator wants us to be responsible, not the dead guy with his old
You are discussing new things (HELD).  If you admit to new things, HELD/LoST works fine.
This is not a backwards compatibility issue - old things don't do HELD queries.

Simple is in the eye of the beholder.  I want all devices to do exactly the same thing in all environments.  You query LIS, then you query LoST.   

> and smaler ISPs with their own LIS.
Today, you don't have HELD either.  This is all new stuff.  Do it right the first time is a good suggestion I think.

> the draft. The ESRP URI is returned by LIS to the VSP, ot to the end
If we change HELD so that it can return an ESRP URI, devices that implement HELD have to change to deal with the ESRP URI instead of location in the response.

So it's "every endpoint that implements HELD", so I don't include existing devices that don't query a LIS.
> the VSP to query the LIS for the ESRP URI (using extended HELD or
Or LoST :)
> at a minimum.
A worthy goal, but when you try to do that, you often make the whole thing more complicated because you don't cover all the cases with the "simple" approach.

> What if some guy is nomadic in the DT IP-network and our
> interop?
I'm trying to help you by asking that you follow -phonebcp, so we don't have the problem you are worried about.  If we implement -phonebcp in the U.S., what do you want to happen for a device roaming from US to Germany or Germany to US?

> It was not just a call, but an emergency call ....  We do not
Backwards compatibility with older devices is of course a problem we all have.  The basic approach is VSP query LIS and VSP query LoST when the device doesn't do it.  You seem to agree.  We're only dealing with the specifics of how that works.  I'd like the VSP to do a straight OBO query for location from the LIS using the IP address of the caller and get some form of location which, when used in a LoST query, returns the ESRP URI you want it to.  Combining LIS/LoST queries into one step is an optimization that I don't think is a good idea.  The VSP doesn't do a HELD query today.  Having the HELD query return ESRP URI is only an optimization  - the VSP needs new code, it has to implement HELD, and asking that it also implement LoST is not an undue burden.

> and smaler ISPs with their own LIS.
I don't understand why you are willing to implement a new HELD query but are not willing to implement a new LoST query.  They could be done in the same box if you want to.

Brian

---

From: Laura Liess <[email-masked]>
Date: Fri, 20 Jul 2012 14:58:28 +0200

Brian,

We already discussed the "two queries" alternative within DT and with
the regulator. There was no acceptance for it. Let me try to explain
why.

There is in Germany no obligation for end devices, for  enterprises,
for VSPs which do not have  an SLA with German carriers to support
emergency calls and no obligation for ISPs to interop with them for
emergency calls. More than that, VSPs and ISPs which must support
emergency calls are not allowed to rely on end device functionality.

DT has no advantage from providing more emergency calling functionalty
 than required by the regulator and every product manager is trying to
keep his costs as low as possible.

DT has today a server similar to a LIS. SIP-proxies query this server
with the IP-address and get a kind of location reference (a string)
and the PSAP URI. PSAPs can query the server with the location
referene (string) and get the  the LbyV. The query is HTTP with
proprietary xml-format. DT has to add some functionality to suport SIP
emergency calls when the ISP and VSP are different. The cost for the
implementation must be kept as low as possible. I see some chance to
replace the proprietary interface and  move to HELD if HELD supports
the functionality we have today. But I would not find any product
manager to pay the vendors for a second LOST query which is not
necessary at all, just to interwork with end devices.  Queries from
end devices are not even desirable. And the regulator sees that if we
have 2 queries to 2 boxes instead of 1 query to 1 box the risk  for
the emergency call to fail is higher.

Sorry for not having better news...Personally, I would like to see
emergency calls working worldwide, too, but unfortunately it's all
about money :-(.

Kind regards
Laura

---

From: "Winterbottom, James" <[email-masked]>
Date: Mon, 30 Jul 2012 09:51:02 +0800

Hi Richard,

If the LIS is returning a PSAP URI and a location URI, why does it need to return any location value at all?

It is important to note that the end-point in the scenarios we are talking about doesn't get location at all, because it breaks the requirements if it does.

Cheers
James

James Winterbottom
Global Product Manager
Commscope GeoLENs
IP Location Product Portfolio
Suite 1, Level 2, iC Enterprise 1
Innovation Campus, Squires Way
North Wollongong, NSW, 2500 Australia
Email: [email-masked]
Phone: +61-2-42-212938
Mobile: +61-447-773-560

www.commscope.com | www.commscopeblogs.com
 
> Richard L. Barnes
> Sent: Saturday, 14 July 2012 2:33 AM
> To: Laura Liess
> solution here.  It is cheap to deploy (a very simple CGI script), and
> meets two important goals:
> taking this thread as very late WGLC comments -- or early IETF LC comments
> :)
> >>

---

From: "Richard L. Barnes" <[email-masked]>
Date: Mon, 30 Jul 2012 00:22:04 -0700

The LIS provides a location value as a fail-safe, in case (for some reason) the endpoint fails to use the local LoST server.

And as Brian points out, there is no point in refusing to return any location at all.  It's a trivial amount of effort to provide it, and not providing it means that people will just get the same information elsewhere (Quova, RIPE, etc.), with less assurance as to its quality.  That's just spiteful.

--Richard