idnits 2.17.1 draft-koponen-hip-registration-01.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 21. -- Found old boilerplate from RFC 3978, Section 5.5 on line 521. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 498. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 505. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 511. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- The document has an RFC 3978 Section 5.2(a) Derivative Works Limitation clause. == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (July 11, 2005) is 6865 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) == Outdated reference: A later version (-03) exists of draft-ietf-hip-arch-02 ** Downref: Normative reference to an Informational draft: draft-ietf-hip-arch (ref. 'I-D.ietf-hip-arch') == Outdated reference: A later version (-10) exists of draft-ietf-hip-base-03 ** Downref: Normative reference to an Experimental draft: draft-ietf-hip-base (ref. 'I-D.ietf-hip-base') == Outdated reference: A later version (-05) exists of draft-ietf-hip-rvs-02 ** Downref: Normative reference to an Experimental draft: draft-ietf-hip-rvs (ref. 'I-D.ietf-hip-rvs') ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) Summary: 7 errors (**), 0 flaws (~~), 5 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Laganier 3 Internet-Draft DoCoMo Euro-Labs 4 Expires: January 12, 2006 T. Koponen 5 HIIT 6 L. Eggert 7 NEC 8 July 11, 2005 10 Host Identity Protocol (HIP) Registration Extension 11 draft-koponen-hip-registration-01 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 This document may not be modified, and derivative works of it may not 20 be created, except to publish it as an RFC and to translate it into 21 languages other than English. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on January 12, 2006. 41 Copyright Notice 43 Copyright (C) The Internet Society (2005). 45 Abstract 47 This document specifies a registration mechanism for the Host 48 Identity Protocol (HIP) that allows hosts to register with services, 49 such as HIP rendezvous servers or middleboxes. 51 1. Introduction 53 This document specifies an extension to the Host Identity Protocol 54 (HIP) [I-D.ietf-hip-arch]. The extension provides a generic means 55 for a host to register with a service. The service may, for example, 56 be a HIP rendezvous server [I-D.ietf-hip-rvs] or a middlebox 57 [RFC3234]. 59 This document makes no further assumptions about the exact type of 60 service. Likewise, this document does not specify any mechanisms to 61 discover the presence of specific services or means to interact with 62 them after registration. Future documents may describe those 63 operations. 65 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 66 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 67 document are to be interpreted as described in [RFC2119]. 69 2. Terminology 71 This section defines terminology that is used throughout the 72 remainder of this document. Please note that terminology shared with 73 other documents is defined elsewhere [I-D.ietf-hip-arch]. 75 Requester: 76 a HIP node registering with a HIP registrar to request 77 registration for a service. 79 Registrar: 80 a HIP node offering registration for one or more services. 82 Service: 83 a facility that provides requesters with new capabilities or 84 functionalities operating at the HIP layer. Examples include 85 firewalls that support HIP traversal or HIP rendezvous servers. 87 Registration: 88 shared state stored by a requester and a registrar, allowing the 89 requester to benefit from one or more HIP services offered by the 90 registrar. Each registration has an associated finite lifetime. 91 Requesters can extend established registrations through re- 92 registration (i.e., perform a refresh). 94 Registration Type: 95 an identifier for a given service in the registration protocol. 96 For example, the rendezvous service is identified by a specific 97 registration type. 99 3. HIP Registration Extension Overview 101 This document does not specify the means by which a requester 102 discovers the availability of a service, or how a requester locates a 103 registrar. After a requester has discovered a registrar, it either 104 initiates HIP base exchange or uses an existing HIP association with 105 the registrar. In both cases, registrars use additional parameters 106 that the remainder of this document defines to announce their quality 107 and grant or refuse registration. Requesters use corresponding 108 parameters to register with the service. The following sections 109 describe the differences between this registration handshake and the 110 standard HIP base exchange [I-D.ietf-hip-base] . 112 3.1 Registrar Announcing its Ability 114 A host that is capable and willing to act as a registrar SHOULD 115 include a REG_INFO parameter in the R1 packets it sends during all 116 base exchanges. If it is currently unable to provide services due to 117 transient conditions, it SHOULD include an empty REG_INFO, i.e., one 118 with no services listed. If services can be provided later, it 119 SHOULD send UPDATE packets indicating the current set of services 120 available in a new REG_INFO parameter to all hosts it is associated 121 with. 123 3.2 Requester Requesting Registration 125 To request registration with a service, a requester constructs and 126 includes a corresponding REG_REQUEST parameter in an I2 or UPDATE 127 packet it sends to the registrar. 129 If the requester has no HIP association established with the 130 registrar, it SHOULD already send the REG_REQUEST in the I2 packet. 131 This minimizes the number of packets that need to be exchanged with 132 the registrar. A registrar MAY end a HIP association that does not 133 carry a REG_REQUEST by including a NOTIFY with the type REG_REQUIRED 134 in the R2. In this case, no HIP association is created between the 135 hosts. The REG_REQUIRED notification error type is TBD. 137 3.3 Registrar Granting or Refusing Service(s) Registration 139 Once registration has been requested, the registrar is able to 140 authenticate the requester based on the host identity included in I2. 142 It then verifies the host identity is authorized to register with the 143 requested service(s), based on local policies. The details of this 144 authorization procedure depend on the type of requested service(s) 145 and on the local policies of the registrar, and are therefore not 146 further specified in this document. 148 After authorization, the registrar includes in its response (i.e., an 149 R2 or an UPDATE, respectively, depending on whether the registration 150 was requested during the base exchange, or using an existing 151 association) a REG_RESPONSE parameter containing the service(s) 152 type(s) for which it has authorized registration, and zero or more 153 REG_FAILED parameter containing the service(s) type(s) for which it 154 has not authorized registration or registration has failed for other 155 reasons. In particular, REG_FAILED with a failure type of zero 156 indicates the service(s) type(s) that require further credentials for 157 registration. 159 If the registrar requires further authorization and the requester has 160 additional credentials available, the requester SHOULD try to again 161 register with the service after the HIP association has been 162 established. 164 Successful processing of a REG_RESPONSE parameter creates 165 registration state at the requester. In a similar manner, successful 166 processing of a REG_REQUEST parameter creates registration state at 167 the registrar and possibly at the service. Both the requester and 168 registrar can cancel a registration before it expires, if the 169 services afforded by a registration are no longer needed by the 170 requester, or cannot be provided any longer by the registrar (for 171 instance, because its configuration has changed). 173 +-----+ I1 +-----+-----+ 174 | |--------------------->| | S1 | 175 | |<---------------------| | | 176 | | R1(REG_INFO:S1,S2) | +-----+ 177 | RQ | | R | S2 | 178 | | I2(REG_REQ:S1) | | | 179 | |--------------------->| +-----+ 180 | |<---------------------| | S3 | 181 | | R2(REG_RESP:S1) | | | 182 +-----+ +-----+-----+ 183 +-----+ +-----+-----+ 184 | | UPDATE(REG_INFO:S) | | | 185 | |<---------------------| | | 186 | RQ |--------------------->| R | S | 187 | | UPDATE(REG_REQ:S) | | | 188 | | UPDATE(REG_RESP:S) | | | 189 | |<---------------------| | | 190 +-----+ +-----+-----+ 192 4. Parameter Formats and Processing 194 This section describes the format and processing of the new 195 parameters introduced by the HIP registration extension. 197 4.1 Encoding Registration Lifetimes with Exponents 199 The HIP registration uses an exponential encoding of registration 200 lifetimes. This allows compact encoding of 255 different lifetime 201 values ranging from 4 ms to 178 days into an 8-bit integer field. 202 The lifetime exponent field used throughout this document MUST be 203 interpreted as representing the lifetime value 2^((lifetime - 64)/8) 204 seconds. 206 4.2 REG_INFO 208 0 1 2 3 209 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 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 | Type | Length | 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 | Min Lifetime | Max Lifetime | Reg Type #1 | Reg Type #2 | 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 | Reg Type #3 | | 216 +-+-+-+-+-+-+-+-+ Padding + 217 | | 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 Type [ TBD by IANA (930) ] 221 Length Length in octets, excluding Type, Length, and Padding. 222 Min Lifetime Minimum registration lifetime. 223 Max Lifetime Maximum registration lifetime. 224 Reg Type The registration types offered by the registrar. 226 Other documents will define specific values for registration types. 228 0-200 Reserved by IANA 229 201-255 Reserved by IANA for private use 230 Registrars include the parameter in R1 packets in order to announce 231 their registration capabilities. The registrar SHOULD include the 232 parameter in UPDATE packets when its service offering has changed. 233 HIP_SIGNATURE_2 protects the parameter within the R1 packets. 235 4.3 REG_REQUEST 237 0 1 2 3 238 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 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 | Type | Length | 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 | Lifetime | Reg Type #1 | Reg Type #2 | Padding | 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 Type [ TBD by IANA (932) ] 246 Length Length in octets, excluding Type, Length, and Padding. 247 Lifetime Requested registration lifetime. 248 Reg Type The preferred registration types in order of preference. 250 Other documents will define specific values for registration types. 252 0-200 Reserved by IANA 253 201-255 Reserved by IANA for private use 255 A requester includes the REG_REQUEST parameter in I2 or UPDATE 256 packets to register with a registrar's service(s). If the 257 REG_REQUEST parameter is in an UPDATE packet, the registrar MUST NOT 258 modify the registrations of registration types which are not listed 259 in the parameter. Moreover, the requester MUST NOT include the 260 parameter unless the registrar's R1 packet or latest received UPDATE 261 packet has contained a REG_INFO parameter with the requested 262 registration types. 264 The requester MUST NOT include more than one REG_REQUEST parameter in 265 its I2 or UPDATE packets, while the registrar MUST be able to process 266 one or more REG_REQUEST parameters in received I2 or UPDATE packets. 268 HIP_SIGNATURE protects the parameter within the I2 and UPDATE 269 packets. 271 4.4 REG_RESPONSE 273 0 1 2 3 274 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 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | Type | Length | 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 | Lifetime | Reg Type #1 | Reg Type #2 | Padding | 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 Type [ TBD by IANA (934) ] 282 Length Length in octets, excluding Type, Length, and Padding. 283 Lifetime Granted registration lifetime. 284 Reg Type The granted registration types in order of preference. 286 Other documents will define specific values for registration types. 288 0-200 Reserved by IANA 289 201-255 Reserved by IANA for private use 291 The registrar SHOULD includes an REG_RESPONSE parameter in its R2 or 292 UPDATE packet only if a registration has successfully completed. 294 The registrar MUST NOT include more than one REG_RESPONSE parameter 295 in its R2 or UPDATE packets, while the requester MUST be able to 296 process one or more REG_REQUEST parameters in received R2 or UPDATE 297 packets. 299 HIP_SIGNATURE protects the parameter within the R2 and UPDATE 300 packets. 302 4.5 REG_FAILED 304 0 1 2 3 305 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 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 | Type | Length | 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 | Failure Type | Reg Type #1 | Reg Type #n | Padding | 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 Type [ TBD by IANA (936) ] 313 Length Length in octets, excluding Type, Length, and Padding. 314 Failure Type Reason for failure. 315 Reg Type The registration types that failed with the specified 316 reason. 318 Other documents will define specific values for registration types. 320 0-200 Reserved by IANA 321 201-255 Reserved by IANA for private use 323 A failure type of zero means a registrar requires additional 324 credentials to authorize a requester to register with the 325 registration types listed in the parameter. Other failure types than 326 zero have not been defined. 328 The registrar SHOULD include the REG_FAILED parameter in its R2 or 329 UPDATE packet, if registration with the registration types listed has 330 not completed successfully and a requester is asked to try again with 331 additional credentials. 333 HIP_SIGNATURE protects the parameter within the R2 and UPDATE 334 packets. 336 5. Establishing and Maintaining Registrations 338 Establishing and/or maintaining a registration may require additional 339 information not available in the transmitted REG_REQUEST or 340 REG_RESPONSE parameters. Therefore, registration type definitions 341 MAY define dependencies for HIP parameters that are not defined in 342 this document. Their semantics are subject to the specific 343 registration type specifications. 345 The minimum lifetime both registrars and requesters MUST support is 346 10 seconds, while they SHOULD support a maximum lifetime of 120 347 seconds, at least. 349 A zero lifetime is reserved for canceling purposes. Requesting a 350 zero lifetime for a registration type equals to canceling the 351 registration of that type. A requester MAY cancel a registration 352 before it expires by sending a REG_REQ to the registrar with a zero 353 lifetime. A registrar SHOULD respond and grant a registration with a 354 zero lifetime. A registrar (and an attached service) MAY cancel a 355 registration before it expires, at its own discretion. However, if 356 it does so, it SHOULD send a REG_RESPONSE with a zero lifetime to all 357 registered requesters. 359 6. Security Considerations 361 This section discusses the threats on the HIP registration protocol, 362 and their implications on the overall security of HIP. In 363 particular, it argues that the extensions described in this document 364 do not introduce additional threats to HIP. 366 The extensions described in this document rely on the HIP base 367 exchange and do not modify its security characteristics, e.g., 368 digital signatures or HMAC. Hence, the only threat introduced by 369 these extensions are related to the creation of soft registration 370 state at the registrar. 372 Registrars act on a voluntary basis and are willing to accept to be a 373 responder and to then create HIP associations with a number of 374 previously unknown hosts. Because they have to store HIP association 375 state anyway, adding a certain amount of time-limited HIP 376 registration state should not introduce and serious additional 377 threats, especially because HIP registrars may cancel registrations 378 at any time at their own discretion, e.g., because of resource 379 constraints during an attack. 381 7. IANA Considerations 383 This section is to be interpreted according to [RFC2434]. 385 This document updates the IANA Registry for HIP Parameters Types by 386 assigning new HIP Parameter Types values for the new HIP Parameters 387 defined in this document: 389 o REG_INFO (defined in Section 4.2) 391 o REG_REQUEST (defined in Section 4.3) 393 o REG_RESPONSE (defined in Section 4.4) 395 o REG_FAILED (defined in Section 4.5) 397 IANA needs to open a new registry for registration types. No types 398 are defined in this document. Adding a new type requires new IETF 399 specifications. 401 8. Acknowledgments 403 The following people have provided thoughtful and helpful discussions 404 and/or suggestions that have improved this document: Pekka Nikander, 405 Hannes Tschofenig and Mika Kousa. 407 Julien Laganier and Lars Eggert are partly funded by Ambient 408 Networks, a research project supported by the European Commission 409 under its Sixth Framework Program. The views and conclusions 410 contained herein are those of the authors and should not be 411 interpreted as necessarily representing the official policies or 412 endorsements, either expressed or implied, of the Ambient Networks 413 project or the European Commission. 415 9. References 417 9.1 Normative References 419 [I-D.ietf-hip-arch] 420 Moskowitz, R., "Host Identity Protocol Architecture", 421 draft-ietf-hip-arch-02 (work in progress), January 2005. 423 [I-D.ietf-hip-base] 424 Moskowitz, R., "Host Identity Protocol", 425 draft-ietf-hip-base-03 (work in progress), June 2005. 427 [I-D.ietf-hip-rvs] 428 Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) 429 Rendezvous Extension", draft-ietf-hip-rvs-02 (work in 430 progress), June 2005. 432 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 433 Requirement Levels", BCP 14, RFC 2119, March 1997. 435 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 436 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 437 October 1998. 439 9.2 Informative References 441 [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and 442 Issues", RFC 3234, February 2002. 444 Authors' Addresses 446 Julien Laganier 447 DoCoMo Communications Laboratories Europe GmbH 448 Landsberger Strasse 312 449 Munich 80687 450 Germany 452 Phone: +49 89 56824 231 453 Email: julien.ietf@laposte.net 454 URI: http://www.docomolab-euro.com/ 456 Teemu Koponen 457 Helsinki Institute for Information Technology 458 Advanced Research Unit (ARU) 459 P.O. Box 9800 460 Helsinki FIN-02015-HUT 461 Finland 463 Phone: +358 9 45 1 464 Email: teemu.koponen@hiit.fi 465 URI: http://www.hiit.fi/ 467 Lars Eggert 468 NEC Network Laboratories 469 Kurfuerstenanlage 36 470 Heidelberg 69115 471 Germany 473 Phone: +49 6221 90511 43 474 Fax: +49 6221 90511 55 475 Email: lars.eggert@netlab.nec.de 476 URI: http://www.netlab.nec.de/ 478 Appendix A. Document Revision History 480 +-----------+-------------------------------------------------------+ 481 | Revision | Comments | 482 +-----------+-------------------------------------------------------+ 483 | 00 | Initial submission. | 484 | 01 | Editorial and boilerplate fixes. Modified | 485 | | terminology. Added security considerations. Changed | 486 | | requirement keyword on new parameters processing. | 487 +-----------+-------------------------------------------------------+ 489 Intellectual Property Statement 491 The IETF takes no position regarding the validity or scope of any 492 Intellectual Property Rights or other rights that might be claimed to 493 pertain to the implementation or use of the technology described in 494 this document or the extent to which any license under such rights 495 might or might not be available; nor does it represent that it has 496 made any independent effort to identify any such rights. Information 497 on the procedures with respect to rights in RFC documents can be 498 found in BCP 78 and BCP 79. 500 Copies of IPR disclosures made to the IETF Secretariat and any 501 assurances of licenses to be made available, or the result of an 502 attempt made to obtain a general license or permission for the use of 503 such proprietary rights by implementers or users of this 504 specification can be obtained from the IETF on-line IPR repository at 505 http://www.ietf.org/ipr. 507 The IETF invites any interested party to bring to its attention any 508 copyrights, patents or patent applications, or other proprietary 509 rights that may cover technology that may be required to implement 510 this standard. Please address the information to the IETF at 511 ietf-ipr@ietf.org. 513 Disclaimer of Validity 515 This document and the information contained herein are provided on an 516 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 517 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 518 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 519 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 520 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 521 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 523 Copyright Statement 525 Copyright (C) The Internet Society (2005). This document is subject 526 to the rights, licenses and restrictions contained in BCP 78, and 527 except as set forth therein, the authors retain all their rights. 529 Acknowledgment 531 Funding for the RFC Editor function is currently provided by the 532 Internet Society.