idnits 2.17.1 draft-ietf-geopriv-dhcp-lbyr-uri-option-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 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 491. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 502. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 509. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 515. 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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: 'RFC3693' is mentioned on line 181, but not defined == Missing Reference: 'RFC3396' is mentioned on line 241, but not defined ** Obsolete normative reference: RFC 3265 (Obsoleted by RFC 6665) == Outdated reference: A later version (-13) exists of draft-ietf-sip-location-conveyance-09 -- 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-01 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 Expires: Aug 18th, 2008 February 18th, 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-00 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 Aug 18th, 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, which 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. 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 new answer. A refresh MAY be done 223 merely at the normal DHCP refresh rate, or necessitated by this 224 timer, perhaps just requesting this Option be refreshed. 226 3. DHC Option Operation 228 The [RFC3046] RAIO MUST be utilized to provide the appropriate 229 indication to the DHCP Server where this DISCOVER or REQUEST message 230 came from, in order to supply the correct response. That said, this 231 Option SHOULD NOT be in a DISCOVER message, because there is zero 232 knowledge by the client of which Server will answer. 234 Caution SHOULD always be used involving the creation of large 235 Options, meaning that this Option MAY need to be in its own INFORM, 236 OPTION or ACK message. 238 It is RECOMMENDED to avoid building URIs, with any parameters, 239 larger than what a single DHCP response can be. However, if a 240 message is larger than 255 bytes, concatenation is allowed, per RFC 241 3396 [RFC3396]. 243 Per [RFC2131], subsequent Location-URI Options, which are 244 non-concatenated, overwrite the previous value. 246 Location URIs MUST NOT reveal identity information of the user of 247 the device, since DHCP is a cleartext delivery protocol. For 248 example, Location URIs such as 250 sips:34LKJH534663J54@example.com 252 should be done, providing no identity information, rather than a 253 Location-URI such as this 255 sips:aliceisinatlanta@example.com 257 This Option is for only communications between a DHCP client and a 258 DHCP server. It may be solicited (requested) by the client, or it 259 may be pushed by the server without a request for it. DHCP Options 260 not understood are ignored. A DHCP server might or might not have 261 the location of a client, therefore direct knowledge of a 262 Location-URI within the server. If a server does not have a 263 client's location, a communication path (or request) to a LIS would 264 be necessary. 266 The LIS function, which is logical, is what creates the URI. The 267 coordination between the logical entity of a DHCP server and the 268 logical entity of a LIS as to which circuit-ID gets which 269 Location-URI is not done via DHCP, therefore it is not defined 270 here. Further, any location revelation rules and policies a user 271 has regarding the treatment of their actual location, and who can 272 access (what precision of) their location will be done with other 273 than DHCP, and likely will be done before anything other than 274 default authentication and authorization permissions are used when a 275 Location Seeker, as defined in RFC 3693, requests a for a Target's 276 location. 278 Any dereferencing of a client's Location-URI would not involve DHCP 279 either, but more likely by an application layer protocol such as 280 SIP, through a subscription to the Location-URI on the LIS. The LIS 281 would also handle all authentication and authorization of location 282 requests, which is also not performed with DHCP, therefore not 283 defined here. 285 In the case of residential gateways being DHCP servers, they usually 286 perform as DHCP clients in a hierarchical fashion up into a service 287 provider's network DHCP server(s), or learn what information to 288 provide via DHCP to residential clients through a protocol such as 289 PPP. In these cases, the Location-URI would likely indicate the 290 residence's civic address to all wired or wireless clients within 291 that residence. This is not inconsistent with what's stated above. 293 3.1 Architectural Assumptions 295 The following assumptions have been made for use of this URI Option 296 for a client to learn it's Location-URI (in no particular order): 298 o Any user control (what Geopriv calls a 'rulemaker') for the 299 parameters and profile options a Location-Object will have is out 300 of scope of this document, but assumed to take place via an 301 external web interface between the user and the LIS (direct or 302 indirect). 304 o Any user attempting to gain access to the information at this URI 305 will be challenged by the LIS, not the DHCP server for 306 credentials and permissions. 308 3.2 Harmful URIs and URLs 310 There are, in fact, some types of URIs that are not good to receive, 311 due to security concerns. For example, any URLs that can have 312 scripts, such as "data:" URLs, and some "HTTP:" URLs that go to web 313 pages - that have scripts. Therefore, 315 o URIs received via this Option SHOULD NOT be sent to a 316 general-browser to connect to a web page, because they could have 317 harmful scripts. 319 o This Option SHOULD NOT contain "data:" URLs, because they could 320 contain harmful scripts. 322 Instead of listing all the types of URIs and URLs that can be 323 misused or potentially have harmful affects, Section 3.3 IANA 324 registers acceptable Location-URI schemes (or types). 326 3.3 Valid Location-URI Schemes or Types 328 Therefore, this document specifies which URI types are acceptable as 329 a Location-URI scheme (or type): 331 1. sip: 332 2. sips: 333 3. pres: 335 These Location-URI types are IANA registered in section 4.2 of this 336 document. 338 4. IANA Considerations 340 4.1 IANA Considerations for DHCP Option Numbering 342 IANA is requested to assigned a DHCP option code of XXX for the 343 Location-URI option, defined in Section 2.0 of this document. 345 Any additional Location-URI parameters to be defined for use via 346 this DHC Option MUST be done through a Standards Track RFC. 348 4.2 IANA Considerations for Acceptable Location-URI Types 350 IANA is requested to create a new registry for acceptable Location 351 URI types. 353 The following 3 URI types are registered by this document: 355 1. sip: 356 2. sips: 357 3. pres: 359 Any additional Location-URI types to be defined for use via 360 this DHC Option MUST be done through a Standards Track RFC. 362 5. Security Considerations 364 Where critical decisions might be based on the value of this 365 Location-URI option, DHCP authentication in [RFC3118] SHOULD be used 366 to protect the integrity of the DHCP options. 368 A real concern with RFC 3118 it is that not widely deployed because 369 it requires keys on both ends of a communication to work (i.e., in 370 the client and in the server). Most implementations do not 371 accommodate this. 373 DHCP is a broadcast initially (a client looking for a server), 374 unicast response (answer from a server) type of protocol. It is not 375 secure in a practical sense. In today's infrastructures, it will be 376 primarily used over a wired, switched Ethernet network, requiring 377 physical access to within a wire to gain access. Further, within an 378 802.11 wireless network, the 802.11 specs have layer 2 security 379 mechanisms in place to help prevent a Location-URI from being 380 learned by an unauthorized entity. 382 That said, having the Location-URI does not mean this unauthorized 383 entity has the location of a client. The Location-URI still needs 384 to be dereferenced to learn the location of the client. This 385 dereferencing function, which is not done using DHCP, is done by 386 requesting the location record at a Location Information Server, or 387 LIS, which is a defined entity built to challenge each request it 388 receives based on a joint policy of what is called a rulemaker. The 389 rulemaker, as defined in RFC 3693, configures the authentication and 390 authorization policies for the location revelation of a Target. 391 This includes giving out more or less precise location information 392 in an answer, therefore it can answer a bad-hat, but not allow it 393 from learning exactly where a user is. The rulemaker, which is a 394 combination of the default rules set up by the location provider and 395 those decided on by the user of the Target device. Likely, the 396 rules the user wants will not be allowed to go past some limits 397 established by the location provider, i.e., the administrator of the 398 LIS, for various capability or security reasons. 400 Penetrating a LIS is supposed to be hard, and hopefully vendors that 401 implement a LIS accomplish this goal. 403 As to the concerns about the Location-URI itself, as stated in the 404 document here (in Section 3.), it must not have any user identifying 405 information in the URI string itself. The Location-URI also must be 406 hard to guess that it belongs to a specific user. There is some 407 debate as to whether this Location-URI need be a random alphanumeric 408 string or just unique. If the latter, there is some debate as to 409 the how we define unique. Is that through space as time, as RFC 3261 410 defines a SIP Call-ID needs to be (meaning: never a duplicate, ever, 411 by any device, ever)? Or is it unique to within a specific domain 412 for as long as it is actively assigned to a client (plus some 413 interval). 415 When implementing a DHC server that will serve clients across an 416 uncontrolled network, one should consider the potential security 417 risks therein. 419 6. Acknowledgements 421 Thanks to James Winterbottom, Marc Linsner and Robert Sparks for 422 their useful comments. And to Lisa Dusseault for her concerns about 423 the types of URIs that can cause harm. To Richard Barnes for 424 inspiring a more robust Security Considerations section. 426 7. References 428 7.1. Normative References 430 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 431 Requirement Levels", BCP 14, RFC 2119, March 1997. 433 [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC 434 3046, January 2001. 436 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 437 March 1997. 439 [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP 440 Messages", RFC 3118, June 2001. 442 [RFC3261] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. 443 Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: 444 Session Initiation Protocol", RFC 3261, May 2002. 446 [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific 447 Event Notification", RFC 3265, June 2002. 449 7.2. Informative References 451 [ID-SIP-LOC] J. Polk, B. Rosen, "SIP Location Conveyance", 452 draft-ietf-sip-location-conveyance-09.txt, "work in 453 progress", Nov 2007 455 [RFC3825] J. Polk, J. Schnizlein, M. Linsner, "Dynamic Host 456 Configuration Protocol Option for Coordinate-based Location 457 Configuration Information", RFC 3825, July 2004 459 [RFC4776] H. Schulzrinne, " Dynamic Host Configuration Protocol 460 (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration 461 Information ", RFC 4776, November 2006 463 [ID-LBYR-REQ] R. Marshall, "Requirements for a Location-by-Reference 464 Mechanism", draft-ietf-geopriv-lbyr-requirements-01.txt, 465 "work in progress", Oct 07 467 Authors' Address 469 James Polk 470 3913 Treemont Circle 471 Colleyville, Texas 76034 472 USA 474 EMail: jmpolk@cisco.com 476 Full Copyright Statement 478 Copyright (C) The IETF Trust (2008). 480 This document is subject to the rights, licenses and restrictions 481 contained in BCP 78, and except as set forth therein, the authors 482 retain all their rights. 484 This document and the information contained herein are provided on 485 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 486 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 487 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 488 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 489 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 490 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 491 FOR A PARTICULAR PURPOSE. 493 Intellectual Property 495 The IETF takes no position regarding the validity or scope of any 496 Intellectual Property Rights or other rights that might be claimed 497 to pertain to the implementation or use of the technology described 498 in this document or the extent to which any license under such 499 rights might or might not be available; nor does it represent that 500 it has made any independent effort to identify any such rights. 501 Information on the procedures with respect to rights in RFC 502 documents can be found in BCP 78 and BCP 79. 504 Copies of IPR disclosures made to the IETF Secretariat and any 505 assurances of licenses to be made available, or the result of an 506 attempt made to obtain a general license or permission for the use 507 of such proprietary rights by implementers or users of this 508 specification can be obtained from the IETF on-line IPR repository 509 at http://www.ietf.org/ipr. 511 The IETF invites any interested party to bring to its attention any 512 copyrights, patents or patent applications, or other proprietary 513 rights that may cover technology that may be required to implement 514 this standard. Please address the information to the IETF at 515 ietf-ipr@ietf.org. 517 Acknowledgment 519 Funding for the RFC Editor function is provided by the IETF 520 Administrative Support Activity (IASA).