GEOPRIV H. Schulzrinne Internet-Draft Columbia U. Expires: August 15, 2006 H. Tschofenig Siemens J. Morris CDT J. Cuellar Siemens J. Polk Cisco February 11, 2006 A Document Format for Expressing Privacy Preferences for Location Information draft-ietf-geopriv-policy-08.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 15, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract Schulzrinne, et al. Expires August 15, 2006 [Page 1] Internet-Draft Geopriv Policy February 2006 This document defines an authorization policy language for controling access to location information. It extends the authorization framework of the common policy markup language to provide location- specific access control. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Basic Data Model and Processing . . . . . . . . . . . . . . . 6 4. Rule Transport . . . . . . . . . . . . . . . . . . . . . . . . 7 5. Securing the Location Object . . . . . . . . . . . . . . . . . 8 6. Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . 10 6.1. Civic Location Condition . . . . . . . . . . . . . . . . . 10 6.2. Geospatial Location Condition . . . . . . . . . . . . . . 10 6.2.1. Polygon . . . . . . . . . . . . . . . . . . . . . . . 10 6.2.2. Altitude . . . . . . . . . . . . . . . . . . . . . . . 11 7. Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 8. Transformations . . . . . . . . . . . . . . . . . . . . . . . 13 8.1. Distribution Transformation . . . . . . . . . . . . . . . 13 8.2. Retention Transformation . . . . . . . . . . . . . . . . . 13 8.3. Keep Rules Transformation . . . . . . . . . . . . . . . . 14 8.4. Civic Location Transformation . . . . . . . . . . . . . . 14 8.5. Geospatial Location Transformation . . . . . . . . . . . . 15 9. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 9.1. Rule Example with Civic Location Condition . . . . . . . . 17 9.2. Rule Example with Geospatial Location Information . . . . 19 10. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 22 11. Security Considerations . . . . . . . . . . . . . . . . . . . 25 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 12.1. Normative References . . . . . . . . . . . . . . . . . . . 26 12.2. Informative References . . . . . . . . . . . . . . . . . . 26 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 28 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 Intellectual Property and Copyright Statements . . . . . . . . . . 32 Schulzrinne, et al. Expires August 15, 2006 [Page 2] Internet-Draft Geopriv Policy February 2006 1. Introduction Location information needs to be protected against unauthorized access to preserve the privacy of the subject of the location information. In [RFC3693], a protocol-independent model for access to geographic information was defined. The model includes a Location Generator (LG) that produces Location Information (LI), a Location Server (LS) that authorizes access to LI, a location recipient (LR) that requests and receives information, and a Rulemaker (RM) that provides authorization policy rules. An authorization policy is a set of rules that regulate an entity's activities with respect to privacy-sensitive information such as location information. The data object containing LI is referred to as Location Object (LO). The basic rule set defined in PIDF-LO [RFC4119] can restrict how long the receiver can retain the information and it can prohibitfurther distribution of the information. It does not allow to customize information to specific receivers, for example. This document describes an enhanced rule set that provides richer constraints on the distribution of LOs. We refer to any entity that uses the rules in this document to restrict the retention or distribution of information as a Rule Enforcer (RE). The rule set allows the RE to enforce access restrictions on location data, including prohibiting any dissemination to particular individuals, during particular times or when the Target is located in a specific region. The RM can also stipulate that only certain parts of the location object are to be distributed to recipients or that the resolution of parts of the location object is limited. The sequence of operations is as follows. The location server receives a query for location information for a particular Target, via the using protocol. The using protocol provides the identity of the requestor, either at the time of the query or when subscribing to the location information. The authenticated identity of the location recipient, together with other information provided by the using protocol or generally available to the server, is then used for searching through the rule set. All matching rules are combined according to a merging algorithm described in [I-D.ietf-geopriv- common-policy]. The resulting rule is applied to the location data, yielding a possibly modified location object that is delivered to the location recipient. This document does not describe or mandate the protocol used to deliver location information from the location server to the location recipient, nor the protocol to update the policies or the protocol that is used by the location generator to convey location information Schulzrinne, et al. Expires August 15, 2006 [Page 3] Internet-Draft Geopriv Policy February 2006 to the location server. This document extends the framework defined in [I-D.ietf-geopriv- common-policy]. That document provides an abstract framework for expressing authorization policy rules. As specified there, each such rule consists of conditions, actions and transformations.'Conditions determine under which circumstances the location server is permitted to perform actions and transformations. Transformations regulate how a location server handles location objects; it might limit when and how data and policy can be distributed and may modify the information elements that are returned to the requestor, e.g., reducing the granularity of location information). The XML schema in Section 10 extends the XML-based authorization framework (see [I-D.ietf-geopriv-common-policy]) by introducing new members of the condition and transformation substitution groups defined there. The schema does not define new actions. To express civic location information, it makes use of that schema in [RFC4119] that defines the 'civicAddress' complex type. Schulzrinne, et al. Expires August 15, 2006 [Page 4] Internet-Draft Geopriv Policy February 2006 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. This document reuses the terminology of [RFC3693], e.g., the terms Location Server (LS) and Location Recipient (LR). This document and the common policy document [I-D.ietf-geopriv-common-policy] share the following terminology: Presentity or target: RFC 3693 uses the term Target to identify the object or person of which location information is required. The presence model described in RFC 2778 [RFC2778] uses the term presentity to describe the entity that provides presence information to a presence service. In a presence system, the target is the presentity. Watcher or Location Recipient: The receiver of location information is the Location Recipient (LR) in the terminology of RFC 3693. A watcher, i.e., an entity that requests presence information about a presentity, is a location recipient in presence systems. Authorization policy: An authorization policy is given by a rule set. A rule set contains an unordered list of rules. A rule has a conditions, an actions and a transformations part. Permission: The term permission indicates the action and transformation components of a rule. The terms 'authorization policy', 'policy' and 'rule set' are used interchangeable. The terms 'authorization policy rule', 'policy rule' and 'rule' are used interchangeable. The term 'using protocol' is defined in [RFC3693]. It refers to the protocol which is used to request access to and to return privacy sensitive data items. The geo privacy policy markup language refers to the authorization language defined in this document. The common policy markup language refers to the authorization language described in [I-D.ietf-geopriv- common-policy]. Schulzrinne, et al. Expires August 15, 2006 [Page 5] Internet-Draft Geopriv Policy February 2006 3. Basic Data Model and Processing Since the geo privacy policy markup language defined in Section 10 extends the common policy markup language in [I-D.ietf-geopriv- common-policy], this document adopts the basic data model as introduced in Section 6 of [I-D.ietf-geopriv-common-policy]. Schulzrinne, et al. Expires August 15, 2006 [Page 6] Internet-Draft Geopriv Policy February 2006 4. Rule Transport The XML data format of the GEOPRIV location object is specified in[RFC4119]. The definition of the location object there allows enhanced authorization policies associated to the location object to be referenced via a URL in the 'ruleset-reference' element containing an URI that indicates where a rule set related to the location object can be found. One of the transformations of the rule set is the removal of the rule set described here before transmission. Only the whole rule set can be removed and not individual elements such as only some conditions. Before transmitting the rules to the location recipient, unless explicitly permitted by the authorization policy, the rule set MUST be removed from the location object, since the rule set might disclose which entities the rule maker trusts (see Section 8). Schulzrinne, et al. Expires August 15, 2006 [Page 7] Internet-Draft Geopriv Policy February 2006 5. Securing the Location Object The GEOPRIV requirements document [RFC3693] addresses the minimal security protection required for the LO, namely mutual end-point authentication, data object integrity, data object confidentiality and replay protection. As proposed in[RFC4119], S/MIME SHOULD be used. Protection for the location object also includes an attached rule set. Protection is likely to be necessary against adversaries who eavesdrop on the communication between the location server and the location recipient or the location generator and the location server, who tamper with the location object or who replay previously recorded location objects. Securing the communication between rule maker and location server depends on the protocol which is used to perform the desired actions (e.g., https). The communication between the location generator and the location server can also be secured using channel security. If the location object is integrity and confidentiality-protected, then the receiving entity (location server or location recipient) has to be able to decrypt and to verify the location object. Since the authorization policy rules described in this document allow the modification of the location object, by granularity reduction or by setting flags, it is not possible to forward the location object without reapplying the cryptographic protection. This applies especially to the location server as it is not the final consumer of the location object. When the location server protects the location object for transmission to the location recipient after successful authorization, then the authenticated identity can be used to select a security association to apply proper protection of the location object. Securing the location object for multiple recipients is currently not provided. Instead of encrypting the location object, the location generator could digitally sign the location object, offering integrity protection, but no confidentiality. However, if the location server needs to modify the location object, it would have to break the digital signature and then apply its own digital signature. Since the location object is generally distributed to more than one location recipient, the location generator lacks the necessary information about the recipient and thus cannot usually apply confidentially protection. By default, the location server re-signs location objects if the Schulzrinne, et al. Expires August 15, 2006 [Page 8] Internet-Draft Geopriv Policy February 2006 signed location object has been modified according to the rule set. If the location server receives a location object that it cannot decrypt, it discards it if and only if the rule requires modification of the content. Schulzrinne, et al. Expires August 15, 2006 [Page 9] Internet-Draft Geopriv Policy February 2006 6. Conditions This section describes the location-specific conditions in a rule, namely the civic and geo-spatial location conditions. The XML elements and attributes shown below are defined by the XML schema in Section 10. 6.1. Civic Location Condition The element matches if the current location of the target matches all the values specified in the child elements of this element. The is of the 'civicAddress' complex type defined in [RFC4119]. It includes a number of fields, including the country, expressed as a two-letter ISO 3166 code, and the administrative units A1 through A6 of [I-D.ietf-geopriv-dhcp- civil]. This designation offers street-level precision. If the civic location of the target is not known, rules that contain a civic location condition never match. This case may occur, for example, if location information has been removed by earlier transmitters of location information or if only the geospatial location is known. If any of the elements through are specified, MUST also be specified. The schema does not enforce that the specification uniquely identifies a particular location. For example, it would be possible to omit the region and match only on city name, so that any city sharing that name within a country would match. This feature is primarily designed to deal with users that may not know the administrative divisions between county and city level. For example, many users may not know the county for cities in the United States. 6.2. Geospatial Location Condition The geospatial location condition allows to make authorization decisions based on the current geospatial location of the target. A rule matches if the current location of the Target is contained in either the identified polygon (see Section 6.2.1) or between a range of altitude values (see Section 6.2.2). 6.2.1. Polygon The condition matches if the longitude and latitude values of the polygon, interpreted as x and y coordinates on a plane, enclose the current location of the target. There are a number of algorithms for determining whether a point is Schulzrinne, et al. Expires August 15, 2006 [Page 10] Internet-Draft Geopriv Policy February 2006 inside a polygon. A common algorithm draws a ray from the test point to the right. The test point is inside if and only if the ray intersects the line segments making up the polygon an odd number of times. The listed points, which constitute the polygon, MUST be listed as they appear in a clockwise direction all the way around the perimeter of the single plane shape. This is the defined concept of a "Ring" within GML [GML]. The final point MUST be a repeat of the first point listed to enclose the polygon. 6.2.2. Altitude The altitude condition matches if the target altitude is defined and falls between the low and high altitude stated in the rule, measured in meters above the WGS84 sphere. If either element is omitted, the altitude range is an open range. Schulzrinne, et al. Expires August 15, 2006 [Page 11] Internet-Draft Geopriv Policy February 2006 7. Actions According to the common policy framework [I-D.ietf-geopriv-common- policy], actions and transformations included in a rule determine which operations the location server MUST execute after having received a location data access request from a location recipient that matches all conditions of this rule. Transformations regulate the location server operations that directly influence the handling of location information. Actions, on the other hand, specify all remaining types of operations the location server is obliged to execute, i.e., all operations that are not of transformation type. This document does not define new, location-specific actions. Schulzrinne, et al. Expires August 15, 2006 [Page 12] Internet-Draft Geopriv Policy February 2006 8. Transformations This policy markup language defines several elements by means of which rulemakers can specify transformations. These transformations determine whether the location server may distribute the location object at all and, if so, limits the accuracy of the location object passed by the location server to the recipient. All transformations defined in this section are privacy-safe in the sense that if the evaluation of the authorization policy related to a given location object does not produce an explicit transformation instruction, the location server MUST execute the transformation in question to ensure minimal discloure of privacy-sensitive information. Extensions to this document may define other transformations. 8.1. Distribution Transformation This transformation can be specified by means of the element whose value is of boolean type. A location server is allowed to distribute this location object if and only if all of the following conditions are satisfied: 1. the authorization policy related to the location object contains a rule with a element, 2. at least one of the rules safisfying (1) matches, and 3. the combined value of this permission is 'true' (see [I-D.ietf- geopriv-common-policy] for the term 'combined value'). In all other cases, the location server MUST NOT distribute the location object in question. In particular, this also comprises the case of an authorization policy that does not contain a rule with a element. 8.2. Retention Transformation This transformation can be specified by means of the element whose value is of integer type. A location server is allowed to retain a location object for the maximum retention time after receiving the location object, if and only if all of the following conditions are satisfied: 1. the authorization policy related to the location object contains a rule with a element, Schulzrinne, et al. Expires August 15, 2006 [Page 13] Internet-Draft Geopriv Policy February 2006 2. at least one of the rules satisfying (1) matches, and 3. the combined value of this permission is the retention time. In all other cases, the location server MUST delete the location object immediately after completing the service that makes use of the location object, such as delivering it to current subscribers in a presence system. 8.3. Keep Rules Transformation This transformation can be specified by means of the element whose value is of boolean type. For a location object subject to this rule, a location server is allowed to keep all authorization policy rules in the location object when delivering it to the location recipient if and only if all of the following econditions are satisfied: 1. the authorization policy related to the location object contains a rule with a element, 2. at least one of the rules satisfying (1) matches, and 3. the combined value of this permission is 'true'. In all other cases, the location server MUST remove all authorization policy rules from the location object. The rules are referenced from PDIF-LO via the 'ruleset-reference' element either using a URI or a CID URI scheme as described in Section 2.2.2 of [RFC4119]. The reference to the ruleset is removed and no rules are carried as MIME bodies (in case of CID URIs). 8.4. Civic Location Transformation The civic location transformation can be specified by means of the element to restrict the level of civic location information the LS is permitted to provide. From lowest to highest level, the names of these levels are: 'null', 'country', 'region', 'city', 'building', 'full'. Each level is given by a set of civic location data items such as and , ..., , as defined in [RFC4119]. Each level includes all elements included by the lower levels. The 'country' level includes only the element; the 'region' level adds the element; the 'city' level adds the and elements; the 'building' level and the 'full' level add further civic location data as shown below: Schulzrinne, et al. Expires August 15, 2006 [Page 14] Internet-Draft Geopriv Policy February 2006 full {, , , , , , , , , , , , , , , , , } | building {, , , , , , , , , , , , , , } | city {, , } | region {, } | country {} | null {} With respect to a given LO, a LS is permitted to pass civic location information corresponding to the given LO on at the level L (L = 'country', 'region', 'city', 'building', or 'full'), if and only if all of the following conditions are satisfied: 1. the authorization policy related to the LO contains a rule with a element, 2. at least one of the rules satisfying 1) matches, and 3. the combined value of this permission is the level L. In all other cases, including the case in which no rule of the authorization policy related to the given location object contains a element, the location server MUST remove all civic location information from the LO before passing it on, thereby providing the 'null' level of civic location information. 8.5. Geospatial Location Transformation The geospatial location transformation can be specified by means of the element to restrict the resolution of the geospatial location information to the value provided in the , and child elements of the element. The resolution is specified as a positive, non-zero number r. If n is the nominal coordinate value (longitude or latitude), the rounded value is computed as Schulzrinne, et al. Expires August 15, 2006 [Page 15] Internet-Draft Geopriv Policy February 2006 floor(n/r + 0.5) * r. For example, if the latitude is n=38.89868 and r=0.01, the latitude value rendered to the recipient of the location object is 38.90. If the longitude is n=77.03723 and r=0.01, the longitude is rendered as 77.04. This computation also works for r that are not integer powers of 10 or r > 1. For example, to round longitude to timezone accuracy, one would use r=15 and obtain a value of 75 in this example. For a given LO, a LS is allowed to pass the longitude or latitude value corresponding to the given LO on at the resolution value r, if and only if all of the following conditions are satisfied: 1. the authorization policy related to the location object contains a rule with a element that has a element, 2. at least one of the rules satisfying (1) matches, and 3. the combined value of this permission is r. In all other cases, the LS MUST remove the coordinate value from the geospatial location information. Schulzrinne, et al. Expires August 15, 2006 [Page 16] Internet-Draft Geopriv Policy February 2006 9. Example This section gives two simple examples for authorization policy rules that make use of the civic and the geospatial location condition. 9.1. Rule Example with Civic Location Condition This example illustrates a single rule that employs the civic location condition which matches if the current location of the target is inside the area specified by the child elements of the element. The syntax of this content complies with the 'civicAddress' complex type defined in [RFC4119]. In this example, requests match only if the Target is at his main office in a Siemens site in Munich. The rule is valid for one year as specified by the element. No actions are imposed on LSs. The section indicates that LSs are allowed to distribute the LOs with authorization policy included and the full set of civic location information, and to pass latitude and longitude values of geospatial location information on at quite a high level of resolution. Since the policy does not contain a rule with a , LSs have to delete LOs immediately upon service completion. Schulzrinne, et al. Expires August 15, 2006 [Page 17] Internet-Draft Geopriv Policy February 2006 2004-11-01T00:00:00+01:00 2005-11-01T00:00:00+01:00 DE Bavaria Munich Perlach Otto-Hahn-Ring 6 true true full 0.00001 0.00001 Schulzrinne, et al. Expires August 15, 2006 [Page 18] Internet-Draft Geopriv Policy February 2006 9.2. Rule Example with Geospatial Location Information This example illustrates a rule that employs the geospatial location condition. The rule matches if the current location of the target is inside the area specified by the child elements of the element. The individual points of the polygon have to be interpreted as points of the WGS-84 coordinate reference system, as specified by the value of the 'crsName' attribute of the element. This coordinate reference systems is also used by GPS. The given four points specify a quadrangle on the surface of the rotational ellipoid being part of the WGS-84 system, corresponding to a certain area in Washington, DC, USA. The transformation part of the example rule allows the location server to distribute location objects from which all authorization policy rules or pointers to them have been removed. The location server is permitted to retain the location objects related to the target for at most one hour. They are allowed to provide civic location information about the target at city level of precision, and geospatial location information at roughly the first decimal of precision. 2004-11-01T00:00:00+01:00 2005-11-01T00:00:00+01:00 38.8986 -77.03724 38.8986 -77.03722 Schulzrinne, et al. Expires August 15, 2006 [Page 19] Internet-Draft Geopriv Policy February 2006 38.8987 -77.03722 38.8987 -77.03724 true false 3600 city 0.2 0.1 The next ruleset indicates that the target has to be at an altitude between 1500 and 4000 meters in order for this rule to match. 2004-11-01T00:00:00+01:00 2005-11-01T00:00:00+01:00 1500.0 4000.0 true false 3600 city 0.3 0.2 Schulzrinne, et al. Expires August 15, 2006 [Page 21] Internet-Draft Geopriv Policy February 2006 10. XML Schema This section presents the XML schema that defines the geo policy language described in the previous sections. The policy markup language introduced by this schema extends the common policy markup language (see[I-D.ietf-geopriv-common-policy]) by introducing new members of the 'condition' and 'transformation' substitution groups whose heads (namely the elements and ) are specified by the common policy schema ([I-D.ietf-geopriv-common- policy]). To express civic location conditions, it imports the 'civicAddress' complex type as defined in [RFC4119]. Schulzrinne, et al. Expires August 15, 2006 [Page 22] Internet-Draft Geopriv Policy February 2006 Schulzrinne, et al. Expires August 15, 2006 [Page 23] Internet-Draft Geopriv Policy February 2006 Schulzrinne, et al. Expires August 15, 2006 [Page 24] Internet-Draft Geopriv Policy February 2006 11. Security Considerations This document aims to make it simple for users to prevent the unintended disclosure of private information to third parties. Security threats are described in [RFC3694] and are applicable to this draft as well. Security requirements are addressed in [RFC3693]. Section 5 addresses issues of protecting the policy rules within the location object and location information itself. Aspects of combining permissions in cases of multiple occurrence are treated in [I-D.ietf-geopriv-common-policy]). How the behavior of location servers can be regulated in terms of location object handling in a privacy-safe fashion is specified in Section 8. Schulzrinne, et al. Expires August 15, 2006 [Page 25] Internet-Draft Geopriv Policy February 2006 12. References 12.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", March 1997. [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. Polk, "Geopriv Requirements", RFC 3693, February 2004. [RFC3694] Danley, M., Mulligan, D., Morris, J., and J. Peterson, "Threat Analysis of the Geopriv Protocol", RFC 3694, February 2004. 12.2. Informative References [GML] OpenGIS, "OpenGIS Geography Markup Language (GML) Implementation Specification, Version 3.00, OGC 02 023r4", http://www.opengeospatial.org/docs/02-023r4.pdf, January 2003. [I-D.ietf-geopriv-common-policy] Schulzrinne, H., "A Document Format for Expressing Privacy Preferences", draft-ietf-geopriv-common-policy-06 (work in progress), October 2005. [I-D.ietf-geopriv-dhcp-civil] Schulzrinne, H., "Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information", draft-ietf-geopriv-dhcp-civil-09 (work in progress), January 2006. [I-D.ietf-simple-xcap] Rosenberg, J., "The Extensible Markup Language (XML) Configuration Access Protocol (XCAP)", draft-ietf-simple-xcap-08 (work in progress), October 2005. [RFC2518] Goland, Y., Whitehead, E., Faizi, A., Carter, S., and D. Jensen, "HTTP Extensions for Distributed Authoring -- WEBDAV", RFC 2518, February 1999. [RFC2778] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence and Instant Messaging", RFC 2778, February 2000. [RFC3825] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host Configuration Protocol Option for Coordinate-based Schulzrinne, et al. Expires August 15, 2006 [Page 26] Internet-Draft Geopriv Policy February 2006 Location Configuration Information", RFC 3825, July 2004. [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object Format", RFC 4119, December 2005. Schulzrinne, et al. Expires August 15, 2006 [Page 27] Internet-Draft Geopriv Policy February 2006 Appendix A. Contributors We would like to thank Christian Guenther for his help with an earlier version of this document. Schulzrinne, et al. Expires August 15, 2006 [Page 28] Internet-Draft Geopriv Policy February 2006 Appendix B. Acknowledgments This document is informed by the discussions within the IETF GEOPRIV working group, including discussions at the GEOPRIV interim meeting in Washington, D.C., in 2003. We particularly want to thank Allison Mankin , Randall Gellens , Andrew Newton , Ted Hardie , Jon Peterson for their help in improving the quality of this document. Schulzrinne, et al. Expires August 15, 2006 [Page 29] Internet-Draft Geopriv Policy February 2006 Authors' Addresses Henning Schulzrinne Columbia University Department of Computer Science 450 Computer Science Building New York, NY 10027 USA Phone: +1 212 939 7042 Email: schulzrinne@cs.columbia.edu URI: http://www.cs.columbia.edu/~hgs Hannes Tschofenig Siemens Otto-Hahn-Ring 6 Munich, Bavaria 81739 Germany Email: Hannes.Tschofenig@siemens.com URI: http://www.tschofenig.com John B. Morris, Jr. Center for Democracy and Technology 1634 I Street NW, Suite 1100 Washington, DC 20006 USA Email: jmorris@cdt.org URI: http://www.cdt.org Jorge R. Cuellar Siemens Otto-Hahn-Ring 6 Munich, Bavaria 81739 Germany Email: Jorge.Cuellar@siemens.com Schulzrinne, et al. Expires August 15, 2006 [Page 30] Internet-Draft Geopriv Policy February 2006 James Polk Cisco 2200 East President George Bush Turnpike Richardson, Texas 75082 USA Email: jmpolk@cisco.com Schulzrinne, et al. Expires August 15, 2006 [Page 31] Internet-Draft Geopriv Policy February 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Schulzrinne, et al. Expires August 15, 2006 [Page 32]