RE: [Ecrit] Location hiding: Consensus?

["Winterbottom, James" <James.Winterbottom at andrew.com>]

Matt,

My real concern is that there is a huge difference for an access network
provider between:

1) Getting a LoST server to return a bunch of URIs and corresponding
service URNs for which it is designed to do based on location
information provided.

And

2) The access network asking the LoST server for the service boundaries
of each emergency URN it knows about, performs intersection on these,
and the providing the intersecting service boundary back to the
end-point. Oh, and making sure that this location doesn't have more than
16 vertices and that it addresses any holes.

Option is a practical solution to a real problem, 2 is quite frankly
ridiculous.

Cheers
James


> -----Original Message-----
> From: Matt Lepinski [mailto:mlepinski at bbn.com]
> Sent: Friday, 11 May 2007 6:22 AM
> To: Winterbottom, James
> Cc: Henning Schulzrinne; ECRIT
> Subject: Re: [Ecrit] Location hiding: Consensus?
> 
> I'm really trying to understand the fundamental disagreement between
> James and Henning and I'm failing completely.
> Any clarification of the following points would be greatly
appreciated.
> 
> 1) I believe James began by stating that there are business
requirements
> for location hiding, and that these are real requirements. I believe
> everyone participating in this thread agrees on that point. (Ignoring
> any value judgement about whether these requirements are good or evil)
> 
> 2) James seems to believe that providing "fuzzed" location to the
> end-point is a bad idea. This would seem to be a fundamental source of
> disagreement with Henning who has supported sending "fuzzed" location
to
> the end-point.
> 
> Henning's argument seems to be that PSAP URI is already a form of
> "fuzzed" location that we're already providing, and James seems to be
> concerned with the access network provider being held accountable for
> providing "low quality" location.
> 
> Is this understanding correct?
> 
> 3)The whole business relationships argument is especially confusing to
> me since it seems that both Henning and James agree that ISPs should
not
> be required to have business relationships with VSPs. (I don't think
> I've heard anyone in this thread argue against that basic point).
> 
> It is reasonable to say that a particular proposal is bad because it
> would require contractual relationships between ISPs and VSPs, but so
> far I don't think I've heard James argue in support of any particular
> proposal.
> 
> Thanks for the clarification, sorry if I'm just being dense,
> - Matt Lepinski :->
> 
> Winterbottom, James wrote:
> 
> >Your responses miss the point in almost all cases.
> >
> >If you want to use IP to location database outside of my access
network
> >control please go ahead. I will certainly not be held accountable for
> >providing you incorrect information, so I agree there may be
> >alternatives, but they are not my concern, and if you choose to use
them
> >on your head be it.
> >
> >If I give you a series of PSAP URIs and you choose to reverse
engineer
> >the service boundary, again that is your prerogative, and I can't
stop
> >you from doing it. It doesn't however, except in some very special
> >circumstances, tell you precisely where you are.
> >
> >As far as I can tell, LoST says currently, if you push in a location,
it
> >can push out a few things, one of which is the uri of a PSAP. It
doesn't
> >say that this MUST be the end-point, if it did, then the whole
> >retransmission-allowed discussion is moot. I have made no attempt to
> >change this premise.
> >
> >I simply do not understand your "business relationships" arguments.
> >ECRIT is, as far as I am concerned, directed at routing emergency
calls.
> >It has always explicitly stated that how an end-point learns it
location
> >or otherwise is out of scope and a geopriv problem. So I put to you
the
> >following the scenario, and perhaps you can explain to me where the
> >"business relationship" impact comes into play.
> >
> >1) I ask the LIS for a location, it gives me back a bunch of dial
> >strings, a corresponding bunch of PSAP URIs, and a location
reference.
> >(so far no business relationship).
> >
> >2) I make a call through my VSP in Sierra Leone (UAC to VSP
relationship
> >but this has always been agreed to).
> >
> >3a) VSP routes call to PSAP (I have a monthly calling plan), PSAP
> >answers call and uses reference (no business relationship)
> >
> >3b) VSP wants to check the URI, it uses a yet to be built LoST
interface
> >that does URI to service mapping, and either bills me, or pushes the
> >call to the PSAP (no business relationship).
> >
> >This is all in scope for ECRIT, and seems fine to me.
> >
> >If I want to use location for other servic
> > network provider should not be able to charge for this. are you
> >saying that they should not be allowed to charge for this?
> >
> >Cheers
> >James
> >
> >
> >
> >
> >
> >>-----Original Message-----
> >>From: Henning Schulzrinne [mailto:hgs at cs.columbia.edu]
> >>Sent: Thursday, 10 May 2007 12:32 PM
> >>To: Winterbottom, James
> >>Cc: ECRIT
> >>Subject: Re: [Ecrit] Location hiding: Consensus?
> >>
> >>
> >>On May 9, 2007, at 10:06 PM, Winterbottom, James wrote:
> >>
> >>
> >>
> >>>Firstly, without the business model this is not going happen
> >>>alternatives will be found, and they will likely be local
> >>>
> >>>
> >derivatives.
> >
> >
> >>>Business requirements are requirements none the less and to ignore
> >>>this
> >>>fact is silly. Two major carriers on this list have indicated that
> >>>they
> >>>will deploy this kind of solution, we can bury our heads in the
> >>>sand, or
> >>>we can solve it. See below that I think any kind of providing
> >>>
> >>>
> >partial
> >
> >
> >>>location is a bad idea.
> >>>
> >>>
> >>>
> >>If you recall the earlier discussion, we had already agreed that
> >>revealing the PSAP URL effectively reveals the PSAP coverage area,
> >>since this is generally public. Thus, trying to hide anything below
> >>that level is pointless, even if you don't believe in the fact that
> >>IP address-based location is, in most cases, at least as precise.
> >>
> >>
> >>
> >>
> >>
> >>>I don't really see ISPs necessarily competing with VSPs, they may
in
> >>>some cases but they certainly don't in others. The example is
> >>>
> >>>
> >exactly
> >
> >
> >>>the Brian's Sierra Leone case, how is my home VSP in Sierra Leone
> >>>competing with my the ISP serving my hotel in Minneapolis?
> >>>
> >>>
> >>They may not be, but the solution has to work even if they are
> >>competing. Let's say I set up a VSP that believes that location
> >>information should be freely given to my customers. You are now
> >>prohibiting me from serving my customers if I don't sign your NDA?
> >>How would you enforce that the Sierra Leonian VSP doesn't hand out
> >>location information to their customers? Should every ISP sign an
NDA
> >>with every VSP?
> >>
> >>I'm sorry,
> >>
> >>
> >ress if we re-argue the
> >
> >
> >>core ECRIT assumptions for each problem. The 'no business
> >>relationship' assumption has been in our requirements document from
> >>the very beginning. It might even be in the charter discussion.
> >>
> >>
> >>
> >>
> >>>If I provide an end-point a fuzzed location how do they know what
> >>>it is
> >>>restricted to? If it is good enough for a LoST server to then
> >>>
> >>>
> >provide
> >
> >
> >>>them with a PSAP URI, how do you ensure without a doubt that it
> >>>
> >>>
> >isn't
> >
> >
> >>>good enough to get them to a Pizza hut? How do you ensure that the
> >>>centroid will get them to the right Pizza hut? How do you stop thw
> >>>wrong
> >>>pizza hut from getting really annoyed because they keeping getting
> >>>incorrect calls? The list goes on.  Not to mention, that a LIS that
> >>>did
> >>>not previously need to know anything about service boundaries now
> >>>needs
> >>>to compute them. Please read this as "I really really really hate
> >>>
> >>>
> >any
> >
> >
> >>>solution that requires a LIS or LIS operator to do this".
> >>>
> >>>
> >>ECRIT is solving the emergency calling problem. Besides, the same
> >>problem will occur with any non-precise information, whether this is
> >>cell-sector or this artificially fuzzed data. As far as I can tell,
> >>you have not been objecting to delivering cell-sector information to
> >>end users.
> >>
> >>
> >>
> >>
> >>>I would also like to stress that I think that this is as much a
> >>>GeoPriv
> >>>problem as it is an ECRIT problem.
> >>>
> >>>
> >>>
> >>I'm sure that adding another working group is going to help us make
> >>progress...
> >>
> >>
> >>
> >>>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.
>
>-----------------------------------------------------------------------
--
> -----------------------
> >[m
> >
> >_______________________________________________
> >Ecrit mailing list
> >Ecrit at ietf.org
> >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]


_______________________________________________
Ecrit mailing list
Ecrit at ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit