idnits 2.17.1 draft-ietf-netconf-soap-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by 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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == 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 (February 13, 2004) is 7370 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '6' is defined on line 484, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 488, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 505, but no explicit reference was found in the text == Unused Reference: '14' is defined on line 517, but no explicit reference was found in the text == Unused Reference: '15' is defined on line 522, but no explicit reference was found in the text == Unused Reference: '17' is defined on line 532, but no explicit reference was found in the text == Unused Reference: '18' is defined on line 535, but no explicit reference was found in the text == Outdated reference: A later version (-01) exists of draft-enns-xmlconf-spec-00 -- Possible downref: Normative reference to a draft: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' ** Obsolete normative reference: RFC 2616 (ref. '8') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 3205 (ref. '9') (Obsoleted by RFC 9205) ** Obsolete normative reference: RFC 2069 (ref. '10') (Obsoleted by RFC 2617) ** Obsolete normative reference: RFC 2246 (ref. '12') (Obsoleted by RFC 4346) -- Obsolete informational reference (is this intentional?): RFC 3288 (ref. '18') (Obsoleted by RFC 4227) Summary: 6 errors (**), 0 flaws (~~), 10 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group T. Goddard 2 Internet-Draft ICEsoft Technologies Inc. 3 Expires: August 13, 2004 February 13, 2004 5 NETCONF Over SOAP 6 draft-ietf-netconf-soap-01 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that other 15 groups may also distribute working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference 20 material or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at http:// 23 www.ietf.org/ietf/1id-abstracts.txt. 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 This Internet-Draft will expire on August 13, 2004. 30 Copyright Notice 32 Copyright (C) The Internet Society (2004). All Rights Reserved. 34 Abstract 36 The device management protocol NETCONF is applicable to a wide range 37 of devices in a variety of environments. The emergence of Web 38 Services gives one such environment, and is presently characterized 39 by the use of SOAP over HTTP. NETCONF finds many benefits in this 40 environment: from the re-use of existing standards, to ease of 41 software development, to integration with deployed systems. Herein, 42 we describe a SOAP over HTTP binding that, when used with persistent 43 HTTP connections, yields an application protocol sufficient for 44 NETCONF. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2. SOAP Background for NETCONF . . . . . . . . . . . . . . . . 4 50 2.1 Use and Storage of WSDL and XSD . . . . . . . . . . . . . . 4 51 2.2 SOAP over HTTP . . . . . . . . . . . . . . . . . . . . . . . 5 52 2.3 HTTP Drawbacks . . . . . . . . . . . . . . . . . . . . . . . 5 53 2.4 BCP56: On the Use of HTTP as a Substrate . . . . . . . . . . 6 54 2.5 Important HTTP 1.1 Features . . . . . . . . . . . . . . . . 6 55 2.6 SOAP Implementation Considerations . . . . . . . . . . . . . 7 56 2.6.1 SOAP Feature Exploitation . . . . . . . . . . . . . . . . . 7 57 2.6.2 SOAP Headers . . . . . . . . . . . . . . . . . . . . . . . . 7 58 3. A SOAP Web Service for NETCONF . . . . . . . . . . . . . . . 8 59 3.1 Fundamental Use Case . . . . . . . . . . . . . . . . . . . . 8 60 3.2 NETCONF Sessions . . . . . . . . . . . . . . . . . . . . . . 8 61 3.3 Capabilities Exchange . . . . . . . . . . . . . . . . . . . 8 62 3.4 A NETCONF/SOAP example . . . . . . . . . . . . . . . . . . . 9 63 4. Security Considerations . . . . . . . . . . . . . . . . . . 11 64 4.1 Integrity, Privacy, and Authentication . . . . . . . . . . . 11 65 4.2 Vulnerabilities . . . . . . . . . . . . . . . . . . . . . . 11 66 4.3 Environmental Specifics . . . . . . . . . . . . . . . . . . 12 67 Normative References . . . . . . . . . . . . . . . . . . . . 13 68 Informative References . . . . . . . . . . . . . . . . . . . 15 69 Author's Address . . . . . . . . . . . . . . . . . . . . . . 15 70 A. WSDL Definitions . . . . . . . . . . . . . . . . . . . . . . 16 71 A.1 NETCONF SOAP Binding . . . . . . . . . . . . . . . . . . . . 16 72 A.2 Sample Service Definition . . . . . . . . . . . . . . . . . 17 73 Intellectual Property and Copyright Statements . . . . . . . 18 75 1. Introduction 77 Given the use of XML [2] and the remote procedure call 78 characteristics, it is natural to consider a binding of the NETCONF 79 [1] operations to a SOAP [3] application protocol. This document 80 proposes a binding of this form. 82 In general, SOAP over HTTP is a natural application protocol for 83 NETCONF, essentially because of the remote procedure call character 84 of both, but care must be taken in some cases as HTTP is inherently 85 synchronous and client-driven. 87 Four basic topics are presented: SOAP specifics of interest to 88 NETCONF, specifics on implementing NETCONF as a SOAP-based web 89 service, security considerations, and an appendix with functional 90 WSDL. In some sense, the most important part of the document is the 91 brief WSDL document presented in the Appendix. With the right tools, 92 the WSDL combined with the base NETCONF XML Schemas provide machine 93 readable descriptions sufficient for the development of software 94 applications using NETCONF. 96 2. SOAP Background for NETCONF 98 Why introduce SOAP as yet another wrapper around what is already a 99 remote procedure call message? There are, in fact, both technical 100 and practical reasons. The technical reasons are perhaps less 101 compelling, but let's examine them first. 103 The use of SOAP does offer a few technical advantages. SOAP is 104 fundamentally an XML messaging scheme (which is capable of supporting 105 remote procedure call) and it defines a simple message format 106 composed of a "header" and a "body" contained within an "envelope". 107 The "header" contains meta-information relating to the message, and 108 can be used to indicate such things as store-and-forward behaviour or 109 transactional characteristics. In addition, SOAP specifies an 110 optional encoding for the "body" of the message. However, this 111 encoding is not applicable to NETCONF as one of the goals is to have 112 highly readable XML, and SOAP-encoding is optimized instead for ease 113 of automated deserialization. These benefits of the SOAP message 114 structure are simple, but worthwhile due to the fact that they are 115 already standardized. 117 It is the practical reasons that truly make SOAP over HTTP an 118 interesting choice for device management. It is not difficult to 119 invent a mechanism for exchanging XML messages over TCP, but what is 120 difficult is getting that mechanism supported in a wide variety of 121 tools and operating systems and having that mechanism understood by a 122 great many developers. SOAP over HTTP (with WSDL) is seeing good 123 success at this, and this means that a device management protocol 124 making use of these technologies has advantages in being implemented 125 and adopted. Admittedly, there are interoperability problems with 126 SOAP and WSDL, but such problems have wide attention and can be 127 expected to be resolved. 129 2.1 Use and Storage of WSDL and XSD 131 One of the advantages of using machine readable formats such as Web 132 Services Description Language (WSDL) [4] and XML Schemas [5] is that 133 they can be used automatically in the software development process. 134 With appropriate tools, WSDL and XSD can be used to generate classes 135 that act as remote interfaces or application specific data 136 structures. Other uses, such as document generation and service 137 location, are also common. A great innovation found with many 138 XML-based definition languages is the use of hyperlinks for referring 139 to documents containing supporting definitions. For instance, in 140 WSDL, the import statement 142 145 imports the definitions of XML types and elements from the base 146 NETCONF schema. Ideally, the file containing that schema is hosted 147 on a web server under the authority of the standards body that 148 defined the schema. In this way, dependent standards can be built up 149 over time and all are accessible to automated software tools that 150 ensure adherence to the standards. Thus, it will gradually become as 151 important for iana.org to host documents like 153 http://iana.org/netconf/1.0/base/base.xsd 155 as the IETF now hosts documents such as 157 http://www.ietf.org/rfc/rfc2616.txt 159 2.2 SOAP over HTTP 161 While it is true that SOAP focuses on messages and can be bound to 162 different underlying protocols such as HTTP, SMTP, or BEEP, most 163 existing SOAP implementations support only HTTP or HTTP/TLS. For 164 this discussion we will assume SOAP over HTTP or HTTP/TLS unless 165 otherwise specified. (This also includes applications of IPSec to 166 SOAP over HTTP.) 168 Note that there are a number of advantages to considering SOAP over 169 protocols other than HTTP, as HTTP assigns the very distinct client 170 and server roles by connection initiation. This would cause 171 difficulties in supporting asynchronous notification and could be 172 relieved in many ways by replacing HTTP with BEEP. 174 2.3 HTTP Drawbacks 176 HTTP is not the ideal transport for messaging, but it is adequate for 177 the most basic interpretation of "remote procedure call". HTTP is 178 based on a communication pattern whereby the client (which initiates 179 the TCP connection) makes a "request" to the server. The server 180 returns a "response" and this process is continued (possibly over a 181 persistent connection, as described below). This matches the basic 182 idea of a remote procedure call where the caller invokes a procedure 183 on a remote server and waits for the return value. 185 Potential criticisms of HTTP could include the following: 187 o server-initiated data flow is awkward 189 o headers are verbose and text-based 191 o idle connections may be closed by intermediate proxies 192 o data encapsulation must adhere to MIME 194 o bulk transfer relies on stream-based ordering 196 In many ways these criticisms are directed at particular compromises 197 in the design of HTTP. As such, they are important to consider, but 198 it is not clear that they result in fatal drawbacks for a device 199 management protocol. 201 2.4 BCP56: On the Use of HTTP as a Substrate 203 Best Current Practice 56 [9] presents a number of important 204 considerations on the use of HTTP in application protocols. In 205 particular, it raises the following concerns: 207 o HTTP may be more complex than is necessary for the application 209 o The use of HTTP may mask the application from some firewalls 211 o A substantially new service should not re-use port 80 as assigned 212 to HTTP 214 Fundamentally, these concerns lie directly with SOAP over HTTP, 215 rather than the application of SOAP over HTTP to NETCONF. As BCP 56 216 indicates, it is debatable whether HTTP is an appropriate protocol 217 for SOAP at all, and it is likely that BEEP would be a superior 218 protocol for most SOAP applications. Unfortunately, SOAP over HTTP is 219 in common use and must be supported if the practical benefits of SOAP 220 are to be realized. 222 It is possible, however, to respond to the concern on the re-use of 223 port 80. A NETCONF SOAP service can be offered on any desired port, 224 and it is recommended that a new standard port for SOAP over HTTP, or 225 a new standard port for NETCONF over SOAP (over HTTP) be defined. 227 2.5 Important HTTP 1.1 Features 229 HTTP 1.1 [8] includes two important features that provide for 230 relatively efficient transport of SOAP messages. These features are 231 "persistent connections" and "chunked transfer-coding". 233 Persistent connections allow a single TCP connection to be used 234 across multiple HTTP requests. This permits multiple SOAP request/ 235 response message pairs to be exchanged without the overhead of 236 creating a new TCP connection for each request. Given that a single 237 stream is used for both requests and responses, it is clear that some 238 form of framing is necessary. For messages whose length is known in 239 advance, this is handled by the HTTP header "Content-length". For 240 messages of dynamic length, "Chunking" is required. 242 HTTP "Chunking" or "chunked transfer-coding" allows the sender to 243 send an indefinite amount of binary data. This is accomplished by 244 informing the receiver of the size of each "chunk" (substring of the 245 data) before the chunk is transmitted. The last chunk is indicated 246 by a chunk of zero length. Chunking can be effectively used to 247 transfer a large XML document where the document is generated on-line 248 from a non-XML form in memory. 250 In terms of application to SOAP message exchanges, persistent 251 connections are clearly important for performance reasons, and are 252 particularly important when it is the persistence of authenticated 253 connections that is at stake. When one considers that messages of 254 dynamic length are the rule rather than the exception for SOAP 255 messages, it is also clear that Chunking is very useful. In some 256 cases it is possible to buffer a SOAP response and determine its 257 length before sending, but the storage requirements for this are 258 prohibitive for many devices. Together, these two features provide a 259 good foundation for device management using SOAP over HTTP. 261 2.6 SOAP Implementation Considerations 263 It is not the goal of this document to cover the SOAP [3] 264 specification in detail. Instead, we provide a few comments that may 265 be of interest to an implementor of NETCONF over SOAP. 267 2.6.1 SOAP Feature Exploitation 269 NETCONF over SOAP does not make extensive use of SOAP features. For 270 instance, NETCONF operations are not broken into SOAP message parts, 271 and the SOAP header is not used to convey metadata. This is a 272 deliberate design decision as it allows the implementor to easily 273 provide NETCONF over multiple substrates while handling the messages 274 over those different substrates in a common way. 276 2.6.2 SOAP Headers 278 Implementors of NETCONF over SOAP should be aware of the following 279 characteristic of SOAP headers: a SOAP header may have the attribute 280 "mustUnderstand" and, if so, the recipient must either process the 281 header block or not process the SOAP message at all, and instead 282 generate a fault. A "mustUnderstand" header must not be silently 283 discarded. 285 3. A SOAP Web Service for NETCONF 287 3.1 Fundamental Use Case 289 The fundamental use case for NETCONF over SOAP (NETCONF/SOAP) over 290 HTTP is that of a management console ("manager" role) managing one or 291 more devices running NETCONF agents ("agent" role). The manager 292 initiates an HTTP connection to an agent and drives the NETCONF 293 session via a sequence of SOAP messages over HTTP requests. When the 294 manager closes the HTTP connection, the NETCONF session is also 295 closed. 297 3.2 NETCONF Sessions 299 NETCONF sessions are persistent for both performance and semantic 300 reasons. NETCONF session state contains the following: 302 1. Authentication Information 304 2. Capability Information 306 3. Locks 308 4. Pending Operations 310 5. Operation Sequence Numbers 312 Authentication must be maintained throughout a session due to the 313 fact that it is expensive to establish. Capability Information is 314 maintained so that appropriate operations can be applied during a 315 session. Locks are released upon termination of a session as this 316 makes the protocol more robust. Pending operations come and go from 317 existence during the normal course of RPC operations. Operation 318 sequence numbers provide the small but necessary state information to 319 refer to operations during the session. 321 In the case of SOAP over HTTP, a NETCONF "session" is supported by an 322 HTTP connection with an authenticated user. To support automated 323 cleanup, a NETCONF over SOAP session is closed when the HTTP 324 connection is closed. 326 3.3 Capabilities Exchange 328 Capabilities exchange, if defined through a NETCONF RPC operation, 329 can easily be accommodated in the SOAP binding. 331 3.4 A NETCONF/SOAP example 333 Since the proposed WSDL (in Appendix A.1) uses document/literal 334 encoding, the use of a SOAP header and body has little impact on the 335 representation of a NETCONF operation. This example shows HTTP/1.0 336 for simplicity. 338 POST /netconf HTTP/1.0 339 Content-Type: text/xml; charset=utf-8 340 Accept: application/soap+xml, text/* 341 Cache-Control: no-cache 342 Pragma: no-cache 343 Content-Length: 470 345 346 348 349 350 351 352 353 354 355 356 357 xml 358 359 360 361 363 The HTTP/1.0 response is also straightforward: 365 HTTP/1.0 200 OK 366 Content-Type: text/xml; charset=utf-8 368 369 371 372 373 374 375 376 root 377 superuser 378 379 380 fred 381 admin 382 383 384 barney 385 admin 386 387 388 389 390 391 393 4. Security Considerations 395 NETCONF is used to access and modify configuration information, so 396 the ability to access this protocol should be limited to users and 397 systems that are authorized to view or modify the agent's 398 configuration data. 400 Because configuration information is sent in both directions, it is 401 not sufficient for just the client or user to be authenticated with 402 the server. The identity of the server should also be authenticated 403 with the client. 405 Configuration data may include sensitive information, such as user 406 names or security keys. So, NETCONF should only be used over 407 communications channels that provide strong encryption for data 408 privacy. 410 If the NETCONF server provides remote access through insecure 411 protocols, such as HTTP, care should be taken to prevent execution of 412 the NETCONF program when strong user authentication or data privacy 413 is not available. 415 4.1 Integrity, Privacy, and Authentication 417 The NETCONF SOAP binding relies on an underlying secure transport for 418 integrity and privacy. Such transports are expected to include TLS 419 [12] and IPSec. There are a number of options for authentication 420 (some of which are deployment-specific): 422 o within the transport (such as with TLS client certificates) 424 o within HTTP (such as Digest Access Authentication [10]) 426 o within SOAP (such as a digital signature in the header [16]) 428 HTTP and SOAP level authentication can be integrated with RADIUS [13] 429 to support remote authentication databases. 431 4.2 Vulnerabilities 433 The above protocols may have various vulnerabilities, and these may 434 be inherited by NETCONF/SOAP. 436 NETCONF itself may have vulnerabilities due to the fact that an 437 authorization model is not currently specified. 439 It is important that device capabilities and authorization remain 440 constant for the duration of any outstanding NETCONF session. In the 441 case of NETCONF, it is important to consider that device management 442 may be taking place over multiple substrates (in addition to SOAP) 443 and it is important that the different substrates have a common 444 authentication model. 446 4.3 Environmental Specifics 448 Some deployments of NETCONF/SOAP may choose to use HTTP without 449 encryption. This presents vulnerabilities but may be selected for 450 deployments involving closed networks or debugging scenarios. 452 A device managed by NETCONF may interact (over protocols other than 453 NETCONF) with devices managed by other protocols, all of differing 454 security. Each point of entry brings with it a potential 455 vulnerability. 457 Normative References 459 [1] Enns, R., "XMLCONF Configuration Protocol", 460 draft-enns-xmlconf-spec-00 (work in progress), Feb 2003, 461 . 464 [2] Bray, T., Paoli, J., Sperberg-McQueen, C. and E. Maler, 465 "Extensible Markup Language (XML) 1.0 (Second Edition)", W3C 466 REC REC-xml-20001006, October 2000, . 469 [3] Box, D., Ehnebuske, D., Kakivaya, G., Layman, A., Mendelsohn, 470 N., Nielsen, H., Thatte, S. and D. Winer, "Simple Object Access 471 Protocol (SOAP) 1.1", W3C Note NOTE-SOAP-20000508, May 2000, 472 . 474 [4] Christensen, E., Curbera, F., Meredith, G. and S. Weerawarana, 475 "Web Services Description Language (WSDL) 1.1", W3C Note 476 NOTE-wsdl-20010315, March 2001, . 479 [5] Thompson, H., Beech, D., Maloney, M. and N. Mendelsohn, "XML 480 Schema Part 1: Structures", W3C Recommendation 481 REC-xmlschema-1-20010502, May 2001, . 484 [6] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 485 Extensions (MIME) Part One: Format of Internet Message Bodies", 486 RFC 2045, November 1996, . 488 [7] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 489 Extensions (MIME) Part Two: Media Types", RFC 2046, November 490 1996, . 492 [8] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., 493 Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- 494 HTTP/1.1", RFC 2616, June 1999, . 497 [9] Moore, K., "On the use of HTTP as a Substrate", RFC 3205, 498 February 2002, . 500 [10] Franks, J., Hallam-Baker, P., Hostetler, J., Leach, P., 501 Luotonen, A., Sink, E. and L. Stewart, "An Extension to HTTP: 502 Digest Access Authentication", RFC 2069, January 1997, . 505 [11] Bradner, S., "Key words for use in RFCs to Indicate Requirement 506 Levels", RFC 2119, March 1997, . 509 [12] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. and 510 P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, January 511 1999, . 513 [13] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote 514 Authentication Dial In User Service (RADIUS)", RFC 2865, June 515 2000, . 517 [14] Rose, M. and D. New, "Reliable Delivery for syslog", RFC 3195, 518 November 2001, . 520 Informative References 522 [15] Barton, J., Nielsen, H. and S. Thatte, "SOAP Messages with 523 Attachments", W3C Note NOTE-SOAP-attachments-20001211, Dec 524 2000, . 527 [16] Brown, A., Fox, B., Hada, S., LaMacchia, B. and H. Maruyama, 528 "SOAP Security Extensions: Digital Signature", W3C Note 529 NOTE-SOAP-dsig-20010206, Feb 2001, . 532 [17] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC 533 3080, March 2001, . 535 [18] O'Tuathail, E. and M. Rose, "Using the Simple Object Access 536 Protocol (SOAP) in Blocks Extensible Exchange Protocol (BEEP)", 537 RFC 3288, June 2002, . 539 Author's Address 541 Ted Goddard 542 ICEsoft Technologies Inc. 543 Suite 300, 1717 10th St. NW 544 Calgary, AB T2M 4S2 545 Canada 547 Phone: (403) 663-3322 548 EMail: ted.goddard@icesoft.com 549 URI: http://www.icesoft.com 551 Appendix A. WSDL Definitions 553 A.1 NETCONF SOAP Binding 555 The following WSDL document assumes a hypothetical location for the 556 NETCONF schema. 558 559 567 570 571 572 573 574 575 577 578 579 580 581 582 584 585 587 588 589 590 592 593 594 596 597 598 600 602 A.2 Sample Service Definition 604 The following WSDL document assumes a hypothetical location for the 605 NETCONF/SOAP WSDL definitions. A typical deployment of a device 606 manageable via NETCONF/SOAP would provide a service definition 607 similar to the following to identify the address of the device. 609 610 617 620 621 622 623 624 626 628 Intellectual Property Statement 630 The IETF takes no position regarding the validity or scope of any 631 intellectual property or other rights that might be claimed to 632 pertain to the implementation or use of the technology described in 633 this document or the extent to which any license under such rights 634 might or might not be available; neither does it represent that it 635 has made any effort to identify any such rights. Information on the 636 IETF's procedures with respect to rights in standards-track and 637 standards-related documentation can be found in BCP-11. Copies of 638 claims of rights made available for publication and any assurances of 639 licenses to be made available, or the result of an attempt made to 640 obtain a general license or permission for the use of such 641 proprietary rights by implementors or users of this specification can 642 be obtained from the IETF Secretariat. 644 The IETF invites any interested party to bring to its attention any 645 copyrights, patents or patent applications, or other proprietary 646 rights which may cover technology that may be required to practice 647 this standard. Please address the information to the IETF Executive 648 Director. 650 Full Copyright Statement 652 Copyright (C) The Internet Society (2004). All Rights Reserved. 654 This document and translations of it may be copied and furnished to 655 others, and derivative works that comment on or otherwise explain it 656 or assist in its implementation may be prepared, copied, published 657 and distributed, in whole or in part, without restriction of any 658 kind, provided that the above copyright notice and this paragraph are 659 included on all such copies and derivative works. However, this 660 document itself may not be modified in any way, such as by removing 661 the copyright notice or references to the Internet Society or other 662 Internet organizations, except as needed for the purpose of 663 developing Internet standards in which case the procedures for 664 copyrights defined in the Internet Standards process must be 665 followed, or as required to translate it into languages other than 666 English. 668 The limited permissions granted above are perpetual and will not be 669 revoked by the Internet Society or its successors or assignees. 671 This document and the information contained herein is provided on an 672 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 673 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 674 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 675 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 676 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 678 Acknowledgment 680 Funding for the RFC Editor function is currently provided by the 681 Internet Society.