idnits 2.17.1 draft-ietf-geopriv-dhcp-lbyr-uri-option-02.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 505. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 516. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 523. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 529. 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 (June 17, 2008) is 5792 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) ** Obsolete normative reference: RFC 3265 (Obsoleted by RFC 6665) == Outdated reference: A later version (-13) exists of draft-ietf-sip-location-conveyance-10 -- 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-02 Summary: 2 errors (**), 0 flaws (~~), 5 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 Expires: Dec 17, 2008 June 17, 2008 5 Intended status: Standards Track (PS) 7 Dynamic Host Configuration Protocol (DHCP) Option for a 8 Location Uniform Resource Identifier (URI) 9 draft-ietf-geopriv-dhcp-lbyr-uri-option-02 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 Dec 17, 2008. 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 Location Uniform Resource Identifier (URI) of an 44 endpoint. For example, an endpoint can be a Session Initiation 45 Protocol (SIP) User Agent (i.e., a phone). This Location-URI can be 46 included in a UA's signaling messages to inform other nodes of that 47 entity's geographic location, once the URI is dereferenced by a 48 Location Recipient. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. DHC Location-URI Elements . . . . . . . . . . . . . . . . . . 4 54 2.1. Elements of the Location Configuration Information . . 5 55 3. DHC Option Operation . . . . . . . . . . . . . . . . . . . . 5 56 3.1 Architectural Assumptions . . . . . . . . . . . . . . . . 7 57 3.2 Harmful URIs and URLs . . . . . . . . . . . . . . . . . . 7 58 3.3 Valid Location-URI Schemes or Types . . . . . . . . . . 7 59 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 60 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 61 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 62 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 63 7.1. Normative References . . . . . . . . . . . . . . . . . . 9 64 7.2. Informative References . . . . . . . . . . . . . . . . . 10 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 66 Intellectual Property and Copyright Statements . . . . . . . . . 10 68 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 69 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 70 document are to be interpreted as described in [RFC2119]. 72 1. Introduction 74 This document creates a Dynamic Host Configuration Protocol (DHCP) 75 Option for delivery of a client's Location Uniform Resource 76 Identifier (URI). For example, a client can be a Session Initiation 77 Protocol (SIP) User Agent (UA) [RFC3261] (i.e., a Phone). This 78 Location-URI can be included in a UA's signaling messages 79 [ID-SIP-LOC] to inform remote devices (i.e., other phones or servers 80 or applications) of that UA's geographic location. This is an 81 indirect means of passing a Location Target's location to another 82 entity, called a dereference (of a URI). In other words, if an 83 entity has the Location URI, it can access the location record at 84 the server the URI points to, if the requestor has permission to 85 access it there. Where the location record is will likely be an 86 entity called a Location Information Server (LIS) [ID-LBYR-REQ], 87 which stores the locations of many Location Targets, which has the 88 ability to challenge each dereference request by whatever means it 89 is capable of, thus providing additive security properties to 90 location revelation. 92 A Location Recipient is a device that has received location from 93 another entity. If this location is delivered by a URI, the URI has 94 to be dereferenced by the Location Recipient to learn the remote 95 device's geographic location. Dereferencing can be done in SIP by 96 use of the SUBSCRIBE/NOTIFY Methods [RFC3265] to either a sip:, 97 sips: or pres: scheme URI. Each of these URI schemes are IANA 98 registered in Section 5 of this document as valid for use by this 99 Option. 101 Endpoints will require their geographic location for a growing 102 number of services. A popular use-case currently is for emergency 103 services, in which SIP requires its location to be placed in a SIP 104 INVITE request [ID-SIP-LOC] towards a public safety answering point 105 (PSAP), i.e., an emergency response center. The reason for this is 106 twofold: 108 o An emergency services SIP request must be routed/retargeted to the 109 appropriate PSAP that is local to where the calling device is. 111 o The first responders require the UA's location in order to know 112 where to be dispatched to render aid to the caller. 114 Including location in the SIP request is the most efficient means of 115 accomplishing both requirements above. 117 There are other use-cases, such as calling the appropriate Pizza Hut 118 without having to look up in a directory which store is closest. A 119 UA knowing its location can call a main/national/international Pizza 120 Hut number or address and let the UA's location tell Pizza Hut 121 enough information to have them route/retarget the SIP request to 122 the appropriate store within the Pizza Hut organization to deliver 123 the pizza to the caller's location. 125 A problem exists within existing RFCs that provide location to the 126 UA ([RFC3825] and [RFC4776]) that type of location has to be updated 127 every time a UA moves. Not all UAs will move frequently, but some 128 will. Refreshing location every time a UA moves does not scale in 129 certain networks/environments, such as IP based cellular networks, 130 enterprise networks or service provider networks with mobile 131 endpoints. An 802.11 based access network is one example of this. 132 Constantly updating location to endpoints might not scale in mobile 133 (residential or enterprise or municipal) networks in which the UA is 134 moving through more than one network attachment point, perhaps as a 135 person walks or drives with their UA down a neighborhood street or 136 apartment complex or a shopping center. 138 If the UA were provided a URI reference to retain and hand out when 139 it wants or needs to convey its location (in a protocol other than 140 DHCP), a Location-URI reference that would not change as the UA's 141 location changes, scaling issues would be significantly reduced. 142 This delivery of an indirect location has the added benefit of not 143 using up valuable or limited bandwidth to the UA with the constant 144 updates. It also relieves the UA from having to determine when it 145 has moved far enough to consider asking for a refresh of its 146 location. Many endpoints will not have this ability, so relying on 147 it could prove fruitless. Once the UA has a Location-URI, a service 148 provider, however it Sights the Location Target, as described in RFC 149 3693 [RFC3693], would merely update the actual location in the LIS 150 record, i.e., the URI the UA already points towards. This document 151 does not define how this update is done, as it will not be done with 152 DHCP. 154 In enterprise networks, if a known location is assigned to each 155 individual Ethernet port in the network, a device that attaches to 156 the network a wall-jack (directly associated with a specific 157 Ethernet Switch port) will be associated with a known location via a 158 unique circuit-ID that's used by the RAIO Option defined in RFC 3046 159 [RFC3046]. This assumes wall-jacks have an updated wiremap 160 database. RFC 3825 and RFC 4776 would return an LCI value of 161 location. This document specifies how a Location-URI is returned by 162 DHCP. Behind the DHCP server, in the backend of the network, via 163 the (logical entity of a) LIS has a PIDF-LO in each location record 164 a URI points to. 166 If an 802.11 Access Port (AP) is at a specific known location within 167 this enterprise network, all wireless Ethernet devices attaching to 168 the network through this AP would be given the same location in 169 their respective location records because the DHCP server would know 170 each device was attaching from a known location, in this case, the 171 same location. This is assuming no 802.11 triangulation is 172 occurring, this would give a more precise location to be placed in 173 the location record (URI) of each device. 175 This Option can be useful in WiMAX connected endpoints or IP 176 cellular endpoints. The Location-URI Option can be configured as a 177 client if it is a router, such as a residential home gateway, with 178 the ability to communicate to downstream endpoints as a server. 180 The means of challenge by any given LIS can vary, and a policy 181 established by a rulemaker [RFC3693] for a Location Target as to 182 what type of challenge(s) are used, how strong a challenge is used 183 or how precise the location information is given to a requestor. All 184 of this is outside the scope of this document (since this will not 185 be accomplished using DHCP). 187 This document IANA registers the new DHC Option for a Location URI. 189 2. DHC Location-URI Elements 191 DHCP is a binary Protocol; URIs are alphanumeric (text) based. 192 There is one byte per URI character. 194 The Location-URI Option format is as follows: 196 0 1 2 3 197 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 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 | Code XXX | Option Length | Valid-For | 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 | Location-URI | 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 / .... \ 204 \ .... / 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 | Location-URI (cont'd) + 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 2.1. Elements of the Location Configuration Information 211 Code XXX: The code for this DHCP option. 213 Option Length: The length of this option variable. 215 Valid-For: The time, in seconds, this URI is to be considered 216 Valid for dereferencing. 218 Location-URI: The Location-by-Reference URI for the client 220 The field indicates how long, in seconds, the client is 221 to consider this Location-URI valid before performing a refresh of 222 this Option, with a refreshed value. A refresh MAY be 223 done merely at the normal DHCP refresh rate, or necessitated by this 224 timer, perhaps with the client just requesting this Option be 225 refreshed. 227 It is RECOMMENDED when the counter associated with this 228 value has passed, the client perform a refresh of this Option. For 229 example, if 600 was the initial value of the field, when 230 300 seconds have passed, the Option SHOULD be refreshed. 232 3. DHC Option Operation 234 The [RFC3046] RAIO MUST be utilized to provide the appropriate 235 indication to the DHCP Server where this DISCOVER or REQUEST message 236 came from, in order to supply the correct response. That said, this 237 Option SHOULD NOT be in a DISCOVER message, because there is zero 238 knowledge by the client of which Server will answer. 240 Caution SHOULD always be used involving the creation of large 241 Options, meaning that this Option MAY need to be in its own INFORM, 242 OPTION or ACK message. 244 It is RECOMMENDED to avoid building URIs, with any parameters, 245 larger than what a single DHCP response can be. However, if a 246 message is larger than 255 bytes, concatenation is allowed, per RFC 247 3396 [RFC3396]. 249 Per [RFC2131], subsequent Location-URI Options, which are 250 non-concatenated, overwrite the previous value. 252 Location URIs MUST NOT reveal identity information of the user of 253 the device, since DHCP is a cleartext delivery protocol. For 254 example, Location URIs such as 256 sips:34LKJH534663J54@example.com 258 should be done, providing no identity information, rather than a 259 Location-URI such as this 261 sips:aliceisinatlanta@example.com 263 This Option is for only communications between a DHCP client and a 264 DHCP server. It may be solicited (requested) by the client, or it 265 may be pushed by the server without a request for it. DHCP Options 266 not understood are ignored. A DHCP server might or might not have 267 the location of a client, therefore direct knowledge of a 268 Location-URI within the server. If a server does not have a 269 client's location, a communication path (or request) to a LIS would 270 be necessary. 272 The LIS function, which is logical, is what creates the URI. The 273 coordination between the logical entity of a DHCP server and the 274 logical entity of a LIS as to which circuit-ID gets which 275 Location-URI is not done via DHCP, therefore it is not defined 276 here. Further, any location revelation rules and policies a user 277 has regarding the treatment of their actual location, and who can 278 access (what precision of) their location will be done with other 279 than DHCP, and likely will be done before anything other than 280 default authentication and authorization permissions are used when a 281 Location Seeker, as defined in RFC 3693, requests a for a Target's 282 location. 284 Any dereferencing of a client's Location-URI would not involve DHCP 285 either, but more likely by an application layer protocol such as 286 SIP, through a subscription to the Location-URI on the LIS. The LIS 287 would also handle all authentication and authorization of location 288 requests, which is also not performed with DHCP, therefore not 289 defined here. 291 In the case of residential gateways being DHCP servers, they usually 292 perform as DHCP clients in a hierarchical fashion up into a service 293 provider's network DHCP server(s), or learn what information to 294 provide via DHCP to residential clients through a protocol such as 295 PPP. In these cases, the Location-URI would likely indicate the 296 residence's civic address to all wired or wireless clients within 297 that residence. This is not inconsistent with what's stated above. 299 3.1 Architectural Assumptions 301 The following assumptions have been made for use of this URI Option 302 for a client to learn it's Location-URI (in no particular order): 304 o Any user control (what Geopriv calls a 'rulemaker') for the 305 parameters and profile options a Location-Object will have is out 306 of scope of this document, but assumed to take place via an 307 external web interface between the user and the LIS (direct or 308 indirect). 310 o Any user attempting to gain access to the information at this URI 311 will be challenged by the LIS, not the DHCP server for 312 credentials and permissions. 314 3.2 Harmful URIs and URLs 316 There are, in fact, some types of URIs that are not good to receive, 317 due to security concerns. For example, any URLs that can have 318 scripts, such as "data:" URLs, and some "HTTP:" URLs that go to web 319 pages - that have scripts. Therefore, 321 o URIs received via this Option SHOULD NOT be sent to a 322 general-browser to connect to a web page, because they could have 323 harmful scripts. 325 o This Option SHOULD NOT contain "data:" URLs, because they could 326 contain harmful scripts. 328 Instead of listing all the types of URIs and URLs that can be 329 misused or potentially have harmful affects, Section 3.3 IANA 330 registers acceptable Location-URI schemes (or types). 332 3.3 Valid Location-URI Schemes or Types 334 Therefore, this document specifies which URI types are acceptable as 335 a Location-URI scheme (or type): 337 1. sip: 338 2. sips: 339 3. pres: 341 These Location-URI types are IANA registered in section 4.2 of this 342 document. 344 4. IANA Considerations 346 4.1 IANA Considerations for DHCP Option Numbering 348 IANA is requested to assigned a DHCP option code of XXX for the 349 Location-URI option, defined in Section 2.0 of this document. 351 Any additional Location-URI parameters to be defined for use via 352 this DHC Option MUST be done through a Standards Track RFC. 354 4.2 IANA Considerations for Acceptable Location-URI Types 356 IANA is requested to create a new registry for acceptable Location 357 URI types. 359 The following 3 URI types are registered by this document: 361 1. sip: 362 2. sips: 363 3. pres: 365 Any additional Location-URI types to be defined for use via 366 this DHC Option MUST be done through a Standards Track RFC. 368 5. Security Considerations 370 Where critical decisions might be based on the value of this 371 Location-URI option, DHCP authentication in [RFC3118] SHOULD be used 372 to protect the integrity of the DHCP options. 374 A real concern with RFC 3118 it is that not widely deployed because 375 it requires keys on both ends of a communication to work (i.e., in 376 the client and in the server). Most implementations do not 377 accommodate this. 379 DHCP is a broadcast initially (a client looking for a server), 380 unicast response (answer from a server) type of protocol. It is not 381 secure in a practical sense. In today's infrastructures, it will be 382 primarily used over a wired, switched Ethernet network, requiring 383 physical access to within a wire to gain access. Further, within an 384 802.11 wireless network, the 802.11 specs have layer 2 security 385 mechanisms in place to help prevent a Location-URI from being 386 learned by an unauthorized entity. 388 That said, having the Location-URI does not mean this unauthorized 389 entity has the location of a client. The Location-URI still needs 390 to be dereferenced to learn the location of the client. This 391 dereferencing function, which is not done using DHCP, is done by 392 requesting the location record at a Location Information Server, or 393 LIS, which is a defined entity built to challenge each request it 394 receives based on a joint policy of what is called a rulemaker. The 395 rulemaker, as defined in RFC 3693, configures the authentication and 396 authorization policies for the location revelation of a Target. 397 This includes giving out more or less precise location information 398 in an answer, therefore it can answer a bad-hat, but not allow it 399 from learning exactly where a user is. The rulemaker, which is a 400 combination of the default rules set up by the location provider and 401 those decided on by the user of the Target device. Likely, the 402 rules the user wants will not be allowed to go past some limits 403 established by the location provider, i.e., the administrator of the 404 LIS, for various capability or security reasons. 406 Penetrating a LIS is supposed to be hard, and hopefully vendors that 407 implement a LIS accomplish this goal. 409 As to the concerns about the Location-URI itself, as stated in the 410 document here (in Section 3.), it must not have any user identifying 411 information in the URI string itself. The Location-URI also must be 412 hard to guess that it belongs to a specific user. There is some 413 debate as to whether this Location-URI need be a random alphanumeric 414 string or just unique. If the latter, there is some debate as to 415 the how we define unique. Is that through space as time, as RFC 3261 416 defines a SIP Call-ID needs to be (meaning: never a duplicate, ever, 417 by any device, ever)? Or is it unique to within a specific domain 418 for as long as it is actively assigned to a client (plus some 419 interval). 421 When implementing a DHC server that will serve clients across an 422 uncontrolled network, one should consider the potential security 423 risks therein. 425 6. Acknowledgements 427 Thanks to James Winterbottom, Marc Linsner, Roger Marshall and 428 Robert Sparks for their useful comments. And to Lisa Dusseault for 429 her concerns about the types of URIs that can cause harm. To 430 Richard Barnes for inspiring a more robust Security Considerations 431 section. 433 7. References 435 7.1. Normative References 437 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 438 Requirement Levels", BCP 14, RFC 2119, March 1997. 440 [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC 441 3046, January 2001. 443 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 444 March 1997. 446 [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP 447 Messages", RFC 3118, June 2001. 449 [RFC3261] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. 450 Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: 451 Session Initiation Protocol", RFC 3261, May 2002. 453 [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific 454 Event Notification", RFC 3265, June 2002. 456 [RFC3396] T. Lemon, S. Cheshire, "Encoding Long Options in the Dynamic 457 Host Configuration Protocol (DHCPv4)", RFC 3396, November 458 2002 460 7.2. Informative References 462 [ID-SIP-LOC] J. Polk, B. Rosen, "SIP Location Conveyance", 463 draft-ietf-sip-location-conveyance-10.txt, "work in 464 progress", Feb 2008 466 [RFC3825] J. Polk, J. Schnizlein, M. Linsner, "Dynamic Host 467 Configuration Protocol Option for Coordinate-based Location 468 Configuration Information", RFC 3825, July 2004 470 [RFC4776] H. Schulzrinne, " Dynamic Host Configuration Protocol 471 (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration 472 Information ", RFC 4776, November 2006 474 [ID-LBYR-REQ] R. Marshall, "Requirements for a Location-by-Reference 475 Mechanism", draft-ietf-geopriv-lbyr-requirements-02.txt, 476 "work in progress", Feb 08 478 [RFC3693] J. Cuellar, J. Morris, D. Mulligan, J. Peterson. J. Polk, 479 "Geopriv Requirements", RFC 3693, February 2004 481 Authors' Address 483 James Polk 484 3913 Treemont Circle 485 Colleyville, Texas 76034 486 USA 488 EMail: jmpolk@cisco.com 490 Full Copyright Statement 492 Copyright (C) The IETF Trust (2008). 494 This document is subject to the rights, licenses and restrictions 495 contained in BCP 78, and except as set forth therein, the authors 496 retain all their rights. 498 This document and the information contained herein are provided on 499 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 500 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 501 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 502 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 503 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 504 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 505 FOR A PARTICULAR PURPOSE. 507 Intellectual Property 509 The IETF takes no position regarding the validity or scope of any 510 Intellectual Property Rights or other rights that might be claimed 511 to pertain to the implementation or use of the technology described 512 in this document or the extent to which any license under such 513 rights might or might not be available; nor does it represent that 514 it has made any independent effort to identify any such rights. 515 Information on the procedures with respect to rights in RFC 516 documents can be found in BCP 78 and BCP 79. 518 Copies of IPR disclosures made to the IETF Secretariat and any 519 assurances of licenses to be made available, or the result of an 520 attempt made to obtain a general license or permission for the use 521 of such proprietary rights by implementers or users of this 522 specification can be obtained from the IETF on-line IPR repository 523 at http://www.ietf.org/ipr. 525 The IETF invites any interested party to bring to its attention any 526 copyrights, patents or patent applications, or other proprietary 527 rights that may cover technology that may be required to implement 528 this standard. Please address the information to the IETF at 529 ietf-ipr@ietf.org. 531 Acknowledgment 533 Funding for the RFC Editor function is provided by the IETF 534 Administrative Support Activity (IASA).