idnits 2.17.1 draft-ietf-geopriv-lbyr-requirements-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 567. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 578. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 585. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 591. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 290 has weird spacing: '...n model for a...' == 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 (September 5, 2007) is 6076 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-geopriv-http-location-delivery' is defined on line 510, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-geopriv-l7-lcp-ps' is defined on line 515, but no explicit reference was found in the text == Unused Reference: 'RFC4119' is defined on line 537, but no explicit reference was found in the text == Outdated reference: A later version (-16) exists of draft-ietf-geopriv-http-location-delivery-01 == Outdated reference: A later version (-10) exists of draft-ietf-geopriv-l7-lcp-ps-04 == Outdated reference: A later version (-11) exists of draft-ietf-geopriv-loc-filters-01 == Outdated reference: A later version (-13) exists of draft-ietf-sip-location-conveyance-08 Summary: 1 error (**), 0 flaws (~~), 10 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 GeoPriv R. Marshall, Ed. 3 Internet-Draft TCS 4 Intended status: Informational September 5, 2007 5 Expires: March 8, 2008 7 Requirements for a Location-by-Reference Mechanism 8 draft-ietf-geopriv-lbyr-requirements-00 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on March 8, 2008. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 This document defines terminology and provides requirements relating 42 to a Location-by-Reference approach to handling location information 43 within SIP signaling and other Internet messaging. The key for a 44 Location-by-Reference mechanism is the Location URI, which is a 45 reference to a location, and is used by either an end-device or a 46 middlebox to represent a location, and is used as a key by a 47 dereferencing protocol to get a usable form of location. An example 48 application for which the Location-by-Reference mechanism is used is 49 emergency call routing with voice-over-IP (VoIP) and general Internet 50 multimedia systems, where Internet protocols are used end-to-end. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Requirements Terminology . . . . . . . . . . . . . . . . . . . 5 56 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 57 3.1. Definition of Terms . . . . . . . . . . . . . . . . . . . 6 58 4. Basic Actors . . . . . . . . . . . . . . . . . . . . . . . . . 8 59 5. High-Level Requirements for a Location Configuration 60 Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 61 6. High-Level Requirements for a Location Dereference 62 Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 63 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 64 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 65 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 66 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 67 10.1. Normative References . . . . . . . . . . . . . . . . . . . 17 68 10.2. Informative References . . . . . . . . . . . . . . . . . . 17 69 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18 70 Intellectual Property and Copyright Statements . . . . . . . . . . 19 72 1. Introduction 74 Location-based services rely on ready access to location information, 75 which can be through a direct, or indirect mechanism. While there is 76 already a direct mechanism which exists to provide location as part 77 of the SIP signaling protocol, an alternative mechanism has been 78 developed for handling location indirectly, via a location reference, 79 a reference which points to the actual location information. This 80 reference is called the location URI, and is used by the Location-by- 81 Reference mechanism. 83 Since possessing the location URI alone is insufficient to perform 84 location-based routing, the location URI must be dereferenced. Once 85 the actual location information is returned to a location recipient, 86 it can then be used as input to some location-based service, such as 87 in the case of routing a VoIP-based emergency call. 89 This document lists a set of requirements for a Location-by-Reference 90 (LbyR) mechanism, using a location URI within the SIP protocol for 91 the purpose of executing a location-based service routing request. 93 There are a variety of actions in which a location URI can be used. 94 Included in this list is the action of 'location configuration', or 95 the acquisition of the location into an end device or middlebox, 96 'location conveyance', which is the shuttling of location between SIP 97 signaling nodes, and, 'location dereferencing', which we define as 98 the action of exchanging a location URI for the actual location 99 information it points to at a dereference server, which we call a 100 Location Information Server, or LIS. 102 Each of these actions are represented by specific individual 103 protocols. A Location Configuration Protocol (LCP), is used by a 104 device or middlebox to acquire a location which already exists 105 (examples of this protocol include DHCP, LLDP-MED, and HELD). By 106 conveyance protocol, we mean a protocol which transports a location 107 URI along from node to node according to specific rules (e.g., SIP). 108 A Location Dereferencing Protocol (LDP), is used by a client to 109 resolve a location URI in exchange for location information at a LIS. 111 Though conveyance of a location URI may be discussed in general 112 terms, any requirements for conveyance using LbyR are not included, 113 and are considered out of scope. 115 In our SIP example, the LbyR is setup, instead of having a content 116 identifier (cid:) pointing to a location object within a SIP body, to 117 have a location URI carried in the SIP Geolocation header. 119 In constrast to LbyR, a direct access to location is equivalent to 120 having a location object included along with the signaling, (e.g., a 121 PIDF-LO), is referred to as the Location-by-Value (LbyV) mechanism, 122 and is treated as out of scope for this document. A separate draft 123 document exists which describes, for both LbyR and LbyV scenarios, a 124 way to convey location within SIP [I-D.ietf-sip-location-conveyance]. 126 The structure of this document first defines terminology in 127 Section 3. Then a short discussion on the basic elements which show 128 LbyR. This section on actors, Section 4 includes a basic LbyR model, 129 and describes the steps which the LbyR mechanism takes. 131 Requirements are outlined separately for the configuration step 132 (LCP), (Section 5), followed by an additional list of requirements 133 targeted toward the dereferencing step (LDP) (Section 6). 135 Location determination, which may include the processes of manual 136 provisioning, automated measurements, or location transformations, 137 (e.g., geo-coding), are beyond the scope of this document. 139 A detailed discussion of Identity information related to the caller, 140 subscriber, or device, as associated to location or location URI, is 141 also out of scope. 143 2. Requirements Terminology 145 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 146 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 147 and "OPTIONAL" in this document are to be interpreted as described in 148 RFC 2119 [RFC2119]. 150 This document outlines only requirements for an LbyR mechanism which 151 is used by two different protocols, a Location Configuration 152 Protocol, and a Location Derferencing Protocol. Each of these 153 protocols has its own unique client and server interactions, and the 154 requirements here are not intended to state what either an LCP or LDP 155 host client or server is expected to do, but rather which 156 requirements must be met by both the LCP and LDP interface protocols. 158 3. Terminology 160 3.1. Definition of Terms 162 Several of the terms presented below are based on Geopriv 163 Requirements [RFC3693], and in some cases, extended to include 164 additional language to support the LbyR model. 166 Civic location: A described location based on some understood 167 location reference system, such a jurisdictions or postal delivery 168 grid. A street address valid within the USPS system is a common 169 example. 171 Coordinate location: A reference to a geographic point which is able 172 to be located as described by a set of defined coordinates within 173 a geographic coordinate system, such as latitude and longitude, 174 within the WGS-84 datum. For example, 2-D geographic location is 175 defined as an (x,y) coordinate value pair according to the 176 distance north or south of the equator and east or west of the 177 prime meridian. A coordinate location may be absolute, or may 178 have associated uncertainty related to it's exact position, 179 depending on how it is represented. 181 Location: Either a geographic coordinate or feature representation 182 based on a specific coordinate reference system, or by other 183 identifiable information such as a street number and street name 184 within a civic, postal, or abstract location reference system. 186 Location-by-Value: The mechanism of representing location either in 187 configuration or conveyance protocols, (i.e., the actual location 188 value is included). 190 Location-by-Reference: The mechanism of representing location either 191 in configuration, conveyance, and dereferencing protocols as an 192 identifier which refers to a fully specified location, (i.e., a 193 pointer to the actual location value). 195 Location Configuration Protocol (LCP): A protocol which is used by a 196 client to acquire location or a location URI from a location 197 configuration server (e.g., (LIS)), based on information unique to 198 the client. 200 Location Dereference Protocol (LDP): A protocol which is used by a 201 client to query a location dereference server (e.g., (LIS)), based 202 on location URI input and which returns location information 203 (e.g., a PIDF-LO). 205 Location Information Server (LIS): The entity which receives a 206 client request for either location or a location reference. In 207 the latter case, also performs the dereference function for a 208 Location Refernce Identifier, in the context of the Location-by- 209 Reference model. May also be referred to as a Location 210 Information Server (LIS). In the SIP Presence architecture, the 211 LIS may be referred to as a Presence Server (PS). In this 212 document the LIS is an instance of an LS. 214 Location Object (LO): An object conveying location information (and 215 possibly privacy rules) to which Geopriv security mechanisms and 216 privacy rules are to be applied. 218 Location Recipient (LR): The entity that receives location 219 information. It may have asked for this location explicitly (by 220 sending a query containing an location URI to a location 221 configuration server), or it may receive this location 222 asynchronously. 224 Location Server (LS): The entity to which a LG publishes location 225 objects, the recipient of queries from location receivers, and the 226 entity that applies rules designed by the rule maker. 228 Location URI: An identifier which serves as a pointer to a location 229 record on a remote host (e.g., LIS). Used within an Location-by- 230 Reference (LbyR) mechanism. A location URI is provided by a 231 location configuration server, based on a client request, and is 232 the input used by the dereference protocol to retrieve the 233 associated location from a dereference server. It is assumed that 234 a LIS can function both as a configuration server and dereference 235 server. 237 Rule Maker (RM): The authority that creates rules governing access 238 to location information for a target (typically, this it the 239 target themselves). 241 Target: A person, end device, or other entity whose location is 242 communicated by a Geopriv Location Object. 244 Using Protocol: A protocol (e.g., SIP) which carries a Location 245 Object or an Location Reference Identifier. 247 4. Basic Actors 249 LbyR with Location Subscription 251 The LbyR mechanism can be used via a normal query/response mode, or 252 alternatively, by using a subscription model to get updated location. 254 In mobile wireless networks it is not efficient for the end host to 255 periodically query the LIS for up-to-date location information. This 256 is especially the case when power is a constraint or a location 257 update is not immediately needed. Furthermore, the end host might 258 want to delegate the task of retrieving and publishing location 259 information to a third party, such as to a presence server. Finally, 260 in some deployments, the network operator may not want to make 261 location information widely available. 263 These use scenarios motivated the introduction of the LbyR concept. 264 Depending on the type of reference, such as HTTP/HTTPS or SIP 265 Presence URI, different operations can be performed. While an HTTP/ 266 HTTPS URI can be resolved to location information, a SIP Presence URI 267 provides further benefits from the SUBSCRIBE/NOTIFY concept that can 268 additionally be combined with location filters 269 [I-D.ietf-geopriv-loc-filters]. 271 +-----------+ Geopriv +-----------+ 272 | | LDP (3) | Location | 273 | LIS +---------------+ Recipient | 274 | | | | 275 +-----+-----+ +----+------+ 276 | -- 277 | -- 278 | Geopriv -- 279 | LCP -- 280 | (1) -- 281 | -- Geopriv 282 | -- Using Protocol 283 | -- (e.g., SIP) 284 +-----+-----+ -- (2) 285 | Target / |-- 286 | End Host + 287 | | 288 +-----------+ 290 Figure 1: Shows the assumed communication model for a layer 7 (L7) 291 LCP and LDP: 293 Note that there is no requirement for using the same protocol in (1) 294 and (3). 296 The following list describes the location subscription approach: 298 1. The end host discovers the LIS. 300 2. The target (end host) sends a request to the LIS asking for a 301 location URI, as shown in (1) of Figure 1. 303 3. The LIS responds to the request and includes a location object 304 along with a subscription URI. 306 4. The Target puts the subscription URI into a SIP message and 307 forwards it to a Location Recipient via a using protocol, as shown in 308 (2) of Figure 1. The Location Recipient subscribes to the obtained 309 subscription URI (see (3) of Figure 1) and potentially uses a 310 location filter (see [I-D.ietf-geopriv-loc-filters]) to limit the 311 notification rate. 313 5. If the Target moves outside a certain area, indicated by a 314 location filter, the Location Recipient will receive a notification. 316 Note that the Target may also act in the role of the Location 317 Recipient whereby it would subscribe to its own location information. 318 For example, the Target obtains a subscription URI from the Geopriv 319 L7 LCP protocol. It subscribes to the URI in order to obtain its 320 current location information. A service boundary indicates the 321 bounded extent up to which the device can move without the need to 322 have an updated location, since a re-query with any location within 323 the boundary would result in the same answer returned from a 324 location-based service. 326 For LbyR, the LIS needs to maintain a list of randomized location 327 URIs for each host, timing out each of these URIs after the reference 328 expires. Location URIs need to expire to prevent the recipient of 329 such a URI from being able to (in some cases) permanently track a 330 host. Furthermore, an expiration mechanism also offers garbage 331 collection capability for the LIS. 333 Location URIs must be designed to prevent adversaries from obtaining 334 a known Target's location. There are at least two approaches: The 335 location URI contains a random component which helps obscure 336 sequential updates to location, yet still allows any holder of the 337 location URI to obtain location information. Alternatively, the 338 location URI can remain public and the LIS performs access control 339 via a separate authentication mechanism, such as HTTP digest or TLS 340 client side authentication, when resolving the reference to a 341 location object. 343 5. High-Level Requirements for a Location Configuration Protocol 345 Below, we summarize high-level design requirements needed for a 346 location-by-reference mechanism as used within the LCP. 348 C1. Location URI support - LCP: The configuration protocol MUST 349 support a location reference in URI form. 351 Motivation: It is helpful to have a consistent form of key for the 352 LbyR mechanism. 354 C2. Location URI expiration: The LCP MUST support the ability to 355 specify to the server, the length of time that a location URI will 356 be valid. 358 Motivation: Location URIs are not intended to represent a location 359 forever, and the identifier eventually may need to be recycled, or 360 may be subject to a specific window of validity, after which the 361 location reference fails to yield a location, or the location is 362 determined to be kept confidential. A configurable carried in the 363 LCP for a location URI ensures that the location reference becomes 364 invalid based on some internal LIS settings. 366 C3. Location URI cancellation: The LCP MUST support the ability to 367 request a cancellation of a specific location URI. 369 Motivation: If the client determines that in its best interest to 370 destroy the ability for a location URI to effectively be used to 371 dereference a location, then there has to be a way to nullify the 372 location URI. (This may be accomplished by setting the C2 373 configurable to 'expire=now', for example.) 375 C4. Random Generated: The location URI MUST be hard to guess, i.e., 376 it MUST contain a cryptographically random component. 378 Motivation: There is some benefit to the client if the location 379 URI is generated in an obscured manner so that its sequence, for 380 example in the case of a client's location update, can't be easy 381 guessed. 383 C5. Identity Protection - LCP : The location URI MUST NOT contain 384 any information that identifies the user, device or address of 385 record within the URI form. 387 Motivation: It is important to protect caller identity or contact 388 address from being included in the form of the location URI itself 389 when it is generated. 391 C6. Reuse flag default: The LCP MUST support the default condition 392 of a requested location URI being repeatedly reused. 394 Motivation: The requestor of a location URI, shouldn't need to 395 specify any special flag in order to receive a location URI which 396 can later be used repeatedly, such as for an updated location. 398 C7. One-time-use: The LCP MUST support the ability for the client to 399 request a 'one-time-use' location URI (e.g., via a reuse flag 400 setting). 402 Motivation: The client requesting a location URI may request a 403 location URI which has a 'one-time-use' only characteristic, as 404 opposed to a location URI having multiple reuse capability. 406 6. High-Level Requirements for a Location Dereference Protocol 408 Below, we summarize high-level design requirements needed for a 409 location-by-reference mechanism. 411 D1. Location URI support - LDP: The LDP MUST support a location 412 reference in URI form. 414 Motivation: It is required that there be consistency of use 415 between location URI formats used in an LCP and those used by a 416 LDP. 418 D2. Location URI expiration status: The LDP MUST support a message 419 indicating that for a location URI which is no longer valid, that 420 the location URI has expired. 422 Motivation: Location URIs are expected to expire, based on LCP 423 parameters, and it is therefore useful to convey the expired 424 status of the location URI in the LDP. 426 D3. Authentication: The LDP MUST support either client-side and 427 server-side authentication between client and server. 429 Motivation: It is reasonable to expect implementations of 430 authentication to vary. Some implementations may choose to 431 implement both client-side and server-side authentication, might 432 implement one only, or may implement neither. 434 D4. Dereferenced Location Form: Location URI dereferencing MUST 435 result in a well-formed PIDF-LO. 437 Motivation: This is in order to ensure both interoperation 438 consistancy and that adequate privacy rules can be adhered to, 439 since the PIDF-LO format comprises the necessary structures to 440 maintain location privacy. 442 D5. Repeated use: The LDP MUST support the ability for the same 443 location URI to be resolved more than once, based on server 444 settings and LCP parameters. 446 Motivation: According to LCP parameters, there may or may not be a 447 limit on the number of dereferencing actions at the dereference 448 server. 450 D6. Updated location: The LDP MUST support the ability for the same 451 location URI to be resolved into a continuum of location values 452 (e.g., location updates). 454 Motivation: A location URI when reused may not always result in 455 the same location value, but may be a mixture of unchanged and 456 changed location values. 458 D7. Location form: The LDP MUST support dereferenced location in 459 both coordinate and civic forms. 461 Motivation: It is important that the LDP not limit which type of 462 location gets dereferenced, since it is assumed that some 463 dereference servers may provide coordinate form of location only, 464 others may provide civic only, while some may provide both forms 465 of location. 467 7. Security Considerations 469 The LbyR mechanism currently addresses security issues as follows. 471 A location URI, regardless of its randomized construction, if 472 public, implies no safeguard against anyone being able to 473 dereference and get the location. The randomization of a location 474 URI in its naming, does help prevent some potential guessing, 475 according to some defined pattern. In the instance of one-time- 476 use location URIs, which function similarly to a pawn ticket, the 477 argument can be made that with a pawn ticket, possession implies 478 permission, and location URIs which are public are protected only 479 by privacy rules enforced at the dereference server. 481 Additional security issues will be discussed in a separate geopriv 482 document. 484 8. IANA Considerations 486 This document does not require actions by the IANA. 488 9. Acknowledgements 490 I would like to thank the IETF GEOPRIV working group chairs, Andy 491 Newton, Allison Mankin and Randall Gellens, for creating the design 492 team which initiated this requirements work. 494 I also would like to thank Andrew Newton; Martin Dawson; Henning 495 Schulzrinne; Marc Linsner; Brian Rosen; Ted Hardie; James M. Polk; 496 James Winterbottom; Martin Thomson; John Schnizlein; Barbara Stark; 497 Jon Peterson; Allison Mankin; Randall Gellens; Cullen Jennings; 498 Richard Barnes; Keith Drage; Rohan Mahy; and Hannes Tschofenig, for 499 their individual contributions and comments. 501 10. References 503 10.1. Normative References 505 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 506 Requirement Levels", BCP 14, RFC 2119, March 1997. 508 10.2. Informative References 510 [I-D.ietf-geopriv-http-location-delivery] 511 Barnes, M., "HTTP Enabled Location Delivery (HELD)", 512 draft-ietf-geopriv-http-location-delivery-01 (work in 513 progress), July 2007. 515 [I-D.ietf-geopriv-l7-lcp-ps] 516 Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 517 Location Configuration Protocol; Problem Statement and 518 Requirements", draft-ietf-geopriv-l7-lcp-ps-04 (work in 519 progress), August 2007. 521 [I-D.ietf-geopriv-loc-filters] 522 Mahy, R., "A Document Format for Filtering and Reporting 523 Location Notications in the Presence Information Document 524 Format Location Object (PIDF-LO)", 525 draft-ietf-geopriv-loc-filters-01 (work in progress), 526 March 2007. 528 [I-D.ietf-sip-location-conveyance] 529 Polk, J. and B. Rosen, "Location Conveyance for the 530 Session Initiation Protocol", 531 draft-ietf-sip-location-conveyance-08 (work in progress), 532 July 2007. 534 [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and 535 J. Polk, "Geopriv Requirements", RFC 3693, February 2004. 537 [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object 538 Format", RFC 4119, December 2005. 540 Author's Address 542 Roger Marshall (editor) 543 TeleCommunication Systems, Inc. 544 2401 Elliott Avenue 545 2nd Floor 546 Seattle, WA 98121 547 US 549 Phone: +1 206 792 2424 550 Email: rmarshall@telecomsys.com 551 URI: http://www.telecomsys.com 553 Full Copyright Statement 555 Copyright (C) The IETF Trust (2007). 557 This document is subject to the rights, licenses and restrictions 558 contained in BCP 78, and except as set forth therein, the authors 559 retain all their rights. 561 This document and the information contained herein are provided on an 562 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 563 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 564 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 565 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 566 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 567 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 569 Intellectual Property 571 The IETF takes no position regarding the validity or scope of any 572 Intellectual Property Rights or other rights that might be claimed to 573 pertain to the implementation or use of the technology described in 574 this document or the extent to which any license under such rights 575 might or might not be available; nor does it represent that it has 576 made any independent effort to identify any such rights. Information 577 on the procedures with respect to rights in RFC documents can be 578 found in BCP 78 and BCP 79. 580 Copies of IPR disclosures made to the IETF Secretariat and any 581 assurances of licenses to be made available, or the result of an 582 attempt made to obtain a general license or permission for the use of 583 such proprietary rights by implementers or users of this 584 specification can be obtained from the IETF on-line IPR repository at 585 http://www.ietf.org/ipr. 587 The IETF invites any interested party to bring to its attention any 588 copyrights, patents or patent applications, or other proprietary 589 rights that may cover technology that may be required to implement 590 this standard. Please address the information to the IETF at 591 ietf-ipr@ietf.org. 593 Acknowledgment 595 Funding for the RFC Editor function is provided by the IETF 596 Administrative Support Activity (IASA).