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: Sun, 15 Apr 2007 17:29:36 -0500
Marc,

> -----Original Message-----
> From: Marc Linsner [mailto:mlinsner@xxxxxxxxx]
> Sent: Monday, 16 April 2007 5:58 AM
> To: Winterbottom, James
> Cc: ecrit@xxxxxxxx
> Subject: RE: [Geopriv] RE: [Ecrit] Not-so-grand compromise on how to
> doendpointcentric LCPwithout giving away the store
> 
> James,
> 
> >
> > I am not so sure that this anymore the case than it would be
> > with a location value is it?
> 
> No, if the client has LbyV, the client can do the LoST lookup at call
> time.
> 
[AJW] This presupposes that the location has not changed. If the
location has changed then this doesn't help unless the client also
requests a new location at call time. In this case I put to you that
there is no difference in the number of queries performed.

> >
> > If the device is fixed, then the likelihood of change in low,
> > but the PSAP route could be tagged with an expiry the same as
> > a literal location can. So I think this is the same problem.
> 
> You are suggesting the host go back to the access network when setting
up
> an
> emergency call?

[AJW] Local network hit is likely to be faster than a wide-area network
hit.

> 
> I wonder if a course location (enough to route properly) with LbyR
> embedded
> in the LbyV would be better.
>

[AJW] Hmmm, maybe. I would need to think about this one a bit more as I
am not sure that we can easily arrive at a solution to how coarse is too
coarse, or too fine.

 
> The access provider can take the fine grain location, perform a LoST
> lookup,
> give the client only the tuples that LoST returned in the service
> boundary.
> The client can then perform a LoST lookup anytime with that set of
tuples.
> If the client is fixed no need to contact the access network at
emergency
> call time.
> 
> I worry about too many dependencies at call time.

[AJW] Agreed, but we need to allow people to deploy it also. Like most
things some ground in the middle will need to be found.

> 
> -Marc-
> 
> >
> > If the device is mobile then yes this does require an extra
> > dip prior to the mobile sending the initial invite, but the
> > proxy doesn't have to the LoST dip on the way, so the net
> > result may be neutral depending on how the proxy does URI
> > checking etc.
> >
> > I am not suggesting that this solution is optimal either, but
> > like Brian and I can live with it.
> >
> > Cheers
> > James
> >
> > > -----Original Message-----
> > > From: Marc Linsner [mailto:mlinsner@xxxxxxxxx]
> > > Sent: Sunday, 15 April 2007 1:32 PM
> > > To: 'Brian Rosen'
> > > Cc: ecrit@xxxxxxxx
> > > Subject: RE: [Geopriv] RE: [Ecrit] Not-so-grand compromise
> > on how to
> > > doendpointcentric LCPwithout giving away the store
> > >
> > > Brian,
> > >
> > > You also realize that an emergency call is going to be routed
using
> > > 'stale'
> > > data.  We've always stated that routing at call time is
> > optimal.  You
> > are
> > > prepared to give that up?
> > >
> > > -Marc-
> > >
> > > > -----Original Message-----
> > > > From: Brian Rosen [mailto:br@xxxxxxxxxxxxxx]
> > > > Sent: Friday, April 13, 2007 3:11 PM
> > > > To: 'Marc Linsner'; Rosen, Brian; geopriv@xxxxxxxx
> > > > Cc: ecrit@xxxxxxxx
> > > > Subject: RE: [Geopriv] RE: [Ecrit] Not-so-grand
> > compromise on how to
> > > > do endpointcentric 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]
> >

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

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