Subject: [Ecrit] LoST Transition Support Issue

From: "Roger Marshall" <[email-masked]>
Date: Wed, 2 Apr 2008 12:42:58 -0700

Late comment to
http://www.ietf.org/internet-drafts/draft-ietf-ecrit-lost-09.txt

I am requesting a simple text change to support adaptability of LoST
during transition stage between non-IP PSAPs and IP-based PSAPs.

Scenario:
If an IP-originated emergency call uses the LoST service to provide
routing instructions for routing the call to a region appropriate PSAP,
yet that particular PSAP doesn't yet support IP, there needs to be a way
within the LoST protocol to be able to still complete the call.  One
simple way is to redirect to another kind of server which can provide
supplemental routing instructions to a non-IP PSAP (e.g., for North
American, the NENA i2 VPC).  Currently, the LoST draft would support
this special kind of redirect, given single wording change:

Proposal:  Change text in the paragraph below, 
From: "LoST application unique string (see Section 4)" 
To: "application unique string (see Section 4)" 

13.3.  Redirects

   A LoST server can respond indicating that the querier should redirect
   the query to another server, using the <redirect> element.  The
   element includes a 'target' attribute indicating the LoST application
   unique string (see Section 4) that the client SHOULD be contacting
   next, as well as the 'source' attribute indicating the server that
   generated the redirect response and a 'message' attribute explaining
   the reason for the redirect response. 

-roger marshall.

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

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

---

From: "Winterbottom, James" <[email-masked]>
Date: Wed, 2 Apr 2008 15:37:58 -0500

Hi Roger,

My only concern with this, is that in i2 an end-point doesn't talk directly to a VPC, it talks to a VSP Call-Server that has several ways that it can talk with a VPC. Your proposed text change implies, at least to me, that the end-point would direct the request to the VPC, I am not sure that I would be in favour of that model in the i2 space. 

Cheers
James

-----Original Message-----
From: [email-masked] on behalf of Roger Marshall
Sent: Wed 4/2/2008 2:42 PM
To: [email-masked]; Ted Hardie
Subject: [Ecrit]  LoST Transition Support Issue
 
Late comment to

Scenario:

13.3.  Redirects

-roger marshall.

------------------------------------------------------------------------------------------------
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: "Brian Rosen" <[email-masked]>
Date: Wed, 2 Apr 2008 17:12:25 -0400

I don't think this works at all.

First of all, the LoST server either is run by the VPC, or it's run by
something like the 9-1-1 Authority.  The latter is where we are headed with
i3. 

If the 9-1-1 Authority runs it, then it can't refer the query to the VPC,
because it doesn't know which VPC.  We'll have to decide (in NENA) what we
do in the cases where there is no URI yet for a particular PSAP.  One
possibility is to return some fixed, non-globally resolvable URI.  The
carrier could provide its own resolution of that URI to its VPC.  That could
just be a default LoST return, rather than a redirect.

If the VPC runs it, it can put some appropriate URI in the LoST return to
get the right thing to happen.

However, let's just say that somehow we do want to do a <redirect>.  It
still has to be a LoST server, because that's what the client is going to do
with it.  If you want to send the call to some URI, that has to be the
output of a LoST server and not a redirect.  So, I think the wording is
correct as written.

Brian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Winterbottom, James
Sent: Wednesday, April 02, 2008 4:38 PM
To: Roger Marshall; [email-masked]; Ted Hardie
Subject: Re: [Ecrit] LoST Transition Support Issue

Hi Roger,

My only concern with this, is that in i2 an end-point doesn't talk directly
to a VPC, it talks to a VSP Call-Server that has several ways that it can
talk with a VPC. Your proposed text change implies, at least to me, that the
end-point would direct the request to the VPC, I am not sure that I would be
in favour of that model in the i2 space. 

Cheers
James

-----Original Message-----
From: [email-masked] on behalf of Roger Marshall
Sent: Wed 4/2/2008 2:42 PM
To: [email-masked]; Ted Hardie
Subject: [Ecrit]  LoST Transition Support Issue
 
Late comment to

Scenario:

13.3.  Redirects

-roger marshall.

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

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

---

From: Ted Hardie <[email-masked]>
Date: Wed, 2 Apr 2008 14:24:41 -0700

>I don't think this works at all.

Well, I can't top that for a comment, but I also have some serious issues
with the proposal.  If adopted, I don't see how it limits what application
unique strings are returned; since a sane processing engine wouldn't
bother dereferencing an application unique string for a protocol
it wasn't going to be able to use at the end of the day, that's not great. 
At a minimum, you would need to define what protocol was going to
be used once the <redirect> were complete.  Given that, it does
seem simpler to return a URI in the LoST response that tells
the end system how to contact that PSAP via whatever system
it needs to use.  If it's not going to understand that kind of response,
it's not going to understand a pointer to a second system which is
going to give it that response once it gets there.

			regards,
				Ted

---

From: "Winterbottom, James" <[email-masked]>
Date: Wed, 2 Apr 2008 17:13:49 -0500

Indeed, you could just as well have the LoST server return an ESRD (or
similar) encoded as a tel uri, and doesn't the problem then kind of go
away? Getting location to the PSAP of course then become the challenge,
but that is a different problem.

Cheers
James

> From: Ted Hardie [mailto:[email-masked]]
> Sent: Thursday, 3 April 2008 8:25 AM
> To: Brian Rosen; Winterbottom, James; 'Roger Marshall'; [email-masked]
> Subject: RE: [Ecrit] LoST Transition Support Issue
> 
> >something like the 9-1-1 Authority.  The latter is where we are
headed
> with
> >because it doesn't know which VPC.  We'll have to decide (in NENA)
what
> we
> >carrier could provide its own resolution of that URI to its VPC.
That
> could
> >still has to be a LoST server, because that's what the client is
going to
> do
> >talk with a VPC. Your proposed text change implies, at least to me,
that
> the
> >end-point would direct the request to the VPC, I am not sure that I
would
> be
>-----------------------------------------------------------------------
--
> ---
>-----------------------------------------------------------------------
--
> ---

---

From: "Dawson, Martin" <[email-masked]>
Date: Wed, 2 Apr 2008 22:32:20 -0500

If the PSAP is not "ECRIT capable" - and this involves more than just
being an "IP PSAP" - then it shouldn't resolve from LoST.

I think the proper transitional situation is for VSPs to try ECRIT
(LoST) and if the route doesn't resolve, to fall back to a VPC request.
VSPs nominate their own VPC (and ESGW and/or proxy) providers, so the
LoST server can't nominate a VPC for them. Actually, for quite some
time, it may make the most sense for the VSP to use i2/VPC first and
make ECRIT the fallback.

In my view, ideally, an ECRIT-capable emergency client will have found
and used the LoST service and sent the call directly to the PSAP in an
ECRIT-capable catchment area anyway. That is, the VSP should only be
involved if that doesn't apply and the call does require i2-type
handling. I know - that's still semi-heretical by the BCP, but I still
think it's correct and would lead to a more stable long term situation.

Cheers,
Martin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Winterbottom, James
Sent: Thursday, 3 April 2008 9:14 AM
To: Ted Hardie; Brian Rosen; Roger Marshall; [email-masked]
Subject: Re: [Ecrit] LoST Transition Support Issue

Cheers
James

headed
what
That
going to
that
would
--
--

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

---

From: "Roger Marshall" <[email-masked]>
Date: Fri, 4 Apr 2008 13:13:08 -0700

Yep, I agree what you're saying makes sense.  Without some sort of
alternate protocol sub-type identifier, it just wouldn't work anyway.
It would be nice to understand, maybe from some bcp point of view, the
different use cases for iterative mode, beside "We have temporarily
failed over.", as is given by (-09 section 13.3) example, since it
wasn't my impression that this is the primary technique of resolving to
another LoST server (via DNS).  Please correct me if not so.

Also, section 14., paragraph 3, last sentence, the phrase "specific
service" threw me a little.  It must therefore be meant as "specific
LoST service".

"Where an HTTP-layer redirect will
   be general, a LoST server redirect as described in 13.3 might be
   specific to a specific service or be the result of other processing
   by the LoST server."

Thanks.

-roger marshall.

> Sent: Wednesday, April 02, 2008 2:25 PM
> To: Brian Rosen; 'Winterbottom, James'; Roger Marshall; [email-masked]
> Well, I can't top that for a comment, but I also have some 
> serious issues with the proposal.  If adopted, I don't see 
> how it limits what application unique strings are returned; 
> since a sane processing engine wouldn't bother dereferencing 
> an application unique string for a protocol it wasn't going 
> to be able to use at the end of the day, that's not great. 
> At a minimum, you would need to define what protocol was 
> going to be used once the <redirect> were complete.  Given 
> that, it does seem simpler to return a URI in the LoST 
> response that tells the end system how to contact that PSAP 
> via whatever system it needs to use.  If it's not going to 
> understand that kind of response, it's not going to 
> understand a pointer to a second system which is going to 
> give it that response once it gets there.
> 
> 			regards,
> 				Ted
> 
> 
> 
> 
> >something like the 9-1-1 Authority.  The latter is where we 
> are headed 
> >with i3.
> >
> >If the 9-1-1 Authority runs it, then it can't refer the query to the 
> >VPC, because it doesn't know which VPC.  We'll have to 
> decide (in NENA) 
> >what we do in the cases where there is no URI yet for a particular 
> >PSAP.  One possibility is to return some fixed, non-globally 
> resolvable 
> >URI.  The carrier could provide its own resolution of that 
> URI to its 
> >VPC.  That could just be a default LoST return, rather than 
> a redirect.
> >
> >If the VPC runs it, it can put some appropriate URI in the 
> LoST return 
> >to get the right thing to happen.
> >
> >still has to be a LoST server, because that's what the 
> client is going 
> >to do with it.  If you want to send the call to some URI, 
> that has to 
> >be the output of a LoST server and not a redirect.  So, I think the 
> >wording is correct as written.
> >
> >Brian
> >
> >My only concern with this, is that in i2 an end-point doesn't talk 
> >directly to a VPC, it talks to a VSP Call-Server that has 
> several ways 
> >that it can talk with a VPC. Your proposed text change implies, at 
> >least to me, that the end-point would direct the request to 
> the VPC, I 
> >am not sure that I would be in favour of that model in the i2 space.
> >
> >Cheers
> >James
> >
> >
> >
> >yet that particular PSAP doesn't yet support IP, there needs to be a 
> >way within the LoST protocol to be able to still complete the call.  
> >One simple way is to redirect to another kind of server which can 
> >provide supplemental routing instructions to a non-IP PSAP 
> (e.g., for 
> >North American, the NENA i2 VPC).  Currently, the LoST draft would 
> >support this special kind of redirect, given single wording change:
> >
> >CONFIDENTIALITY NOTICE: The information contained in this 
> message may 
> >be privileged and/or confidential. If you are not the intended 
> >recipient, or responsible for delivering this message to the 
> intended 
> >recipient, any review, forwarding, dissemination, distribution or 
> >copying of this communication or any attachment(s) is strictly 
> >prohibited. If you have received this message in error, 
> please notify 
> >the sender immediately, and delete it and all attachments 
> from your computer and network.
> >
> >-----
> >This message is for the designated recipient only and may contain 
> >privileged, proprietary, or otherwise private information.
> immediately 
> >and delete the original.  Any unauthorized use of this email is 
> >prohibited.
> >-----

---

From: "Roger Marshall" <[email-masked]>
Date: Fri, 4 Apr 2008 13:16:54 -0700

It's certainly another approach - looks like the right one. 

Thanks.

-roger marshall.

> From: Winterbottom, James [mailto:[email-masked]] 
> Sent: Wednesday, April 02, 2008 3:14 PM
> similar) encoded as a tel uri, and doesn't the problem then 
> kind of go away? Getting location to the PSAP of course then 
> become the challenge, but that is a different problem.
> 
> Cheers
> James
> 
> > bother dereferencing an application unique string for a protocol it 
> > wasn't going to be able to use at the end of the day, that's not
> great.
> going to be 
> > used once the <redirect> were complete.  Given that, it does seem 
> > simpler to return a URI in the LoST response that tells the 
> end system 
> > how to contact that PSAP via whatever system it needs to 
> use.  If it's 
> > not going to understand that kind of
> response,
> VPC,
> > >output of a LoST server and not a redirect.  So, I think 
> the wording
> is
> > >correct as written.
> > >
> > >Brian
> > >
> > directly
> > >to a VPC, it talks to a VSP Call-Server that has several 
> ways that it
> can
> way
> > >received this message in error, please notify the sender 
> immediately,
> and
> > >immediately and delete the original.  Any unauthorized use of this 
> > >email is prohibited.
> >

---

From: "Roger Marshall" <[email-masked]>
Date: Fri, 4 Apr 2008 13:23:30 -0700

Martin:
Agree that this is another viable approach, though admittedly not
popular here.

The LoST-based architecture is an IETF 'pure-play'.  I look forward to
more transition discussion, since getting there will take some time.

Thanks.

-roger marshall.

> From: Dawson, Martin [mailto:[email-masked]] 
> Sent: Wednesday, April 02, 2008 8:32 PM
> To: Winterbottom, James; Ted Hardie; Brian Rosen; Roger 
> Marshall; [email-masked]
> If the PSAP is not "ECRIT capable" - and this involves more 
> than just being an "IP PSAP" - then it shouldn't resolve from LoST.
> 
> VSPs nominate their own VPC (and ESGW and/or proxy) 
> providers, so the LoST server can't nominate a VPC for them. 
> Actually, for quite some time, it may make the most sense for 
> the VSP to use i2/VPC first and make ECRIT the fallback.
> 
> In my view, ideally, an ECRIT-capable emergency client will 
> have found and used the LoST service and sent the call 
> directly to the PSAP in an ECRIT-capable catchment area 
> anyway. That is, the VSP should only be involved if that 
> doesn't apply and the call does require i2-type handling. I 
> know - that's still semi-heretical by the BCP, but I still 
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Winterbottom, James