Subject: [Geopriv] Fwd: New Version Notification for draft-barnes-geopriv-lo-sec-05

From: Alissa Cooper <[email-masked]>
Date: Mon, 9 Mar 2009 16:45:08 -0400

All,

We have submitted an update to the lo-sec document, available at http://www.ietf.org/internet-drafts/draft-barnes-geopriv-lo-sec-05.txt 
. The new abstract is pasted at the and of this message.

The draft has undergone a massive revision since the -04 version,  
which was focused primarily on additional security issues that were  
identified in the process of drafting draft-ietf-geopriv-l7-lcp-ps-09.  
A good portion of the text from the -04 version was imported into the  
-05 version (in section 4), but the main focus of the document has  
shifted.

Several of the document's authors have been participating in the W3C  
Geolocation WG, and they and the others were simultaneously starting  
to note the need to be able to explain Geopriv concepts to a broader  
audience, in particular an audience comprised of web-based  
applications and services developers. We thus re-worked the lo-sec  
draft to accomplish a number of new goals:

1) Provide a high-level introduction to Geopriv for readers who may be  
unfamiliar with it;
2) Clarify certain concepts in RFCs 3693 and 3694 that have proven to  
cause confusion over the years since those documents were written  
(while not officially updating those RFCs);
3) Explain how Geopriv concepts apply to some use cases that have  
become more prominent since the publication of RFCs 3693 and 3694; and
4) Discuss the additional security considerations that were the  
original focus of lo-sec.

We discovered the need to introduce a few new concepts that are useful  
either in explaining Geopriv to newcomers or clarifying the original  
requirements.  Although this draft is (we think) consistent with the  
existing Geopriv architecture, it does use some new terms that we  
think will be helpful to understanding how Geopriv works. The changes  
to the document include:

A.  The concepts of Location Server and Location Recipient have been  
refined to address, in a generic way, one of the issues that sip-lo- 
retransmission addresses: what happens when an intermediary is both an  
LS and an LR? The lo-sec-05 document makes clear that multiples LSes  
may be involved in distributing location to an ultimate LR, and  
explains the requirements for each entity along the distribution chain.

B.  To help explain the responsibilities of Location Servers, we named  
two LS subclasses:  An LS that  can get rules directly from a Rule  
Maker is known as an "Authorized LS" (LSa), while an LS that gets its  
Rules only from an LO is known as an "Independent LS" (LSi).

C.  We attempted to clarify the difference between privacy rules that  
govern an LS's behavior and privacy rules passed in a LO by  
introducing new terms for each: Local Rules for the former and  
Forwarded Rules for the latter.

The WG will, we are sure, have lots of opinions about the proposed new  
terms and the draft at large.  We look forward to your feedback on the  
list and in San Francisco.

Alissa

Begin forwarded message:

> From: IETF I-D Submission Tool <[email-masked]>
> Date: March 9, 2009 12:20:53 PM EDT
> To: [email-masked]
> Cc: [email-masked], [email-masked], [email-masked], [email-masked] 
> , [email-masked]
> Subject: New Version Notification for draft-barnes-geopriv-lo-sec-05
>
>
> A new version of I-D, draft-barnes-geopriv-lo-sec-05.txt has been  
> successfuly submitted by Richard Barnes and posted to the IETF  
> repository.
>
> Filename:	 draft-barnes-geopriv-lo-sec
> Revision:	 05
> Title:		 An Architecture for Location and Location Privacy in  
> Internet Applications
> Creation_date:	 2009-03-09
> WG ID:		 Independent Submission
> Number_of_pages: 48
>
> Abstract:
> Location-based services (such as navigation applications, emergency
> services, management of equipment in the field) need geographic
> location information about Internet hosts, their users, and other
> related entities.  These applications need to securely gather and
> transfer location information for location services, and at the same
> time protect the privacy of the individuals involved.  This document
> describes an architecture for privacy-preserving location-based
> services in the Internet, focusing on authorization, security, and
> privacy requirements for the data formats and protocols used by these
> services.
>
>
>
> The IETF Secretariat.

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 09 Mar 2009 16:02:00 -0500

>Forwarded Rules for the latter.

without reading the ID (given that I'm still finishing my last ID 
before the deadline, so please be aware of that in this comment), I 
see an inconsistency in B and C (but mostly in B), namely the line 
above stating "An LS that can get rules directly from a Rule Maker 
..." appears to make the assumption that the rules within an LO are 
not necessarily adhered to.  It may be the wording used in this 
message, and it is not the case in the ID.

It appears to me that the two new subclasses ought to be hierarchical 
instead of one or the other, namely, LSi is a subset of LSa because 
it cannot "..get rules from the Rule Maker..." while the LSa can 
still learn rules from within the LO (i.e., within the message that 
it is processing).

James

---

From: Alissa Cooper <[email-masked]>
Date: Mon, 9 Mar 2009 17:32:00 -0400

On Mar 9, 2009, at 5:02 PM, James M. Polk wrote:

> above stating "An LS that can get rules directly from a Rule  
> Maker ..." appears to make the assumption that the rules within an  
> LO are not necessarily adhered to.  It may be the wording used in  
> this message, and it is not the case in the ID.
>

The wording in the message was unclear. The I-D does not make that  
assumption.

> It appears to me that the two new subclasses ought to be  
> hierarchical instead of one or the other, namely, LSi is a subset of  
> LSa because it cannot "..get rules from the Rule Maker..." while the  
> LSa can still learn rules from within the LO (i.e., within the  
> message that it is processing).
>

Yes, they are hierarchical. This is not explicitly stated in the I-D,  
but if it's not clear enough from the text then perhaps it should be  
made explicit.

Alissa

---

From: John Morris <[email-masked]>
Date: Mon, 9 Mar 2009 22:11:47 -0400

And James, if the draft is not sufficiently clear on this point or 
any other, let's work to get the document as crisp and clear as 
possible.  It is clear to me (as one of the original co-authors -- 
with you -- of 3693) that (a) we could use a better intro and 
overview document for Geopriv, and (b) there are some Geopriv 
concepts that would benefit from more granularity to be easily 
understandable.  We welcome any suggestions on how to explain Geopriv 
in a straightforward manner.

John

At 5:32 PM -0400 3/9/09, Alissa Cooper wrote:
>The wording in the message was unclear. The I-D does not make that assumption.
>
>>hierarchical instead of one or the other, namely, LSi is a subset 
>>of LSa because it cannot "..get rules from the Rule Maker..." while 
>>the LSa can still learn rules from within the LO (i.e., within the 
>Yes, they are hierarchical. This is not explicitly stated in the 
>I-D, but if it's not clear enough from the text then perhaps it 
>should be made explicit.
>
>Alissa
>
>
>
>
>
>
>_______________________________________________
>Geopriv mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/geopriv