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 _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
