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

RE: AW: [Ecrit] Location Hiding -- State of the Art

Subject: RE: AW: [Ecrit] Location Hiding -- State of the Art
From: "Winterbottom, James"
Date: Tue, 11 Dec 2007 15:42:55 -0600
I will reply to this in more detail later Brian, when my brain is a little less 
fried.

The basis of my proposal is that the Location provider knows what services etc 
that it will grant access to. There is no way for the VSP to know this unless 
they are also the access provider. So while the VSPs may want to get into the 
location dependent routing game, I think that this is actually a very good 
value-add that access providers will have dominance over for some time.

Cheers
James

> -----Original Message-----
> From: Brian Rosen [mailto:br@xxxxxxxxxxxxxx]
> Sent: Wednesday, 12 December 2007 8:21 AM
> To: 'Liess, Laura'; hardie@xxxxxxxxxxxx; Winterbottom, James;
> bs7652@xxxxxxx; Dawson, Martin
> Cc: ecrit@xxxxxxxx
> Subject: RE: AW: [Ecrit] Location Hiding -- State of the Art
> 
> Yeah, my problem with this is that every client has to implement two
> mechanisms.  They need to implement the LCP then dereference then LoST
> lookup AND they have to implement the HELD+LoST mechanism.
> 
> I think this mechanism requires the reverse LoST lookup for VSPs, so more
> work for LoST servers.  I think James wants to ignore that problem
> (something about letting VSPs charge for emergency calls and working it
> out
> later).
> 
> BTW, the HELD return would have to supply ALL of the service URNs,
> dialstrings, and boundaries that the LoST server knows about.  I'm not
> quite
> sure how the HELD server figures that out.  If there are commercial
> services
> using LoST, all of them would have to be returned.  I think the VSP wants
> to
> get into the "Location Based Routing" act (they do route calls after all,
> and ISPs don't).  I'm not sure how it would do so with this proposal.
> 
> If the device is mobile, what happens?  The way we specified it so far,
> the
> endpoint would subscribe to a location update service and get location
> updates.  It would have the service boundary from LoST, and it would
> requery
> if it moved beyond the service boundary.  That works, and makes sense to
> me.
> I'm not sure what James proposes.
> 
> If we're going to go beyond the basic location hiding idea, using what I
> proposed, which takes no standards changes and puts the burden on the LIS
> who is hiding location, then I think Richard's idea of allowing LoST to
> dereference is a better one.  I don't like that idea; we've talked about
> why
> it's not a great idea in the past, but it's better than James'.
> 
> Brian
> 
> > -----Original Message-----
> > From: Liess, Laura [mailto:Laura.Liess@xxxxxxxxxxxxx]
> > Sent: Tuesday, December 11, 2007 3:58 PM
> > To: hardie@xxxxxxxxxxxx; James.Winterbottom@xxxxxxxxxx; bs7652@xxxxxxx;
> > br@xxxxxxxxxxxxxx; Martin.Dawson@xxxxxxxxxx
> > Cc: ecrit@xxxxxxxx
> > Subject: AW: AW: [Ecrit] Location Hiding -- State of the Art
> >
> >
> > I see two advantages with James URI proposal:
> >
> > 1) It's simple. People (also product managers) understand it within 2
> > minutes and like it exactly for this reason. The chance to get it
> > implemented soon is probably quite high.
> >
> > 2) The ISP provider is responsible for most EC functionality. The VSP is
> > just "transport". (Marc pointed out this aspect to me last week.)
> Probably
> > the regulators would like this because they can control the ISPs better
> > than the VSPs.
> > The chance for this solution to work, at lest at the beginning, is
> > probably higher than if 3 different providers (the ISP, the VSP and the
> > LOST provider), with eventually conflicting economical interests, have
> to
> > cooperate to provide the EC functionality.
> >
> > What if we have both options, coarse location and ESRP/PSAP URI? Does
> this
> > mean too high implementation effort for clients?
> >
> > Laura
> >
> > -----Ursprüngliche Nachricht-----
> > Von: Ted Hardie [mailto:hardie@xxxxxxxxxxxx]
> > Gesendet: Montag, 10. Dezember 2007 22:38
> > An: Winterbottom, James; Stark, Barbara; Brian Rosen; Dawson, Martin;
> > Henning Schulzrinne
> > Cc: ecrit@xxxxxxxx; Liess, Laura
> > Betreff: RE: AW: [Ecrit] Location Hiding -- State of the Art
> >
> > At 1:25 PM -0600 12/10/07, Winterbottom, James wrote:
> > >If the device is simply given a PSAP URI, a service URN, and a location
> > >URI, what more does it need?
> >
> > As several people have pointed out, it needs/could use the ability to
> > sanity
> > check the location.  You've argued it doesn't need that as much as
> > the operators need to be paid for location infrastructure deployed,
> > which set up the whole apples to oranges discussion that has been
> > going so far.
> >
> > Past that, you're introducing a mechanism that combines two services
> > (receiving a location and associating that location with a psap URI).
> If
> > you gave
> > that data to a device which has a different LoST server configured, what
> > do you expect to happen?  Is it going to pass that location URI to its
> > own LoST server to confirm it gets the same PSAP URI?  The current
> > system allows a user/device to request service boundaries and to
> > make reasonable choices about when to refresh URI mappings.  How
> > are you replicating that functionality?  The service boundaries are,
> > after all, pretty much at the level of Brian's proposal.
> >
> > > > For non-emergency cases, you are dealing instead with the
> > >> case where you have a concern that selling someone location
> > >> for purpose X gets them location for purpose Y.  That's both
> > >> a different problem and it falls into an area where there are
> > >> enough other problems that it is, honestly, probably the least
> > >> of your worries.  It's also way out of the charter of this group.
> > >>
> > >
> > >I would argue that location hiding is not in the charter of this WG at
> > >all. How to route to a PSAP is the current charter, so if the end-point
> > >is given all it needs to route to the PSAP then we are done aren't we?
> > >
> >
> > I agree that location hiding is not in the charter of this working
> group.
> > You've been among those saying it had to be considered.  What you're
> > proposing goes in a different design direction to the one the
> > working group has had so far and it goes against some base principles
> > of location in GeoPRIV contexts as well (see:  the user controls access
> to
> > his/her location)
> >
> > If what you were providing were as robust as the other methods being
> > offered we might be done, despite the design difference.  But there is
> > no consensus that this is the case.  At least Henning and I feel it is
> > more
> > fragile.  I believe there are others as well.
> >
> > >Umm, how is providing the end point with where it needs to go more
> > >fragile than giving it a bodgey location?
> > >
> >
> > It can check the location it is provided.  You can be working off a
> bodgey
> > location, and it would never know.
> >
> > Really, try the cocoa.  It's quite nice.
> >                             Ted
> >
> >
> >
> > >
> > >Cheers
> > >James
> > >-----------------------------------------------------------------------
> --
> > -----------------------
> > >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>