Re: [Ecrit] Location hiding: Consensus?

[Andrew Newton <andy at hxr.us>]

On May 8, 2007, at 3:25 PM, Henning Schulzrinne wrote:
> Maybe lowering the !? volume would be helpful.

I didn't realize your sensitivity to punctuation.

> You had written about the commercial usefulness of country-level  
> location information as a reason that we should support hiding it.  
> This is a business model issue, in my view. Protecting commercial  
> value is certainly not a technical requirement.

So what is the reason for supporting location hiding?  Otherwise, you  
seem to be arguing that your view location hiding is correct and  
cannot be questioned.  I have simply pointed out that location hiding  
should hide all location information and that there are good reasons  
for it.  I certainly would like to hear your reasons why my arguments  
should not be considered.

> > While centroid calculations on polygons may be something we end up  
> > needing to do, the normal case would not seek to avoid holes - or  
> > jurisdictions contained entirely in another jurisdiction.   
> > However, for location hiding, the centroid calculation would have  
> > to compensate for any holes to avoid misrouting the call.
>
> However, that pothole-avoidance computation only needs to be done  
> by the LIS, not the LoST server. Thus, the computational and  
> complexity burden is imposed on the party that is restricting  
> access to location information, which seems to me to be the right  
> trade-off.

I don't think calling jurisdictions contained within other  
jurisdictions "potholes" is a good idea.  But the hole-avoidance  
computation needs to be done by the validating seeker, which is the  
VSP.  And it needs to know when it is to do the hole-avoidance vs.  
just a normal polygon lookup.

If that is not the case, perhaps I misunderstanding how this is to  
work.  Could you describe the inputs, computations, and outputs at  
every step in the process?

> > > > Issue 1-3 UAs must now be forbidden from conveying dereferenced  
> > > > location information.
> > >
> > > I don't see why. LocationConveyance supports multiple locations.
> >
> > For the normal case, there is nothing wrong with an end point  
> > dereferencing an LbyR and passing along the location information  
> > as a value.  With location-hiding, you don't want an endpoint  
> > doing this because the coarse location may have compensated for a  
> > hole and its centroid might not be accurate enough for dispatch.
>
> I think this is an instance of a general problem, namely that the  
> SIP INVITE may contain multiple locations with different  
> characteristics. For example, it could contain a (fixed) value and  
> a reference that's updated based on movement of the caller. In that  
> case, you also have a location (value) that may no longer be  
> suitable for dispatch, and another (reference) which is preferable,  
> i.e., exactly the same behavior.

Perhaps it is my reading of the phone-bcp document.  Steps 10, 11, &  
12 in section 6.1 talk about what to do here.  There are no steps  
that say "do not dereference an LbyR and use the result as an LbyV".   
Now that must be expressly disallowed, though your example above also  
provides a good reason to disallow it.

> I'd be the last to defend location hiding as desirable, but I fail  
> to see why providing no location at all is preferable to providing  
> some location. As noted on the Wiki, having some location at least  
> allows the end system/user to detect gross errors before placing a  
> call.

Well, I think it would be preferable to fully support location hiding  
rather than to only partially support it.  But suggesting that end  
users will be able to know gross location errors is a bit of wishful  
thinking.  For lat/long, I doubt most users would be able to know.   
As for civic, I always tend to get confused when I've driven into  
Montgomery Co., MD, when I'm in DC -- knowing the demarkation for  
various civic jurisdictions isn't something you can count on an end  
user understanding.

> > > > Issue 2a-2 The work around LoST discovery needs to be completed.  
> > > > This is not specific to location hiding.
> > >
> > > The issue is that LoST discovery will likely return multiple  
> > > servers. I had earlier pointed out at least three plausible  
> > > operators (ISP, VSP, general public service), provided by several  
> > > different configuration mechanisms. The UA has to use the right  
> > > one, as things will fail otherwise.
> >
> > I don't understand your point.  Do you believe codifying the  
> > preference order is difficult and too burdensome to define?
>
> Yes, because the LIS won't know what other location sources are  
> available to the end user and what services it wants to use. Would  
> this special LoST resolver be available for other lookups, e.g.,  
> generated from GPS data? Would it support non-emergency services?

-andy

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