An Architecture for Location and Location Privacy in Internet Applications
RFC 6280

Approval announcement
Draft of message to be sent after approval:

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: Internet Architecture Board <iab@iab.org>,
    RFC Editor <rfc-editor@rfc-editor.org>,
    geopriv mailing list <geopriv@ietf.org>,
    geopriv chair <geopriv-chairs@tools.ietf.org>
Subject: Protocol Action: 'An Architecture for Location and Location Privacy in Internet Applications' to BCP (draft-ietf-geopriv-arch-03.txt)

The IESG has approved the following document:
- 'An Architecture for Location and Location Privacy in Internet
   Applications'
  (draft-ietf-geopriv-arch-03.txt) as a BCP

This document is the product of the Geographic Location/Privacy Working
Group.

The IESG contact persons are Robert Sparks and Gonzalo Camarillo.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-geopriv-arch/


Technical Summary

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. It updates RFCs 3693 and 3694, the GEOPRIV Requirements
and Threat Analysis, to reflect current WG thinking and terminology usage.


Working Group Summary

As location-based services have proliferated, the WG has found the need
for a single document that clearly articulates the GEOPRIV architecture
and terminology. This document was drafted to suit that need, and the
process of revising it allowed the WG as a whole to crystallize its
thinking about the architecture in practice and how terminology has
changed since the WG's early days.

Note that the chairs are the document editors and one of the chairs is
acting as shepherd. The ADs called consensus during the working group's
last call. The discussion during that last call was not controversial.

Document Quality

This document has received significant review by many members of the
GEOPRIV working group and has been discussed in the ECRIT working group.

Personnel

Alissa Cooper is the document shepherd. 
Robert Sparks is the responsible AD.

RFC Editor Note 

(applies to -03)

Please add the following two paragraphs to section 4.2.4 just after the description of the example LO override policy and before the paragraph that begins "Different policies may be applicable in different scenarios.":

<NEW>
The default combination policy for an LS that receives multiple rule sets is to combine them according to procedures in  Section 10 of RFC 4745 [RFC4745].  Privacy rules always grant access, i.e., the default is to deny access and rules specify conditions under which access is allowed.  Thus, when an LS is provided more than one policy document that applies to a given LO, it has been instructed to provide access when any of the rules apply.  That is, the "Union" policy is the default policy for a LS with multiple sources of policy.  An LS MAY choose to apply a more restrictive policy by ignoring some of the grants of permission in the privacy rules provided. The "Intersection" and "Override" policies above are of this latter character.  

Protocols that are used for managing rules should allow an RM to retrieve from the LS the set of rules that will ultimately be applied.  For example, in the basic HTTP-based protocol defined in [I-D.ietf-geopriv-policy-uri], an RM can use a GET request to retrieve the policy being applied by the LS and a PUT request to specify new rules.
</NEW>

Please correct the following nits (identified by Francis Dupont, GENART reviewer)

The acronyms LR and LO should be read as letters, hence "an LR" and "an LO" should be used
consistently throughout.

Section 1.3, page 6: delete the word "siloed"

Section 2.2 page 10: Recpients -> Recipients

Section 3.1.1 page 15: alamanac -> almanac

Section 3.2.4 page 22: trused -> trusted

Section 4 page 24: the LO need -> needs

Section 4 page 26: entites -> entities and undesireable -> undesirable

Section 4 page 26: confidentility -> confidentiality

Section 5.2 page 29: mutually untrusting components -> components that do not trust each other

Section 6 page 34 (LO): latitiude -> latitude