Subject: [Ecrit] Hum: draft-schulzrinne-ecrit-location-hiding-req

From: <[email-masked]>
Date: Tue, 13 May 2008 10:09:45 +0300

Hi all, 

Henning gave a presentation about this draft at previous IETF meetings.
Although this is a controversal topic we believe it is important to
capture the problem statement and the requirements. This document is NOT
meant to capture solutions -- this is something for future work. We
would therefore like to confirm the hum on the mailing list. If you have
not stated your opinion or if you object please let us know. 

Deadline for your response: 30 May 2008

Ciao
Hannes & Marc

_______________________________________________
Ecrit mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ecrit

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 13 May 2008 09:46:53 -0500

At 02:09 AM 5/13/2008, [email-masked] wrote:
>Content-class: urn:content-classes:message
>Content-Type: multipart/alternative;
>         boundary="----_=_NextPart_001_01C8B4C8.52CB610A"
>
>Hi all,
>
>Henning gave a presentation about this draft at previous IETF 
>meetings. Although this is a controversal topic we believe it is 
>important to capture the problem statement and the requirements. 
>This document is NOT meant to capture solutions -- this is something 
>for future work. We would therefore like to confirm the hum on the 
>mailing list. If you have not stated your opinion or if you object 
>please let us know.

I am opposed to anything that will enable or guide the ability of a 
user (or device on the user's behalf) to lie about where they are.  A 
user should be able to increase their target area to the point of 
"I'm in Manhattan (or just New York, or just US, or just North 
America), instead of which street address I'm on" (i.e., reducing 
one's granularity or resolution).

---

From: Richard Barnes <[email-masked]>
Date: Tue, 13 May 2008 13:39:12 -0400

I strongly support solving this problem.  However I believe the problem 
is well-enough understood at this point that we should be driving toward 
solutions, not just documenting requirements.  If we're going to add 
scope, that scope should include solutions in addition to requirements.

So I hum in favor, with additional support for pursuing solutions as well.

--Richard

[email-masked] wrote:
> ------------------------------------------------------------------------
>

---

From: Richard Barnes <[email-masked]>
Date: Tue, 13 May 2008 13:56:48 -0400

James,

I'm confused.  As I see it, location hiding doesn't do anything to 
encourage or discourage endpoints lying about their location.  If 
anything, it denies them information from which to diverge -- at worst, 
it forces them to guess about their location (for non-emergency 
services).  It doesn't give them a basis of truth from which to generate 
falsehood.

Could you explain your concern?

--Richard

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 13 May 2008 11:12:18 -0400

At least one proposed way to do this works that way; you return a location
accurate enough to get the right route out of LoST, but otherwise a large
area polygon (or some equivalent civic).

A user or a device can always lie.  Actually, that is a significant problem
for emergency services, and many of us want location signing, or some other
way to assure that the location obtained from a LIS via a device is at the
very least, a real ("MSAG valid", although that's not what we really mean
any more) address.

Brian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
James M. Polk
Sent: Tuesday, May 13, 2008 10:47 AM
To: [email-masked]; [email-masked]
Subject: Re: [Ecrit] Hum: draft-schulzrinne-ecrit-location-hiding-req

---

From: "[email-masked]" <[email-masked]>
Date: Tue, 13 May 2008 22:14:17 +0300

I guess you have to read the draft. This is not about making false
claims of where you are. 

Ciao
Hannes

>From: ext James M. Polk [mailto:[email-masked]] 
>Sent: 13 May, 2008 17:47
>To: Tschofenig Hannes (NSN - FI/Espoo); [email-masked]
>meetings. 
>>capture the problem statement and the requirements.
>I am opposed to anything that will enable or guide the ability 
>of a user (or device on the user's behalf) to lie about where 
>they are.  A user should be able to increase their target area 
>to the point of "I'm in Manhattan (or just New York, or just 
>US, or just North America), instead of which street address 
>I'm on" (i.e., reducing one's granularity or resolution).
>
>

---

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 13 May 2008 18:00:11 -0500

Then I believe that two solutions have been provided

One is a location "obscuring" solution where the end-point is provided a
location.

The other, that has been discussed, hides location by providing the
end-point with a location URI, and a set of service URNs and
corresponding destination URIs. Only the thing on the end of the
destination URI is allowed to dereference the location URI.

I will state again, that how this is done is a Geopriv problem, how it
is used in emergency communications is an ECRIT problem.

Cheers
James

> Richard Barnes
> Sent: Wednesday, 14 May 2008 3:39 AM
> To: [email-masked]
> Cc: [email-masked]
meetings.

------------------------------------------------------------------------------------------------
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]

---

From: <[email-masked]>
Date: Wed, 14 May 2008 10:00:23 +0300

No solution discussions -- PLEASE!

>From: ext Winterbottom, James [mailto:[email-masked]] 
>Sent: 14 May, 2008 02:00
>To: Richard Barnes; Tschofenig Hannes (NSN - FI/Espoo)
>Cc: [email-masked]
>Subject: RE: [Ecrit] Hum: draft-schulzrinne-ecrit-location-hiding-req
>
>One is a location "obscuring" solution where the end-point is 
>provided a location.
>
>The other, that has been discussed, hides location by 
>providing the end-point with a location URI, and a set of 
>service URNs and corresponding destination URIs. Only the 
>thing on the end of the destination URI is allowed to 
>dereference the location URI.
>
>I will state again, that how this is done is a Geopriv 
>problem, how it is used in emergency communications is an 
>ECRIT problem.
>
>Cheers
>James
>
>
>> From: [email-masked] [mailto:[email-masked]] 
>On Behalf
>Of
>> Richard Barnes
>> > capture the problem statement and the requirements. This 
>document is
>NOT

---

From: "Stark, Barbara" <[email-masked]>
Date: Wed, 14 May 2008 10:49:17 -0400

I think this is an important ecrit effort.
ecrit needs to make sure its architecture (defined through framework,
phonebcp, LoST, and LoST-related docs) meets the needs of all
stakeholders.
The service provider community has stated that "location hiding" is a
requirement, to provide buy-in to the ecrit architecture.
 
Once the requirements have been defined, this may drive solutions that
impact geopriv and ecrit efforts. I've heard potential solutions that
impact location configuration protocols (geopriv) and some that impact
LoST or even phonebcp / framework. Once we have agreed on the
requirements (which hopefully can be done quickly, given how few
requirements there appear to be), we should be able to come up with
potential solutions that are backward compatible with work done to date.
This may mean enhancements to geopriv and/or ecrit RFCs.
 
If James P thinks there needs to be a requirement that "location hiding"
mechanisms are allowed to obscure location (by specifying a large area
and saying the target is somewhere in that area), but not provide a
false location (by specifying some other specific point within the same
emergency service area), I'm ok with that. That's reasonable.
 
Backward compatibility is probably also a requirement. That is, if
devices, access networks, and services provider networks are built to
existing phonebcp requirements, the introduction of new location hiding
capabilities shouldn't cause these to break.
 
Anyway, I hum in favor of this "location hiding" requirements
documenting effort.
Barbara

________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf
Of [email-masked]
Sent: Tuesday, May 13, 2008 3:10 AM
To: [email-masked]
Subject: [Ecrit] Hum: draft-schulzrinne-ecrit-location-hiding-req

Hi all, 

Ciao 
Hannes & Marc

---

From: "Liess, Laura" <[email-masked]>
Date: Thu, 29 May 2008 16:30:56 +0200

Here is my personal hum and the hum of my company in favour of the
"location hiding requirements" documenting effort. 

An additional comment: 

James Polk also raised a very good point: users or end devices providing
false location. But, as Brian pointed out, "a user or a device can
always lie."  In my opinion, if we choose the right solution(s),
location hiding can improve this situation and minimize the risk that
users lie about the location (and make the PSAPs life easier). 

I don't want to discuss location hiding solutions, just try to an
example where, in my opinion, the location information received by the
PSAPs is more reliable with location hiding than without it.  Example:
if an end device finds out the ESRP (LOST query) based on a coarse
location and sends in the INVITE to the ESRP instead of the precise
location a location URI, the ESRP gets the precise location from the LIS
based on the location URI. The ESRP then sends the precise location
directly to the PSAP.  Both the ESRP and the LIS are local and trusted
by the local PSAP. 

Laura

  _____  

Von: [email-masked] [mailto:[email-masked]] Im Auftrag
von [email-masked]
Gesendet: Dienstag, 13. Mai 2008 09:10
An: [email-masked]
Betreff: [Ecrit] Hum: draft-schulzrinne-ecrit-location-hiding-req

Hi all, 

Ciao 
Hannes & Marc

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 29 May 2008 13:30:07 -0500

At 09:30 AM 5/29/2008, Liess, Laura wrote:
>         boundary="----_=_NextPart_001_01C8C198.9BFCB0AB"
>
>James Polk also raised a very good point: users or end devices 
>providing false location. But, as Brian pointed out, "a user or a 
>device can always lie."  In my opinion, if we choose the right 
>solution(s), location hiding can improve this situation and minimize 
>the risk that users lie about the location (and make the PSAPs life easier).
>example where, in my opinion, the location information received by 
>the PSAPs is more reliable with location hiding than without 
>it.  Example: if an end device finds out the ESRP (LOST query) based 
>on a coarse location and sends in the INVITE to the ESRP instead of 
>the precise location a location URI, the ESRP gets the precise 
>location from the LIS based on the location URI. The ESRP then sends 
>the precise location directly to the PSAP.  Both the ESRP and the 
>LIS are local and trusted by the local PSAP.

Laura - you are assuming location is always provided by-reference, 
and not by-value (as demonstrated in your example by the PSAP 
retrieving more precise location from the LIS through another 
transaction). What if the UA's location is GPS derived, or otherwise 
given to the UA by-value?

>
>Laura
>
>
>
>----------
>Von: [email-masked] [mailto:[email-masked]] Im 
>Auftrag von [email-masked]

---

From: "Liess, Laura" <[email-masked]>
Date: Fri, 30 May 2008 22:01:10 +0200

James,

The example was just one possible scenario, not the general case. 
If the UA has a location-by-value, GPS derived or received from the AN, the UA can in principle do everything with this location. 

The intention of the "location hiding" is, as Barbara already pointed out, to obscure the location, not to provide a false location. 

Laura

---

From: "James M. Polk" <[email-masked]>
Date: Fri, 30 May 2008 16:55:35 -0500

>The example was just one possible scenario, not the general case.

fair point

>If the UA has a location-by-value, GPS derived 
>or received from the AN, the UA can in principle 
>do everything with this location.
>
>The intention of the "location hiding" is, as 
>Barbara already pointed out, to obscure the 
>location, not to provide a false location.

I just can't help with the baggage of (way) 
earlier discussion in which false location was a 
goal.  I guess I'm over sensitive to that, as I 
(strongly) don't agree enabling that 
"feature".  I have always understood a user can 
lie, but in some scenarios we've defined, the 
user isn't completely involved in attaining the 
location that will be conveyed.

forgive my sensitivity on this matter.