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 08:37:41 -0600
Hi Ted,

I think you mischaracterize my position, which is that I don't want to
do location hiding, but if some people, namely those that need to deploy
location in access network, say that we need it, then I want it done
properly and not with a half-baked solution that doesn't really serve
anyone.

To that end, if we insist upon completing the framework and phone BCP
documents quickly, the documents need to say that this issue, along with
unauthenticated access are work in progress and not propose ANY
solution.

Cheers
James



> -----Original Message-----
> From: Ted Hardie [mailto:hardie@xxxxxxxxxxxx]
> Sent: Tuesday, 11 December 2007 8:38 AM
> To: Winterbottom, James; Stark, Barbara; Brian Rosen; Dawson, Martin;
> Henning Schulzrinne
> Cc: ecrit@xxxxxxxx; Liess, Laura
> Subject: 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>