idnits 2.17.1 draft-ietf-crisp-iris-lwz-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 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 633. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 610. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 617. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 623. ** 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 copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 6 has weird spacing: '...for the the I...' == Line 131 has weird spacing: '...esponse descr...' == Line 193 has weird spacing: '...payload types...' == Line 222 has weird spacing: '...s other infor...' == Line 246 has weird spacing: '... 1. In respo...' == (2 more instances...) -- 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 7, 2005) is 6890 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) ** Downref: Normative reference to an Informational RFC: RFC 1951 (ref. '1') -- Possible downref: Non-RFC (?) normative reference: ref. '2' ** Obsolete normative reference: RFC 2396 (ref. '5') (Obsoleted by RFC 3986) -- No information found for draft-ietf-crips-iris-common-transport - is the name correct? -- Possible downref: Normative reference to a draft: ref. '7' Summary: 5 errors (**), 0 flaws (~~), 8 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Newton 3 Internet-Draft VeriSign, Inc. 4 Expires: December 9, 2005 June 7, 2005 6 A Lightweight UDP Transfer Protocol for the the Internet Registry 7 Information Service 8 draft-ietf-crisp-iris-lwz-03 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on December 9, 2005. 35 Copyright Notice 37 Copyright (C) The Internet Society (2005). 39 Abstract 41 This document describes a lightweight UDP transfer protocol for the 42 Internet Registry Information Service (IRIS). 44 Table of Contents 46 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 47 2. Document Terminology . . . . . . . . . . . . . . . . . . . . . 4 48 3. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . 5 49 3.1 Payload Descriptor . . . . . . . . . . . . . . . . . . . . 5 50 3.1.1 Payload Request Descriptor . . . . . . . . . . . . . . 5 51 3.1.2 Payload Response Descriptor . . . . . . . . . . . . . 6 52 3.1.3 Payload Header . . . . . . . . . . . . . . . . . . . . 6 53 3.1.4 Payload Types . . . . . . . . . . . . . . . . . . . . 7 54 3.1.5 Version Information . . . . . . . . . . . . . . . . . 7 55 3.1.6 Size Information . . . . . . . . . . . . . . . . . . . 8 56 3.1.7 Other Information . . . . . . . . . . . . . . . . . . 8 57 4. Internationalization Considerations . . . . . . . . . . . . . 10 58 5. IRIS Transport Mapping Definitions . . . . . . . . . . . . . . 11 59 5.1 URI Scheme . . . . . . . . . . . . . . . . . . . . . . . . 11 60 5.2 Application Protocol Label . . . . . . . . . . . . . . . . 11 61 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 62 6.1 Registrations . . . . . . . . . . . . . . . . . . . . . . 12 63 6.1.1 URI Scheme Registration . . . . . . . . . . . . . . . 12 64 6.1.2 Well-known UDP Port Registration . . . . . . . . . . . 12 65 6.1.3 S-NAPTR Registration . . . . . . . . . . . . . . . . . 12 66 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 67 8. Normative References . . . . . . . . . . . . . . . . . . . . . 14 68 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 14 69 A. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 70 Intellectual Property and Copyright Statements . . . . . . . . 20 72 1. Introduction 74 Using S-NAPTR [4], IRIS has the ability to define the use of multiple 75 application transports or transfer protocols for different types of 76 registry services, all at the descretion of the server operator. The 77 UDP transfer protocol defined in this document is completely modular 78 and may be used by any registry types. 80 The binding of this UDP transfer protocol to IRIS is called IRIS-LWZ 81 (for IRIS Lightweight using Compression). 83 IRIS-LWZ is composed of two parts, a binary payload descriptor and an 84 request/response transaction payload. The request/response 85 transaction payload may be compressed using the DEFLATE [1] 86 algorithm. 88 2. Document Terminology 90 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 91 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 92 document are to be interpreted as described in RFC2119 [6]. 94 3. Packet Format 96 The UDP packet format for IRIS-LWZ is as follows: 98 +------+------+----------+--------+------------+---------+ 99 field | src | dest | checksum | UDP | payload | payload | 100 | port | port | | length | descriptor | | 101 +------+------+----------+--------+------------+---------+ 102 octets 2 2 2 2 1..261 0..n 104 (where "src port" means source port and "dest port" means destination 105 port). 107 Each IRIS-LWZ query or response is contained in a single UDP packet. 109 3.1 Payload Descriptor 111 The payload descriptor has two different formats, one for a request 112 and one for a response. However, each format shares a common 1 octet 113 payload header described in Section 3.1.3. 115 3.1.1 Payload Request Descriptor 117 The payload descriptor for request packets has the following format: 119 +--------+-------------+----------+-----------+-----------+ 120 field | header | transaction | maximum | authority | authority | 121 | | ID | response | length | | 122 | | | length | | | 123 +--------+-------------+----------+-----------+-----------+ 124 octets 1 2 2 1 0..255 126 These fields have the following meanings: 128 header - as described in Section 3.1.3. 130 transaction ID - a 16 bit value identifying the transaction. This 131 value will be returned in the payload response descriptor 132 (Section 3.1.2) and can be used by clients to match requests with 133 responses. Clients SHOULD pick the value randomly and SHOULD NOT 134 use sequences of 16 bit values. Clients MUST NOT set all the bits 135 in this value to 1 (i.e. use a value of 0xFFFF). 137 maximum response length - the total length of the UDP packet (i.e. 138 UDP header length + payload descriptor length + XML payload 139 length) that should not be exceeded when responding to this 140 request. If the server cannot provide a response that is equal to 141 or less than this value, then it MUST respond with size 142 information (Section 3.1.6). 144 authority length - the length of the authority field in this 145 payload descriptor. 147 authority - a string of octets describing the authority against 148 wich this request is to be executed. See [3] for the definition 149 and description of an authority. The number of octets in this 150 string MUST be no more and no less than the number specified by 151 the authority length. 153 3.1.2 Payload Response Descriptor 155 The payload descriptor for response packets consists of a payload 156 header (Section 3.1.3) and a transaction ID. 158 +--------+-------------+ 159 field | header | transaction | 160 | | ID | 161 +--------+-------------+ 162 octets 1 2 164 The transaction ID MUST be the value of the transaction ID of the 165 corresponding request. If the corresponding request did not contain 166 a transaction ID, servers MUST use a transaction ID with all bits set 167 to 1 (i.e. use a value of 0xFFFF) and send a descriptor error (see 168 Section 3.1.7). 170 3.1.3 Payload Header 172 Each bit in the 1 byte payload header has the following meaning: 174 bits 7 and 6 - version number ('V' field) - If 0 (both bits are 175 zero), the protocol is the version defined in this document. 176 Otherwise, the rest of the bits in the header and the payload may 177 be interpreted as another version. 179 bit 5 - request/response flag ('RR' flag) - If 0, this packet is a 180 request (Section 3.1.1) packet. If 1, this packet is a response 181 (Section 3.1.2) packet. 183 bits 4 - payload deflated ('PD' flag) - If 1, the payload is 184 compressed using the DEFLATE [1] algorithm. 186 bit 3 - deflate supported ('DS' flag) - If 1, the sender of this 187 packet supports compression using the DEFLATE algorithm. When 188 this bit is 0 in a request, the payload of the response MUST NOT 189 be compressed with DEFLATE. 191 bit 2 - reserved - This MUST be 0. 193 bits 1 and 0 - The value of these bits indicate payload types 194 (Section 3.1.4) ('PT' field). 196 3.1.4 Payload Types 198 A payload type indicates the type of content in the UDP packet 199 following the payload descriptor. Some payload types have no meaning 200 in request packets, and some payload types differ in meaning between 201 requests and responses. Some payload types indicate an empty 202 payload. 204 The payload type values in binary are as follows: 206 00 - xml payload ('xml' type). The payload is either an IRIS- 207 based XML request or an IRIS-based XML response. 209 01 - version info ('vi' type). In a request packet, this payload 210 type indicates that the server is to respond with version 211 information (Section 3.1.5), and that the payload is empty. In a 212 response packet, this payload type indicates that the payload is 213 version information (Section 3.1.5). 215 10 - size info ('si' type). This payload type has no meaning in a 216 request packet and is a descriptor error. In a response packet, 217 this payload type indicates that the payload is size information 218 (Section 3.1.6). 220 11 - other info ('oi' type). This payload type has no meaning in 221 a request packet and is a descriptor error. In a response packet, 222 this payload type indicates that the payload is other information 223 (Section 3.1.7). 225 3.1.5 Version Information 227 A payload type with version information ('vi') MUST be comformant to 228 the XML defined in [7] and use the element as the root 229 element. 231 In the context of IRIS-LWZ, the protocol identifiers for these 232 elements are as follows: 234 - the value "iris.lwz1" to indicate the 235 protocol specified in this document. 237 - the XML namespace identifier for IRIS [3]. 239 - the XML namespace identifier for IRIS registries. 241 This document defines no extension identifiers and no authentication 242 mechanism identifiers. 244 Servers SHOULD send version information in the following cases: 246 1. In response to a version information request (i.e. the PT flag 247 is set to 'vi'). 249 2. The version in a payload descriptor header does not match a 250 version the server supports. 252 3. The IRIS-based XML payload does not match a version the server 253 supports. 255 The protocols identified by the element MUST only 256 indicate protocols running on the same socket as the sender of the 257 corresponding request. In other words, while a server operator may 258 also be running IRIS-XPC, this XML instance is only intended to 259 describe version negotiation for IRIS-LWZ. 261 The definition of octet size for the 'requestSizeOctets' and 262 'responseSizeOctets' attributes of the element are 263 defined in Section 3.1.6. 265 3.1.6 Size Information 267 A payload type with size information ('si') MUST be comformant to the 268 XML defined in [7] and use the element as the root element. 270 Octet counts provided by this information are defined as the total 271 length of the UDP packet (i.e. UDP header length + payload 272 descriptor length + XML payload length). 274 3.1.7 Other Information 276 A payload type with other information ('oi') MUST be comformant to 277 the XML defined in [7] and use the element as the root 278 element. 280 The values for the 'type' attribute of are as follows: 282 'descriptor-error' - indicates there was an error decoding the 283 descriptor. Servers SHOULD send a descriptor error in the 284 following cases: 286 1. When a request is received with a payload type indicating size 287 information (i.e. the PT flag is 'si'). 289 2. When a request is received with a payload type indicating 290 other information (i.e. the PT flag is 'oi'). 292 3. When a request is sent with an invalid transaction ID. 294 4. When reserved bits in the payload descriptor are set to 295 values other than zero. 297 'payload-error' - indicates there was an error interpretting the 298 payload. Servers MUST send a payload error if they receive XML 299 (i.e. the PT flag is set to 'xml') and the XML cannot be parsed. 301 'system-error' - indicates that the receiver cannot process the 302 request due to a condition not related to this protocol. Servers 303 SHOULD send a system-error when they are capable of responding to 304 requests but not capable of processing requests. 306 'authority-error' - indicates that the intended authority 307 specified in the corresponding request is not served by the 308 receiver. Servers SHOULD send an authority error when they 309 receive a request directed to an authority other than those they 310 serve. 312 'no-inflation-support-error' - indicates that the receiver does 313 not support payloads that have been compressed with DEFLATE [1]. 314 Servers MUST send this error when they receive a request that has 315 been compressed with DEFLATE but they do not support inflation. 317 4. Internationalization Considerations 319 XML processors are obliged to recognize both UTF-8 and UTF-16 [2] 320 encodings. Use of the XML defined by [7] MUST NOT use any other 321 character encodings other than UTF-8 or UTF-16. 323 5. IRIS Transport Mapping Definitions 325 This section lists the definitions required by IRIS [3] for transport 326 mappings. 328 5.1 URI Scheme 330 See Section 6.1.1. 332 5.2 Application Protocol Label 334 See Section 6.1.3. 336 6. IANA Considerations 338 6.1 Registrations 340 6.1.1 URI Scheme Registration 342 URL scheme name: iris.lwz 344 URL scheme syntax: defined in Section 5.1 and [3]. 346 Character encoding considerations: as defined in RFC2396 [5]. 348 Intended usage: identifies an IRIS entity made available using XML 349 over UDP 351 Applications using this scheme: defined in IRIS [3]. 353 Interoperability considerations: n/a 355 Security Considerations: defined in Section 7. 357 Relevant Publications: IRIS [3]. 359 Contact Information: Andrew Newton 361 Author/Change controller: the IESG 363 6.1.2 Well-known UDP Port Registration 365 Protocol Number: UDP 367 Message Formats, Types, Opcodes, and Sequences: defined in Section 3 368 and Section 3.1. 370 Functions: defined in IRIS [3]. 372 Use of Broadcast/Multicast: none 374 Proposed Name: IRIS-LWZ 376 Short name: iris.lwz 378 Contact Information: Andrew Newton 380 6.1.3 S-NAPTR Registration 382 Application Protocol Label (see [4]): iris.lwz 383 Intended usage: identifies an IRIS server using XML over UDP 385 Interoperability considerations: n/a 387 Security Considerations: defined in Section 7. 389 Relevant Publications: IRIS [3]. 391 Contact Information: Andrew Newton 393 Author/Change controller: the IESG 395 7. Security Considerations 397 IRIS-LWZ is intended for serving public data; it provides no in-band 398 mechanisms for authentication or encryption. Any application with 399 this need must provide out of band mechanisms to provide it (e.g., 400 IPSec), or use the IRIS transfer protocols that provides such 401 capabilities. 403 8. Normative References 405 [1] Deutsch, P., "DEFLATE Compressed Data Format Specification 406 version 1.3", RFC 1951, May 1996. 408 [2] The Unicode Consortium, "The Unicode Standard, Version 3", 409 ISBN 0-201-61633-5, 2000, . 411 [3] Newton, A. and M. Sanz, "Internet Registry Information Service", 412 RFC 3891, January 2004. 414 [4] Daigle, L. and A. Newton, "Domain-Based Application Service 415 Location Using SRV RRs and the Dynamic Delegation Discovery 416 Service (DDDS)", RFC 3958, January 2005. 418 [5] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 419 Resource Identifiers (URI): Generic Syntax", RFC 2396, 420 August 1998. 422 [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement 423 Levels", RFC 2119, BCP 14, March 1997. 425 [7] Newton, A., "A Common Schema for Internet Registry Information 426 Service Transfer Protocols", 427 draft-ietf-crips-iris-common-transport-00 (work in progress), 428 April 2005. 430 Author's Address 432 Andrew L. Newton 433 VeriSign, Inc. 434 21345 Ridgetop Circle 435 Sterling, VA 20166 436 USA 438 Phone: +1 703 948 3382 439 Email: anewton@verisignlabs.com; andy@hxr.us 440 URI: http://www.verisignlabs.com/ 442 Appendix A. Examples 444 This section gives examples of IRIS-LWZ exchanges. Lines beginning 445 with "C:" denote data sent by the client to the server, and lines 446 beginning with "S:" denote data sent by the server to the client. 447 Following the "C:" or "S:", the line either contains octet values in 448 hexadecimal notation with comments or XML fragments. No line 449 contains both octet values with comments and XML fragments. Comments 450 are contained within parenthesis. 452 The following example demonstrates an IRIS client requesting a lookup 453 of 'AUP' in the 'local' entity class of a 'dreg1' registry. The 454 client passes a bag with the search request. The server responds 455 with a 'nameNotFound' response and an explanation. 457 C: (request packet) 458 C: 0x08 (header: V=0,RR=request,PD=no,DS=yes,PT=xml) 459 C: 0x03 0xA4 (transaction ID=932) 460 C: 0x05 0xDA (maximum response size=1498) 461 C: 0x09 (authority length=9) 462 C: (authority="localhost") 463 C: 0x6c 0x6f 0x63 0x61 0x6c 0x68 0x6f 0x73 0x74 464 C: (IRIS XML request) 465 C: 467 C: 468 C: 469 C: 470 C: 127.0.0.1:3434 471 C: 4LnQ1KdCahzyvwBqJis5rw== 472 C: 473 C: 474 C: 478 C: 479 C: 481 S: (response packet) 482 S: 0x20 (header: V=0,RR=response,PD=no,DS=no,PT=xml) 483 S: 0x03 0xA4 (transaction ID=932) 484 S: (IRIS XML response) 485 S: 486 S: 487 S: 488 S: The name 'AUP' is not found in 'local'. 489 S: 491 Figure 4: Example 1 493 The following example demonstrates an IRIS client requesting domain 494 availability information for 'milo.example.com'. The server responds 495 that the domain is assigned and active. 497 C: (request packet) 498 C: 0x00 (header: V=0,RR=request,PD=no,DS=no,PT=xml) 499 C: 0x0B 0xE7 (transaction ID=3047) 500 C: 0x0F 0xA0 (maximum response size=4000) 501 C: 0x0B (authority length=11) 502 C: (authority="example.com") 503 C: 0x65 0x78 0x61 0x6D 0x70 0x6C 0x65 0x23 0x63 0x6F 0x6D 504 C: (IRIS XML request) 505 C: 508 C: 509 C: 513 C: 514 C: 516 S: (response packet) 517 S: 0x20 (header: V=0,RR=response,PD=no,DS=no,PT=xml) 518 S: 0x0B 0xE7 (transaction ID=3047) 519 S: (IRIS XML response) 520 S: 521 S: 526 S: milo.example.com 527 S: 528 S: 530 Figure 5: Example 2 532 The following example demonstrates an IRIS client requesting domain 533 availability information for felix.example.net, hobbes.example.net, 534 and daffy.example.net. The client does not support responses 535 compressed with DEFLATE and the maximum UDP packet it can safely 536 receive is 498 octets. The server responds with size information 537 indicating that it would take 1211 octets to provide an answer. 539 C: (request packet) 540 C: 0x00 (header: V=0,RR=request,PD=no,DS=no,PT=xml) 541 C: 0x7E 0x8A (transaction ID=32394) 542 C: 0x01 0xF2 (maximum response size=498) 543 C: 0x0B (authority length=11) 544 C: (authority="example.net") 545 C: 0x65 0x78 0x61 0x6D 0x70 0x6C 0x65 0x23 0x6E 0x65 0x74 546 C: (IRIS XML request) 547 C: 550 C: 551 C: 553 C: 554 C: 555 C: 557 C: 558 C: 559 C: 561 C: 562 C: 564 S: (response packet) 565 S: 0x22 (header: V=0,RR=response,PD=no,DS=no,PT=si) 566 S: 0x7E 0x8A (transaction ID=32394) 567 S: (Size Information XML response) 568 S: 569 S: 1211 570 S: 572 Figure 6: Example 3 574 The following example illustrates an IRIS client requesting the 575 version information from a server, and the server returning the 576 verion information. 578 C: (request packet) 579 C: 0x01 (header: V=0,RR=request,PD=no,DS=no,PT=vi) 580 C: 0x2E 0x9C (transaction ID=11932) 581 C: 0x01 0xF2 (maximum response size=498) 582 C: 0x0B (authority length=11) 583 C: (authority="example.net") 584 C: 0x65 0x78 0x61 0x6D 0x70 0x6C 0x65 0x23 0x6E 0x65 0x74 586 S: (response packet) 587 S: 0x21 (header: V=0,RR=response,PD=no,DS=no,PT=vi) 588 S: 0x2E 0x9C (transaction ID=11932) 589 S: (Version Information XML response) 590 S: 591 S: 592 S: 593 S: 594 S: 595 S: 596 S: 597 S: 599 Figure 7: Example 4 601 Intellectual Property Statement 603 The IETF takes no position regarding the validity or scope of any 604 Intellectual Property Rights or other rights that might be claimed to 605 pertain to the implementation or use of the technology described in 606 this document or the extent to which any license under such rights 607 might or might not be available; nor does it represent that it has 608 made any independent effort to identify any such rights. Information 609 on the procedures with respect to rights in RFC documents can be 610 found in BCP 78 and BCP 79. 612 Copies of IPR disclosures made to the IETF Secretariat and any 613 assurances of licenses to be made available, or the result of an 614 attempt made to obtain a general license or permission for the use of 615 such proprietary rights by implementers or users of this 616 specification can be obtained from the IETF on-line IPR repository at 617 http://www.ietf.org/ipr. 619 The IETF invites any interested party to bring to its attention any 620 copyrights, patents or patent applications, or other proprietary 621 rights that may cover technology that may be required to implement 622 this standard. Please address the information to the IETF at 623 ietf-ipr@ietf.org. 625 Disclaimer of Validity 627 This document and the information contained herein are provided on an 628 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 629 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 630 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 631 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 632 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 633 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 635 Copyright Statement 637 Copyright (C) The Internet Society (2005). This document is subject 638 to the rights, licenses and restrictions contained in BCP 78, and 639 except as set forth therein, the authors retain all their rights. 641 Acknowledgment 643 Funding for the RFC Editor function is currently provided by the 644 Internet Society.