Network Working Group J. Cuellar Request for Comments: 3693 Siemens AG Category: Informational J. Morris Center for Democracy & Technology D. Mulligan Samuelson Law, Technology & Public Policy Clinic J. Peterson NeuStar J. Polk Cisco February 2004 Geopriv Requirements Status of this Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved.
AbstractLocation-based services, navigation applications, emergency services, management of equipment in the field, and other location-dependent services need geographic location information about a Target (such as a user, resource or other entity). There is a need to securely gather and transfer location information for location services, while at the same time protect the privacy of the individuals involved. This document focuses on the authorization, security and privacy requirements for such location-dependent services. Specifically, it describes the requirements for the Geopriv Location Object (LO) and for the protocols that use this Location Object. This LO is envisioned to be the primary data structure used in all Geopriv protocol exchanges to securely transfer location data.
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions Used in this Document. . . . . . . . . . . . . . . 4 3. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Primary Geopriv Entities . . . . . . . . . . . . . . . . . . . 6 5. Further Geopriv Terminology. . . . . . . . . . . . . . . . . . 7 5.1. Location Information and Sighting. . . . . . . . . . . . 7 5.2. The Location Object and Using Protocol . . . . . . . . . 9 5.3. Trusted vs. Non-trusted Data Flows . . . . . . . . . . . 10 5.4. Further Geopriv Principals . . . . . . . . . . . . . . . 10 5.5. Privacy Rules. . . . . . . . . . . . . . . . . . . . . . 12 5.6. Identifiers, Authentication and Authorization. . . . . . 13 6. Scenarios and Explanatory Discussion . . . . . . . . . . . . . 15 7. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 19 7.1. Location Object. . . . . . . . . . . . . . . . . . . . . 19 7.2. The Using Protocol . . . . . . . . . . . . . . . . . . . 21 7.3. Rule based Location Data Transfer. . . . . . . . . . . . 21 7.4. Location Object Privacy and Security . . . . . . . . . . 22 7.4.1. Identity Protection. . . . . . . . . . . . . . . 22 7.4.2. Authentication Requirements. . . . . . . . . . . 23 7.4.3. Actions to be secured. . . . . . . . . . . . . . 23 7.5. Non-Requirements . . . . . . . . . . . . . . . . . . . . 24 8. Security Considerations. . . . . . . . . . . . . . . . . . . . 24 8.1. Traffic Analysis . . . . . . . . . . . . . . . . . . . . 24 8.2. Securing the Privacy Rules . . . . . . . . . . . . . . . 24 8.3. Emergency Case . . . . . . . . . . . . . . . . . . . . . 24 8.4. Identities and Anonymity . . . . . . . . . . . . . . . . 25 8.5. Unintended Target. . . . . . . . . . . . . . . . . . . . 26 9. Protocol and LO Issues for later Consideration . . . . . . . . 26 9.1. Multiple Locations in one LO . . . . . . . . . . . . . . 26 9.2. Translation Fields . . . . . . . . . . . . . . . . . . . 26 9.3. Truth Flag . . . . . . . . . . . . . . . . . . . . . . . 27 9.4. Timing Information Format. . . . . . . . . . . . . . . . 27 9.5. The Name Space of Identifiers. . . . . . . . . . . . . . 27 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 11.1. Normative Reference . . . . . . . . . . . . . . . . . . 28 11.2. Informative References . . . . . . . . . . . . . . . . . 28 12. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 29 13. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 30
Section 3 and 5.4 below, the "Rule Maker"). The ability to gather and generate a Target's location, and access to the derived or computed location, are key elements of the location- based services privacy equation. Central to a Target's privacy are (a) the identity of entities that have access to raw location data, derive or compute location, and/or have access to derived or computed location information, and (b) whether those entities can be trusted to know and follow the Privacy Rules of the user. The main principles guiding the requirements described in this document are: 1) Security of the transmission of Location Object is essential to guarantee the integrity and confidentiality of the location information. This includes authenticating the sender and receiver of the Location Object, and securing the Location Object itself. 2) A critical role is played by user-controlled Privacy Rules, which describe the restrictions imposed or permissions given by the "user" (or, as defined below, the "Rule Maker"). The Privacy Rules specify the necessary conditions that allow a Location Server to forward Location Information to a Location Recipient, and the conditions and purposes for which the Location Information can be used. 3) One type of Privacy Rules specify how location information should be filtered, depending on who the recipient is. Filtering is the process of reducing the precision or resolution of the data. A typical rule may be of the form: "my location can only be disclosed to the owner of such credentials in such precision or resolution" (e.g., "my co-workers can be told the city I am currently in"). 4) The Location Object should be able to carry a limited but core set of Privacy Rules. The exact form or expressiveness of those Rules in the core set or in the full set is not further discussed in this document, but will be discussed more extensively in future documents produced by this working group.
5) Whenever appropriate, the location information should not be linked to the real identity of the user or a static identifier easily linked back to the real identity of the user (i.e., Personally Identifiable Information such as a name, mailing address, phone number, social security number, or email address or username). Rather, the user should be able to specify which local identifier, unlinked pseudonym, or private identifier is to be bound to the location information. 6) The user may want to hide the real identities of himself and his partners, not only to eavesdroppers but also to other entities participating in the protocol. Although complete anonymity may not be appropriate for some applications because of legal constraints or because some location services may in fact need explicit identifications, most often the location services only need some type of authorization information and/or perhaps anonymous identifiers of the entities in question. RFC2119]. Note that the requirements discussed here are requirements on the generic Location Object and on using protocols for location services. Thus, for the most part, the requirements discussed in this document refer to capabilities that are mandatory-to-implement. For example, requiring that implementations support integrity is not the same thing as requiring that all protocol traffic be authenticated. In contrast, an example of a mandatory-to-use (not just mandatory-to- implement) requirement might be one that states that the user always receives a notice when his location data was not authenticated. This practice is mandatory-to-use, not just to implement.
Location Object (LO): An object conveying location information (and possibly privacy rules) to which Geopriv security mechanisms and privacy rules are to be applied. Location Recipient (LR): The entity that receives location information. It may have asked for this location explicitly (by sending a query to a location server), or it may receive this location asynchronously. Location Server (LS): The entity to which a LG publishes location objects, the recipient of queries from location receivers, and the entity that applies rules designed by the rule maker. Precision: The number of significant digits to which a value has been reliably measured. Principal: The holder/subject of the credentials, e.g., a workstation user or a network server. Resolution: The fineness of detail that can be distinguished in a measured area. Applied to Geopriv this means the finite area within provided and closed borders (ex. Latitude and Longitude boundaries). Rule Holder: The entity that provides the rules associated with a particular target for the distribution of location information. It may either 'push' rules to a location server, or a location server may 'pull' rules from the Rule Holder. Rule Maker: The authority that creates rules governing access to location information for a target (typically, this it the target themselves). Rule, or Privacy Rule: A directive that regulates an entity's activities with respect to location information, including the collection, use, disclosure, and retention of location information. Target: A person or other entity whose location is communicated by a Geopriv Location Object. Using Protocol: A protocol that carries a Location Object. Viewer: A Principal that consumes location information that is communicated by a Geopriv Location Object, but does not pass this information further.
Resolution and Precision are very close terms. Either quality can be 'reduced' to coarsen location information: 'resolution' by defining a off-center perimeter around a user's location or otherwise enlarging the area in consideration (from state to country, say) and 'precision' by discarding significant digits of positioning information (rounding off longitude and latitude from seconds to minutes, say). Another WG document discusses this topic in much more detail.
Location Recipient (LR): The LR is an element that receives notifications of Location Objects from Location Servers. The LR may render these LOs to a user or automaton in some fashion. Rule Holder (RH): The RH is an element that houses Privacy Rules for receiving, filtering and distributing Location Objects for specific Targets. An LS may query an RH for a set of rules, or rules may be pushed from the RH to an LS. The rules in the Rule Holder are populated by the Rule Maker. Thus Location Generation is the process of gathering Location Information, perhaps from multiple sources, at an IP-based Geopriv Entity, the LG, which communicates with other Geopriv Entities. Rules MUST be authenticated and protected. How this is done and in particular how to distribute the keys to the RM and other authorities is outside of the scope of this document. See also Section 8.2, "Securing the Privacy Rules". The interfaces between the Geopriv entities are not necessarily protocol interfaces; they could be internal interfaces within a single composed device. In some architectures, the Location Generator, Rule Holder, and Location Server might all be implemented in the same device. There may be several Rule Holders that enforce the Privacy Rules at a particular Location Server.
This Location Information may have been determined in many different ways, including: (a) derived or computed from information generally not available to the general public (such as information mainly available to a network or service provider), (b) determined by a Device that may not be generally publicly addressable or accessible, or (c) input or otherwise provided by a Target. As examples, the Location Information could include (a) information calculated by triangulating on a wireless signal with respect to cell phone towers, (b) longitude and latitude information determined by a Device with GPS (global positioning satellite) capabilities, (c) information manually entered into a cell phone or laptop by a Target in response to a query, or (d) automatically delivered by some other IP protocol, such as at device configuration via DHCP. Excluded from this definition is the determination of location information wholly without the knowledge or consent of the Target (or the Target's network or access service provider), based on generally available information such as an IP or e-mail address. In some cases, information like IP address can enable someone to estimate (at least roughly) a location. Commercial services exist that provide rough location information based on IP addresses. Currently, this type of location information is typically less precise than the type of location information addressed in this document. Although this type of location computation still raises significant potential privacy and public privacy concerns, such scenarios are generally outside the scope of this document. Within any given location-based transaction, the INITIAL determination of location (and thus the initial creation of Location Information) is termed a Sighting: Sighting: The initial determination of location based on non-public information (as discussed in the definition of Location Information), and the initial creation of Location Information. Some variant of the sighting information is included in the Location Object. Abstractly, it consists of two separate data fields: (Identifier, Location)
where Identifier is the identifier assigned to a Target being sighted, and Location is the current position of that Target being sighted. Not all entities may have access to exactly the same piece of sighting information. A sighting may be transformed to a new sighting pair: (Identifier-1, Location-1) before it is provided by a Location Generator or Location Server to Location Recipient. In this case, Identifier-1 may be a Pseudonym, and Location-1 may have less precision or resolution than the original value.
When defining the LO, the design should observe that the security mechanisms of the Location Object itself are to be preferred. Thus the definition of the LO MUST include some minimal crypto functionality (Req. 14 and 15). Moreover, if the RM specifies the use of a particular LO security mechanism, it MUST be used (Req. 4).
Rule Maker (RM): The individual or entity that has the authorization to set the applicable Privacy Rules for a potential Geopriv Target. In many cases this will be the owner of the Device, and in other cases this may be the user who is in possession of the Device. For example, parents may control what happens to the location information derived from a child's cell phone. A company, in contrast, may own and provide a cell phone to an employee but permit the employee to set the privacy rules. There are four scenarios in which some form of constraint or override might be placed on the Privacy Rules of the Rule Maker: 1. In the case of emergency services (such as E911 within the United States), local or national laws may require that accurate location information be transmitted in certain defined emergency call situations. The Geopriv Working Group MUST facilitate this situation. 2. In the case of legal interception, the RM may not be aware of an override directive imposed by a legal authority. It is not the expectation of the Working Group that a particular accommodation will be made to facilitate this situation. 3. In the context of an employment relationship or other contractual relationship, the owner of a particular location (such as a corporate campus) may impose constraints on the use of Privacy Rules by a Rule Maker. It is not the expectation of the Working Group that a particular accommodation will be made to facilitate this situation. 4. It is conceivable that a governmental authority may seek to impose constraints on the use of Privacy Rules by a Rule Maker in non-emergency situations. It is not the expectation of the Working Group that a particular accommodation will be made to facilitate this situation. Viewer: An individual or entity who receives location data about a Target and does not transmit the location information or information based on the Target's location (such as driving directions to or from the Target) to any party OTHER than the Target or the Rule Maker.
Data Transporter: An entity or network that receives and forwards data without processing or altering it. A Data Transporter could theoretically be involved in almost any transmission between a Device and a Location Server, a Location Server and a second Location Server, or a Location Server and a Viewer. Some location tracking scenarios may not involve a Data Transporter. Access Provider (AP): The domain that provides the initial network access or other data communications services essential for the operation of communications functions of the Device or computer equipment in which the Device operates. Often, the AP -- which will be a wireless carrier, an Internet Service Provider, or an internal corporate network -- contains the LG. Sometimes the AP has a "dumb" LG, one that transmits Geopriv LOs but does not use any part of the Geopriv Location Object. Other cases may not involve any AP, or the AP may only act as a Data Transporter. Location Storage: A Device or entity that stores raw or processed Location Information, such as a database, for any period of time longer than the duration necessary to complete an immediate transaction regarding the Location Information. The existence and data storage practices of Location Storage is crucial to privacy considerations, because this may influence what Location Information could eventually be revealed (through later distribution, technical breach, or legal processes). OECD]. Privacy Rule: A rule or set of rules that regulate an entity's activities with respect to location information, including the collection, use, disclosure, and retention of location information. In particular, the Rule describes how location information may be used by an entity and which transformed location information may be released to which entities under which conditions. Rules must be obeyed; they are not advisory.
A full set of Privacy Rules will likely include both rules that have only one possible technical meaning, and rules that will be affected by a locality's prevailing laws and customs. For example, a distribution rule of the form "my location can only be disclosed to the owner of such credentials and in such precision or resolution" has clear-cut implications for the protocol that uses the LO. But other rules, like retention or usage Rules, may have unclear technical consequences for the protocol or for the involved entities. For example, the precise scope of a retention rule stating "you may not store my location for more than 2 days" may in part turn on local laws or customs. ISO99] A pseudonym is simply a bit string which is unique as an ID and is suitable to be used for end-point authentication. Unlinked Pseudonym: A pseudonym where the linking between the pseudonym and its holder is, at least initially, not known to anybody with the possible exception of the holder himself or a trusted server of the user. See [Pfi01] (there the term is called Initially Unlinked Pseudonym). The word authentication is used in different manners. Some require that authentication associates an entity with a more or less well- known identity. This basically means that if A authenticates another entity B as being "id-B", then the label "id-B" is a well-known, or at least a linkable identity of the entity. In this case, the label "id-B" is called a publicly known identifier, and the authentication is "explicit": Explicit Authentication: The act of verifying a claimed identity as the sole originator of a message (message authentication) or as the end-point of a channel (entity authentication). Moreover, this identity is easily linked back to the real identity of the entity in question, for instance being a pre-existing static label from a predefined name space (telephone number, name, etc.)
Authorization: The act of determining if a particular right, such as access to some resource, can be granted to the presenter of a particular credential. Depending on the type of credential, authorization may or may not imply Explicit Authentication.
SCENARIO 2: Cell Phone Roaming In this example, a cell phone is used outside its home service area (roaming). Also, the cell phone service provider (cell phone Corp 2) outsourced the accounting of cell phone usage. The cell phone is not GPS-enabled. Location is derived by the cell phone network in which the Target and Device are roaming. When the Target wishes to use the cell phone, cell phone Corp 1 (AP) provides the roaming service for the Target, which sends the raw data about usage (e.g., duration of call, location in the roaming network, etc.) to cell phone Corp 2, the home service provider. Cell phone Corp 2 submits the raw data to the accounting company, which processes the raw data for the accounting statements. Finally, the raw data is sent to a data warehouse where the raw data is stored in a Location Server (e.g., computer server). Cell Phone Corp 1 Cell Phone Corp 2 ----------------- ----------------- Sighting / \ Publish / \ Device ----- | Data Transporter | --------- | Data Transporter | Target \ / Interface \ / ----------------- / ----------------- / | / | Notification / | Interface ----------- | / V ------------ / ---------- / \ / / \ / Location \ / | Location | | Storage | Location Info | Storage | | |<----------------- | | | Location | | Location | | Recipient | | Recipient | \ / \ / ------------- ---------- Here, cell phone Corp 1 is the AP and the LG. In this scenario, Cell phone Corp 2 is likely to be a Trusted entity, but cell phone Corp 1 may be Non-trusted.
SCENARIO 3: Mobile Communities and Location-Based Services The figure below shows a common scenario, where a user wants to find his friends or colleagues or wants to share his position with them or with a Location-Based Service Provider. Some of the messages use a Location Object to carry, for instance, identities or pseudonyms, credentials and proof-of-possession of them, Rules and Location Data Information, including Data Types and Precision or Resolution. Messages that do not use the Location Object and are outside of the scope of the Geopriv WG, but should be mentioned for understandability, are shown in the figure as starred arrows ("***>"). +---------+ +------------+ | | | | | Location|<** | Public | |Generator| * | Rule Holder| | | * | | +---------+\ * +------------+ \ *3 1a* * \ * * * \ ** * \ * * *1a \* * * * \ * * * \ * * * \4 * * * \ * V * \->+-----------+ +----------+ 1 | Location | | Rule |--------------------->| Server + | | Maker | | Private | +----------+ |Rule Holder| +-----------+ ^ | 3| |5 | V +----------+ | Location | | Recipient| +----------+ Assume that the Rule Maker and the Target are registered with the Location Server. The RM has somehow proven to the LS that he indeed is the owner of the privacy rights of the Target (the Target is usually a Device owned by the Rule Maker). The Rule Maker and the Location Server have agreed on the set of keys or credentials and cryptographic material that they will use to authenticate each other,
and in particular, to authenticate or sign the Rules. How this has been done is outside of the scope of the document. 1: Rule Transfer: The Rule Maker sends a Rule to the Location Server. This Rule may or may not be a field in a Location Object. 1a:Signed Rule: As an alternative, the Rule Maker may write a Rule and place it in a Public Rule Holder. The entities access the repository to read the signed Rules. 2: Location Information Request: The Location Recipient requests location information for a Target. In this request, the Location Recipient may select which location information data type it prefers. One way of requesting Location Information MAY be sending a partially filled Location Object, including only the identities of the Target and Location Recipient and the desired Data Type and precision or resolution, and providing proof of possession of the required credentials. But whether or not the using protocol understands this partially filled object as a request MAY depend on the using protocol or on the context. The Location Recipient could also specify the need for periodic location information updates, but this is probably out of the scope of Geopriv. 3: Locate: When a Location Server receives a Location Information Request for a Target which has no current location information, the server may ask the Location Generator to locate the Target. 4: Location Information: The Location Generator sends the "full" location information to the Location Server. This Location Information may or may not be embedded in a Location Object. 5: Filtered Location Information: The Location Server sends the location information to the Location Recipient. The information may be filtered in the sense that in general a less precise or a computed version of the information is being delivered.
1.6) The object MUST permit (but not require) the Privacy Rules to be enforced by a third party. 1.7) The object MUST be usable in a variety of protocols, such as HTTP and SIP, as well as local APIs. 1.8) The object MUST be usable in a secure manner even by applications on constrained devices. Req. 2. (Location Object fields) The Location Object definition MUST contain the following Fields, which MAY be optional to use: 2.1) Target Identifier 2.2) Location Recipient Identity This identity may be a multicast or group identity, used to include the Location Object in multicast-based using protocols. 2.3) Location Recipient Credential 2.4) Location Recipient Proof-of-Possession of the Credential 2.5) Location Field 2.5.1) Motion and direction vectors. This field MUST be optional. 2.6) Location Data Type When transmitting the Location Object, the sender and the receiver must agree on the data type of the location information. The using protocol may specify that the data type information is part of the Location Object or that the sender and receiver have agreed on it before the actual data transfer. 2.7) Timing information: (a) When was the Location Information accurate? (sighting time) (b) Until when considered current? TTL (Time-to-live) (This is different than a privacy rule setting a limit on data retention) 2.8) Rule Field: this field MAY be a referral to an applicable Rule (for instance, a URI to a full Rule), or it MAY contain a Limited Rule (see Req. 11), or both. 2.9) Security-headers and -trailers (for instance encryption information, hashes, or signatures) (see Req. 14 and 15). 2.10) Version number
Req. 3. (Location Data Types) 3.1) The Location Object MUST define at least one Location Data Type to be supported by all Geopriv receivers (entities that receive LOs). 3.2) The Location Object SHOULD define two Location Data Types: one for latitude / longitude / altitude coordinates and one for civil locations (City, Street, Number) supported by all Geopriv receivers (entities that receive LOs). 3.3) The latitude / longitude / altitude Data Type SHOULD also support a delta format in addition to an absolute one, used for the purpose of reducing the size of the packages or the security and confidentiality needs. 3.4) The Location Object definition SHOULD agree on further Location Data Types supported by some Geopriv entities and defined by other organizations. Section 9 (Protocol and LO Issues for later Consideration).
It is outside of our scope how Privacy Rules are managed and how a Location Server has access to the Privacy Rules. Note that it might be that some rules contain private information not intended for untrusted parties. Req. 8. (LG Rules) Even if a Location Generator is unaware of and lacks access to the full Privacy Rules defined by the Rule Maker, the Location Generator MUST transmit Location Information in compliance with instructions set by the Rule Maker. Such compliance MAY be accomplished by the Location Generator transmitting the LO only to a URI designated by the Rule Maker. Req. 9. (Viewer Rules) A Viewer does not need to be aware of the full Rules defined by the Rule Maker (because a Viewer SHOULD NOT retransmit Location Information), and thus a Viewer SHOULD receive only the subset of Privacy Rules necessary for the Viewer to handle the LO in compliance with the full Privacy Rules (such as, instruction on the time period for which the LO can be retained). Req. 10. (Full Rule language) Geopriv MAY specify a Rule language capable of expressing a wide range of privacy rules concerning location information. This Rule language MAY be an existing one, an adaptation of an existing one or a new Rule language, and it SHOULD be as simple as possible. Req. 11. (Limited Rule language) Geopriv MUST specify a limited Rule language capable of expressing a limited set of privacy rules concerning location information. This Rule language MAY be an existing one, an adaptation of an existing one or a new Rule language. The Location Object MUST include sufficient fields and data to express the limited set of privacy rules.
unauthenticated emergency server over no call completion at all, even at the risk that he is talking to an attacker or that his information is not secured.
authentication bypass for emergency calls (mentioned in Req 15.3) is to let the user have the choice of writing a Rule that says: - "If the emergency server does not authenticate itself, send the location information anyway", or - "If the emergency server does not authenticate itself, let the call fail". Second, in the case where the authentication of the emergency call fails because the user may not authenticate itself, the question arises: whose Rule to use? It is reasonable to use a default one: this location information can only be sent to an emergency center. The third situation, which should be studied in more detail, is: what to do if not only the user fails to authenticate itself, but also the emergency center is not authenticable? It is reasonable to send the Location Information anyway, but are there any security threats that must be considered?
On some occasions, a Location Server has to know who is supplying the Privacy Rules for a particular Target, while in other situations it could be enough to know that the supplier of the Rules is authorized to do so.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [Bra00] Stefan A.: Rethinking Public Key Infrastructures and Digital Certificates : Building in Privacy, MIT Press; ISBN: 0262024918; 1st edition, August, 2000 [Cha85] Chaum, David: Security without Identification, Card Computers to make Big Brother Obsolete. Original Version appeared in: Communications of the ACM, vol. 28 no. 10, October 1985 pp. 1030-1044. Revised version available at http://www.chaum.com/articles/ [ISO99] ISO99: ISO IS 15408, 1999, http://www.commoncriteria.org/. [OECD] OECD Guidelines on the Protection of Privacy and Transborder Flows of Personal Data, http://www.oecd.org. [Pfi01] Pfitzmann, Andreas; Koehntopp, Marit: Anonymity, Unobservability, and Pseudonymity - A Proposal for Terminology; in: H Federrath (Ed.): Designing Privacy Enhancing Technologies; Proc. Workshop on Design Issues in Anonymity and Unobservability; LNCS 2009; 2001; 1-9. Newer versions available at http://www.koehntopp.de/marit/pub/anon
http://www.cdt.org Deirdre K. Mulligan Samuelson Law, Technology & Public Policy Clinic Boalt Hall School of Law University of California Berkeley, CA 94720 USA EMail: email@example.com URI: http://www.law.berkeley.edu/cenpro/samuelson/ Jon Peterson NeuStar, Inc. 1800 Sutter St Suite 5707 Concord, CA 94520 USA EMail: firstname.lastname@example.org URI: http://www.neustar.biz/ James M. Polk Cisco Systems 2200 East President George Bush Turnpike Richardson, Texas 75082 USA EMail: email@example.com
BCP 78 and except as set forth therein, the authors retain all their rights. 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. Intellectual Property 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 firstname.lastname@example.org. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.