RE: [Geopriv] coming to terms on location by reference

I have the opportunity to talk to cellular operators pretty much every
day and there's no ambiguity that the ability to get a location update
*at any time* and *as many times* as possible is a strict requirement.
It's not just about getting the more accurate location the second time
around but, certainly, where GPS is involved that is absolutely the
case. (I'm just boggling at the prospect of a DHCP server providing
assistance data for a GPS fix... thphhht... OK, I'm better now). The
requirement is there because in some emergency situations the ability to
track the caller is vital to a successful outcome (the classic hostage
in a trunk scenario; though the reality may be more prosaic). The fact
that it's not needed in the majority of cases hardly seems important -
unless you're advocating a deterioration of the quality of emergency
service as an inevitable consequence of the switch of telephony to IP.

In any case - what are you actually talking about? If you are in a
topology where it is possible to get a location update request back to
the device, then by all means use location by value - whether you need
to do it once or multiple time. It's got zip to do with whether it's
DHCP or not so I don't even know what that comment is doing in there.

How do you propose to get this request back to the terminal for the many
years in which we are going to be using i2?

Cheers,
Martin

> -----Original Message-----
> From: Brian Rosen [mailto:br@brianrosen.net]
> Sent: Friday, 15 September 2006 4:09 AM
> To: Dawson, Martin; 'Hannes Tschofenig'
> Cc: Thomson, Martin; 'Henning Schulzrinne'; 'GEOPRIV'
> Subject: RE: [Geopriv] coming to terms on location by reference
>
> Martin
>
> I recently had the occasion to discuss with several wireless carriers
and
> PSAP people how location update is actually used.
>
> As you know, initial routing today is almost always based on
cell/sector.
> What actually happens is that some time after the call is answered,
the
> call
> taker requests a location update. The actual location of the caller
is
> returned.
>
> In nearly every case, that is ALL there is, one update. Sometimes the
> call
> taker asks too early, and they have to do the query once more.
>
> Use LbyV. Send a request back to the endpoint, let it ask the LIS,
and
> return the answer. It will work fine. IT WILL WORK FINE IF DHCP IS
THE
> ONLY LCP THE ACCESS NETWORK IMPLEMENTS!!!!!
>
> If the call taker requeries more than once, do it again. It's MANUAL.
If
> it's manual, there is no problem in any system I can think of to go
back
> to
> the endpoint and let it get you the new location.
>
> Brian
>
>
>
>
>
> > -----Original Message-----
> > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com]
> > Sent: Thursday, September 14, 2006 10:38 AM
> > To: Hannes Tschofenig
> > Cc: Brian Rosen; Thomson, Martin; Henning Schulzrinne; GEOPRIV
> > Subject: RE: [Geopriv] coming to terms on location by reference
> >
> > G'day Hannes,
> >
> > What is the end host that you're referring to?
> >
> > In i2 - which is specifically designed to get emergency services
support
> > now (without having to wait for when we can replace the CPE in
thousands
> > of devolved PSAPs) - delivers the call through an IP to switch
circuit
> > gateway, through a tandem exchange (selective router), and on to the
> > PSAP on primarily CAMA trunks. PSAPs only have the ability to query
for
> > location through an ALI - you can't swim back upstream through all
that
> > legacy interconnect to initiate a request for location conveyance.
i2
> > re-uses the cellular infrastructure to query the equivalent of a
mobile
> > position center (the VoIP position center) which provides both the
> > routing function and the location caching and update function.
> >
> > i3 may support call-associated conveyance for location updates but
it is
> > not a characteristic of i2. The purpose of i2 is to allow VoIP
telephony
> > to become mainstream by having full E911 support in the migratory
period
> > between now and when IP telephony exists from all callers and to all
> > PSAP end points. Given the architecture is now defined (a lot of
work to
> > get there) and is now being communicated to the PSAP, ALI, VoIP
> > provider, and access provider participants in the emergency
industry, I
> > am particularly keen to ensure that the IETF doesn't throw a spanner
in
> > the works. For example, that is why I have been advocating the
reference
> > conveyance in the SIP thread - it's needed to support i2.
> >
> > Cheers,
> > Martin
> >
> > > -----Original Message-----
> > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]
> > > Sent: Friday, 15 September 2006 12:19 AM
> > > To: Dawson, Martin
> > > Cc: Brian Rosen; Thomson, Martin; Henning Schulzrinne; GEOPRIV
> > > Subject: Re: [Geopriv] coming to terms on location by reference
> > >
> > > Hi Martin,
> > >
> > > I don't know the details of the i3 infrastructure but this seems
> > pretty
> > > complicated. I wonder why NENA does not go for a simple solution,
> > namely:
> > >
> > > * Pass location information to the end host
> > > * Use SIP location conveyance
> > > * Done
> > >
> > > Ciao
> > > Hannes
> > >
> > > Dawson, Martin schrieb:
> > > > I don't know what the current intent of i3 is - or indeed ECRIT
-
> > but
> > > > presumably an end-to-end IP location call can be quite
sophisticated
> > as
> > > > far as how location updates are acquired.
> > > >
> > > > You've probably noticed, I'm most concerned with facilitating
> > getting i2
> > > > working without barriers being introduced by IETF protocol
anomalies
> > > > (i.e. I'd prefer it if IETF protocols could be used).
> > > >
> > > > In i2, the VPC queries the LIS. The VPC is a hub for all the
PSAPs
> > and
> > > > PSAPs are a hub for all the police and etc. Each hub has to have
its
> > own
> > > > authorization architecture - and does in the legacy emergency
> > network.
> > > > The LIS, however, is only concerned with the VPCs. VESA
certificates
> > for
> > > > VPCs are the intended mechanism. The scale should be quite
> > manageable.
> > > >
> > > > Perhaps i3/ECRIT should consider a similarly scalable hierarchy.
> > > >
> > > > Authenticating the LIS identity is actually a separate issue.
Again,
> > i2
> > > > proposes VESA certificates provided to broadband access
> > infrastructure
> > > > providers (not ISPs necessarily). However, this is about
providing
> > > > location integrity - ensuring the emergency network has
confidence
> > in
> > > > the source of the location information. It is the same concern
as
> > exists
> > > > with respect to location-by-value.
> > > >
> > > > I believe a LIS will always be in the same jurisdiction as the
VPC -
> > and
> > > > the VPC will always be in the same jurisdiction as the emergency
> > call
> > > > center. The VSP may be cross-jurisdictional to these entities.
While
> > > > this doesn't impact the protocols themselves, I believe it will
be
> > > > structured this way to maintain jurisdictional integrity.
> > > >
> > > > Cheers,
> > > > Martin
> > > >
> > > >> -----Original Message-----
> > > >> From: Brian Rosen [mailto:br@brianrosen.net]
> > > >> Sent: Thursday, 14 September 2006 8:59 AM
> > > >> To: Thomson, Martin; 'Henning Schulzrinne'; 'Hannes Tschofenig'
> > > >> Cc: 'GEOPRIV'
> > > >> Subject: RE: [Geopriv] coming to terms on location by reference
> > > >>
> > > >> I do not buy the physical presence argument at all. For
example, I
> > > > may
> > > >> outsource the "ESRP", which needs location to route. Henning's
> > > > example
> > > >> was
> > > >> a mutual aid fire company from out of area needing to access
> > current
> > > >> location.
> > > >>
> > > >> I think it may be possible to get credentials issued to PSAPs
in
> > North
> > > >> America, although I have been trying diligently for a year to
get
> > it
> > > >> started
> > > >> with zero progress. Getting every responder who may need
location
> > > >> credentials is MUCH more problematic. Getting credentials in
other
> > > > areas
> > > >> may be even more problematic. And I am an optimist about
> > credentials.
> > > >>
> > > >> I think we should treat the reference as we do the location.
> > > >>
> > > >> Security of reference = security of object
> > > >>
> > > >> If you got it, you are honor bound to obey the ruleset, but you
> > have
> > > > the
> > > >> location. That means the dereferencer doesn't check
credentials.
> > > > This
> > > >> does
> > > >> not imply that privacy and integrity protection is not
desirable,
> > but
> > > > in
> > > >> the
> > > >> emergency case, you fall back to none.
> > > >>
> > > >> Brian
> > > >>
> > > >>> -----Original Message-----
> > > >>> From: Thomson, Martin [mailto:Martin.Thomson@andrew.com]
> > > >>> Sent: Wednesday, September 13, 2006 6:39 PM
> > > >>> To: Henning Schulzrinne; Hannes Tschofenig
> > > >>> Cc: GEOPRIV
> > > >>> Subject: RE: [Geopriv] coming to terms on location by
reference
> > > >>>
> > > >>>> To amplify: The fundamental problem is that, in general, a
LIS
> > > > can't
> > > >>>> know all the legitimate recipients of location information
and
> > the
> > > >>>> PSAPs (and other associated entities, such as first
responders)
> > do
> > > >>>> not know all or even most of the LIS, as these can be
operated by
> > > >>>> thousands of entities within a particular jurisdiction. Both
sets
> > > > are
> > > >>>> fairly dynamic, sometimes on short time scales ('mutual
aid').
> > > >>> I don't think that this is necessarily true. An access
network
> > > > provider
> > > >>> has to have some sort of physical presence to provide an
internet
> > > > link.
> > > >>> This means that they exist in the same jurisdiction as the
PSAP
> > (et.
> > > >> al.).
> > > >>> Because both have a link to the physical location, then there
is a
> > > > good
> > > >>> possibility that something can be worked out.
> > > >>>
> > > >>> In the US, NENA is looking at setting up a certificate
authority
> > to
> > > >>> certify PSAPs - the possession of a VESA certificate will
indicate
> > > > to a
> > > >>> LIS that the requester is a valid emergency entity. To my
> > > > knowledge,
> > > >> the
> > > >>> number of these credentials required will be smaller than you
hint
> > > > at.
> > > >>> This is a reasonable indication of how to authenticate
emergency
> > > >> entities
> > > >>> for the retrieval of location information.
> > > >>>
> > > >>> Authentication of a LIS is, understandably, a different class
of
> > > >> problem.
> > > >>> Like you say, thousands of LISes might exist, with far greater
> > > >> diversity.
> > > >
> >
------------------------------------------------------------------------
> > > >> --
> > > >>> ----------------------
> > > >>> 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]
> > > >>
> > > >> _______________________________________________
> > > >> Geopriv mailing list
> > > >> Geopriv@ietf.org
> > > >> 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]
> > > >
> > > >
> > >
> >
> >
------------------------------------------------------------------------
> --
> > ----------------------
> > 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]
>

------------------------------------------------------------------------------------------------
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]

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv
Received on Thu, 14 Sep 2006 17:01:47 -0500