Subject: RE: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to doendpointcentric LCP without giving away the store

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

Yah, the PSAP URI is "by value" as much as any URI is by value.

Brian

> -----Original Message-----
> From: Dawson, Martin [mailto:[email-masked]]
> Sent: Wednesday, April 18, 2007 3:55 AM
> To: Brian Rosen; Henning Schulzrinne; Rosen, Brian
> Cc: [email-masked]; [email-masked]
> Subject: RE: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to
> doendpointcentric LCP without giving away the store
> 
> I certainly think that it's most optimal to get both location and PSAP
> URI at the time of the call. I don't think anyone has suggested that
the
> PSAP URI should be provided "by reference" (right?) - it pretty much
is
> a reference anyway...
> 
> Cheers,
> Martin
> 
> -----Original Message-----
> From: Brian Rosen [mailto:[email-masked]]
> Sent: Tuesday, 17 April 2007 3:36 AM
> To: 'Henning Schulzrinne'; Rosen, Brian
> Cc: [email-masked]; Dawson, Martin; [email-masked]
> Subject: RE: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to
> doendpointcentric LCP without giving away the store
> 
> Okay, let's look at this.
> 
> For fixed devices, the PSAP URI doesn't change often, the cached value
> is
> very likely to be good.  However, it MIGHT change on short notice.
The
> call
> time query fixes this, if it works.
> 
> For mobile devices, the endpoint may get a reference.  The REFERENCE
> doesn't
> change.  It's good for a long time (probably as long as the carrier -
> subscriber relationship holds).  If it gets a value, then it wants an
> update
> when it moves beyond the PSAP boundary.  With a value, it queries LoST
> and
> gets the boundary, then passes that to its location determination
> mechanism
> and asks for a notification when it moves beyond that.
> 
> The above, of course, is fairly far from what IMS currently talks
about,
> but
> that is what the IETF ecrit/presence architecture would say.
> 
> If the access network plays cozy with the location, so it passes a
> reference
> and a PSAP URI, then it needs a way to TELL the device when the PSAP
URI
> is
> no longer valid.  Perhaps we could define a SIP event package for this
> purpose, so a LIS could notify an endpoint of a new PSAP URI when its
> current location warranted that.  I suppose this is a presence thing,
> and
> maybe we could tie this more strongly into the existing presence
system.
> 
> Brian
> 
> 
> 
> > -----Original Message-----
> > From: Henning Schulzrinne [mailto:[email-masked]]
> > Sent: Monday, April 16, 2007 12:54 PM
> > To: Rosen, Brian
> > Cc: [email-masked]; Dawson, Martin; [email-masked]
> > Subject: Re: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to
> > doendpointcentric LCP without giving away the store
> >
> >
> > On Apr 16, 2007, at 12:14 PM, Rosen, Brian wrote:
> >
> > > Right.  Good summary.
> > >
> > > However, because at least some networks have to get through Pay to
> > > Play,
> > > we need to provide mechanisms that work.
> > >
> > > The proposal (access networks that want pay to play must provide
> LbyR,
> > > PSAP URI and dialstrings seems a workable solution to those
> networks.
> >
> > This only works for stationary devices, barely, unless there's an
> > event notification mechanism that updates that information,
> > particularly the PSAP URL.
> >
> > Otherwise, you have to rely on call-time queries, which
significantly
> > degrade reliability and performance. In that case, you're not
> > providing a service that is equivalent and the customer pays for the
> > provider's pay-to-play dreams with their life and property.
> >
> > Henning
> >
> > _______________________________________________
> > Geopriv mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/geopriv
> 
> 
>
------------------------------------------------------------------------
--
> ----------------------
> 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: Hannes Tschofenig <[email-masked]>
Date: Wed, 18 Apr 2007 13:38:22 +0200

I am sure that someone will sooner or late get the idea that it would be 
nice not to disclose the URI of the PSAP and hence we should just return 
a reference to it.

Ciao
Hannes

---

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

Actually, that is why the ESRP is there.  It can obscure what PSAP actually
gets the call.

The argument that PSAPs want security by obscurity in this way has been
asserted many times in NENA meetings.  I have went so far as to get up in
the front of the room with hundreds of technical and operational (NENA
TDC/ODC general sessions) and ask if there were any PSAP people who believed
this to please see me privately and explain.  I have NEVER talked or heard
of a PSAP who believed that his service area was a secret, or that some
hiding of which calls go to them would be valuable.

Now, several VENDORS asserted this was true, but so far, that assertion is,
from my point of view, baseless.

This gives rise to what the "PSAP URI" coming out of LoST when an ESRP is
used really is.

One possibility is:
sip:[email-masked]

Another possibility is:
sip:[email-masked]

In both cases, the esrp in New York state gets the call first.  In the
former, the esrp may need a LoST dip to determine which PSAP gets the call.
In the latter, some policy decisions would need to be made, and in some
circumstances a LoST dip, but in normal circumstances, the Buffalo, NY PSAP
gets the call.

Brian

> From: Hannes Tschofenig [mailto:[email-masked]]
> Sent: Wednesday, April 18, 2007 7:38 AM
> To: Rosen, Brian
> Cc: Dawson, Martin; Brian Rosen; Henning Schulzrinne; [email-masked];
> [email-masked]