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

If there were design flaws in i2, I wouldn't ask the IETF to fix them -
no. Since there aren't any that I'm aware of I guess I don't need to
deal with that dilemma in any case.

Silly

Cheers,
Martin

> -----Original Message-----
> From: Marc Linsner [mailto:mlinsner@cisco.com]
> Sent: Thursday, 14 September 2006 11:35 PM
> To: Dawson, Martin; 'Brian Rosen'; Thomson, Martin; 'Henning
Schulzrinne';
> 'Hannes Tschofenig'
> Cc: 'GEOPRIV'
> Subject: RE: [Geopriv] coming to terms on location by reference
>
> Martin,
>
> You are asking the IETF to fix design flaws for NENA i2? Why don't
you
> fix
> i2?
>
> -Marc-
>
> > -----Original Message-----
> > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com]
> > Sent: Wednesday, September 13, 2006 8:21 PM
> > To: Brian Rosen; Thomson, Martin; Henning Schulzrinne; Hannes
> > Tschofenig
> > Cc: GEOPRIV
> > Subject: RE: [Geopriv] coming to terms on location by reference
> >
> > 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]
> >
> > _______________________________________________
> > 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]

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