[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Ecrit] Location hiding: Consensus?

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 services, nobody has said that the
access 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, but we are not going to make progress 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.
------------------------------------------------------------------------------------------------
[mf2]


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