Subject: [Ecrit] Proposals 1 and 3 - summary of perspectives

From: "Dawson, Martin" <[email-masked]>
Date: Tue, 12 Jun 2007 09:08:01 -0500

For some reason this hasn't made it through moderation. Now I'm a list
subscriber, I'll try again...

It's a long weekend in Australia and winter has finally hit - with cold
wind and rain. What better time, then, to spend some time catching up
with the action on the ECRIT list. I only went back a couple of weeks;
obviously the main topic has been to do with the question of how to
define the "location hiding" capability. Mostly it's a debate about the
utility of option 1 and 3.

Having just read through all the postings and while they are fresh in my
mind, here is how I characterize the perspectives. First my summary of
the options...

*	Option 1 achieves location hiding, somewhat oxymoronically, by
providing location. Whether it's by reference to the local LoST facility
or by some internal knowledge, the LIS generates a coarse location which
it knows will result in a correct PSAP URI resolution if/when another
party makes a request to the LoST facility. This is provided in addition
to a location reference for subsequent accurate location requests from
the PSAP for dispatch etc.
*	Option 3 achieves location hiding by making the request to the
local LoST facility using the end points location and providing the PSAP
URI that the LoST service returns (in addition to a location reference)
so the call can be routed to that PSAP - whether directly from the
device or via a proxy/VSP.

Both suggestions are based on an assumption that a LIS, being associated
with the local jurisdiction, has enough local knowledge to identify the
correct LoST service for that jurisdiction or, at least in the case of
option 1, to determine what "coarse location" isn't too coarse.

Perspective 1 - articulated by a lot of people, Ted, Brian, Andy,...
etc. is that LoST needs to progress and get to a first release and
changes associated with this particular use case should be avoided for
now. I haven't seen anything in either proposal that does require a
change to LoST. In the one case either or both of the LIS and VSP/proxy
make LoST queries but neither options appears to *dictate* a specific
change to LoST.

Perspective 2 - articulated by, for example, James W and Barbara is that
the LIS operator should have the option of providing location or not - a
"coarse location" is still a location and location information to the
granularity of PSAP boundaries, for example, could still support a lot
of value-added services and be used for other than emergency services.

Perspective 3 - articulated by, for example, Andy and Laura is that,
when the end-point initiates a call through the VSP/proxy with a
pre-determined PSAP URI, the proxy may not know that this really is a
genuine emergency call destination. In fact it could be used to call
anyone by just pretending it's an emergency call. This means the VSP may
lose call revenue through the fraudulent nomination of emergency calls.

Perspective 4 - articulated by, in particular, Hannes (sorry Hannes, I
can't see anyone else emphasising this point) is that all emergency
calls should go through a VSP so that there's an authenticated
subscriber identity to be associated with the call. This seems like an
orthogonal point to me. If we accept that some calls will go through
VSPs and therefore Perspective 3 is valid then the question of whether
all emergency calls have to go through a VSP is moot. I have to admit to
being really surprised by the perspective - it wasn't one that I thought
had any currency in this forum.

There were miscellaneous other perspectives including some good
suggestions for alternatives/compromises from Richard and Henning.

Martin D's perspective -

*	On perspective 1, I don't see any impediment to pushing LoST
out. Even if there are changes to come, they can be done in a revision
or whatever. But I haven't seen any definitive statement about how
either option *requires* a change to LoST.
*	On perspective 4, I don't think it's decisive in the discussion.
*	So, really, it boils down to an evaluation of which of
perspectives 2 and 3 are the most valid - i.e. are the interests of the
LIS operator or a VSP to have priority.

I don't understand why the interests of LIS operators and VSPs can't
both be served. I'm surprised that with all the experience and knowledge
in the forum that nobody can provide a practical way for a proxy/VSP to
determine whether a PSAP URI is a valid emergency destination or not. I
know that adding the reverse-lookup to LoST has been discussed. That
would be effective, but it's not in keeping with perspective 1. Surely,
though, there are alternatives.

I think option 3 supports a faster and smoother deployment of global
emergency calling for VoIP. Here's my rationale.

1.	Both options require a LoST and LIS capability to exist at a
local and jurisdictional level - so their availability is a premise in
either proposal
2.	Option 1 assumes that each VSP can make an effective LoST query
even if it is a "non-local" VSP to the point from where the call is
being originated. This is either by the VSP automatically knowing which
LoST server is applicable to the coarse location or by the use of the so
called forest guide and perhaps some international hierarchy of
interconnected LoST servers.
3.	Option 3 only assumes that this local knowledge is in the local
LIS function and doesn't rely on the existence of the infrastructure
described in point 2.
4.	The ability to verify a destination PSAP URI as a valid
emergency URI could be supported by reference to a relatively static
table maintained by global cooperation. In fact, I would have thought
that filtering based on domain name would be extremely reliable and
fast. It would certainly obviate the ability to make arbitrary calls by
pretending they are emergency calls.
5.	Perhaps a later revision of LoST can include the reverse-lookup
mechanism and, perhaps by then, the international infrastructure of LoST
servers, forest guides, etc. may be in place.

I mention point 4 as one possible way to protect the interest of the
VSPs without requiring a change to the current LoST definition. Are
there any other proposals on how to achieve this or, alternatively, a
view that it simply isn't possible?

Cheers,

Martin

 Martin Dawson

Andrew Network Solutions Asia-Pacific

Email: [email-masked]

Phone: +61 2 42212992

Fax: +61 2 42212901

Mobile: +61 412 120300

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.

------------------------------------------------------------------------------------------------
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]
_______________________________________________
Ecrit mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ecrit

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 12 Jun 2007 10:17:37 -0400

I think those of us pushing for Option 1 for now is that we think VSP
validation is a fact of life we have to deal with, waving hands over
"reference to a relatively static table maintained by global cooperation" is
not adequate, and something like a reverse lookup is required.  This would
be a change to LoST and we are reluctant to take this change on at this
time.

Brian

  _____  

From: Dawson, Martin [mailto:[email-masked]] 
Sent: Tuesday, June 12, 2007 10:08 AM
To: [email-masked]
Subject: [Ecrit] Proposals 1 and 3 - summary of perspectives

For some reason this hasn't made it through moderation. Now I'm a list
subscriber, I'll try again.

It's a long weekend in Australia and winter has finally hit - with cold wind
and rain. What better time, then, to spend some time catching up with the
action on the ECRIT list. I only went back a couple of weeks; obviously the
main topic has been to do with the question of how to define the "location
hiding" capability. Mostly it's a debate about the utility of option 1 and
3.

Having just read through all the postings and while they are fresh in my
mind, here is how I characterize the perspectives. First my summary of the
options.

*	Option 1 achieves location hiding, somewhat oxymoronically, by
providing location. Whether it's by reference to the local LoST facility or
by some internal knowledge, the LIS generates a coarse location which it
knows will result in a correct PSAP URI resolution if/when another party
makes a request to the LoST facility. This is provided in addition to a
location reference for subsequent accurate location requests from the PSAP
for dispatch etc.
*	Option 3 achieves location hiding by making the request to the local
LoST facility using the end points location and providing the PSAP URI that
the LoST service returns (in addition to a location reference) so the call
can be routed to that PSAP - whether directly from the device or via a
proxy/VSP.

Perspective 1 - articulated by a lot of people, Ted, Brian, Andy,. etc. is
that LoST needs to progress and get to a first release and changes
associated with this particular use case should be avoided for now. I
haven't seen anything in either proposal that does require a change to LoST.
In the one case either or both of the LIS and VSP/proxy make LoST queries
but neither options appears to *dictate* a specific change to LoST.

Perspective 2 - articulated by, for example, James W and Barbara is that the
LIS operator should have the option of providing location or not - a "coarse
location" is still a location and location information to the granularity of
PSAP boundaries, for example, could still support a lot of value-added
services and be used for other than emergency services.

Perspective 3 - articulated by, for example, Andy and Laura is that, when
the end-point initiates a call through the VSP/proxy with a pre-determined
PSAP URI, the proxy may not know that this really is a genuine emergency
call destination. In fact it could be used to call anyone by just pretending
it's an emergency call. This means the VSP may lose call revenue through the
fraudulent nomination of emergency calls.

Perspective 4 - articulated by, in particular, Hannes (sorry Hannes, I can't
see anyone else emphasising this point) is that all emergency calls should
go through a VSP so that there's an authenticated subscriber identity to be
associated with the call. This seems like an orthogonal point to me. If we
accept that some calls will go through VSPs and therefore Perspective 3 is
valid then the question of whether all emergency calls have to go through a
VSP is moot. I have to admit to being really surprised by the perspective -
it wasn't one that I thought had any currency in this forum.

There were miscellaneous other perspectives including some good suggestions
for alternatives/compromises from Richard and Henning.

Martin D's perspective -

*	On perspective 1, I don't see any impediment to pushing LoST out.
Even if there are changes to come, they can be done in a revision or
whatever. But I haven't seen any definitive statement about how either
option *requires* a change to LoST.
*	On perspective 4, I don't think it's decisive in the discussion.
*	So, really, it boils down to an evaluation of which of perspectives
2 and 3 are the most valid - i.e. are the interests of the LIS operator or a
VSP to have priority.

I don't understand why the interests of LIS operators and VSPs can't both be
served. I'm surprised that with all the experience and knowledge in the
forum that nobody can provide a practical way for a proxy/VSP to determine
whether a PSAP URI is a valid emergency destination or not. I know that
adding the reverse-lookup to LoST has been discussed. That would be
effective, but it's not in keeping with perspective 1. Surely, though, there
are alternatives.

1.	Both options require a LoST and LIS capability to exist at a local
and jurisdictional level - so their availability is a premise in either
proposal
2.	Option 1 assumes that each VSP can make an effective LoST query even
if it is a "non-local" VSP to the point from where the call is being
originated. This is either by the VSP automatically knowing which LoST
server is applicable to the coarse location or by the use of the so called
forest guide and perhaps some international hierarchy of interconnected LoST
servers.
3.	Option 3 only assumes that this local knowledge is in the local LIS
function and doesn't rely on the existence of the infrastructure described
in point 2.
4.	The ability to verify a destination PSAP URI as a valid emergency
URI could be supported by reference to a relatively static table maintained
by global cooperation. In fact, I would have thought that filtering based on
domain name would be extremely reliable and fast. It would certainly obviate
the ability to make arbitrary calls by pretending they are emergency calls.
5.	Perhaps a later revision of LoST can include the reverse-lookup
mechanism and, perhaps by then, the international infrastructure of LoST
servers, forest guides, etc. may be in place.

I mention point 4 as one possible way to protect the interest of the VSPs
without requiring a change to the current LoST definition. Are there any
other proposals on how to achieve this or, alternatively, a view that it
simply isn't possible?

Cheers,

Martin

Martin Dawson

Phone: +61 2 42212992

Fax: +61 2 42212901

Mobile: +61 412 120300

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: "Dawson, Martin" <[email-masked]>
Date: Tue, 12 Jun 2007 16:18:45 -0500

Well hand waving was about all I could invest in an email, but are you
saying you'd just have to give up at that stage? What is a reference to
a "forest guide", if it's not a particularly low-detail suggestion of
the sort of thing we need to resolve the right LoST server? Yet, without
that, option 1 doesn't work. Why wouldn't this "validation" be a
function of that system and why is reverse lookup the only option?

Cheers,

Martin

________________________________

From: Brian Rosen [mailto:[email-masked]] 
Sent: Wednesday, 13 June 2007 12:18 AM
To: Dawson, Martin; [email-masked]
Subject: RE: [Ecrit] Proposals 1 and 3 - summary of perspectives

I think those of us pushing for Option 1 for now is that we think VSP
validation is a fact of life we have to deal with, waving hands over
"reference to a relatively static table maintained by global
cooperation" is not adequate, and something like a reverse lookup is
required.  This would be a change to LoST and we are reluctant to take
this change on at this time.

Brian

________________________________

 

Martin D's perspective -

Cheers,

Martin

 Martin Dawson

Phone: +61 2 42212992

Fax: +61 2 42212901

Mobile: +61 412 120300

 

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

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 12 Jun 2007 20:27:39 -0400

I'm sorry but the forest guide idea is a whole lot more developed that any
notion of an authoritative list of PSAP URIs.  I'm not saying it can't be
done, I'm saying we need a whole lot more work on it to make it real, and
it's not at all clear to me that the reverse lookup idea has more or less
merit.  However, both of them are beyond what I think is appropriate for
LoST at this point.

Brian

  _____  

From: Dawson, Martin [mailto:[email-masked]] 
Sent: Tuesday, June 12, 2007 5:19 PM
To: Brian Rosen; [email-masked]
Subject: RE: [Ecrit] Proposals 1 and 3 - summary of perspectives

Well hand waving was about all I could invest in an email, but are you
saying you'd just have to give up at that stage? What is a reference to a
"forest guide", if it's not a particularly low-detail suggestion of the sort
of thing we need to resolve the right LoST server? Yet, without that, option
1 doesn't work. Why wouldn't this "validation" be a function of that system
and why is reverse lookup the only option?

Cheers,

Martin

  _____  

Brian

  _____  

 

Martin D's perspective -

Cheers,

Martin

Martin Dawson

Phone: +61 2 42212992

Fax: +61 2 42212901

Mobile: +61 412 120300

---

From: "Dawson, Martin" <[email-masked]>
Date: Wed, 13 Jun 2007 02:37:59 -0500

I wasn't suggesting they were an identical level of definition. I was
saying that it's still not definitive solution; of course it's a matter
of degree. Without a definitive forest guide solution, how does a VSP
know how to find the right LoST server to find the PSAP URI? At least
with option 3, the PSAP URI is provided at the point of local knowledge
where the applicable LoST server is known.

Pull your last comment apart for me... are you saying that the "forest
guide" implementation requires changes to LoST? Without those changes,
the Forest Guide won't work either?

Cheers,

Martin

From: Brian Rosen [mailto:[email-masked]] 
Sent: Wednesday, 13 June 2007 10:28 AM
To: Dawson, Martin; [email-masked]
Subject: RE: [Ecrit] Proposals 1 and 3 - summary of perspectives

I'm sorry but the forest guide idea is a whole lot more developed that
any notion of an authoritative list of PSAP URIs.  I'm not saying it
can't be done, I'm saying we need a whole lot more work on it to make it
real, and it's not at all clear to me that the reverse lookup idea has
more or less merit.  However, both of them are beyond what I think is
appropriate for LoST at this point.

Brian

Cheers,

Martin

Brian

 

Martin D's perspective -

Cheers,

Martin

 Martin Dawson

Phone: +61 2 42212992

Fax: +61 2 42212901

Mobile: +61 412 120300

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 13 Jun 2007 08:30:46 -0400

I don't see any changes needed in LoST for forest guides.  

Brian

  _____  

From: Dawson, Martin [mailto:[email-masked]] 
Sent: Wednesday, June 13, 2007 3:38 AM
To: Brian Rosen; [email-masked]
Subject: RE: [Ecrit] Proposals 1 and 3 - summary of perspectives

I wasn't suggesting they were an identical level of definition. I was saying
that it's still not definitive solution; of course it's a matter of degree.
Without a definitive forest guide solution, how does a VSP know how to find
the right LoST server to find the PSAP URI? At least with option 3, the PSAP
URI is provided at the point of local knowledge where the applicable LoST
server is known.

Pull your last comment apart for me. are you saying that the "forest guide"
implementation requires changes to LoST? Without those changes, the Forest
Guide won't work either?

Cheers,

Martin

  _____  

Brian

  _____  

Cheers,

Martin

  _____  

Brian

  _____  

 

Martin D's perspective -

Cheers,

Martin

Martin Dawson

Phone: +61 2 42212992

Fax: +61 2 42212901

Mobile: +61 412 120300

---

From: "Dawson, Martin" <[email-masked]>
Date: Wed, 13 Jun 2007 07:37:01 -0500

OK, well neither did I. I didn't understand where the proposition of
"both" came in with respect to LoST. I only know of reverse-lookup as
being discussed as a potential LoST function.

I am suggesting that, as yet another possibility and in the spirit of
not just giving up (and saying, we've looked after VSP operator
interests but we won't worry about the LIS operators so much) is that
validating a PSAP URI could also be a forest guide function.

Cheers,

Martin

From: Brian Rosen [mailto:[email-masked]] 
Sent: Wednesday, 13 June 2007 10:31 PM
To: Dawson, Martin; [email-masked]
Subject: RE: [Ecrit] Proposals 1 and 3 - summary of perspectives

Brian

Cheers,

Martin

Brian

Cheers,

Martin

Brian

 

Martin D's perspective -

Cheers,

Martin

 Martin Dawson

Phone: +61 2 42212992

Fax: +61 2 42212901

Mobile: +61 412 120300

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 13 Jun 2007 09:55:27 -0400

I don't understand how this would work.  The forest guide thing doesn't need
any more protocol function than we have already.  There is no function I
know of in LoST that would accept a URI as a query and return anything
resembling or computable to a Boolean (valid) in response.  That's some kind
of protocol mechanism.  Whether the implementation of that is reverse lookup
or flooding or some other mechanism would have to be invented, and using
some of the forest guide ideas may work, but it's quite a stretch from where
we are now, and needs a new protocol mechanism of some sort.

We can do that, but later, please.

Brian

  _____  

From: Dawson, Martin [mailto:[email-masked]] 
Sent: Wednesday, June 13, 2007 8:37 AM
To: Brian Rosen; [email-masked]
Subject: RE: [Ecrit] Proposals 1 and 3 - summary of perspectives

OK, well neither did I. I didn't understand where the proposition of "both"
came in with respect to LoST. I only know of reverse-lookup as being
discussed as a potential LoST function.

I am suggesting that, as yet another possibility and in the spirit of not
just giving up (and saying, we've looked after VSP operator interests but we
won't worry about the LIS operators so much) is that validating a PSAP URI
could also be a forest guide function.

Cheers,

Martin

  _____  

Brian

  _____  

Cheers,

Martin

  _____  

Brian

  _____  

Cheers,

Martin

  _____  

Brian

  _____  

 

Martin D's perspective -

Cheers,

Martin

Martin Dawson

Phone: +61 2 42212992

Fax: +61 2 42212901

Mobile: +61 412 120300

---

From: "Dawson, Martin" <[email-masked]>
Date: Wed, 13 Jun 2007 09:06:33 -0500

I understood that "later please" was a request with respect to LoST...
which is why I'm avoiding it.

Option 1, as I understand it, can't work at all until the forest guide
definitions are completed and, in fact, until the actual forest guide
system/network is *implemented*. So I'm suggesting that the URI
validation be added to the, still in development, forest guide
specification.

In the mean time, option 3 works regardless and, as the URI validation
becomes available through the forest guide network, then the issue of
"pretend" emergency calls is obviated as well.

Cheers,

Martin

From: Brian Rosen [mailto:[email-masked]] 
Sent: Wednesday, 13 June 2007 11:55 PM
To: Dawson, Martin; [email-masked]
Subject: RE: [Ecrit] Proposals 1 and 3 - summary of perspectives

I don't understand how this would work.  The forest guide thing doesn't
need any more protocol function than we have already.  There is no
function I know of in LoST that would accept a URI as a query and return
anything resembling or computable to a Boolean (valid) in response.
That's some kind of protocol mechanism.  Whether the implementation of
that is reverse lookup or flooding or some other mechanism would have to
be invented, and using some of the forest guide ideas may work, but it's
quite a stretch from where we are now, and needs a new protocol
mechanism of some sort.

Brian

Cheers,

Martin

Brian

Cheers,

Martin

Brian

Cheers,

Martin

Brian

 

Martin D's perspective -

Cheers,

Martin

 Martin Dawson

Phone: +61 2 42212992

Fax: +61 2 42212901

Mobile: +61 412 120300

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 13 Jun 2007 10:18:56 -0400

Hello?

Even if we were to include URI validation as one of the forest guide's
tasks, which I'm not sure is the right way, that isn't enough; we need a
protocol mechanism to implement it.  THAT is what I want to defer, at least
for now.

I also don't want that problem delaying development of forest guides.  

Brian

  _____  

From: Dawson, Martin [mailto:[email-masked]] 
Sent: Wednesday, June 13, 2007 10:07 AM
To: Brian Rosen; [email-masked]
Subject: RE: [Ecrit] Proposals 1 and 3 - summary of perspectives

I understood that "later please" was a request with respect to LoST. which
is why I'm avoiding it.

Option 1, as I understand it, can't work at all until the forest guide
definitions are completed and, in fact, until the actual forest guide
system/network is *implemented*. So I'm suggesting that the URI validation
be added to the, still in development, forest guide specification.

Cheers,

Martin

  _____  

Brian

  _____  

Cheers,

Martin

  _____  

Brian

  _____  

Cheers,

Martin

  _____  

Brian

  _____  

Cheers,

Martin

  _____  

Brian

  _____  

 

Martin D's perspective -

Cheers,

Martin

Martin Dawson

Phone: +61 2 42212992

Fax: +61 2 42212901

Mobile: +61 412 120300

---

From: "Dawson, Martin" <[email-masked]>
Date: Wed, 13 Jun 2007 09:24:19 -0500

So that would be to say that

i)                     We can't change LoST

ii)                   We can't change the forest guide (even though it's
not done yet)

iii)                  We can't change anything that means that a VSP
would have a way to verify a URI?

I'm pretty sure we could define a "here's a URI, provide a Boolean
response" protocol element without a significant delay. So this seems
like a contrived obstruction...

Cheers,

Martin

From: Brian Rosen [mailto:[email-masked]] 
Sent: Thursday, 14 June 2007 12:19 AM
To: Dawson, Martin; [email-masked]
Subject: RE: [Ecrit] Proposals 1 and 3 - summary of perspectives

Hello?

Even if we were to include URI validation as one of the forest guide's
tasks, which I'm not sure is the right way, that isn't enough; we need a
protocol mechanism to implement it.  THAT is what I want to defer, at
least for now.

Brian

Cheers,

Martin

Brian

Cheers,

Martin

Brian

Cheers,

Martin

Brian

Cheers,

Martin

Brian

 

Martin D's perspective -

Cheers,

Martin

 Martin Dawson

Phone: +61 2 42212992

Fax: +61 2 42212901

Mobile: +61 412 120300

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 13 Jun 2007 10:29:41 -0400

This will be my last message on this particular thread, I don't think we're
getting anywhere.

I don't want to extend the development of LoST to add this feature.  I agree
with Andy: Option #1 is good enough FOR NOW, and we can work on other
options later.

Brian

  _____  

From: Dawson, Martin [mailto:[email-masked]] 
Sent: Wednesday, June 13, 2007 10:24 AM
To: Brian Rosen; [email-masked]
Subject: RE: [Ecrit] Proposals 1 and 3 - summary of perspectives

i)                 We can't change LoST

ii)                We can't change the forest guide (even though it's not
done yet)

iii)              We can't change anything that means that a VSP would have
a way to verify a URI?

I'm pretty sure we could define a "here's a URI, provide a Boolean response"
protocol element without a significant delay. So this seems like a contrived
obstruction.

Cheers,

Martin

  _____  

Hello?

Brian

  _____  

Cheers,

Martin

  _____  

Brian

  _____  

Cheers,

Martin

  _____  

Brian

  _____  

Cheers,

Martin

  _____  

Brian

  _____  

Cheers,

Martin

  _____  

Brian

  _____  

 

Martin D's perspective -

Cheers,

Martin

Martin Dawson

Phone: +61 2 42212992

Fax: +61 2 42212901

Mobile: +61 412 120300

---

From: "Dawson, Martin" <[email-masked]>
Date: Wed, 13 Jun 2007 09:54:10 -0500

Nobody has suggested changing LoST so this point is just a distraction.

Option 1 means that emergency calls will not be able to be routed until
the forest guide network is implemented. Option 3 means that emergency
calls will be able to be routed regardless of the state of deployment of
the forest guide.

I'm of the opinion that option 3 is good enough for now and option 1 is
not good enough for now and, in fact, that's true regardless of a desire
to provide location hiding or not.

Cheers,

Martin

From: Brian Rosen [mailto:[email-masked]] 
Sent: Thursday, 14 June 2007 12:30 AM
To: Dawson, Martin; [email-masked]
Subject: RE: [Ecrit] Proposals 1 and 3 - summary of perspectives

This will be my last message on this particular thread, I don't think
we're getting anywhere.

I don't want to extend the development of LoST to add this feature.  I
agree with Andy: Option #1 is good enough FOR NOW, and we can work on
other options later.

Brian

i)                 We can't change LoST

iii)              We can't change anything that means that a VSP would
have a way to verify a URI?

Cheers,

Martin

Hello?

Brian

Cheers,

Martin

Brian

Cheers,

Martin

Brian

Cheers,

Martin

Brian

Cheers,

Martin

Brian

 

Martin D's perspective -

Cheers,

Martin

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 13 Jun 2007 10:57:59 -0400

On Jun 13, 2007, at 10:54 AM, Dawson, Martin wrote:

> Option 1 means that emergency calls will not be able to be routed  
> until the forest guide network is implemented. Option 3 means that  
> emergency calls will be able to be routed regardless of the state  
> of deployment of the forest guide.
>
>
This is not true, at least for comparable installations. The ISP can  
offer a LoST server that has the locally-relevant information. Same  
for the VSP. This does not require a forest guide as such.

---

From: "Dawson, Martin" <[email-masked]>
Date: Wed, 13 Jun 2007 10:28:10 -0500

The ISP could... but that's the essence of Option 3; the LIS knows what
the local LoST server is because it is always local. It can get the PSAP
URI directly from that LoST server to provide to the device.

However a VSP in a completely different country from where the call is
originated can't inherently know which is the correct LoST server to go
to and query for the PSAP URI - which is the essence of option 1. Hence
the call can't be routed.

"Comparable" installations, viz degree of "localness", aren't the
interesting case. With global VoIP operators - which are quite common -
this is not a scenario that can be ignored.

Cheers,
Martin

---

From: "Stark, Barbara" <[email-masked]>
Date: Wed, 13 Jun 2007 13:07:59 -0400

Just to be clear, I was never suggesting that the list of PSAP URIs be
global. I really don't care if a VSP in Sierra Leone bills for 9-1-1
calls it has to process that go to US PSAPs. There is absolutely nothing
that says the Sierra Leone VSP can't bill for that, unless Sierra Leone
signs a treaty with the US and requires its VSPs to not bill. There's
also nothing that requires the Sierra Leone VSP to route unauthenticated
calls that claim to be "sos" and that want to be routed to a US PSAP
(but the VSP doesn't know it's a PSAP). The only PSAP URIs that the
Sierra Leone VSP is probably required to know about, are the ones in
Sierra Leone.
 
The only rules (billing, handling of unauthenticated calls) that exist
are for VSPs within the same regulatory region as the PSAP. 
Barbara

From: Brian Rosen [mailto:[email-masked]] 
Sent: Tuesday, June 12, 2007 8:28 PM
To: 'Dawson, Martin'; [email-masked]
Subject: RE: [Ecrit] Proposals 1 and 3 - summary of perspectives

Brian

Cheers,

Martin

Brian

 

Martin D's perspective -

Cheers,

Martin

 Martin Dawson

Phone: +61 2 42212992

Fax: +61 2 42212901

Mobile: +61 412 120300

 

 

*****

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: "Winterbottom, James" <[email-masked]>
Date: Wed, 13 Jun 2007 19:00:30 -0500

Henning,

I think that your proposal only works if the VSP is able to provide a
LoST server for all jurisdictions that it plans to provide service for,
or it has to do it for everything (sounds awfully like a global VPC to
me). Option 3 would be deployable from a local area to a local PSAP
REGARDLESS of the VSP having a LoST server that has boundary information
for the local area I am in. It provides a global solution from the
get-go.

Let's take the good old Sierra-Leone example again.

My VSP is in Sierra-Leone and I am visiting Samoa. In option 3, I get a
PSA P URI for the local Samoan PSAP from the local access LIS serving
the area I am in, I send my call to VSP, it sends it on the PSAP. I get
billed, call completes, we are done. I can quibble with my VSP later
over the 10 cent call charge if I can be bothered.

With option 1, I send my call with location to my VSP, and one of three
things happens. Either it has a complete forest guide network set-up to
be able to talk to the Samoan LoST server nearest me, my call fails, or
the VSP routes the call anyway because the end-point has done the LoST
lookup. I point out, that from the VSP perspective the third alternative
here is simply option 3 re-badged. I am sure that VSPs wouldn't drop the
call on the floor, so choice 2 isn't an option, and choice 1 can ONLY
occur if the whole network is up and running, and it doesn't consist of
isolated copse of Forest Guides and LoST Servers.

So to my mind, option 3 is the ONLY deployable solution in the short
term that will actually work universally.

Cheers
James

> Cc: [email-masked]

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 13 Jun 2007 20:21:34 -0400

I assume that your discussion has nothing to do with location hiding  
at this point, but wanted to call this out just in case I'm missing  
your train of thought.

I'm afraid I don't follow your logic. Unless you assume that every  
ISP deploys a LoST+HELD server, VSPs will have to have LoST servers  
with PSAP knowledge for the places their customers are likely to  
visit. This doesn't change whether HELD also gets converted into a  
LoST access protocol or not. So far, at least, VSPs seem a whole lot  
more interested in providing emergency call services than ISPs,  
presumably because their customers look to them for that service, not  
to the random hot spot operator.

It's always been the model that both ISPs and VSPs (as well as third  
parties that are neither) can and should operate LoST servers, as  
that seems most likely to ensure that you get broad coverage.

Henning

---

From: "Winterbottom, James" <[email-masked]>
Date: Wed, 13 Jun 2007 19:44:21 -0500

You are not too far off the mark, option 3 not only provides location
hiding but provides a mechanism for enabling this service regardless of
core infrastructure does.

Much of the debate over option 1 versus option 3 is purely one of
billing. Option 1 puts most, if not all the cost back on the location
provider, option 3 puts the risk on the VSP that they can't charge
per-call.

The first thing is that I don't think that the LoST and HELD servers
need to be run by the same operator as you suggest below. The thing that
does need to be in place is for the HELD server to have access to a LoST
server, these two things are not the same. That aside, I believe that if
we provided an extension to HELD that supported option 3, that most
location providers would deploy it initially. This is because the onus
is on the access providers to provide location and this is where the
initial cost is all going to be incurred. The VSP has, to some extent a
choice as to whether it incurs costs in any of this, the access provider
does not.

Cheers
James 

> Sent: Thursday, 14 June 2007 10:22 AM
> To: Winterbottom, James
> Cc: ECRIT
----------------------------------------------------------------------
> > --------------------------
----------------------------------------------------------------------
> > --------------------------
> > [mf2]
> >
>

---

From: "Dawson, Martin" <[email-masked]>
Date: Wed, 13 Jun 2007 20:14:18 -0500

BTW - as I understand option 1, it requires the LIS to query the local
LoST server as well. At least that's how I recall Brian's original
proposal being stated. It returns a "PSAP URI boundary" location instead
of the PSAP URI.

I think folk are being inconsistent characterising option 3 as adding
LoST functionality to HELD. Both proposals require the LIS to interact
with LoST with the subsequent proxying of results to the device.

If the proposition of option 1 is that it's actually the LIS that holds
the PSAP-relevant boundary information, then option 1 is actually much
more like adding LoST functionality to the LIS (and adds inappropriate
responsibility to the LIS provider).

Further, given my understanding, both proposals rely on the LIS knowing
inherently what the appropriate local LoST server is. Option 1 just
means that this is required *as well as* the VSP being able to reach
that same local LoST service.

Neither option requires the ISP to implement LoST, they just require the
ISP to know which LoST server is applicable to the local area of
coverage. That's much more practical than expecting any arbitrary global
VSP being able to work that out but that is what option 3 requires *in
addition*.

Cheers,
Martin

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]] 
Sent: Thursday, 14 June 2007 10:22 AM
To: Winterbottom, James
Cc: ECRIT
Subject: Re: [Ecrit] Proposals 1 and 3 - summary of perspectives

Henning

---

From: "Dawson, Martin" <[email-masked]>
Date: Wed, 13 Jun 2007 21:55:51 -0500

Typo alert - obviously it should have said that option *1* requires the
VSP to work out the local LoST server in addition to the LIS needing to
know it.

Cheers,
Martin

-----Original Message-----
From: Dawson, Martin [mailto:[email-masked]] 
Sent: Thursday, 14 June 2007 11:14 AM
To: Henning Schulzrinne; Winterbottom, James
Cc: ECRIT
Subject: RE: [Ecrit] Proposals 1 and 3 - summary of perspectives

Cheers,
Martin

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]] 
Sent: Thursday, 14 June 2007 10:22 AM
To: Winterbottom, James
Cc: ECRIT
Subject: Re: [Ecrit] Proposals 1 and 3 - summary of perspectives

Henning

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 14 Jun 2007 09:06:51 -0400

Wait a minute, we're getting confused.

Option 1 requires that the access network dereference to anyone with at
least coarse location suitable for emergency call routing.  If the endpoint
does routing, it will use a local LoST server which has high probability of
having the route.  If a VSP wants to verify, it needs access to a LoST
server covering the area where his customers roam.  The cost is on the
carrier that is trying to hide location (which, AFAIK, is an economic issue
all the way, the hiding is so the access network can charge for non
emergency uses of location).

Option 3 requires that the access network dereference to anyone with at
least coarse location suitable for emergency call routing.  This is because
if the endpoint doesn't route (or more specifically, if it doesn't recognize
emergency dialstrings, query LoST, and add the PSAP URI), but does supply
location, then the VSP has to route, and it will have to dereference.  If
the endpoint does routing, option 3 is easy, because it will have the
correct PSAP URIs (it has to be all of them, BTW, a problem in itself).  If
a VSP wants to verify, it needs access to a LoST server covering the area
where his customers roam.  It can't use the LCP, it has to dereference the
location, and then query LoST.  

If we supply a different mechanism for a VSP to validate, that could change,
and it would affect 1 and 3 the same way.

Brian

> Sent: Wednesday, June 13, 2007 10:56 PM
> To: ECRIT

---

From: "Stark, Barbara" <[email-masked]>
Date: Thu, 14 Jun 2007 09:09:49 -0400

No, VSPs only "have to have" knowledge of LoST servers for PSAPs within
the regional boundaries of their stated area of operations. A VSP that
claims to serve only the US, only sells to people with US addresses, and
only provides US phone numbers (if interaction with the PSTN is
provided), does not have to have knowledge of European or Australian
PSAPs. The fact that many people in Europe and Australia use such
services does not present a requirement on such services. 

And VSPs weren't particularly interested in providing emergency call
service until some got bad press and then the government stepped in and
required it. Since ISPs don't get bad press today (for not being
involved in support of emergency services), the government hasn't
required such involvement, and it's going to cost a whole lot, you're
right in that ISPs aren't interested. 

Interest and willingness to deploy result from one of two things: (1)
positive business case, or (2) regulation. In the absence of positive
business cases, who sets up LoST servers will largely be a question of
whether the government provides LoST servers (usually by contracting
certain companies to do it), or the government requires certain
companies (e.g., all VSPs, VSPs with over x number of customers, all
ISPs, ISPs with over x number of customers) to provide LoST servers. 

By the way, I agree that we need no further work in LoST for Location
Hiding. The question of whether a LCP may also include the LoST
information in the info it sends a device is a geopriv question. Unless
I really misunderstand how IETF works, just because ecrit doesn't
include mention of or support for this option in its emergency services
architecture, doesn't mean that the option can't exist within a LCP for
other purposes. But that's a topic for geopriv (I hope).
Barbara

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]] 
Sent: Wednesday, June 13, 2007 8:22 PM
To: Winterbottom, James
Cc: ECRIT
Subject: Re: [Ecrit] Proposals 1 and 3 - summary of perspectives

I assume that your discussion has nothing to do with location hiding at
this point, but wanted to call this out just in case I'm missing your
train of thought.

I'm afraid I don't follow your logic. Unless you assume that every ISP
deploys a LoST+HELD server, VSPs will have to have LoST servers with
PSAP knowledge for the places their customers are likely to visit. This
doesn't change whether HELD also gets converted into a LoST access
protocol or not. So far, at least, VSPs seem a whole lot more interested
in providing emergency call services than ISPs, presumably because their
customers look to them for that service, not to the random hot spot
operator.

It's always been the model that both ISPs and VSPs (as well as third
parties that are neither) can and should operate LoST servers, as that
seems most likely to ensure that you get broad coverage.

Henning

On Jun 13, 2007, at 8:00 PM, Winterbottom, James wrote:

> LoST server for all jurisdictions that it plans to provide service 
> for, or it has to do it for everything (sounds awfully like a global 
> VPC to me). Option 3 would be deployable from a local area to a local 
> PSAP REGARDLESS of the VSP having a LoST server that has boundary 
> information for the local area I am in. It provides a global solution 
> from the get-go.
>
> My VSP is in Sierra-Leone and I am visiting Samoa. In option 3, I get 
> a PSA P URI for the local Samoan PSAP from the local access LIS 
> serving the area I am in, I send my call to VSP, it sends it on the 
> PSAP. I get billed, call completes, we are done. I can quibble with my

> VSP later over the 10 cent call charge if I can be bothered.
>
> With option 1, I send my call with location to my VSP, and one of 
> three things happens. Either it has a complete forest guide network 
> set- up to be able to talk to the Samoan LoST server nearest me, my 
> call fails, or the VSP routes the call anyway because the end-point 
> has done the LoST lookup. I point out, that from the VSP perspective 
> the third alternative here is simply option 3 re-badged. I am sure 
> that VSPs wouldn't drop the call on the floor, so choice 2 isn't an 
> option, and choice 1 can ONLY occur if the whole network is up and 
> running, and it doesn't consist of isolated copse of Forest Guides and

> LoST Servers.
>>> emergency calls will be able to be routed regardless of the state of

>>> deployment of the forest guide.
>>>
>>>
> 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.

---

From: Andrew Newton <[email-masked]>
Date: Thu, 14 Jun 2007 13:00:36 -0400

> services does not present a requirement on such services.

You've over generalized here.  There are VSPs that cover more than  
one country.

> required it.

And again, you've over generalized.  Some VSPs have offered emergency  
call service since day 1 of operation.  Some continue to offer it to  
customers in bad standing.

And the notion that VSPs are entities that solely retail services is  
incorrect.  Some very, very large VSPs are the IT departments of  
large, multi-national corporations and non-profits.

-andy

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 14 Jun 2007 17:14:12 -0400

Just to add a small note to Andy's comments: Rather than guessing  
what regulators may or may not require or what VSP (or ISPs) will try  
to get away with, I think it is more productive to make it possible  
for all parties to do the right thing, which presumably includes the  
ability for VSPs to serve their traveling customers. After all, even  
if looked at from a purely monetary perspective, a traveling customer  
that can dial 911 is better than a dead customer. I realize we may  
not get there immediately and universally.

Henning

---

From: "Dawson, Martin" <[email-masked]>
Date: Fri, 15 Jun 2007 02:32:06 -0500

Speak for yourself :) Your description of option 3 does not correlate
with my description or understanding of it. So, if there's confusion,
perhaps this is the root of it.

In option 3 - the access network doesn't determine coarse location at
all. It doesn't concern itself with coarse location. It uses the precise
location that it determines for the device, queries the local LoST
server and provides the resultant PSAP URI directly to the device. At
this point the routing has been achieved and the device can route
directly or via the VSP. When the PSAP dereferences, it gets the precise
location from the LIS. It is exactly because the routing is achieved by
just the local elements that this option doesn't have the Achilles heel
of option 1 which requires the VSP, absolutely, to be able to find the
authoritative local LoST server. As I say, for a very remote VSP and no
functioning forest guide, it may very well not be able to.

There's a basic principle here - emergency services are local to the
caller, the access network operator (and LIS) are local to the caller,
and the authoritative LoST server is going to most local to the caller.
The ability to reliably route the call is going to be optimal if it's
done between all these local entities who are best placed to be aware of
each other. Waiting until the call scenario has geographically diverged
to the VSP before attempting to determine routing is unnecessarily
sub-optimal.

In option 1 - how do you propose the access network determine the
"coarse location"? I believe your proposal is that it uses the local
LoST server applicable to its area of coverage and utilize the semantics
of LoST which provide a PSAP boundary in the response. Can you confirm
that this is your proposal? Otherwise, how would you anticipate that the
access provider, who doesn't manage the PSAP boundaries after all, would
know what is the appropriate coarse location that will result in a
reliable response when LoST is queried?

With respect to Henning's comment about LoST services being provided by
ISPs and/or VSPs, I didn't resonate with that. I would expect that LoST
is emergency services specific and it is likely to be part of some
jurisdictional function or some provider of services to that
jurisdictional function. I don't see that either ISPs or VSPs are
qualified to manage the PSAP routing information contained in a LoST
server.

Cheers,
Martin

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Thursday, 14 June 2007 11:07 PM
To: Dawson, Martin; 'ECRIT'
Subject: RE: [Ecrit] Proposals 1 and 3 - summary of perspectives

Option 1 requires that the access network dereference to anyone with at
least coarse location suitable for emergency call routing.  If the
endpoint
does routing, it will use a local LoST server which has high probability
of
having the route.  If a VSP wants to verify, it needs access to a LoST
server covering the area where his customers roam.  The cost is on the
carrier that is trying to hide location (which, AFAIK, is an economic
issue
all the way, the hiding is so the access network can charge for non
emergency uses of location).

Option 3 requires that the access network dereference to anyone with at
least coarse location suitable for emergency call routing.  This is
because
if the endpoint doesn't route (or more specifically, if it doesn't
recognize
emergency dialstrings, query LoST, and add the PSAP URI), but does
supply
location, then the VSP has to route, and it will have to dereference.
If
the endpoint does routing, option 3 is easy, because it will have the
correct PSAP URIs (it has to be all of them, BTW, a problem in itself).
If
a VSP wants to verify, it needs access to a LoST server covering the
area
where his customers roam.  It can't use the LCP, it has to dereference
the
location, and then query LoST.  

If we supply a different mechanism for a VSP to validate, that could
change,
and it would affect 1 and 3 the same way.

Brian

> > for,
> > three
--
> ----------------------
--
> ----------------------

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 15 Jun 2007 09:03:18 -0400

Yeah, you agree with me.  You just want to ignore the VSP validation
problem.  I'd like to ignore the location hiding problem, but we're stuck
with both.

If you come up with some way other than allowing the VSP to get coarse
location and using that to validate the PSAP URI, then we can use that for
option 1 or 3.  So far there is no other mechanism that we can use.  We can
extend LoST in some way to do it, but several of us are suggesting that we
postpone that work and get LoST out now.

I certainly agree that the basic assumption that the access provider, LoST
server and PSAP are local to one another is a good one.  It's what makes
option 1 or 3 possible, and gives the greatest likelihood that the system
will work.  I think having the VSP route is fairly easy, but "fairly" means
that we need forest guides so that callers that are remote can be routed.
I'd strongly prefer endpoints to route.  That will be much more likely to
work in all circumstances.  It seems very unlikely to me that we would have
a situation where the endpoint could supply location, but could not do
dialstring recognition and routing.  Having the VSP supply location AND
route is really going to be difficult with VPNs and NATs, etc.

With respect to who runs the servers, I believe you are conflating two parts
of the problem: who is responsible for the data, and who runs the actual
server.  The PSAP is responsible for the data.  It will probably run a
server which anyone can use.  However, I believe most access network
providers will want a copy of the data in a server they run.  That is the
purpose of the LoST mechanisms to maintain replicas of the data.

Brian

> Sent: Friday, June 15, 2007 3:32 AM
> To: [email-masked]

---

From: "Dawson, Martin" <[email-masked]>
Date: Fri, 15 Jun 2007 08:19:11 -0500

OK - but there's a very significant qualitative difference that you
haven't acknowledged yet.

Option 3 works without dependency on forest guides - it can work
straight away. Option 1 means that emergency calls will simply fail to
route until a global and reliable forest guide infrastructure is in
place. As I said, that's completely independent of the question of
location hiding. Even if the LIS wasn't hiding location I'd still
recommend that the device acquires the PSAP URI from the local services
and not just hope that the VSP can do it for it.

If the VSP is really going to run its own copy of the LoST data for the
area of coverage that it cares about, then it can use any internal
mechanism it likes to spot the matching PSAP URI in the database. It
doesn't have to talk LoST to its own infrastructure. Barbara pointed out
that, as a VSP operator, she isn't going to be so concerned about those
"foreign" emergency calls anyway. I actually agree with the sentiments
expressed that a VSP should still have a mission to support emergency
calling regardless of point of origin. In the spirit of Barbara's
position, however, perhaps it's still reasonable if they charge for
those "foreign" emergency calls.

Main point - I think the ability to provide global emergency service as
soon as possible is a better goal than saying I'll wait until I can be
sure that global emergency service can be provided for free before the
service can be used at all.

Cheers,
Martin 

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Friday, 15 June 2007 11:03 PM
To: Dawson, Martin; [email-masked]
Subject: RE: [Ecrit] Proposals 1 and 3 - summary of perspectives

Yeah, you agree with me.  You just want to ignore the VSP validation
problem.  I'd like to ignore the location hiding problem, but we're
stuck
with both.

If you come up with some way other than allowing the VSP to get coarse
location and using that to validate the PSAP URI, then we can use that
for
option 1 or 3.  So far there is no other mechanism that we can use.  We
can
extend LoST in some way to do it, but several of us are suggesting that
we
postpone that work and get LoST out now.

I certainly agree that the basic assumption that the access provider,
LoST
server and PSAP are local to one another is a good one.  It's what makes
option 1 or 3 possible, and gives the greatest likelihood that the
system
will work.  I think having the VSP route is fairly easy, but "fairly"
means
that we need forest guides so that callers that are remote can be
routed.
I'd strongly prefer endpoints to route.  That will be much more likely
to
work in all circumstances.  It seems very unlikely to me that we would
have
a situation where the endpoint could supply location, but could not do
dialstring recognition and routing.  Having the VSP supply location AND
route is really going to be difficult with VPNs and NATs, etc.

With respect to who runs the servers, I believe you are conflating two
parts
of the problem: who is responsible for the data, and who runs the actual
server.  The PSAP is responsible for the data.  It will probably run a
server which anyone can use.  However, I believe most access network
providers will want a copy of the data in a server they run.  That is
the
purpose of the LoST mechanisms to maintain replicas of the data.

Brian

> > > I think that your proposal only works if the VSP is able to
provide
> a
> > > or it has to do it for everything (sounds awfully like a global
VPC
> to
> > > the area I am in, I send my call to VSP, it sends it on the PSAP.
I
> > > get

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 15 Jun 2007 10:52:56 -0400

Huh?  I said the normal case is endpoint route.  If the endpoint routes,
option 1 is endpoint gets coarse location, endpoint queries LoST.  No forest
guide.

If the VSP routes, either option needs forest guides.

Option 1 and Option 3 need forest guides for the VSP to validate.

I don't see why a VSP would have a replica of the LoST database, but if it
did, it wouldn't cover the world.  So unless it restricts nomading, it has
to rely on forest guides to validate (or route).  If it did have a replica,
it could have some non standard way to validate for the parts of the
database it had.  That's not a solution, that's an optimization.  I don't
think you can handwave with "charge for foreign emergency calls".  They
aren't "foreign" to the guy making them.  I think it would be illegal in the
U.S. for example, although the VSP may not be subject to U.S. law in all
cases.

I think a reasonable strategy for a VSP attempting to validate is to arrange
forest guides, and to permit emergency calls from areas where it cannot get
coverage for without validation.  

Brian

> Sent: Friday, June 15, 2007 9:19 AM

---

From: "Dawson, Martin" <[email-masked]>
Date: Fri, 15 Jun 2007 21:24:50 -0500

If the "normal case" is endpoint route, then there's no need to
validate, right? So option 3 supports this without any need to provide
location information. Option 1 requires it to provide location
information *for all requests* since it doesn't really know this is an
emergency scenario.

So - let's leave end-point route out of the discussion with the note
that option 3 satisfies the location hiding requirement most
satisfactorily and without impact on VSP validation.

Now - for VSP route where the issue of URI validation comes up (which is
also purely a commercial issue AFAIK).

A. If there's no forest guide in place, option 1 doesn't allow the
emergency call to be routed at all but at least nobody will have to
worry about whether the non-call should be charged for or not.

B. If there's no functional way to validate the proffered PSAP URI then
option 3 requires the VSP to decide whether to charge for the call or
not based on its policy in this regard. However, the emergency call can
always be made regardless of the availability of a functional forest
guide network.

Your proposition is that scenario A is preferable to scenario B. I think
that is profoundly incorrect. I think it's self-evidently so.

You continually dismiss any attempt on my part to start a discussion
about ways for a VSP to validate the PSAP URI as "hand waving". Every
reasonable discussion based on a genuine desire to solve a problem
starts with those sorts of suggestions. Your approach is a
self-fulfilling argument that says there's no solution therefore there
can't be a solution, because I'm simply not going to talk about one. How
about a BCP that says that PSAP URIs should follow a specific convention
in terms of domain name structure? The VSP would only provide emergency
call tariffs to destinations that satisfy that BCP. Then somebody
wanting to "scam a free call" would have to make sure that the called
party URI met that form. Not particularly useful.

There's no precedent for a US-based operator charging for emergency
calls made by subscribers roaming in foreign jurisdictions. PSTN calls
(whether cellular or wireline) are always handled by an operator in that
jurisdiction. In the case of cellular, it is handled by the roaming
partner in that jurisdiction. VoIP is the first instance of the call
processing occurring at the home provider end while the call occurs in
the foreign jurisdiction. I think it's extremely unlikely that charging
for emergency calls made in foreign jurisdictions would be illegal.
There's only the barest shreds of legislation covering VoIP in any
respect at all at the moment.

Cheers,
Martin

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Saturday, 16 June 2007 12:53 AM
To: Dawson, Martin; [email-masked]
Subject: RE: [Ecrit] Proposals 1 and 3 - summary of perspectives

Huh?  I said the normal case is endpoint route.  If the endpoint routes,
option 1 is endpoint gets coarse location, endpoint queries LoST.  No
forest
guide.

I don't see why a VSP would have a replica of the LoST database, but if
it
did, it wouldn't cover the world.  So unless it restricts nomading, it
has
to rely on forest guides to validate (or route).  If it did have a
replica,
it could have some non standard way to validate for the parts of the
database it had.  That's not a solution, that's an optimization.  I
don't
think you can handwave with "charge for foreign emergency calls".  They
aren't "foreign" to the guy making them.  I think it would be illegal in
the
U.S. for example, although the VSP may not be subject to U.S. law in all
cases.

I think a reasonable strategy for a VSP attempting to validate is to
arrange
forest guides, and to permit emergency calls from areas where it cannot
get
coverage for without validation.  

Brian

> > done between all these local entities who are best placed to be
aware
> > > Typo alert - obviously it should have said that option *1*
requires
> > the
> > > VSP to work out the local LoST server in addition to the LIS
needing
> > > Neither option requires the ISP to implement LoST, they just
require
> > > > My VSP is in Sierra-Leone and I am visiting Samoa. In option 3,
I
> > > > get a
> > > > things happens. Either it has a complete forest guide network
set-
> > > > up to
> > > > the VSP routes the call anyway because the end-point has done
the
> > > >> This is not true, at least for comparable installations. The
ISP

---

From: "Dawson, Martin" <[email-masked]>
Date: Sat, 16 Jun 2007 10:29:15 -0500

Cheers,
Martin

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Saturday, 16 June 2007 12:53 AM
To: Dawson, Martin; [email-masked]
Subject: RE: [Ecrit] Proposals 1 and 3 - summary of perspectives

Brian

aware
requires
needing
require
I
set-
the
ISP

---

From: "Brian Rosen" <[email-masked]>
Date: Sat, 16 Jun 2007 16:40:40 -0400

Maybe we're getting ourselves confused with the word "validation".  An
endpoint would like to know that the location it got was a valid location.
It can do that by querying LoST.  If it's given a reference and a PSAP URI,
it can't check it unless it does a dereference, gets some kind of location
and queries LoST.  So option 3 leaves the endpoint not being able to
validate.

If an endpoint routes, some VSPs want to validate that the route the
endpoint handed it is valid.  That's another form of validation.  Option 3
doesn't provide any way for the VSP to validate that the PSAP URI in the
Request URI is a bona fide PSAP URI.

Yes, option 1 requires the LIS to provide a coarse location value for anyone
that asks.  It provides a way for the endpoint to validate that the location
results in a route to a PSAP, and it provides a way for a VSP to validate
that the URI is a valid PSAP URI.

If there is no forest guide, the local LoST server is still highly likely to
have the route for the location the endpoint is given.  Everything except
VSP validation works without forest guides.  PSAP validation requires that
the VSP have access to the same LoST data that the endpoint does.  In the
general case, that means forest guides.  There are lots of cases where the
VSP could reasonably get access to the LoST data where MOST of his
subscribers are, but most is not all, and forest guides would be required.

With option 3, the LIS is highly likely to have access to LoST data covering
it's service area, so no forest guides are needed.  The endpoint can't
validate, so whether there are forest guides is moot.  Same for VSP
validation.  

There is a document that describes how forest guides work.  There has been
discussion on this document, which has had more than one revision.  The only
words describing how option 3 might provide validation are email discussions
of reverse lookups, and one email from you that said "The ability to verify
a destination PSAP URI as a valid emergency URI could be supported by
reference to a relatively static table maintained by global cooperation."
That is the extent of the discussion.  There is no text.

I more or less understand how reverse lookup would work.  I think we would
have a significant piece of work to add that to the current LoST document.
I think everyone agrees that now is not the time to do that work.  If you
accept VSP validation as a requirement, which I do (reluctantly, but then I
accept location hiding as a requirement just as reluctantly) then we need
something that doesn't need a change to LoST with the impact of reverse
lookups.  You have suggested something.  I think it won't work, but it's
hard to criticize because there is no text.  In your latest email, you have
another idea, which I find equally unlikely to work, but again, there is no
text to criticize.

I don't really like option 3, but I could live with it if there was a way
for the VSP to validate.  I'd really like a way for the endpoint to
validate, but that is not quite so important.  I don't want to hold up LoST.

So, I'd say, in the absence of a reasonable alternative, with text that has
had some level of review, and has at least a reasonable amount of consensus,
that we document option 1 (in phonebcp) and keep working.

Brian
> Sent: Friday, June 15, 2007 10:25 PM

---

From: "Winterbottom, James" <[email-masked]>
Date: Sun, 17 Jun 2007 18:33:56 -0500

I would like to bring your attention to something that Barbara Stark has
said a couple of times now.

If the calls are national, then the potential list (even if there is one
per PSAP in the USA) is not unmanageable. So that can easily be kept
local. There is no mandate, or precedent for allowing free international
emergency calls, so why set one?

In short, this problem quite simply doesn't warrant a complex reverse
LoST lookup at this point. We are talking a sub 1% of emergency calls,
and these calls won't fail, they will just be billed until the
destination URI can be confirmed. What happened to the old 90% rule,
this problem isn't even in the 1% category!

Cheers
James

> Sent: Sunday, 17 June 2007 6:41 AM
> If there is no forest guide, the local LoST server is still highly
likely
> discussion on this document, which has had more than one revision.
The
> only
> accept VSP validation as a requirement, which I do (reluctantly, but
then
> another idea, which I find equally unlikely to work, but again, there
is
> no
> So, I'd say, in the absence of a reasonable alternative, with text
that
> > > If the VSP is really going to run its own copy of the LoST data
for
> > > doesn't have to talk LoST to its own infrastructure. Barbara
pointed
> > out
> > > Main point - I think the ability to provide global emergency
service
> > as
> > > option 1 or 3.  So far there is no other mechanism that we can
use.
> > We
> > > dialstring recognition and routing.  Having the VSP supply
location
> > AND
> > > > In option 3 - the access network doesn't determine coarse
location
> > at
> > > > server and provides the resultant PSAP URI directly to the
device.
> > At
> > > > location from the LIS. It is exactly because the routing is
achieved
> > > by
> > > > just the local elements that this option doesn't have the
Achilles
> > > heel
> > > > of option 1 which requires the VSP, absolutely, to be able to
find
> > the
> > > > authoritative local LoST server. As I say, for a very remote VSP
and
> > > no
> > > > that this is your proposal? Otherwise, how would you anticipate
that
> > > the
> > > > access provider, who doesn't manage the PSAP boundaries after
all,
> > > would
> > > > With respect to Henning's comment about LoST services being
provided
> > > by
> > > > ISPs and/or VSPs, I didn't resonate with that. I would expect
that
> > > > Option 1 requires that the access network dereference to anyone
with
> > > at
> > > > having the route.  If a VSP wants to verify, it needs access to
a
> > LoST
> > > > server covering the area where his customers roam.  The cost is
on
> > > > Option 3 requires that the access network dereference to anyone
with
> > > at
> > > > the endpoint does routing, option 3 is easy, because it will
have
> > > > > BTW - as I understand option 1, it requires the LIS to query
the
> > > local
> > > > > proposal being stated. It returns a "PSAP URI boundary"
location
> > > > instead
> > > > > If the proposition of option 1 is that it's actually the LIS
that
> > > > holds
> > > > > the PSAP-relevant boundary information, then option 1 is
actually
> > > much
> > > > > Further, given my understanding, both proposals rely on the
LIS
> > > > knowing
> > > > > coverage. That's much more practical than expecting any
arbitrary
> > > > global
> > > > > VSP being able to work that out but that is what option 3
requires
> > > *in
> > > > > LoST access protocol or not. So far, at least, VSPs seem a
whole
> > lot
> > > > > presumably because their customers look to them for that
service,
> > > not
> > > > > > me). Option 3 would be deployable from a local area to a
local
> > > PSAP
> > > > > > for the local area I am in. It provides a global solution
from
> > > > > > PSA P URI for the local Samoan PSAP from the local access
LIS
> > > > serving
> > > > > > billed, call completes, we are done. I can quibble with my
VSP
> > > later
> > > > > > With option 1, I send my call with location to my VSP, and
one
> > > > > > be able to talk to the Samoan LoST server nearest me, my
call
> > > > > > fails, or
> > > > > > here is simply option 3 re-badged. I am sure that VSPs
wouldn't
> > > > > > drop the
> > > > > > call on the floor, so choice 2 isn't an option, and choice 1
can
> > > > ONLY
> > > > > > So to my mind, option 3 is the ONLY deployable solution in
the
> > > short
> > > > > >>> until the forest guide network is implemented. Option 3
means
> > > that
> > > > > >>> emergency calls will be able to be routed regardless of
the
> > > state
> > > > > >> offer a LoST server that has the locally-relevant
information.
> > > Same

---

From: "Dawson, Martin" <[email-masked]>
Date: Sun, 17 Jun 2007 22:06:30 -0500

I'd like to challenge the following:

" If there is no forest guide, the local LoST server is still highly
likely to have the route for the location the endpoint is given.
Everything except
VSP validation works without forest guides."

You make it sound as if routing will work without forest guides given
option 1.  It does not unless by (insert miracle happens here) the VSP
happens to have the foreign jurisdiction LoST identity or a copy of the
foreign jurisdiction LoST information.

I have only referred to "validation" in the context of this thread as
meaning "confirming that a nominal PSAP URI is a genuine PSAP URI". So
that hasn't been a root of any confusion for me. I think option 3 does
provide validation of the PSAP URI because it is based on the
understanding that the LIS acquires the URI from the local LoST server.

I guess what I object to is the precipitous settling on option 1 (with
its inherent failure) before anybody has an option to submit alternative
text in any form.

In the mean time, and as you acknowledge below, both options 1 and 3
have "commercial" compromises for one or other party and there's no
objective way to give one priority over the other on that basis.

I would be interested in hearing from others (than Brian) whether they
think scenario A or scenario B below are the best starting point for
now.

Cheers,
Martin

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Sunday, 17 June 2007 6:41 AM
To: Dawson, Martin; [email-masked]
Subject: RE: [Ecrit] Proposals 1 and 3 - summary of perspectives

Maybe we're getting ourselves confused with the word "validation".  An
endpoint would like to know that the location it got was a valid
location.
It can do that by querying LoST.  If it's given a reference and a PSAP
URI,
it can't check it unless it does a dereference, gets some kind of
location
and queries LoST.  So option 3 leaves the endpoint not being able to
validate.

If an endpoint routes, some VSPs want to validate that the route the
endpoint handed it is valid.  That's another form of validation.  Option
3
doesn't provide any way for the VSP to validate that the PSAP URI in the
Request URI is a bona fide PSAP URI.

Yes, option 1 requires the LIS to provide a coarse location value for
anyone
that asks.  It provides a way for the endpoint to validate that the
location
results in a route to a PSAP, and it provides a way for a VSP to
validate
that the URI is a valid PSAP URI.

If there is no forest guide, the local LoST server is still highly
likely to
have the route for the location the endpoint is given.  Everything
except
VSP validation works without forest guides.  PSAP validation requires
that
the VSP have access to the same LoST data that the endpoint does.  In
the
general case, that means forest guides.  There are lots of cases where
the
VSP could reasonably get access to the LoST data where MOST of his
subscribers are, but most is not all, and forest guides would be
required.

With option 3, the LIS is highly likely to have access to LoST data
covering
it's service area, so no forest guides are needed.  The endpoint can't
validate, so whether there are forest guides is moot.  Same for VSP
validation.  

There is a document that describes how forest guides work.  There has
been
discussion on this document, which has had more than one revision.  The
only
words describing how option 3 might provide validation are email
discussions
of reverse lookups, and one email from you that said "The ability to
verify
a destination PSAP URI as a valid emergency URI could be supported by
reference to a relatively static table maintained by global
cooperation."
That is the extent of the discussion.  There is no text.

I more or less understand how reverse lookup would work.  I think we
would
have a significant piece of work to add that to the current LoST
document.
I think everyone agrees that now is not the time to do that work.  If
you
accept VSP validation as a requirement, which I do (reluctantly, but
then I
accept location hiding as a requirement just as reluctantly) then we
need
something that doesn't need a change to LoST with the impact of reverse
lookups.  You have suggested something.  I think it won't work, but it's
hard to criticize because there is no text.  In your latest email, you
have
another idea, which I find equally unlikely to work, but again, there is
no
text to criticize.

I don't really like option 3, but I could live with it if there was a
way
for the VSP to validate.  I'd really like a way for the endpoint to
validate, but that is not quite so important.  I don't want to hold up
LoST.

So, I'd say, in the absence of a reasonable alternative, with text that
has
had some level of review, and has at least a reasonable amount of
consensus,
that we document option 1 (in phonebcp) and keep working.

Brian
achieved
and
that
provided
with
with
that
actually
arbitrary
requires
service,
wouldn't
can
means
information.

---

From: "Dawson, Martin" <[email-masked]>
Date: Sun, 17 Jun 2007 22:46:56 -0500

Hi Brian,

I owe you an apology. I understood option 1 incorrectly (this has been
the disconnect). I've just had it pointed out to me that option 1 also
relies on the LIS (or the end point) to obtain the PSAP URI for the
endpoint to send it to the VSP along with the coarse location. I
understood that it was only the VSP that was going to do that (if the
VSP was going to be involved in the call processing).

So to correct my summary of the two methods:

Option 1 (VSP call processing)
1. The end-point queries the LIS which determines the location of the
device
2. The LIS queries LoST to obtain the PSAP coverage (coarse location)
and PSAP URI
3. The LIS provides the coarse location and (optionally?) the PSAP URI
4. The end point (optionally?) queries LoST again for the PSAP URI
5. The end point invokes the emergency call to the VSP with the coarse
location and the PSAP URI
6. The VSP invokes the forest guide (if necessary) and queries LoST
again to see if the PSAP URI that is returned is the same as the one
provided by the end point
7. If the PSAP URI has "validated" then the call is processed.

Option 3 (VSP call processing)
1. The end-point queries the LIS which determines the location of the
device
2. The LIS queries LoST to obtain the PSAP URI for the location
3. The LIS provides the PSAP URI to the device
4. The end point invokes the emergency call to the VSP with the PSAP URI
5. The VSP routes the emergency call (and charges for it or not
depending on policy)

Option 1 requires the LIS operator to always provide location
information - which is useful depending on the granularity required by
the jurisdiction. The VSP might be able to validate the PSAP URI if the
forest guide exists or it happens to have the access to the LoST
information one way or the other.

Option 3 does not require the LIS operator to provide any location. The
VSP has to apply a policy on emergency calls in the absence of the
ability validate the PSAP URI - at least until such time as the forest
guide or other mechanism supports this validation (text pending).

Does that summarize things more fairly?

Cheers,
Martin

-----Original Message-----
From: Dawson, Martin [mailto:[email-masked]] 
Sent: Monday, 18 June 2007 1:07 PM
To: Brian Rosen; [email-masked]
Subject: RE: [Ecrit] Proposals 1 and 3 - summary of perspectives

Cheers,
Martin

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Sunday, 17 June 2007 6:41 AM
To: Dawson, Martin; [email-masked]
Subject: RE: [Ecrit] Proposals 1 and 3 - summary of perspectives

Brian
achieved
and
that
provided
with
with
that
actually
arbitrary
requires
service,
wouldn't
can
means
information.

---

From: "Dawson, Martin" <[email-masked]>
Date: Sun, 17 Jun 2007 22:51:47 -0500

Hi James,

A counter perspective.

I'm currently logged on with Skype. I use it multiple times every day -
because it can work anywhere I am (like in a Singapore hotel at the
moment) as I know you do.

According to the Skype client, there are currently 5,166,796 users on
line. These users are spread over the globe and, I would suggest, that
very few of them are local to the VSP - wherever that may be.

It doesn't really matter whether we think that Skype is typical of what
VoIP is or will become (I think it is, because I can't understand why it
wouldn't). Regardless, it represents the extreme scenario that we need
to address. We cannot assume any proportional representation of local
versus foreign subscribers.

That's why we need to rely on the local infrastructure when it comes to
processing emergency calls. We could go to the 3GPP extreme and
*require* the call processing to be part of the local network as well.
When an end-point routes directly to the PSAP URI, this is effectively
what happens. Unlike 3GPP, ECRIT/i3 doesn't actually require the access
network to have a local call session control function that has a
relationship with the VSP.

If we are going to permit the scenario where the home VSP participates
in the routing according to the ECRIT/i3 model, then we need to reduce
the amount of "caller-local" knowledge that the VSP has to have and
maximize the use of the "caller-local" network resources.

Cheers,
Martin

-----Original Message-----
From: Winterbottom, James 
Sent: Monday, 18 June 2007 9:34 AM
To: Brian Rosen; Dawson, Martin; [email-masked]
Subject: RE: [Ecrit] Proposals 1 and 3 - summary of perspectives

Cheers
James

location.
location
validate
likely
except
that
the
the
required.
been
The
cooperation."
would
document.
you
then
need
is
way
that
for
pointed
service
use.
location
location
device.
achieved
Achilles
find
and
that
all,
provided
that
with
a
on
with
have
the
location
that
actually
LIS
arbitrary
requires
whole
service,
local
from
LIS
VSP
one
call
wouldn't
can
the
means
the
information.

---

From: "Dawson, Martin" <[email-masked]>
Date: Sun, 17 Jun 2007 22:58:14 -0500

Freakin' Outlook - I don't know why it deleted the line-feeds in my
enumerated list. It was plain text mode. Here's an attempt to make it
more readable.

Hi Brian,

understood that the VSP wasn't going to know the PSAP URI until it
retrieved it from LoST.

Cheers,
Martin

-----Original Message-----
From: Dawson, Martin [mailto:[email-masked]] 
Sent: Monday, 18 June 2007 1:07 PM
To: Brian Rosen; [email-masked]
Subject: RE: [Ecrit] Proposals 1 and 3 - summary of perspectives

Cheers,
Martin

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Sunday, 17 June 2007 6:41 AM
To: Dawson, Martin; [email-masked]
Subject: RE: [Ecrit] Proposals 1 and 3 - summary of perspectives

Brian
achieved
and
that
provided
with
with
that
actually
arbitrary
requires
service,
wouldn't
can
means
information.

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 18 Jun 2007 11:55:40 -0400

Yeah.  

I don't think we need the LIS to provide the PSAP URI for option 1.

In the U.S., I think 9-1-1 calls have to be free.  If your VSP is Sierra
Leone VoIP Services Pty, I don't think they can charge for it if they have a
nomad in Chicago.  It may be the case that SLVS is not subject to U.S. law,
but in theory, you can't charge for emergency calls within the jurisdiction
of the caller.  I do think, as a practical matter, that if the VSP doesn't
have a forest guide that can get it to the LoST server who is authoritative
for the location, it has to assume it's valid.  I think that will work.  I
think they could subsequently look into it (why they didn't have a forest
guide with the data, and if it was valid).  That's a trust but subsequently
verify modus operandi. 

I think it's a requirement to validate, just like it's a requirement to
support location hiding.  I think in the absence of a worked out way to
validate, Option 3 is a future possibility and not a currently acceptable
proposal.  We may be able to get there, but not right now.

Brian

> Sent: Sunday, June 17, 2007 11:58 PM
> To: [email-masked]

---

From: "Winterbottom, James" <[email-masked]>
Date: Mon, 18 Jun 2007 18:30:29 -0500

Brian,

While I agree with some of what you have said below, I certainly don't
agree with a lot of it.

I think that there are no grounds to suggest that SLVS can't charge
their mobile sub for making a call in the US emergency or not. Indeed
making this assertion in the way in which you have would be tantamount
to saying that all calls they made to US destinations while in the US
were national calls and their for likely free from tariff also. Which I
think we all agree is ridiculous.

As you point out, if there is no forest guide, then the VSP has to trust
the URI provided by the caller or bill them. This is the same as
solution 3 from the VSP perspective. So what you are saying is that
solution 3 has to be the case where a forest guide is not available.
Thanks for the support.. ;)

I think what this boils down to is that in the future PSAP URI
validation may be possible, and that from a VSP perspective it is a
billing requirement. Initially this will not be possible, either because
forest guides will not be available, or because no mechanism for PSAP
URI to service lookup will be available.

Cheers
James

> Sent: Tuesday, 19 June 2007 1:56 AM
> Leone VoIP Services Pty, I don't think they can charge for it if they
have
The
that
> > > Now - for VSP route where the issue of URI validation comes up
(which
> > > not based on its policy in this regard. However, the emergency
call
> > > can't be a solution, because I'm simply not going to talk about
one.
> > How
> > > (whether cellular or wireline) are always handled by an operator
in
> > > I don't see why a VSP would have a replica of the LoST database,
but
> > if
> > > aren't "foreign" to the guy making them.  I think it would be
illegal
> > in
> > > the
> > > U.S. for example, although the VSP may not be subject to U.S. law
in
> > all
> > > > straight away. Option 1 means that emergency calls will simply
fail
for
pointed
> > > out
> > > > that, as a VSP operator, she isn't going to be so concerned
about
> > > those
service
> > > as
> > > > soon as possible is a better goal than saying I'll wait until I
can
> > be
> > > > sure that global emergency service can be provided for free
before
> > > > location and using that to validate the PSAP URI, then we can
use
use.
> > > We
> > > > can
> > > > extend LoST in some way to do it, but several of us are
suggesting
> > > > server and PSAP are local to one another is a good one.  It's
what
> > > makes
> > > > a situation where the endpoint could supply location, but could
not
> > do
location
> > > > With respect to who runs the servers, I believe you are
conflating
> > two
> > > > parts
> > > > of the problem: who is responsible for the data, and who runs
the
> > > actual
> > > > server.  The PSAP is responsible for the data.  It will probably
run
> > > > providers will want a copy of the data in a server they run.
That
location
> > > at
> > > > > all. It doesn't concern itself with coarse location. It uses
the
> > > > precise
device.
> > > > > directly or via the VSP. When the PSAP dereferences, it gets
the
> > > > precise
Achilles
find
> > > > > There's a basic principle here - emergency services are local
to
> > > > > and the authoritative LoST server is going to most local to
the
> > > > caller.
> > > > > The ability to reliably route the call is going to be optimal
if
> > > it's
all,
that
> > > > > qualified to manage the PSAP routing information contained in
a
> > > > > having the route.  If a VSP wants to verify, it needs access
to a
> > > LoST
> > > > > server covering the area where his customers roam.  The cost
is on
> > > > > all the way, the hiding is so the access network can charge
for
> > non
> > > > > least coarse location suitable for emergency call routing.
This
have
> > > > > a VSP wants to verify, it needs access to a LoST server
covering
the
location
> > > > > instead
> > > > > > of the PSAP URI.
> > > > > >
> > > > > > I think folk are being inconsistent characterising option 3
as
> > > > adding
> > > > > > LoST functionality to HELD. Both proposals require the LIS
to
> > > > interact
LIS
> > > > > knowing
> > > > > > inherently what the appropriate local LoST server is. Option
1
> > > just
> > > > > > means that this is required *as well as* the VSP being able
to
> > > reach
> > > > > > I assume that your discussion has nothing to do with
location
> > > hiding
> > > > > > visit. This doesn't change whether HELD also gets converted
into
whole
> > > > > > It's always been the model that both ISPs and VSPs (as well
as
> > > third
> > > > > > parties that are neither) can and should operate LoST
servers,
local
> > > > PSAP
> > > > > > > REGARDLESS of the VSP having a LoST server that has
boundary
> > > > > > > information
from
> > > > > > > My VSP is in Sierra-Leone and I am visiting Samoa. In
option
> > 3,
LIS
> > > > > serving
> > > > > > > the area I am in, I send my call to VSP, it sends it on
the
> > > PSAP.
VSP
one
call
> > > > > > > lookup. I point out, that from the VSP perspective the
third
> > > > > > > alternative
> > > > > > > occur if the whole network is up and running, and it
doesn't
> > > > > > > consist of
the
> > > > > > >>> Nobody has suggested changing LoST so this point is just
a
> > > > > > >>> distraction.
> > > > > > >>>
> > > > > > >>>
> > > > > > >>>
> > > > > > >>> Option 1 means that emergency calls will not be able to
be
> > > > routed
the

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 18 Jun 2007 21:15:35 -0400

You can scream all you want, but I think (IANAL) that a 9-1-1 call within
the US has to be free, no matter who the carrier is.  The US could rule that
calls within the U.S. had to be in U.S. tariffs.  They have chosen not to.
If they did, I suspect the systems would look different, but that is
speculation and not relevant.  

I think getting a forest guide for 90% of the places a VoIP subscriber
nomdads will be easy. Getting the last 10% will be hard.  I don't see a
problem in a VSP handling the last 10% by assume good and investigate.  Most
of the world will have only a couple of entries per customer, and regional
forest guides will be readily available.  It may be that there are
commercial ventures who dig up the data and operate forest guides before the
"official" ones, but even that may be so short life it isn't worth it.  It's
in everyone's best interest to have forest guides work, so that nomads get
service.  While I am very much in favor of having endpoints route, VSP route
is going to be common as we start out.

I think you have to treat VSP validation with as much respect as location
hiding.  They are both economic arguments.  They are valid, somewhat.  Long
term, I suspect the hiding stuff fades away, but the validation is likely to
be with us for a long time, at least until all the pricing is all you can
eat.

Brian

> From: Winterbottom, James [mailto:[email-masked]]
> Sent: Monday, June 18, 2007 7:30 PM