Subject: [Ecrit] ECRIT: Next Steps

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

Hi all, 

The chairs had a chat with our AD regarding the next steps with the
working group. Here is a short summary. 

It is OK for Jon to add the following documents to the charter of the
group:
* Location Hiding PS and Requirements
* Synchronizing Location-to-Service Translation (LoST) Servers
* Specifying Holes in LoST Service Boundaries

I asked the Henning and James to tell whether it is useful to merge the
last two documents or not. No useful response so far. Hence, I will
treat these two documents separately. 

I will ask the group in separate mails for a hum on these documents. 

The following items are currently outside the scope of the working group
and would, if necessary, require a rechartering:

* Unauthenticated Emergency Services
* Solution for Location Hiding

We plan to start the rechartering discussions before the next IETF
meeting. 

Another topic of interest for discussion is the "early warning topic".
There is a separate mailing list for it (see
https://www1.ietf.org/mailman/listinfo/earlywarning) and we should
discuss there what we could do and where that work could take place. 

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:39:25 -0500

>* Location Hiding PS and Requirements

What does Location Hiding really have to do with ECRIT when 
"Location" is Geopriv's charter?

---

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

It's a requirement peculiar to emergency services.  Location must be
provided (typically by regulation) for emergency calls, but not for other
uses.  We need a mechanism to restrict handing out of location to only the
emergency case.

Brian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
James M. Polk
Sent: Tuesday, May 13, 2008 10:39 AM
To: [email-masked]
Subject: Re: [Ecrit] ECRIT: Next Steps

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 13 May 2008 11:17:56 -0400

As noted before, this is not a technical requirement. This also does  
not, in any way, benefit end users or make the Internet a better  
place. This is a maximizing-profit requirement for certain operators  
and thus differs from typical IETF requirements (at least the publicly  
stated ones...).

---

From: Ted Hardie <[email-masked]>
Date: Tue, 13 May 2008 08:23:06 -0700

>uses.  We need a mechanism to restrict handing out of location to only the

You top-posted away James' point, which is that GeoPRIV in general
handles location issues.  Though you are right that handing out location
for emergency calls is mandated, there are lots of other cases where
the location-seller wants to hand out location for a single app/purpose/instance
and wants to get paid again for the next app/purpose/instance.  Having
an agreement on a common mechanism for that seems like better design
for those that believe in the requirement than is having a design that
kind-of works for emergencies and does not apply at all to other cases.

Note that I think the requirement is, in general, completely bogus.  It
is handled trivially by allowing location-selleres that wish to be paid for location
to charge for it for emergency use.  That puts the problem squarely in
the economic/regulatory realms (where it belongs) and leaves out
stupid protocol tricks to get around it.  I also fall into the camp of believing
that location information is rapidly ceasing to be data valuable enough to
charge for separately, but that is an argument for the Internet Economic
Task Force, not this one.

Color me opposed to the requirement and believing that if it is solved
at all, it ought to be generally solved.

				Ted

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 13 May 2008 09:11:11 -0700

I certainly understand ECRIT doing requirements here, but I was hoping  
the mechanisms geopriv was developing would be general enough to meet  
these needs. If not, that seems to indicate a pretty serious concern  
with the mechanisms.

---

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

This is a requirements doc.

---

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

I think that current and planned GEOPRIV mechanisms will be sufficient 
for providing selective access to location, but that's not the whole story.

There's some sort of framework document called for here that describes 
how the location access mechanisms are used.  This document is necessary 
because if different entities (callers, location providers, VSPs) make 
different assumptions about who is authorized and whose job it is to 
access location, then you can run into serious interoperability issues. 
  If you look at the solution sketches on the wiki, they're not all 
interoperable with each other (i.e., if one entity behaves as if its in 
one scenario, and another another, then the call fails).
<http://www.shingou.info/twiki/bin/view/EmergencyServices/LocationHiding>
Depending on what that framework looks like, there could be some ECRIT 
changes necessary in addition to describing how to use GEOPRIV mechanisms.

For example, several of the solutions require a mechanism to discover an 
entity that's authorized to receive location.  For emergency services, 
it seems to me that this would be an ECRIT function.  If, as Ted 
suggests, there's a more general interest in discovering services that 
are authorized to use a given access-restricted location object, then it 
might be of interest in GEOPRIV.  Note though that while LoST was 
developed in ECRIT, it has non-emergency use cases as well.

--Richard

---

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

>uses.  We need a mechanism to restrict handing out of location to only the

Isn't this a configuration choice? (and one I agree with BTW)

Why do we need a mechanism?

Diffserv is a mechanism. Shirley we don't need something like that to 
just say when and when not to include location.

---

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

>This is a requirements doc.

...which lead to solution(s) being proposed before the requirements 
are even agreed to...

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 13 May 2008 14:26:23 -0400

Actually, the solutions preceded the requirements work, and we correctly
decided to first agree on requirements before we specified mechanisms.

This is a request to work on requirements.

It's appropriate in ecrit I believe.

Brian
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
James M. Polk
Sent: Tuesday, May 13, 2008 2:11 PM
To: [email-masked]
Subject: Re: [Ecrit] ECRIT: Next Steps

---

From: <[email-masked]>
Date: Tue, 13 May 2008 22:43:53 +0300

Hi Cullen, 

>I certainly understand ECRIT doing requirements here, but I 
>was hoping the mechanisms geopriv was developing would be 
>general enough to meet these needs. If not, that seems to 
>indicate a pretty serious concern with the mechanisms.

Our discussions focused on emergency services. I don't think that the
discussion makes a lot of sense outside the emergency services space. 

The current PS and requirements / design goal document does not address
solutions. It documents the discussions we had. 

Ciao
Hannes

>> provided (typically by regulation) for emergency calls, but not for 
>> other uses.  We need a mechanism to restrict handing out of location 
>> to only the emergency case.
>>
>> Brian
>>
>> From: [email-masked] [mailto:[email-masked]] 
>On Behalf 
>> Of James M. Polk

---

From: <[email-masked]>
Date: Tue, 13 May 2008 22:48:28 +0300

It always happen that people propose solutions before the requirements
work is finished. At least in the IETF this is quite common. 

In fact, I would even argue that working on strawman proposals at the
same time as you work on requirements is a good thing since otherwise
you might get a lot of surprises later on because the requirements are
unrealistic. 

In general, you cannot prevent someone from thinking ahead....

>On Behalf Of ext James M. Polk
>Sent: 13 May, 2008 21:11
>To: [email-masked]
>...which lead to solution(s) being proposed before the 
>requirements are even agreed to...
>
>
>> > other

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 13 May 2008 12:48:06 -0700

I think I was just confused on what "PS" means. What does it mean here?

On May 13, 2008, at 12:43 PM, <[email-masked]> <[email-masked] 
 > wrote:

---

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

Oh. I should have spelled it out. That can easily be confused with
Proposed Standard. Sorry. Was meant to mean "Problem Statement" 

>From: ext Cullen Jennings [mailto:[email-masked]] 
>Sent: 13 May, 2008 22:48
>To: Tschofenig Hannes (NSN - FI/Espoo)
>Cc: [email-masked]; [email-masked]
>On May 13, 2008, at 12:43 PM, <[email-masked]> 
><[email-masked]  > wrote:
>
>> Hi Cullen,
>>
>> >I certainly understand ECRIT doing requirements here, but I was 
>> >hoping the mechanisms geopriv was developing would be 
>general enough 
>> >to meet these needs. If not, that seems to indicate a 
>pretty serious 
>> >concern with the mechanisms.
>>
>> The current PS and requirements / design goal document does not 
>> address solutions. It documents the discussions we had.
>>
>>
>> Ciao
>> Hannes
>>
>> >

---

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

It seems that you have skipped our tough location hiding discussion.
Lucky you!

This might be a good basis to read the requirements and problem
statement draft in order to tell us whether we captured the discussion
in a reasonable fashion. 

Do you volunteer? 

>>other uses.  We need a mechanism to restrict handing out of 
>location to 
>>only the emergency case.
>
>Diffserv is a mechanism. Shirley we don't need something like 
>that to just say when and when not to include location.
>
>
>>Brian
>>
>On Behalf Of

---

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

"Location Hiding" was just the name of the topic under which the
discussion took place. 
Everyone knows what is meant with it 

>Sent: 13 May, 2008 17:39

---

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 13 May 2008 17:07:28 -0500

Totally right James, I believe that I have been saying this for the best
part of a year now.

Please may the record stand that James Polk and I agree on this point
also.
I think that is 3 things this year!

> Sent: Wednesday, 14 May 2008 12:39 AM
> To: [email-masked]

------------------------------------------------------------------------------------------------
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: Cullen Jennings <[email-masked]>
Date: Tue, 13 May 2008 17:59:27 -0700

Ah, thanks, now I understand. I should have known. That makes sense.

On May 13, 2008, at 12:51 PM, <[email-masked]> <[email-masked] 

>>> location

---

From: <[email-masked]>
Date: Wed, 14 May 2008 09:59:40 +0300

James, 

You are focusing on the solution aspects and you have a very specific
solution in mind and hence you believe it belongs to GEOPRIV since you
want to dump the LoST functionality in HELD. 

Here we focus on the Problem Statement and the Requirements document. We
are not discussing the solutions. 

Ciao
Hannes

>On Behalf Of ext Winterbottom, James
>Sent: 14 May, 2008 01:07
>To: James M. Polk; [email-masked]
>Totally right James, I believe that I have been saying this 
>for the best part of a year now.
>
>Please may the record stand that James Polk and I agree on 
>this point also.
>Of