idnits 2.17.00 (12 Aug 2021) /tmp/idnits12103/draft-ietf-geopriv-policy-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 11 instances of too long lines in the document, the longest one being 11 characters in excess of 72. ** There are 2 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 20, 2003) is 6788 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '1' is defined on line 1179, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 1214, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 1222, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 1229, but no explicit reference was found in the text == Outdated reference: draft-ietf-geopriv-reqs has been published as RFC 3693 ** Downref: Normative reference to an Informational draft: draft-ietf-geopriv-reqs (ref. '2') == Outdated reference: draft-ietf-geopriv-threat-analysis has been published as RFC 3694 ** Downref: Normative reference to an Informational draft: draft-ietf-geopriv-threat-analysis (ref. '3') == Outdated reference: A later version (-01) exists of draft-ietf-simple-xcap-auth-usage-00 == Outdated reference: draft-ietf-simple-xcap has been published as RFC 4825 == Outdated reference: A later version (-01) exists of draft-ietf-geopriv-dhcp-lo-option-00 == Outdated reference: draft-mealling-iana-xmlns-registry has been published as RFC 3688 == Outdated reference: A later version (-02) exists of draft-peterson-geopriv-pidf-lo-01 == Outdated reference: draft-ietf-simple-rpid has been published as RFC 4480 == Outdated reference: draft-ietf-geopriv-dhcp-civil has been published as RFC 4676 == Outdated reference: draft-ietf-impp-cpim-pidf has been published as RFC 3863 Summary: 6 errors (**), 0 flaws (~~), 17 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 GEOPRIV H. Schulzrinne 3 Internet-Draft Columbia U. 4 Expires: April 19, 2004 J. Morris 5 CDT 6 H. Tschofenig 7 J. Cuellar 8 Siemens 9 J. Polk 10 Cisco 11 October 20, 2003 13 Policy Rules for Disclosure and Modification of Geographic 14 Information 15 draft-ietf-geopriv-policy-00 17 Status of this Memo 19 This document is an Internet-Draft and is in full conformance with 20 all provisions of Section 10 of RFC2026. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that other 24 groups may also distribute working documents as Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at http:// 32 www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on April 19, 2004. 39 Copyright Notice 41 Copyright (C) The Internet Society (2003). All Rights Reserved. 43 Abstract 45 This document describes an XML schema for governing the disclosure 46 and transformation of geographic location information. It also 47 describes the goals and the non-goals of the design considerations 48 for the policy rules and the details of the attributes used within 49 the policy rules. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.1 Passive Request-Response - LS as Server (Responder) . . . . 4 55 1.2 Request-Response - LS as Client (Initiator) . . . . . . . . 4 56 1.3 Event Notification . . . . . . . . . . . . . . . . . . . . . 4 57 2. Goals and Assumptions . . . . . . . . . . . . . . . . . . . 6 58 3. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . . 8 59 4. Basic Data Model . . . . . . . . . . . . . . . . . . . . . . 9 60 4.1 Civil Location . . . . . . . . . . . . . . . . . . . . . . . 9 61 4.2 Rule Transport . . . . . . . . . . . . . . . . . . . . . . . 11 62 4.2.1 HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 63 4.2.2 SIP Message Body . . . . . . . . . . . . . . . . . . . . . . 11 64 4.2.3 Location Object . . . . . . . . . . . . . . . . . . . . . . 12 65 4.3 Securing the Location Object . . . . . . . . . . . . . . . . 12 66 4.4 Extensions . . . . . . . . . . . . . . . . . . . . . . . . . 13 67 4.5 Identification . . . . . . . . . . . . . . . . . . . . . . . 13 68 4.6 Conditions . . . . . . . . . . . . . . . . . . . . . . . . . 13 69 4.6.1 Identity of the requestor (URI) . . . . . . . . . . . . . . 14 70 4.6.2 Validity . . . . . . . . . . . . . . . . . . . . . . . . . . 14 71 4.6.3 Sphere . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 72 4.6.4 Civil Location . . . . . . . . . . . . . . . . . . . . . . . 15 73 4.6.5 Geospatial Location . . . . . . . . . . . . . . . . . . . . 16 74 4.7 Conditions . . . . . . . . . . . . . . . . . . . . . . . . . 16 75 4.8 Procedure for combining Permissions . . . . . . . . . . . . 17 76 5. Access Control for Policies . . . . . . . . . . . . . . . . 19 77 6. Actions . . . . . . . . . . . . . . . . . . . . . . . . . . 20 78 6.1 Subscription Duration . . . . . . . . . . . . . . . . . . . 20 79 6.2 Confirm Subscription . . . . . . . . . . . . . . . . . . . . 20 80 7. Transformations . . . . . . . . . . . . . . . . . . . . . . 22 81 7.1 Set D (Distribute) Flag . . . . . . . . . . . . . . . . . . 22 82 7.2 Set R (Retention) Time . . . . . . . . . . . . . . . . . . . 22 83 7.3 Keep Rule (RR) . . . . . . . . . . . . . . . . . . . . . . . 22 84 7.4 Provide Civil Location . . . . . . . . . . . . . . . . . . . 22 85 7.5 Provide Geospatial Location . . . . . . . . . . . . . . . . 23 86 7.6 Provide Timezone Flag . . . . . . . . . . . . . . . . . . . 23 87 8. Example . . . . . . . . . . . . . . . . . . . . . . . . . . 25 88 8.1 Example for a rule . . . . . . . . . . . . . . . . . . . . . 25 89 8.2 Permission-combining Example . . . . . . . . . . . . . . . . 26 90 9. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . 27 91 10. Security Considerations . . . . . . . . . . . . . . . . . . 30 92 11. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . 31 93 Normative References . . . . . . . . . . . . . . . . . . . . 34 94 Informative References . . . . . . . . . . . . . . . . . . . 35 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 36 96 A. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 38 97 B. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 39 98 Intellectual Property and Copyright Statements . . . . . . . 40 100 1. Introduction 102 Location information needs to be protected against unauthorized 103 access to preserve privacy of the owner of the location information. 104 The GEOPRIV working group has defined a protocol-independent model 105 for access to geographic information. The model includes a location 106 generator (LG) that produces location information, a location server 107 (LS) that authorizes access to location information, a location 108 recipient (LR) that requests and receives information, and a 109 rulemaker (RM) that provides policy rules to the LS which enforce 110 access control policies on access to a target. 112 Two policy rule namespaces have been defined. The first basic rule 113 set [10] can restrict how long the receiver can retain the 114 information and it can prohibit any further distribution of the 115 information. It does not allow to customize information to specific 116 receivers, for example. This document describes an enhanced rule set 117 that provides richer constrains on location objects, including the 118 basic rules in [10]. 120 We refer to any element that uses the rules in this document to 121 restrict the retention or distribution of information as a rule 122 enforcer. Typically, these are LS and LR. 124 This rule set allows the rule enforcer to enforce access restrictions 125 on location data, including prohibiting any dissemination to 126 particular individuals or during particular times. The rule maker 127 can also stipulate that only certain parts of the location object are 128 distributed to recipients or that the resolution of parts of the 129 location object is limited. 131 Below, we describe how different types of using protocols might 132 employ the rules described in this document. We assume that a basic 133 location object [10] can contain a reference to additional rule sets. 134 Note that the protocols used to query location information (between 135 LS and LR), update policies at the location server and the protocol 136 between the LG to LS and from LS to LR do not have to be the same. 138 In all cases, the abstract sequence of operations is similar. The LS 139 receives either a query for location data or receives an update for 140 the location of the target, via the using protocol. The using 141 protocol provides the identity of the requestor, either at the time 142 of the query or subscription to the location information. This 143 verified location recipient identity, together with other information 144 contained in the location information or generally available to the 145 server, is then used to search the rule set. All matching rules are 146 combined according to a merging algorithm described in this document. 147 The resulting rule is applied to the location data, yielding a 148 possibly modified location object that is delivered to the location 149 recipient. 151 A single LS may serve location data in more than one mode. Rather 152 than having different rulesets for different modes, this document 153 takes the approach of supporting all three modes in one ruleset 154 schema. Specific instances of the ruleset can omit elements that are 155 only applicable to the subscription model. The three different modes 156 are explained below. 158 1.1 Passive Request-Response - LS as Server (Responder) 160 In a passive request-response scenario, the LR queries the LS for 161 location information about the target. Examples of protocols 162 following this mode of operation include HTTP, ftp, LDAP, finger or 163 various RPC protocols, including Sun RPC, DCE, DCOM, Corba and SOAP. 165 The LS uses the rule set to prevent the transmission of information 166 to the LR by refusing the request or to filter the information by 167 removing elements or by reducing the resolution of elements. 169 1.2 Request-Response - LS as Client (Initiator) 171 Alternatively, the LS may contact the LR and convey the location 172 information, e.g., to obtain some location-specific service. 173 Examples include HTTP, SIP session setup (INVITE request), H.323 174 session setup or SMTP. 176 1.3 Event Notification 178 Event notification adds a subscription phase to the "LS as client" 179 mode of operation. A watcher or subscriber asks to be added to the 180 notification list for a particular presentity [cite] or event. When 181 the presentity changes state or the event occurs, the LS sends a 182 message to the LR containing the updated state. (Presence is a 183 special case of event notification; thus, we often use the term 184 interchangeably.) 186 In addition, the subscriber may itself add a filter to the 187 subscription, limiting the rate [cite] or content [cite] of the 188 notifications. If an event, after filtering by the 189 rulemaker-provided rules and by the subscriber-provide rules, only 190 produces the same notification content that was sent previously, no 191 event notification is sent. 193 For SIP, the model is described in more detail in [cite]. 195 Thus, for this model, a policy is needed for both subscription and 196 notification operations. While both can be expressed in separate 197 policy rulesets, it is often helpful to synchronize the two. For 198 example, it allows the location server to indicate to the subscriber 199 what kind of information the subscriber can obtain. A subscriber may 200 decide that the information is too limited to be of use and thus drop 201 the subscription before wasting its own resources or those of the LS. 202 (This does not reveal any additional information since the 203 notification has to indicate the data received.) 205 2. Goals and Assumptions 207 Below, we summarize our design goals and constraints. 209 Table representation: Each rule must be representable as a row in a 210 relational database. This design goal should allow efficient 211 policy rule implementation by utilizing standard database 212 optimization techniques. 214 Permit only: Allowing both 'permit' and 'deny' actions requires some 215 rule ordering which has implications to the update operations 216 executed on these rules. Additionally it makes distributed rule 217 sets more complicated. An advantage is the more efficient rule 218 handling. However, to avoid complex conflict resolution with 219 these rules only 'permit'. This also implies that rule ordering 220 is not important. Consequently, to make achieve a policy decision 221 it is necessary to process all policy rules. 223 Additive permissions: A query of the location recipient is matched 224 against the rules in the rule database. If several rules fire 225 then, the location recipient obtains the permissions of all rules. 227 Upgradeable: It should be possible to add additional rule elements 228 later, without breaking location servers that have not been 229 upgraded. Any such upgrades must not degrade privacy constraints, 230 but may reveal less information than the rulemaker would have 231 chosen. 233 Versioning support: In addition to the previous goal, a rule maker 234 should be able to determine which types of rule elements are 235 supported by the LS. We assume that the number of different 236 versions of rule sets is best kept modest, so that a capability 237 indication rather than an enumeration of fields is sufficient. 238 This capability indication may take the form of indicating support 239 for an XML namespace. 241 Protocol-independent: The rule set supports constraints on both 242 notifications or queries as well as subscriptions for event-based 243 systems such as presence systems. 245 No false assurance: It appears more dangerous to give the user the 246 impression that the system will prevent disclosure automatically, 247 but fail to do so with a significant probability of operator error 248 or misunderstanding, than to force the user to explicitly invoke 249 simpler rules. Among the rules proposed in earlier working group 250 discussion, rules based on weekday and time-of-day ranges seem 251 particularly subject to misinterpretation and false assumptions on 252 part of the rulemaker. (For example, a non-technical rulemaker 253 would probably assume that the rules are based on the timezone of 254 his current location, which may not be known to other components 255 of the system.) 257 3. Non-Goals 259 We explicitly decided that a number of possibly worthwhile 260 capabilities are beyond the scope of this first version. Future 261 versions may include these capabilities, using the extension 262 mechanism described in this document. Non-goals include: 264 No queries: Following the model being pursued for presence 265 information, we do not support the notion of queries where the LR 266 requests only a subset of the information available. This can 267 readily be separated into a separate rule set and has different 268 properties and authentication models. 270 No external references: Attributes within specific rules cannot refer 271 to external rule sets, databases, directories or other network 272 elements. Any such external reference would make simple database 273 implementation impossible and would severely impact the 274 scalability of the LS. External references also add significant 275 failure handling complexity. An LS would have to make decisions 276 on how long or often to attempt, what credentials to use and how 277 to query. Thus, any such queries would have to be constrained to 278 queries expressible as URIs. 280 No regular expression or wildcard matching: Conditions are matched on 281 equality or 'greater-than'-style comparisons, not regular 282 expressions, partial matches such as the SQL LIKE operator (e.g., 283 LIKE "%foo%") or glob-style matches ("*@example.com"). Most of 284 these are better expressed as explicit elements. For example, if 285 it were desired to allow domain matches, the domain of the LR 286 should be identified as a separate condition element. 288 No all-except conditions: It is not possible to express exclusion 289 conditions based on identities such as "everybody except Alice". 290 This is not only a ruleset limitation, but a limitation inherent 291 in many access control systems (such as [8]). Limitations on the 292 identity of this type do not provide rich functionality since it 293 is easy for users such as Alice to acquire a different identity 294 that is not blacklisted. 296 No repeat times: Repeat times are difficult to make work correctly, 297 due to the different time zones that LG, LS and LR may occupy. It 298 appears that suggestions for including time intervals are often 299 based on supporting work/non-work distinctions, which 300 unfortunately are difficult to capture by time alone. 302 4. Basic Data Model 304 A rule set consists of zero or more rules. The ordering of these 305 rules is immaterial. The rule set can be stored in the LS and 306 conveyed from RM to LS as a single document, in subsets or as 307 individual rules. In addition, the LO can carry these rules as a data 308 object, e.g., as multi-part MIME, or reference them via a URI. These 309 alternatives are described in more detail in Section Section 4.2. 311 While the rules are encoding in XML, this is purely an exchange 312 format between RM and LS. Additionally, if rules are attached to the 313 location object then the rules are encoded in XML. The format does 314 not imply that the RM or the LS use this format internally, e.g., in 315 matching a query with the policy rules. The rules are designed so 316 that a LS may translate the rules into a relational database table, 317 with each rule represented by one row in the database. The database 318 representation is by no means mandatory; we will use it as a 319 convenient and widely-understood example of an interna 320 representation. The database model has the advantage that operations 321 on rows have tightly defined meanings. In addition, it appears 322 plausible that larger-scale implementations will employ a backend 323 database to store and query rules, as they can then benefit from 324 existing optimized indexing, access control, scaling and integrity 325 constraint mechanisms. Smaller-scale implementations may well choose 326 different implementations, e.g., a simple traversal of the set of 327 rules. 329 A rule consists of three types of elements (or fields): conditions, 330 transformations and actions. (Some people have also used the term 331 matching rules, matching conditions or constraints for what we term 332 conditions.) One can think of the "conditions" part as the 'if' part 333 of a statement, the transformations and actions as the "then" part of 334 the statement. Since only one type of action i.e. 'permit' is 335 allowed it does not need to be represented. 337 Transforming permissions ask the entity using the rules to modify the 338 location object, e.g., to remove or modify a particular element. 339 Actions cause the location server to take a certain action, such as 340 adding a subscription. 342 4.1 Civil Location 344 TBD: The description below is only included for concreteness, since 345 a civil location object has not yet been defined and the description 346 does not make sense without. It will migrate to a separate document. 348 This designation offers street-level precision. 350 The civil location elements are as follows: 352 +----------------------+----------------------+---------------------+ 353 | Label | Description | Example | 354 +----------------------+----------------------+---------------------+ 355 | country | The country is | US | 356 | | identified by the | | 357 | | two-letter ISO 3166 | | 358 | | code. | | 359 | | | | 360 | A1 | national | New York | 361 | | subdivisions (state, | | 362 | | region, province, | | 363 | | prefecture) | | 364 | | | | 365 | A2 | county, parish, gun | King's County | 366 | | (JP), district (IN) | | 367 | | | | 368 | A3 | city, township, shi | New York | 369 | | (JP) | | 370 | | | | 371 | A4 | city division, | Manhattan | 372 | | borough, city | | 373 | | district, ward, chou | | 374 | | (JP) | | 375 | | | | 376 | A5 | neighborhood, block | Morningside Heights | 377 | | | | 378 | A6 | street | Broadway | 379 | | | | 380 | PRD | Leading street | N, W | 381 | | direction | | 382 | | | | 383 | POD | Trailing street | SW | 384 | | suffix | | 385 | | | | 386 | STS | Street suffix | Avenue, Platz, | 387 | | | Street | 388 | | | | 389 | HNO | House number, | 123 | 390 | | numeric part only. | | 391 | | | | 392 | HNS | House number suffix | A, 1/2 | 393 | | | | 394 | LMK | Landmark or vanity | Low Library | 395 | | address | | 396 | | | | 397 | LOC | Additional location | Room 543 | 398 | | information | | 399 | | | | 400 | FLR | Floor | 5 | 401 | | | | 402 | NAM | Name (residence, | Joe's Barbershop | 403 | | business or office | | 404 | | occupant) | | 405 | | | | 406 | PC | Postal code | 10027-0401 | 407 +----------------------+----------------------+---------------------+ 409 Table 1 411 4.2 Rule Transport 413 We make no assumption as to how rules are conveyed to entities within 414 the network. Purely as examples, we below describe a few plausible 415 options. None of the elements depend on the properties of how rule 416 sets are conveyed to an LS or LR. Mechanism may allow partial 417 updates of rule sets. To simplify such partial updates, we include 418 an identifier in each rule. This identifier is only unique among all 419 the rules for a single target. 421 Transaction semantics for policy rule update is not required since 422 'permit only' and 'additive permissions' properties have to be used 423 (as described in Section 2). These properties also prevent 424 inconsistency during concurrent query and update operations. 426 4.2.1 HTTP 428 A rule set could be uploaded to the LS via an HTTP POST operation or 429 more fully-featured WEBDAV. Each rule could be modeled as a single 430 'file', with the rule identifier as a file name. (Since multiple 431 rules may have the LR identity in the condition part of the rule, the 432 LR identity cannot be used.) One example of this approach includes 433 XCAP [6]. 435 The rule set can also be referenced from within a location object. 436 The attribute 'ruleset-reference' specified in Section 2.2.2 of [10] 437 and contains a URI that indicates where a fuller ruleset of policies 438 related to this object can be found. The URI MAY alternatively use 439 the CID URI scheme in which case it MUST denote a MIME body carried 440 with the Location Object by the using protocol. 442 4.2.2 SIP Message Body 444 The rule set can be carried, as a separate MIME message body, in the 445 SIP message that conveys location information from a LG (a SIP UAC) 446 via an LS (a SIP proxy) to an LR (a SIP UAS). The ruleset would then 447 govern the behavior expected of the LR. 449 4.2.3 Location Object 451 The ruleset can be carried in location objects in two ways: by 452 reference and by value. In any case the 'ruleset-reference' 453 attribute inside the LO [10] points to to the location of the rules. 455 Instead the LG or LS can include the ruleset itself. 457 One of the transformations of the ruleset is the removal of the 458 ruleset described here before further transmission. Only the whole 459 ruleset can be removed. 461 4.3 Securing the Location Object 463 The Geopriv requirements draft [2] addresses the minimal security 464 protection required for the Location Object: Mutual end-point 465 authentication, data object integrity, data object confidentiality 466 and replay protection. These security properties are implemented via 467 S/MIME and between elements. Protection for the LO includes any 468 attached authorization rules. 470 Protection is likely to be necessary against adversaries who 471 eavesdrop on the communication between the LS and the LR or the LG 472 and the LS, who tamper with the location object or who replay 473 previously recorded LOs. Securing the communication between rule 474 maker and the LS depends on the protocol which is used to perform the 475 desired actions (e.g., https). The communication between the LG and 476 the LS can also be secured using channel security. 478 If the LO is integrity and confidentiality-protected then the 479 receiving entity (LS or LR) has to be able to decrypt and to verify 480 the LO. Since the policy rules described in this document allow the 481 modification of the LO (via granularity reduction or by setting 482 flags), it is not possible to forward the LO without reapplying the 483 cryptographic protection. This is particularly true for the LS as it 484 is not the final consumer of the LO. 486 When the LS protects the LO for transmission to the LR (after 487 successful authorization), then the authenticated identity can be 488 used to select a security association to apply proper protection of 489 the location object. Securing the LO for multiple LRs is not 490 provided. 492 Instead of encrypting the LO, the LG could digitally sign the LO, 493 offering integrity, but no confidentiality. However, if the LS needs 494 to perform modifications on the LO, then it would have to break the 495 digital signature and may apply its own digital signature. 497 Since the LO is generally distributed to more than one LR, the LG 498 lacks the necessary information about the recipient and thus cannot 499 usually apply confidentially protections. 501 By default, the LS re-signs LOs if the signed LO has been modified 502 according to the rule set. If the LS receives an LO that it cannot 503 decrypt, it discards it if and only if the rule requires modification 504 of the content. 506 It remains for further study whether there should be an action that 507 discards an LO that is signed or encrypted and needs to be modified 508 according to the matching rule set. 510 4.4 Extensions 512 The format is meant to be extensible. Each new extension needs to 513 define a new namespace for its conditions and actions. A 514 rule-enforcing entity MUST drop any rules where one or more of the 515 elements or actions has an unknown namespace. It SHOULD 516 simply ignore any transformations with unknown elements. 518 This behavior is privacy-safe since it prevents adding any 519 permissions where the rule enforcer would not test for a particular 520 condition. Consider an example: If a condition "Dow Jones 521 Industrial Average" is added and a rule enforcer would ignore this 522 condition, a watcher may obtain additional information even though 523 the stock market condition is not met. Similarly, rules with unknown 524 actions must be dropped since these actions may provide additional 525 privacy protections, such as logging. Omitting transformations is 526 safe, however, since this will only prevent the inclusion of data. 528 4.5 Identification 530 Each rule has an identifier, using the 'id' parameter of the rule 531 element, which serves the purpose of partial updates as mentioned in 532 Section 4.2. The identifier is an opaque token chosen by the 533 rulemaker. A rule maker MUST NOT use the same identifier for two 534 rules that are available to the LS at the same time for a given 535 target. The combination uniquely 536 identifies a rule. 538 4.6 Conditions 540 Conditions are identified by the element in a rule. In 541 all cases, conditions elements that are missing or empty are treated 542 as if they contain a NULL value and always match. 544 4.6.1 Identity of the requestor (URI) 546 Location recipients are identified by URIs and matched by string 547 matching on the element. Matching rules are governed by the 548 URI scheme. 550 For some using protocols, the identity is encoded in the URI. It does 551 not have to be the same identity that the protocol-specific 552 authentication mechanism uses. For example, SIP URIs are sufficient 553 to describe a requestor, but the user name for the SIP Digest 554 authentication may differ from that identifier. (Some domains, for 555 example, only require a name as the user identifier, while other use 556 the full user@host form.) 558 For HTTP, the user name is not encoded in the URI. Thus, we define a 559 new pseudo-URI scheme, http-auth, that carries the user name found in 560 the authentication operation. For example, 561 http-auth:alice@example.com. 563 It is left to the URI scheme and the using protocol to designate an 564 identifier that denotes an 'anonymous user', i.e., a user that has 565 not authenticated themselves. This allows to restrict anonymous 566 access to users of a particular protocol, for example. 568 As an example, SIP can use the anonymous Digest authentication 569 mechanism to grant access to holders of a particular secret. The 570 rule sip:anonymous:myticket@anonymous.invalid would then match a 571 requestor that includes the 'secret' myticket in the password part of 572 the SIP request URI. This requires no special capabilities in the 573 ruleset described here. 575 The definition of pseudonyms is left to each URI scheme and the 576 related using protocol and any domain that it implies. For example, 577 in SIP, a pseudonym might be 'sip:user42@coldmail.example', assuming 578 that coldmail.example offers pseudonym accounts. 580 Anonymous users are treated by omitting this attribute in the rule 581 which causes a 'NULL' value to be created in the ruleset table of a 582 relational database. Any request for a location object (for a given 583 target) would match with respect to this attribute in a rule. 585 4.6.2 Validity 587 The rule validity period is expressed as a two elements, a starting 588 and ending time. Times are expressed in XML schema dateTime format. 590 An example of a rule fragment is shown below: 592 2003-08-15T10:20:00.000-05:00 593 2003-09-15T10:20:00.000-05:00 595 4.6.3 Sphere 597 The rule matches only if the target is currently in the state 598 indicated. The state may be conveyed by manual configuration of the 599 LS or by some protocol. For example, RPID provides the LG with the 600 ability to inform the LS of its current sphere. The 'sphere' element 601 is an XML schema token. An example of a rule fragment is shown 602 below: 604 work 606 4.6.4 Civil Location 608 The Civil Location matches if the current civil location of the 609 target matches all elements in the description given in the rule. 611 The civil location match includes a number of fields, including the 612 timezone, the country (expressed as a two-letter ISO 3166 code), and 613 the administrative units of [12] A1 through A6. This designation 614 offers street-level precision. 616 If the civil location of the target is not known, rules that contain 617 a civil location never match. (This case may occur, for example, if 618 location information has been removed by earlier transmitters of 619 location information or if only the geospatial location is known.) 621 If any of the elements through are specified, 622 also MUST to be specified. The schema does not enforce that the 623 specification uniquely identifies a particular location. For 624 example, it would be possible to omit the region and match only on 625 city name, so that any city sharing that name within a country would 626 match. This 'feature' is primarily designed to deal with users that 627 may not know the administrative divisions between country and city 628 level. For example, many users may not know the county for cities in 629 the United States. 631 An example of a civil location condition fragment is shown below: 633 US 634 NJ 635 Bergen 636 Leonia 637 Westview 639 4.6.5 Geospatial Location 641 The geospatial location conditions make the rule apply if the target 642 is currently located within the area bounded by a set of two 643 longitude (longitude1, longitude2) and two latitude (latitude1, 644 latitude2) values, describing a spherical trapezoid. 646 These four elements define a spherical trapezoid that is 647 characterized as follows: the northern boundary of the spherical 648 trapezoid is on the latitude given by the latitude1 element, and the 649 southern boundary is on the latitude given by the latitude2 element - 650 the western boundary is on the longitude given by the longitude1 651 element, and the eastern boundary is on the longitude given by the 652 longitude2 element. 654 4.7 Conditions 656 Conditions are in conjunctive normal form, i.e., all defined elements 657 in the rule have to match the query. It is possible to leave some 658 attributes within a row empty or omit the element altogether; these 659 attributes then assume the default value of NULL. NULL entries 660 always match. 662 Expressed in database terms, queries on the rule set can be modeled 663 as SELECT queries, as in 665 SELECT permission1,permission2, ... FROM ruleset 666 WHERE (condition1='p1' OR condition1 IS NULL) 667 AND (condition2='p2' OR condition2 IS NULL) 668 AND (...) 670 Here, p1, p2, etc. are properties of the querier, time of day or 671 properties of the target, such as its current location. The 672 attributes available for these conditions are described in Section 673 4.6. After determining the rules which fire for a given query the 674 permissions have to be combined. Combining the permissions is 675 described in Section 7 and leads to a final result which is applied 676 to the location object. 678 Expressed in programming terms, the process of determining a result 679 can be written as (the first part represents the query): 681 for each policy rule in ruleset do { 682 if ((condition1 == 'p1' || condition1 == NULL) 683 && (condition2 == 'p2' || condition2 == NULL) 684 ,.. 685 then { 686 collect permissions and add them to the firing-ruleset 687 } // end if 688 } // end for 689 result = Apply permission-combining algorithm on firering-ruleset 690 Transform location object based on result 692 Conditions can be of four datatypes: 694 a string (e.g. civil location) 696 an integer 698 a date (e.g. validity) 700 Naturally, sets are equivalent from an implementation perspective to 701 integers. 703 In addition to the equality operator, range operators ("is between"), 704 set intersection and inequality operators are also supported. Only 705 one type of operator is defined for each element. 707 4.8 Procedure for combining Permissions 709 This section describes the procedure for combining permissions in 710 case that multiple rules fire. As indicated in Section 2 permissions 711 are additive i.e. a LR obtains permissions of multiple firing rules. 712 The assumption is made that the attributes are ordered and that the 713 value of one attribute does not depend on the value of another 714 (different) attribute. 716 Combining permissions depends on the following four datatypes: 718 undefined (NULL) 720 an integer or enumeration 722 a boolean (true or false) 724 A query will be matched against all rules and any number of rules 725 might fire. The permissions of all fireing rules are combined 726 according to permission-specific combining rules. The combining 727 rules are simple and depend on the datatype: 729 Boolean: If any boolean row for a transformation is true, the result 730 is true. If all rows are either undefined or false, the result is 731 false. 733 Integer or enumeration: The result is the maximum across all rows. 734 If all rows are 'NULL', the interpretation depends on the 735 permission type. 737 5. Access Control for Policies 739 Each rule set is logically associated with exactly one target; we can 740 consider this target to be another condition column in the rule set. 741 A single rule maker can manage rule sets for a large number of 742 targets, and a location server can be provided with rules for 743 different targets by different rule makers. 745 Access restrictions to the rule set itself are beyond the scope of 746 this document. A complete geo-privacy system would need to specify 747 how a location server can verify the identity and authorization of a 748 rule maker to insert, update or delete a particular rule. 750 A simple mechanism, followed in XCAP Section 2, restricts 751 modifications to the target itself, but third-party authorizations 752 are likely to be useful. 754 6. Actions 756 Actions describe what the recipient of the rule is allowed to do if 757 the rule matches. Note that subscriptions are automatically allowed 758 for any subscriber that matches a ruleset, possibly after 759 confirmation. To refuse a subscription, the rulemaker simply omits 760 the undesirable subscriber from the ruleset. 762 Actions that modify the location object have a default value of NULL. 763 The behavior of NULL actions differs for parts of the LO describing 764 the location and parts of the LO describing usage rules. For the 765 former, only components that are explicitly included through non-NULL 766 actions are kept by the LS. For the usage rules, elements are left 767 unchanged unless a non-NULL action modifies the rule. 769 This approach ensures that extensions in the capabilities of the 770 location server do not suddenly change the behavior of the location 771 server for the same rule set. The behavior is also 772 privacy-preserving, under the assumption that removing location 773 objects can only enhance privacy and that keeping unknown usage rules 774 also does not diminuish privacy. 776 The operations defined in Section 4.8 are also applicable in this 777 context if multiple rules fire. 779 6.1 Subscription Duration 781 The Subscription Duration action only applies to event-based or 782 presence systems. It indicates the duration, measured in seconds, 783 that the watcher is allowed to subscribe to this event. This action 784 is ignored for queries. The default value is 3600 seconds (one 785 hour). 787 6.2 Confirm Subscription 789 This action only applies to using protocols that follow a 790 subscription model. 792 If the Confirm Subscription flag is set, the principal whose 793 information is being desired has to approve the subscription. The 794 subscription is marked as 'pending' while the server waits for the 795 presentity to decide. The approval mechanism depends on the using 796 protocol and is beyond the scope of this document. As an example, 797 SIP defines a mechanism where the presentity is notified of the 798 subscription attempt [cite] and then updates the ruleset to either 799 allow or refuse the subscription. 801 It is an error if both the Confirm Subscription and Subscription 802 Duration action are non-null. 804 The default value for this attribute is 'true'. 806 7. Transformations 808 In addition to the transformations below, LS MAY translate and add 809 location information. For example, they may add timezone information 810 based on civil information. 812 All transformations are privacy-safe, i.e., if a transformation is 813 NULL (i.e., if the attribute is not present or empty in a policy 814 rule), the LS removes the corresponding location information from the 815 LO and leaves the LO flags undisturbed. 817 Extensions to this document may define other transformations. 819 7.1 Set D (Distribute) Flag 821 This transformation sets the D flag in the location object to either 822 'true' or 'false'. A value of 'true' means the recipient of the LO 823 is allowed to further distribute it. A value of 'false' prevents 824 further distribution. 826 The value NULL keeps the D flag in the LO as is. 828 7.2 Set R (Retention) Time 830 The retention transformation sets the retention value in the location 831 object to the current time plus the time provided in the element, 832 measured in seconds. 834 The value NULL keeps the retention time in the LO as is. 836 7.3 Keep Rule (RR) 838 If the Keep Rule (RR) flag is set, any extended rules included in the 839 location object are kept. 841 7.4 Provide Civil Location 843 The Provide Civil Location transformation restricts the civil 844 location to one of six levels, from lowest to highest: null, 845 country, region, city, building, full. Each level includes all 846 elements included by the lower levels. The 'country' level includes 847 only the element; the 'region' level adds the element; 848 the 'city' level adds the and elements; the 'building' 849 level and the 'full' level add further civil location data as shown 850 below. 852 If this action is NULL, all civil information is removed from the LO. 854 The lattice for this attribute has the following shape: 856 Full 857 {, , , , , , , 858 , , , , , , , , 859 , , } 860 | 861 Building 862 {, , , , , , , 863 , , , , , , , } 864 | 865 City 866 {, , } 867 | 868 Region 869 {, } 870 | 871 Country 872 {} 873 | 874 'NULL' 875 {} 877 7.5 Provide Geospatial Location 879 The Provide Geospatial Location transformation restricts the 880 resolution of the geospatial location information to the number of 881 bits provided, separately for longitude and latitude. The default 882 value is zero. 884 For purposes of this transformation, longitude and latitude are 885 treated as a 34 bit fixed point value consisting of 9 bits of integer 886 and 25 bits of fraction. Altitude is treated as a fixed-point 22-bit 887 integer part with a 8-bit fraction, measured in meters. This 888 corresponds to the representation in [7], but does not constrain the 889 representation in the location object. 891 If the transformation value is NULL, all geospatial location 892 information is removed from the LO. 894 7.6 Provide Timezone Flag 896 The Provide Timezone transformation includes the timezone of the 897 target, i.e., the offset from UTC. The value of 'false' causes 898 timezone information to be excluded from the LO. 900 If the transformation value is NULL, all timezone information is 901 removed from the LO. 903 8. Example 905 This section lists some basic examples to show the functionality. 907 8.1 Example for a rule 909 This example rule illustrates a ruleset with a single rule. The rule 910 consists of three parts: an part which represents the 911 conditions, an part and a part. The 912 conditions match to a location requestor named alice@example.com. 913 The rule is valid for one month (2003-08-15 to 2003-09-15). Requests 914 only match if the target has set its sphere identifier to "work" and 915 it is currently located at the indicated civil location. The 916 indicate that the granularity of the location 917 information is reduced for both civil and for geospatial location 918 information. The D flag is set to 'true' and the rules included in 919 the LO are kept. 921 922 923 924 pres:alice@example.com 925 2003-08-15T10:20:00.000-05:00 926 2003-09-15T10:20:00.000-05:00 927 work 928 US 929 NJ 930 Bergen 931 Leonia 932 Westview 933 935 936 1800 937 true 938 940 941 region 942 10 943 true 944 true 945 9 946 9 947 6 948 949 951 953 8.2 Permission-combining Example 955 TBD: Example should go in here. 957 9. XML Schema 959 This section describes an XML schema for the authorization policies 960 described in the previous sections. It does not extend other 961 schemas. It is a preliminary version primarily to show the simplicity 962 of the policies. In [5] the XML schema in the XCAP Usages for 963 Setting Presence Authorization draft [4] to have a better alignment 964 with policies used in SIP presence. It is expected that future 965 versions of [4] will experience some changes. We do not abandon 966 either one of the approaches. 968 969 976 977 978 979 980 981 982 984 985 986 987 988 989 990 991 992 993 995 996 997 998 999 1000 1002 1003 1004 1005 1006 1007 1008 1010 1011 1012 1013 1014 1015 1016 1017 1018 1019 1022 1023 1024 1025 1026 1027 1028 1029 1030 1032 1033 1035 1036 1037 1038 1039 1040 1042 1043 1044 1045 1046 1047 1048 1049 1050 1051 1052 1053 1054 1056 1057 1058 1059 1060 1061 1062 1063 1064 1065 1067 1069 10. Security Considerations 1071 This document aims to make it simple for users to prevent the 1072 unintended disclosure of private information to third parties. The 1073 described policies accomplish this task. Threats applicable to this 1074 draft are described in [3] and requirements are addressed in [2]. 1075 Section 4.3 addresses issues of protecting the policy rules within 1076 the LO and location information itself. Aspects of privacy-safe 1077 combining permissions is illustrated in Section 7. 1079 11. Open Issues 1081 Some open issues have been identified during the process of working 1082 on this draft: 1084 Transformation: A default behavior for transformation attributes (see 1085 Section 7) has to be defined to indicate what behavior has to be 1086 assumed for omitted values (i.e. for values how appear as 'NULL' 1087 values in an attribute of row. Currently it seems that it is not 1088 sufficient to specify a single default behavior rule for all 1089 transformation attributes in order for them to be privacy-safe. 1090 Instead at least a differentiation between 1092 Attributes whose removal may lessen privacy (the R/D/microwave 1093 flags) and 1095 Attributes whose removal can only increase privacy (location 1096 objects). 1098 Extensions: More text needs to be provided on how to deal with 1099 extensions and version conflicts. 1101 Logging: Functionality for triggering logging has been started with 1102 [14] and continued in [5]. For this draft it was decided not to 1103 provide encryption and logging functionality as part of the policy 1104 rules. For logging a simple mechanism would be to just have this 1105 be a binary flag. It is then up to the LS to decide where to log 1106 this and how. One problem with logging is that it does not apply 1107 if the rule set is included in the LO. Asking the LR to log the 1108 information is meaningless in most cases since the target/RM would 1109 not be able to access this information. While logging seems 1110 simple, it also causes interactions with the retention mechanism. 1111 If someone sends a LO that says "do no retain" and "log", you have 1112 a problem. Additionally, you may want to specify exactly what gets 1113 logged: Just the fact that user A got location information at a 1114 certain time? The precise location information he did get, after 1115 filtering? Just the fact that location information was distributed 1116 to some set of users, which you can derive by looking at the rule 1117 set? Finally, logging would be done in general for each target, 1118 not just for one recipient. Hence there is a question why it 1119 should be done based on one particular rule. 1121 Encryption: For encryption similar concerns are applicable as for 1122 logging. It needs to be decided whether encryption should be 1123 handled on a per-rule basis and whether a single flag would be 1124 sufficient. Some further issues deserve attention such as: 1126 What happens if the public key is not known for the recipient? 1128 What encryption technique should I use? 1130 Should an identity be provided within the rule? 1132 What happens if this identity specifies a SIPS URI (i.e., 1133 requiring that the request be via SIP-over-TLS) and the flag is 1134 not set, should it be refused? 1136 If encryption is specified and the request was HTTP (not 1137 HTTPS), should the request be refused? 1139 Identities: A number of issues have been discussed with regard to 1140 identities of the LR (specified in the URI attribute). 1142 Authentication Types: Element E (Permission to disclose only to 1143 someone presenting a specified key) of [14] was implemented in [5] 1144 as authentication levels (see Section 2.1 in ). [4] specifies the 1145 elements and inside the acceptance 1146 permission which allows to refer to SIP specific authentication 1147 mechanisms such as None, TLS, Digest, SMIME and P-Asserted-ID. For 1148 this draft is was decided to omit these attributes since they 1149 might be difficult to understand for end users, difficult to 1150 realize since authentication levels are not universally defined 1151 and in case of specific authentication mechanisms it is difficult 1152 to imply the meaning for Geopriv. 1154 Notifications: A concept which appears to be simple is to require 1155 notice to the rule maker if location is provided (Element K of 1156 [14]. The concept of 'notice' might be meaningless without saying 1157 how. Currently there is no such mechanism define in Geopriv and 1158 therefore there are no parameters which might be needed for this 1159 operation.There are certainly many possible protocols on how to 1160 notify the RM, including event notification (using SIP, Jabber, 1161 SOAP events, etc.), email, some kind of RPC mechanism, an HTTP 1162 request to a specific address, syslog. Currently we think that 1163 this issues deserves further discussion. 1165 Permission-Combining Example: An example describing the 1166 permission-combining algorithm has to be provided for Section 8. 1167 Working on this example the concept of a 'default' rule was 1168 discussed. The term default rule refers to a rule where the 1169 condition elements are all set to 'NULL'. This rule will fire with 1170 every query. 1172 Lying: Functionality for lying by the LS is not supported. 1174 A number of other minor issues are still buried in the drafts [5], 1175 [14] and in [4]. 1177 Normative References 1179 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1180 Levels", BCP 14, RFC 2119, March 1997. 1182 [2] Cuellar, J., Morris, J., Mulligan, D., Peterson, J. and J. Polk, 1183 "Geopriv requirements", draft-ietf-geopriv-reqs-03 (work in 1184 progress), March 2003. 1186 [3] Morris, J., Danley, M. and J. Peterson, "Threat Analysis of the 1187 geopriv Protocol", draft-ietf-geopriv-threat-analysis-01 (work 1188 in progress), September 2003. 1190 Informative References 1192 [4] Rosenberg, J., "Extensible Markup Language (XML) Configuration 1193 Access Protocol (XCAP) Usages for Setting Presence 1194 Authorization", draft-ietf-simple-xcap-auth-usage-00 (work in 1195 progress), June 2003. 1197 [5] Tschofenig, H., Morris, J., Cuellar, J., Polk, J. and H. 1198 Schulzrinne, "Location Object Authorization Policies", 1199 draft-tschofenig-geopriv-authz-00 (work in progress), August 1200 2003. 1202 [6] Rosenberg, J., "The Extensible Markup Language (XML) 1203 Configuration Access Protocol (XCAP)", 1204 draft-ietf-simple-xcap-00 (work in progress), June 2003. 1206 [7] Polk, J., Schnizlein, J. and M. Linsner, "DHC Location Object 1207 within GEOPRIV", draft-ietf-geopriv-dhcp-lo-option-00 (work in 1208 progress), January 2003. 1210 [8] Gong, L., "Inside Java 2 Platform Security", Addison Wesley, 1211 Reading, Massachusetts Addison Wesley, Reading, Massachusetts, 1212 June 1999. 1214 [9] Mealling, M., "The IETF XML Registry", 1215 draft-mealling-iana-xmlns-registry-05 (work in progress), June 1216 2003. 1218 [10] Peterson, J., "A Presence-based GEOPRIV Location Object 1219 Format", DRAFT draft-peterson-geopriv-pidf-lo-01, September 1220 2003. 1222 [11] Schulzrinne, H., "RPID - Rich Presence Information Data 1223 Format", draft-ietf-simple-rpid-00 (work in progress), July 1224 2003. 1226 [12] Schulzrinne, H., "DHCP Option for Civil Location", 1227 draft-ietf-geopriv-dhcp-civil-00 (work in progress), July 2003. 1229 [13] Sugano, H. and S. Fujimoto, "Presence Information Data Format 1230 (PIDF)", draft-ietf-impp-cpim-pidf-08 (work in progress), May 1231 2003. 1233 [14] Morris, J., Mulligan, D. and J. Cuellar, "Core Privacy 1234 Protections for Geopriv Location Object", 1235 draft-morris-geopriv-core-02 (work in progress), July 2003. 1237 Authors' Addresses 1239 Henning Schulzrinne 1240 Columbia University 1241 Department of Computer Science 1242 450 Computer Science Building 1243 New York, NY 10027 1244 US 1246 Phone: +1 212 939 7042 1247 EMail: hgs+geopriv@cs.columbia.edu 1248 URI: http://www.cs.columbia.edu 1250 John B. Morris, Jr. 1251 Center for Democracy and Technology 1252 1634 I Street NW, Suite 1100 1253 Washington, DC 20006 1254 US 1256 EMail: jmorris@cdt.org 1257 URI: http://www.cdt.org 1259 Hannes Tschofenig 1260 Siemens 1261 Otto-Hahn-Ring 6 1262 Munich, Bayern 81739 1263 Germany 1265 EMail: Jorge.Cuellar@siemens.com 1266 URI: http://www.cdt.org 1268 Jorge R. Cuellar 1269 Siemens 1270 Otto-Hahn-Ring 6 1271 Munich, Bayern 81739 1272 Germany 1274 EMail: Jorge.Cuellar@siemens.com 1275 URI: http://www.cdt.org 1276 James Polk 1277 Cisco 1278 2200 East President George Bush Turnpike 1279 Richardson, Texas 75082 1280 US 1282 EMail: jmpolk@cisco.com 1284 Appendix A. Contributors 1286 Jonathan Rosenberg 1287 dynamicsoft 1288 600 Lanidex Plaza 1289 Parsippany, NJ 07054-2711 1290 USA 1291 Email: jdrosen@dynamicsoft.com 1293 Appendix B. Acknowledgments 1295 This document is based on the discussions within the IETF GEOPRIV 1296 working group. Discussions at the Geopriv Interim Meeting 2003 in 1297 Washington, D.C. helped the working group to make progress on the 1298 authorization policies based on the discussions among the 1299 participants. We would to particularly thank Jon Peterson for his 1300 helpful comments. Additionally, we would like to thank Christian 1301 Guenther for his work on the XML schema. 1303 Intellectual Property Statement 1305 The IETF takes no position regarding the validity or scope of any 1306 intellectual property or other rights that might be claimed to 1307 pertain to the implementation or use of the technology described in 1308 this document or the extent to which any license under such rights 1309 might or might not be available; neither does it represent that it 1310 has made any effort to identify any such rights. Information on the 1311 IETF's procedures with respect to rights in standards-track and 1312 standards-related documentation can be found in BCP-11. Copies of 1313 claims of rights made available for publication and any assurances of 1314 licenses to be made available, or the result of an attempt made to 1315 obtain a general license or permission for the use of such 1316 proprietary rights by implementors or users of this specification can 1317 be obtained from the IETF Secretariat. 1319 The IETF invites any interested party to bring to its attention any 1320 copyrights, patents or patent applications, or other proprietary 1321 rights which may cover technology that may be required to practice 1322 this standard. Please address the information to the IETF Executive 1323 Director. 1325 Full Copyright Statement 1327 Copyright (C) The Internet Society (2003). All Rights Reserved. 1329 This document and translations of it may be copied and furnished to 1330 others, and derivative works that comment on or otherwise explain it 1331 or assist in its implementation may be prepared, copied, published 1332 and distributed, in whole or in part, without restriction of any 1333 kind, provided that the above copyright notice and this paragraph are 1334 included on all such copies and derivative works. However, this 1335 document itself may not be modified in any way, such as by removing 1336 the copyright notice or references to the Internet Society or other 1337 Internet organizations, except as needed for the purpose of 1338 developing Internet standards in which case the procedures for 1339 copyrights defined in the Internet Standards process must be 1340 followed, or as required to translate it into languages other than 1341 English. 1343 The limited permissions granted above are perpetual and will not be 1344 revoked by the Internet Society or its successors or assignees. 1346 This document and the information contained herein is provided on an 1347 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1348 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1349 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1350 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1351 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1353 Acknowledgment 1355 Funding for the RFC Editor function is currently provided by the 1356 Internet Society.