idnits 2.17.1 draft-ietf-geopriv-dhcp-lbyr-uri-option-03.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 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 514. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 525. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 532. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 538. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 0 form feeds but 11 pages 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 == Unrecognized Status in 'Intended status: Standards Track (PS)', assuming Proposed Standard (Expected one of 'Standards Track', 'Full Standard', 'Draft Standard', 'Proposed Standard', 'Best Current Practice', 'Informational', 'Experimental', 'Informational', 'Historic'.) -- 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 (Nov 3, 2008) is 5625 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) == Missing Reference: 'ID-SIP-CON' is mentioned on line 89, but not defined == Unused Reference: 'RFC3265' is defined on line 457, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3265 (Obsoleted by RFC 6665) == Outdated reference: A later version (-13) exists of draft-ietf-sip-location-conveyance-11 -- Obsolete informational reference (is this intentional?): RFC 3825 (Obsoleted by RFC 6225) == Outdated reference: A later version (-09) exists of draft-ietf-geopriv-lbyr-requirements-04 Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Geopriv WG James Polk 3 Internet-Draft Cisco Systems 4 Intended status: Standards Track (PS) Nov 3, 2008 5 Expires: May 3, 2009 7 Dynamic Host Configuration Protocol (DHCP) Option for a 8 Location Uniform Resource Identifier (URI) 9 draft-ietf-geopriv-dhcp-lbyr-uri-option-03 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other documents 25 at any time. It is inappropriate to use Internet-Drafts as 26 reference material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on May 3, 2009. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2008). 40 Abstract 42 This document creates a Dynamic Host Configuration Protocol (DHCP) 43 Option for the downloading of a Uniform Resource Identifier (URI) 44 pointing to the geolocation record of an endpoint. This URI, called 45 a Location-by-Reference (LbyR), points to a record on a location 46 server which tracks the geolocation of the endpoint. Once 47 downloaded by an endpoint, this LbyR can be forwarded to another 48 entity, to be dereferenced if this entity wants to learn the 49 geolocation of the sender endpoint. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. DHC Location-URI Elements . . . . . . . . . . . . . . . . . . 4 55 2.1. Elements of the Location Configuration Information . . 5 56 3. DHC Option Operation . . . . . . . . . . . . . . . . . . . . 5 57 3.1 Architectural Assumptions . . . . . . . . . . . . . . . . 7 58 3.2 Harmful URIs and URLs . . . . . . . . . . . . . . . . . . 7 59 3.3 Valid Location-URI Schemes or Types . . . . . . . . . . 7 60 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 61 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 62 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 63 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 64 7.1. Normative References . . . . . . . . . . . . . . . . . . 9 65 7.2. Informative References . . . . . . . . . . . . . . . . . 10 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 67 Intellectual Property and Copyright Statements . . . . . . . . . 11 69 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 70 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 71 document are to be interpreted as described in [RFC2119]. 73 1. Introduction 75 This document creates a Dynamic Host Configuration Protocol (DHCP) 76 Option for the downloading of a Uniform Resource Identifier (URI) 77 pointing to the geolocation record of an endpoint. A client, for 78 example, can be a Session Initiation Protocol (SIP) User Agent (UA) 79 [RFC3261] (i.e., a Phone). This URI, called a 80 Location-by-Reference (LbyR), points to a record on a location 81 server [ID-LBYR-REQ] which tracks the geolocation of the endpoint 82 (through means not defined in this document). The LbyR record 83 stores the Geolocation of a Location Target. Once downloaded by an 84 endpoint (the target in this case), this LbyR can be forwarded to 85 another entity, using SIP as defined in [ID-SIP-LOC], to be 86 dereferenced if this second entity wants to learn the geolocation of 87 the Location Target. 89 The act of dereferencing location is explained in [ID-SIP-CON], 90 which demonstrates how a possessor of a LbyR subscribes to a 91 Location Server to attain the location of the Target. If the 92 dereferencer has permission, defined in [ID-GEO-POL], the location 93 of the target will be returned to the Location Seeker. The Location 94 Server will grant permission to location inquires based on the rules 95 established by a Rule Holder [RFC3693]. Therefore, the Location 96 Server has the ability to challenge any location seeker's request, 97 thus providing additive security properties to location revelation. 98 Option. 100 Endpoints will require their geographic location for a growing 101 number of services. A popular use-case currently is for emergency 102 services, in which SIP requires its location to be placed in a SIP 103 INVITE request [ID-SIP-LOC] towards a public safety answering point 104 (PSAP), i.e., an emergency response center. The reason for this is 105 twofold: 107 o An emergency services SIP request must be routed/retargeted to the 108 appropriate PSAP that is local to where the calling device is. 110 o The first responders require the UA's location in order to know 111 where to be dispatched to render aid to the caller. 113 Including location in the SIP request is the most efficient means of 114 accomplishing both requirements above. 116 There are other use-cases, such as calling the appropriate Pizza Hut 117 without having to look up in a directory which store is closest. A 118 UA knowing its location can call a main/national/international Pizza 119 Hut number or address and let the UA's location tell Pizza Hut 120 enough information to have them route/retarget the SIP request to 121 the appropriate store within the Pizza Hut organization to deliver 122 the pizza to the caller's location. 124 A problem exists within existing RFCs that provide location to the 125 UA ([RFC3825] and [RFC4776]) that type of location has to be updated 126 every time a UA moves. Not all UAs will move frequently, but some 127 will. Refreshing location every time a UA moves does not scale in 128 certain networks/environments, such as IP based cellular networks, 129 enterprise networks or service provider networks with mobile 130 endpoints. An 802.11 based access network is one example of this. 131 Constantly updating location to endpoints might not scale in mobile 132 (residential or enterprise or municipal) networks in which the UA is 133 moving through more than one network attachment point, perhaps as a 134 person walks or drives with their UA down a neighborhood street or 135 apartment complex or a shopping center. 137 If the UA were provided a URI reference to retain and hand out when 138 it wants or needs to convey its location (in a protocol other than 139 DHCP), a Location-URI reference that would not change as the UA's 140 location changes, scaling issues would be significantly reduced. 141 This delivery of an indirect location has the added benefit of not 142 using up valuable or limited bandwidth to the UA with the constant 143 updates. It also relieves the UA from having to determine when it 144 has moved far enough to consider asking for a refresh of its 145 location. Many endpoints will not have this ability, so relying on 146 it could prove fruitless. Once the UA has a Location-URI, a service 147 provider, however it Sights the Location Target, as described in RFC 148 3693 [RFC3693], would merely update the actual location in the LIS 149 record, i.e., the URI the UA already points towards. This document 150 does not define how this update is done, as it will not be done with 151 DHCP. 153 In enterprise networks, if a known location is assigned to each 154 individual Ethernet port in the network, a device that attaches to 155 the network a wall-jack (directly associated with a specific 156 Ethernet Switch port) will be associated with a known location via a 157 unique circuit-ID that's used by the RAIO Option defined in RFC 3046 158 [RFC3046]. This assumes wall-jacks have an updated wiremap 159 database. RFC 3825 and RFC 4776 would return an LCI value of 160 location. This document specifies how a Location-URI is returned by 161 DHCP. Behind the DHCP server, in the backend of the network, via 162 the (logical entity of a) LIS has a PIDF-LO in each location record 163 a URI points to. 165 If an 802.11 Access Port (AP) is at a specific known location within 166 this enterprise network, all wireless Ethernet devices attaching to 167 the network through this AP would be given the same location in 168 their respective location records because the DHCP server would know 169 each device was attaching from a known location, in this case, the 170 same location. This is assuming no 802.11 triangulation is 171 occurring, this would give a more precise location to be placed in 172 the location record (URI) of each device. 174 This Option can be useful in WiMAX connected endpoints or IP 175 cellular endpoints. The Location-URI Option can be configured as a 176 client if it is a router, such as a residential home gateway, with 177 the ability to communicate to downstream endpoints as a server. 179 The means of challenge by any given LIS can vary, and a policy 180 established by a rulemaker [RFC3693] for a Location Target as to 181 what type of challenge(s) are used, how strong a challenge is used 182 or how precise the location information is given to a requestor. All 183 of this is outside the scope of this document (since this will not 184 be accomplished using DHCP). 186 This document IANA registers the new DHC Option for a Location URI. 188 2. DHC Location-URI Elements 190 DHCP is a binary Protocol; URIs are alphanumeric (text) based. 191 There is one byte per URI character. 193 The Location-URI Option format is as follows: 195 0 1 2 3 196 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 | Code XXX | Option Length | Valid-For | 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 | Location-URI | 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 / .... \ 203 \ .... / 204 / .... \ 205 \ .... / 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 | Location-URI (cont'd) + 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 2.1. Elements of the Location Configuration Information 212 Code XXX: The code for this DHCP option. 214 Option Length: The length of this option variable. 216 Valid-For: The time, in seconds, this URI is to be considered 217 Valid for dereferencing. 219 Location-URI: The Location-by-Reference URI for the client 221 The field indicates how long, in seconds, the client is 222 to consider this Location-URI valid before performing a refresh of 223 this Option, with a refreshed value. A refresh MAY be 224 done merely at the normal DHCP refresh rate, or necessitated by this 225 timer, perhaps with the client just requesting this Option be 226 refreshed. 228 It is RECOMMENDED when the counter associated with this 229 value has passed, the client perform a refresh of this Option. For 230 example, if 600 was the initial value of the field, when 231 300 seconds have passed, the Option SHOULD be refreshed. 233 3. DHC Option Operation 235 The [RFC3046] RAIO MUST be utilized to provide the appropriate 236 indication to the DHCP Server where this DISCOVER or REQUEST message 237 came from, in order to supply the correct response. That said, this 238 Option SHOULD NOT be in a DISCOVER message, because there is zero 239 knowledge by the client of which Server will answer. 241 Caution SHOULD always be used involving the creation of large 242 Options, meaning that this Option MAY need to be in its own INFORM, 243 OPTION or ACK message. 245 It is RECOMMENDED to avoid building URIs, with any parameters, 246 larger than what a single DHCP response can be. However, if a 247 message is larger than 255 bytes, concatenation is allowed, per RFC 248 3396 [RFC3396]. 250 Per [RFC2131], subsequent Location-URI Options, which are 251 non-concatenated, overwrite the previous value. 253 Location URIs MUST NOT reveal identity information of the user of 254 the device, since DHCP is a cleartext delivery protocol. For 255 example, Location URIs such as 257 sips:34LKJH534663J54@example.com 259 should be done, providing no identity information, rather than a 260 Location-URI such as this 262 sips:aliceisinatlanta@example.com 264 This Option is for only communications between a DHCP client and a 265 DHCP server. It can be solicited (requested) by the client, or it 266 can be pushed by the server without a request for it. DHCP Options 267 not understood are ignored. A DHCP server might or might not have 268 the location of a client, therefore direct knowledge of a 269 Location-URI within the server. If a server does not have a 270 client's location, a communication path (or request) to a LIS would 271 be necessary. 273 The LIS function, which is logical, is what creates the LbyR. The 274 coordination between the logical entity of a DHCP server and the 275 logical entity of a LIS as to which circuit-ID gets which 276 Location-URI is not done via DHCP, therefore it is not defined 277 here. Further, any location revelation rules and policies a user 278 has regarding the treatment of their actual location, and who can 279 access (what precision of) their location will be done with other 280 than DHCP, and likely will be done before anything other than 281 default authentication and authorization permissions are used when a 282 Location Seeker, as defined in RFC 3693, requests a for a Target's 283 location. 285 Differentiating clients is done via client identifiers. Therefore, 286 in many implementations, each client can be assigned unique LbyRs, 287 though this is not mandatory. 289 Any dereferencing of a client's Location-URI would not involve DHCP 290 either, but more likely by an application layer protocol such as 291 SIP, through a subscription to the Location-URI on the LIS. The LIS 292 would also handle all authentication and authorization of location 293 requests, which is also not performed with DHCP, therefore not 294 defined here. 296 In the case of residential gateways being DHCP servers, they usually 297 perform as DHCP clients in a hierarchical fashion up into a service 298 provider's network DHCP server(s), or learn what information to 299 provide via DHCP to residential clients through a protocol such as 300 PPP. In these cases, the Location-URI would likely indicate the 301 residence's civic address to all wired or wireless clients within 302 that residence. This is not inconsistent with what's stated above. 304 3.1 Architectural Assumptions 306 The following assumptions have been made for use of this URI Option 307 for a client to learn it's Location-URI (in no particular order): 309 o Any user control (what Geopriv calls a 'rulemaker') for the 310 parameters and profile options a Location-Object will have is out 311 of scope of this document, but assumed to take place via an 312 external web interface between the user and the LIS (direct or 313 indirect). 315 o Any user attempting to gain access to the information at this URI 316 will be challenged by the LIS, not the DHCP server for 317 credentials and permissions. 319 3.2 Harmful URIs and URLs 321 There are, in fact, some types of URIs that are not good to receive, 322 due to security concerns. For example, any URLs that can have 323 scripts, such as "data:" URLs, and some "HTTP:" URLs that go to web 324 pages - that have scripts. Therefore, 326 o URIs received via this Option SHOULD NOT be sent to a 327 general-browser to connect to a web page, because they could have 328 harmful scripts. 330 o This Option SHOULD NOT contain "data:" URLs, because they could 331 contain harmful scripts. 333 Instead of listing all the types of URIs and URLs that can be 334 misused or potentially have harmful affects, Section 3.3 IANA 335 registers acceptable Location-URI schemes (or types). 337 3.3 Valid Location-URI Schemes or Types 339 Therefore, this document specifies which URI types are acceptable as 340 a Location-URI scheme (or type): 342 1. sip: 343 2. sips: 344 3. pres: 346 These Location-URI types are IANA registered in section 4.2 of this 347 document. 348 4. IANA Considerations 350 4.1 IANA Considerations for DHCP Option Numbering 352 IANA is requested to assigned a DHCP option code of XXX for the 353 Location-URI option, defined in Section 2.0 of this document. 355 Any additional Location-URI parameters to be defined for use via 356 this DHC Option MUST be done through a Standards Track RFC. 358 4.2 IANA Considerations for Acceptable Location-URI Types 360 IANA is requested to create a new registry for acceptable Location 361 URI types. 363 The following 3 URI types are registered by this document: 365 1. sip: 366 2. sips: 367 3. pres: 369 Any additional Location-URI types to be defined for use via 370 this DHC Option MUST be done through a Standards Track RFC. 372 5. Security Considerations 374 Where critical decisions might be based on the value of this 375 Location-URI option, DHCP authentication in [RFC3118] SHOULD be used 376 to protect the integrity of the DHCP options. 378 A real concern with RFC 3118 it is that not widely deployed because 379 it requires keys on both ends of a communication to work (i.e., in 380 the client and in the server). Most implementations do not 381 accommodate this. 383 DHCP is a broadcast initially (a client looking for a server), 384 unicast response (answer from a server) type of protocol. It is not 385 secure in a practical sense. In today's infrastructures, it will be 386 primarily used over a wired, switched Ethernet network, requiring 387 physical access to within a wire to gain access. Further, within an 388 802.11 wireless network, the 802.11 specs have layer 2 security 389 mechanisms in place to help prevent a Location-URI from being 390 learned by an unauthorized entity. 392 That said, having the Location-URI does not mean this unauthorized 393 entity has the location of a client. The Location-URI still needs 394 to be dereferenced to learn the location of the client. This 395 dereferencing function, which is not done using DHCP, is done by 396 requesting the location record at a Location Information Server, or 397 LIS, which is a defined entity built to challenge each request it 398 receives based on a joint policy of what is called a rulemaker. The 399 rulemaker, as defined in RFC 3693, configures the authentication and 400 authorization policies for the location revelation of a Target. 401 This includes giving out more or less precise location information 402 in an answer, therefore it can answer a bad-hat, but not allow it 403 from learning exactly where a user is. The rulemaker, which is a 404 combination of the default rules set up by the location provider and 405 those decided on by the user of the Target device. Likely, the 406 rules the user wants will not be allowed to go past some limits 407 established by the location provider, i.e., the administrator of the 408 LIS, for various capability or security reasons. 410 Penetrating a LIS is supposed to be hard, and hopefully vendors that 411 implement a LIS accomplish this goal. 413 As to the concerns about the Location-URI itself, as stated in the 414 document here (in Section 3.), it must not have any user identifying 415 information in the URI string itself. The Location-URI also must be 416 hard to guess that it belongs to a specific user. There is some 417 debate as to whether this Location-URI need be a random alphanumeric 418 string or just unique. If the latter, there is some debate as to 419 the how we define unique. Is that through space as time, as RFC 3261 420 defines a SIP Call-ID needs to be (meaning: never a duplicate, ever, 421 by any device, ever)? Or is it unique to within a specific domain 422 for as long as it is actively assigned to a client (plus some 423 interval). 425 When implementing a DHC server that will serve clients across an 426 uncontrolled network, one should consider the potential security 427 risks therein. 429 6. Acknowledgements 431 Thanks to James Winterbottom, Marc Linsner, Roger Marshall and 432 Robert Sparks for their useful comments. And to Lisa Dusseault for 433 her concerns about the types of URIs that can cause harm. To 434 Richard Barnes for inspiring a more robust Security Considerations 435 section. 437 7. References 439 7.1. Normative References 441 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 442 Requirement Levels", BCP 14, RFC 2119, March 1997. 444 [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC 445 3046, January 2001. 447 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 448 March 1997. 450 [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP 451 Messages", RFC 3118, June 2001. 453 [RFC3261] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. 454 Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: 455 Session Initiation Protocol", RFC 3261, May 2002. 457 [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific 458 Event Notification", RFC 3265, June 2002. 460 [RFC3396] T. Lemon, S. Cheshire, "Encoding Long Options in the Dynamic 461 Host Configuration Protocol (DHCPv4)", RFC 3396, November 462 2002 464 7.2. Informative References 466 [ID-SIP-LOC] J. Polk, B. Rosen, "SIP Location Conveyance", 467 draft-ietf-sip-location-conveyance-11.txt, "work in 468 progress", Oct 2008 470 [RFC3825] J. Polk, J. Schnizlein, M. Linsner, "Dynamic Host 471 Configuration Protocol Option for Coordinate-based Location 472 Configuration Information", RFC 3825, July 2004 474 [RFC4776] H. Schulzrinne, " Dynamic Host Configuration Protocol 475 (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration 476 Information ", RFC 4776, November 2006 478 [ID-LBYR-REQ] R. Marshall, "Requirements for a Location-by-Reference 479 Mechanism", draft-ietf-geopriv-lbyr-requirements-04.txt, 480 "work in progress", Nov 08 482 [RFC3693] J. Cuellar, J. Morris, D. Mulligan, J. Peterson. J. Polk, 483 "Geopriv Requirements", RFC 3693, February 2004 485 [ID-GEO-POL] H. Schulzrinne, H. Tschofenig, J. Morris, J. Cuellar, J. 486 Polk, "Geolocation Policy: A Document Format for Expressing 487 Privacy Preferences for Location Information", "work in 488 progress", Oct 2008 490 Authors' Address 492 James Polk 493 3913 Treemont Circle 494 Colleyville, Texas 76034 495 USA 497 EMail: jmpolk@cisco.com 499 Full Copyright Statement 501 Copyright (C) The IETF Trust (2008). 503 This document is subject to the rights, licenses and restrictions 504 contained in BCP 78, and except as set forth therein, the authors 505 retain all their rights. 507 This document and the information contained herein are provided on 508 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 509 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 510 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 511 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 512 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 513 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 514 FOR A PARTICULAR PURPOSE. 516 Intellectual Property 518 The IETF takes no position regarding the validity or scope of any 519 Intellectual Property Rights or other rights that might be claimed 520 to pertain to the implementation or use of the technology described 521 in this document or the extent to which any license under such 522 rights might or might not be available; nor does it represent that 523 it has made any independent effort to identify any such rights. 524 Information on the procedures with respect to rights in RFC 525 documents can be found in BCP 78 and BCP 79. 527 Copies of IPR disclosures made to the IETF Secretariat and any 528 assurances of licenses to be made available, or the result of an 529 attempt made to obtain a general license or permission for the use 530 of such proprietary rights by implementers or users of this 531 specification can be obtained from the IETF on-line IPR repository 532 at http://www.ietf.org/ipr. 534 The IETF invites any interested party to bring to its attention any 535 copyrights, patents or patent applications, or other proprietary 536 rights that may cover technology that may be required to implement 537 this standard. Please address the information to the IETF at 538 ietf-ipr@ietf.org. 540 Acknowledgment 542 Funding for the RFC Editor function is provided by the IETF 543 Administrative Support Activity (IASA).