ecrit@ietf.org
[Top] [All Lists]

RE: [Geopriv] RE: [Ecrit] Not-so-grand compromise on how to doendpointce

Subject: RE: [Geopriv] RE: [Ecrit] Not-so-grand compromise on how to doendpointcentric LCPwithout giving away the store
From: "Winterbottom, James"
Date: Sat, 14 Apr 2007 19:14:14 -0500
I agree.

Indirectly the access network is already assuming this responsibility
since it is providing location to the end-point in any case, either
directly or indirectly.

> -----Original Message-----
> From: Brian Rosen [mailto:br@xxxxxxxxxxxxxx]
> Sent: Saturday, 14 April 2007 5:11 AM
> To: 'Marc Linsner'; Rosen, Brian; geopriv@xxxxxxxx
> Cc: ecrit@xxxxxxxx
> Subject: RE: [Geopriv] RE: [Ecrit] Not-so-grand compromise on how to
> doendpointcentric LCPwithout giving away the store
> 
> I think that is part of the tradeoff an access network makes.  If its
> restricting access to location, and location is needed to route, then
it
> has
> to assume the liability for misroute, since it's providing the route
in
> lieu
> of providing location for the VSP to route.
> 
> If it doesn't want to assume that liability, then it has to give
location
> to
> someone who does the route, and we're back around that axle again.
> 
> So, I think it's reasonable that the access network deal with
misroutes in
> this case.
> 
> Brian
> 
> > -----Original Message-----
> > From: Marc Linsner [mailto:mlinsner@xxxxxxxxx]
> > Sent: Friday, April 13, 2007 1:23 PM
> > To: 'Rosen, Brian'; geopriv@xxxxxxxx
> > Cc: ecrit@xxxxxxxx
> > Subject: [Geopriv] RE: [Ecrit] Not-so-grand compromise on how to do
> > endpointcentric LCPwithout giving away the store
> >
> > Who is responsible for PSAP mis-routes?  I would think this
transfers
> > liability for routing to the access-provider, are they willing to
step
> up
> > to
> > that?
> >
> > -Marc-
> >
> > > -----Original Message-----
> > > From: Rosen, Brian [mailto:Brian.Rosen@xxxxxxxxxxx]
> > > Sent: Friday, April 13, 2007 7:18 AM
> > > To: geopriv@xxxxxxxx
> > > Cc: ecrit@xxxxxxxx
> > > Subject: [Ecrit] Not-so-grand compromise on how to do
> > > endpoint centric LCPwithout giving away the store
> > >
> > > In the Emergency Services SDO Coordination workshop, a
> > > familiar discussion took place: how does location get
> > > provided for emergency calls?  The real issue is revenue.
> > > Access networks have location.  They may be willing to (or
> > > may be regulated to be required to) provide location for
> > > emergency calls.  However, they are not willing to give it
> > > away for free for other uses.  The issue with that is how we
> > > support calling networks that don't have relationships with
> > > access networks, i.e. the Skype situation.  How is location
> > > provided such that a Skype emergency call can be placed, but
> > > the access network can restrict what else may be done with
> > > the location it provides?
> > >
> > > We have been wrapped around the axle on this for, dare I say,
years.
> > >
> > > So, I think Barbara Stark first described this, and it needs
> > > some work, but suppose that, as an option, an access network
> > > could supply:
> > >
> > > 1. A reference to location
> > >
> > > 2. The results of a LoST query on the location value (viz,
> > > PSAP URI and local dialstring)
> > >
> > > With this, an endpoint could recognize an emergency call and
> > > start routing it to the right PSAP.  The LIS would agree to
> > > dereference for PSAPs, but could restrict other uses of location.
> > >
> > > Hannes points out that we need one more thing: the calling
> > > network has to be able to validate that the PSAP URI really
> > > is a PSAP URI so that charging (emergency calls generally are
> > > free) is protected.  We need a mechanism for them to do that.
> > >
> > > Perhaps we include in the LoST return a country code for a
> > > query with a geo.  We add a new operation to LoST that takes
> > > a service, a country code and a PSAP URI and returns yes/no
> > > validation ("Yes, that URI is a valid URI for that service in
> > > that country").
> > >
> > > What would we need to do to make this happen?
> > >
> > > We need extensions to LCPs or some new protocol that returns
> > > an LbyR and the LoST results.  I wonder if this is just more
> > > HELD work.
> > >
> > > We need the PSAP URI validation.
> > >
> > > Again, this is optional.  The access network may well give up an
LbyV.
> > > It may give up an LbyR that it will dereference for the
> > > endpoint.  The access network may have a relationship with
> > > the calling network such that the endpoint need not be involved.
> > >
> > > The PSAP URI validation is actually useful without this idea,
> > > especially when location is an LbyR.  Instead of having to
> > > have the calling network dereference, and then do a LoST
> > > query to validate, it can just do this PSAP URI validation.
> > >
> > > Would this solve our problem?  Would access carriers
> > > concerned about revenue issues with "giving away" location to
> > > it's subscribers be willing to provide LbyR dereferenceable
> > > by PSAPs (again remembering that the access network are local
> > > to the PSAPs) as well as LoST query services to their
> > > endpoints?  Would this address the concerns raised by
> > > Deutsche Telecom on this issue?
> > >
> > > Let me be very clear that I think this is an ugly solution.
> > > I think that everyone will be much better off if endpoints
> > > knew where they were, and apps could take advantage of that.
> > > I think we'll get there.  I think tying location
> > > configuration with the LoST query is a bad idea.  I think
> > > using LbyR for emergency calls is a bad idea.
> > >
> > > But I can live with it.
> > >
> > > Brian
> > >
> > > _______________________________________________
> > > Ecrit mailing list
> > > Ecrit@xxxxxxxx
> > > https://www1.ietf.org/mailman/listinfo/ecrit
> >
> > _______________________________________________
> > Geopriv mailing list
> > Geopriv@xxxxxxxx
> > https://www1.ietf.org/mailman/listinfo/geopriv
> 
> 
> _______________________________________________
> Ecrit mailing list
> Ecrit@xxxxxxxx
> https://www1.ietf.org/mailman/listinfo/ecrit

------------------------------------------------------------------------------------------------
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@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/geopriv

<Prev in Thread] Current Thread [Next in Thread>