idnits 2.17.1 draft-lear-newtrk-decruft-experiment-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 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 466. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 443. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 450. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 456. ** 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 == 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 : ---------------------------------------------------------------------------- ** 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 (July 12, 2005) is 6862 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) No issues found here. Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Lear 3 Internet-Draft Cisco Systems GmbH 4 Expires: January 13, 2006 H. Alvestrand 5 Cisco Systems 6 July 12, 2005 8 Getting rid of the cruft: an experiment to identify obsolete standards 9 document" 10 draft-lear-newtrk-decruft-experiment-01.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on January 13, 2006. 37 Copyright Notice 39 Copyright (C) The Internet Society (2005). 41 Abstract 43 This memo documents an experiment to review and classify Proposed 44 Standards as not reflecting documented practice within the world 45 today. The results identify three classes of documents marked as 46 Proposed Standards that should be considered for retirement in some 47 way or another. We propose four options to move forward with further 48 work in this area ranging from doing nothing to accepting the results 49 entirely. 51 1. Introduction and history 53 RFC 2026, and RFC 1602 before it, specified time lines for review of 54 immature (draft or proposed) standards. The purpose of such review 55 was to determine whether such documents should be advanced, retired, 56 or developed further.[1] 58 This procedure has never been followed in the history of the IETF. 59 Since this procedure has not been followed, members of the community 60 have suggested that the retiring of a document to Historic is a 61 significant event, which should be justified carefully - leading to 62 the production of documents such as RFC 2556 (OSI connectionless 63 transport services on top of UDP Applicability Statement for Historic 64 Status) and RFC 3166 (Request to Move RFC 1433 to Historic Status). 66 Such documents require significant time and effort on the part of 67 authors, area directors, and the RFC Editor. 69 2. Bulk Decommissioning Procedure 71 From the Fall of 2004 through the Spring of 2005 the authors 72 conducted an experiment to determine how many Proposed Standards 73 could be considered obsolete. The experiment was operated as 74 follows: 75 o Identify with a group of documents that are standards. 76 o Assume by default that each document will be retired. 77 o Create a mailing list for discussion with a policy of open access. 78 o Allow any document to be removed from the list of those to be 79 retired for virtually any reason, so long as a reason is provided. 80 o Present the list to the working group, IETF, and IESG for review. 81 o Revise list based on comments. 82 o Write up results. 84 While the initial intent of the authors was to present a list of 85 documents to be reclassified as Historic, whether the actual 86 classification is Historic is left to the NEWTRK working group, the 87 IESG, and the IETF as a community. We will discuss this further 88 below. 90 3. Input, Mailing list, Output, and Observations 92 We started with our initial document set being all RFCs with numbers 93 less than 2000 and a status of Proposed Standard. This includes 125 94 documents. The input we used, starting 25 Nov 2004 can be found in 95 the Appendix. There were some 125 documents in all. 97 A mailing list, old-standards@alvestrand.no, was created to discuss 98 and remove candidates from this list. A call for participation was 99 issued to the IETF-Announce list on or around the 15 Nov 2004. There 100 were 29 members of the mailing list. Approximately 244 messages were 101 sent to the list. People were encouraged to consider the question of 102 whether or not an implementor would either write a new implementation 103 or maintain an existing one. 105 After some months the list of documents to be considered was reduced 106 considerably. This list was then forwarded to the IETF discussion 107 list on 16 Dec 04 and to the NEWTRK working group list for wider 108 review. 110 Here are the results: 112 RFC1234 (Tunneling IPX traffic through IP networks) 113 RFC1239 (Reassignment of experimental MIBs to standard MIBs) 114 RFC1276 (Replication and Distributed Operations extensions to 115 provide an Internet Directory using X.500) 116 RFC1285 (FDDI Management Information Base) 117 RFC1314 (A File Format for the Exchange of Images in the Internet) 118 RFC1328 (X.400 1988 to 1984 downgrading) 119 RFC1370 (Applicability Statement for OSPF) 120 RFC1378 (The PPP AppleTalk Control Protocol (ATCP)) 121 RFC1381 (SNMP MIB Extension for X.25 LAPB) 122 RFC1382 (SNMP MIB Extension for the X.25 Packet Layer) 123 RFC1397 (Default Route Advertisement In BGP2 and BGP3 Version of 124 The Border Gateway Protocol) 125 RFC1414 (Identification MIB) 126 RFC1415 (FTP-FTAM Gateway Specification) 127 RFC1418 (SNMP over OSI) 128 RFC1419 (SNMP over AppleTalk) 129 RFC1421 (Privacy Enhancement for Internet Electronic Mail: Part I: 130 Message Encryption and Authentication Procedures) 131 RFC1422 (Privacy Enhancement for Internet Electronic Mail: Part 132 II: Certificate-Based Key Management) 133 RFC1423 (Privacy Enhancement for Internet Electronic Mail: Part 134 III: Algorithms, Modes, and Identifiers) 135 RFC1424 (Privacy Enhancement for Internet Electronic Mail: Part 136 IV: Key Certification and Related Services) 137 RFC1461 (SNMP MIB extension for Multiprotocol Interconnect over 138 X.25) 139 RFC1469 (IP Multicast over Token-Ring Local Area Networks) 140 RFC1471 (The Definitions of Managed Objects for the Link Control 141 Protocol of the Point-to-Point Protocol) 142 RFC1472 (The Definitions of Managed Objects for the Security 143 Protocols of the Point-to-Point Protocol) 144 RFC1473 (The Definitions of Managed Objects for the IP Network 145 Control Protocol of the Point-to-Point Protocol) 146 RFC1474 (The Definitions of Managed Objects for the Bridge Network 147 Control Protocol of the Point-to-Point Protocol) 148 RFC1478 (An Architecture for Inter-Domain Policy Routing) 149 RFC1479 (Inter-Domain Policy Routing Protocol Specification: 150 Version 1) 151 RFC1494 (Equivalences between 1988 X.400 and RFC-822 Message 152 Bodies) 153 RFC1496 (Rules for downgrading messages from X.400/88 to X.400/84) 154 when MIME content-types are present in the messages 155 RFC1502 (X.400 Use of Extended Character Sets) 156 RFC1512 (FDDI Management Information Base) 157 RFC1513 (Token Ring Extensions to the Remote Network Monitoring 158 MIB) 159 RFC1518 (An Architecture for IP Address Allocation with CIDR) 160 RFC1519 (Classless Inter-Domain Routing (CIDR): an Address 161 Assignment and Aggregation Strategy) 162 RFC1525 (Definitions of Managed Objects for Source Routing 163 Bridges) 164 RFC1552 (The PPP Internetworking Packet Exchange Control Protocol 165 (IPXCP)) 166 RFC1553 (Compressing IPX Headers Over WAN Media (CIPX)) 167 RFC1582 (Extensions to RIP to Support Demand Circuits) 168 RFC1584 (Multicast Extensions to OSPF) 169 RFC1598 (PPP in X.25) 170 RFC1648 (Postmaster Convention for X.400 Operations) 171 RFC1666 (Definitions of Managed Objects for SNA NAUs using SMIv2) 172 RFC1692 (Transport Multiplexing Protocol (TMux)) 173 RFC1696 (Modem Management Information Base (MIB) using SMIv2) 174 RFC1742 (AppleTalk Management Information Base II) 175 RFC1747 (Definitions of Managed Objects for SNA Data Link Control 176 (SDLC) using SMIv2) 177 RFC1749 (IEEE 802.5 Station Source Routing MIB using SMIv2) 178 RFC1755 (ATM Signaling Support for IP over ATM) 179 RFC1763 (The PPP Banyan Vines Control Protocol (BVCP)) 180 RFC1764 (The PPP XNS IDP Control Protocol (XNSCP)) 181 RFC1828 (IP Authentication using Keyed MD5) 182 RFC1829 (The ESP DES-CBC Transform) 183 RFC1835 (Architecture of the WHOIS++ service) 184 RFC1848 (MIME Object Security Services) 185 RFC1913 (Architecture of the Whois++ Index Service) 186 RFC1914 (How to Interact with a Whois++ Mesh) 188 4. Discussion 190 As one peruses this list one sees several classes of documents: 192 o Multiprotocol functions for protocols that are obsolete, such as 193 Appletalk or X.400. 194 o Protocols that were defined but not used, such as PEM or Whois++ 195 o Functions that require at the very least updated applicability 196 statements, such as the ESP DES-CBC transform. 198 Of the set above it is clear that additional process for the later 199 one is unnecessary, since a document should be written one way or 200 another. It is the first two cases that are more interesting. In 201 either case a judgment is necessary as to whether or not a protocol 202 is both in use and likely to be supported. The parameters of our 203 experiment were sufficiently conservative to avoid cases where 204 protocols were likely to continue to be supported. That is, anyone 205 could remove a document from the list for any reason. In fact, in 206 some cases we may have been too conservative. Thus, It is also worth 207 considering the categories of documents that were removed from the 208 list: 209 o specifications known to be in full use that should be considered 210 for advancement 211 o specifications that are currently under review within the IETF 212 process 213 o Specifications that were previously considered for deprecation and 214 rejected. 216 The last category is exclusive to telnet options. Arguably such 217 options should be reconsidered for deprecation. Realistically nobody 218 is going to develop a new version of telnet that supports the TACACS 219 option, for instance. Nevertheless, as a first cut we were still 220 left with 61 documents that could be reclassified. 222 In at least one case discussion of deprecation has spurred work on 223 documents. For instance, there is a CIDR update in progress. 225 5. Next Steps 227 As we mention in the introduction, the current process requires 228 reconsideration of immature standards, and that this review currently 229 does not occur. This experiment has been an attempt at a procedure 230 that could ease that review. There are several potential next steps, 231 based on these results: 232 1. Accept the results of this experiment, issue a last call, and 233 deprecate standards that remain on the list past last call. This 234 is an aggressive approach that would preserve the intent of RFC 235 2026. 236 2. Do not accept the results of this experiment and update RFC 2026 237 to indicate a new practice. 239 3. Revise the procedure based on the results of this experiment, 240 based on feedback from the IESG. This option might take into 241 account the different types of old standards as described above. 242 4. Do nothing. This would leave the IETF and the IESG practice 243 inconsistent with documented practice. 245 It should be pointed out that we only looked at proposed standards 246 and only those RFCs with numbers less than 2000. Should either the 247 first or third of the above options be accepted, draft standards and 248 those older than several years should be considered. 250 Finally, should NEWTRK deliver a new document classification system, 251 these documents may provide a basis for one or more new categories of 252 that. 254 6. Security Considerations 256 Documents that have security problems may require special attention 257 and individual documents to indicate what concerns exist, and when or 258 in what ways an implementation can be deployed to alleviate concerns 259 concerns. 261 7. Acknowledgments 263 This experiment would have been completely useless without 264 participation of the members of the old-standards mailing list. Most 265 notably, Pekka Savalo, Bob Braden, and John Klensin were very active 266 contributors to the discussions. 268 8. Normative References 270 [1] Bradner, S., "The Internet Standards Process -- Revision 3", 271 BCP 9, RFC 2026, October 1996. 273 Authors' Addresses 275 Eliot Lear 276 Cisco Systems GmbH 277 Glatt-com 278 Glattzentrum, ZH CH-8301 279 Switzerland 281 Phone: +41 1 878 7525 282 Email: lear@cisco.com 283 Harald Tveit Alvestrand 284 Cisco Systems 285 Weidemanns vei 27 286 Trondheim 7043 287 NO 289 Email: harald@alvestrand.no 291 Appendix A. Input RFCs 292 RFC0698 (Telnet extended ASCII option) 293 RFC0726 (Remote Controlled Transmission and Echoing Telnet option) 294 RFC0727 (Telnet logout option) 295 RFC0735 (Revised Telnet byte macro option) 296 RFC0736 (Telnet SUPDUP option) 297 RFC0749 (Telnet SUPDUP-Output option) 298 RFC0779 (Telnet send-location option) 299 RFC0885 (Telnet end of record option) 300 RFC0927 (TACACS user identification Telnet option) 301 RFC0933 (Output marking Telnet option) 302 RFC0946 (Telnet terminal location number option) 303 RFC0977 (Network News Transfer Protocol) 304 RFC1041 (Telnet 3270 regime option) 305 RFC1043 (Telnet Data Entry Terminal option: DODIIS implementation) 306 RFC1053 (Telnet X.3 PAD option) 307 RFC1073 (Telnet window size option) 308 RFC1079 (Telnet terminal speed option) 309 RFC1091 (Telnet terminal-type option) 310 RFC1096 (Telnet X display location option) 311 RFC1144 (Compressing TCP/IP headers for low-speed serial links) 312 RFC1195 (Use of OSI IS-IS for routing in TCP/IP and dual) 313 RFC1234 (Tunneling IPX traffic through IP networks) 314 RFC1239 (Reassignment of experimental MIBs to standard MIBs) 315 RFC1256 (ICMP Router Discovery Messages) 316 RFC1269 (Definitions of Managed Objects for the Border Gateway 317 Protocol: Version 3) 318 RFC1274 (The COSINE and Internet X.500 Schema) 319 RFC1276 (Replication and Distributed Operations extensions to 320 provide an Internet Directory using X.500) 321 RFC1277 (Encoding Network Addresses to Support Operation over Non- 322 OSI Lower Layers) 323 RFC1285 (FDDI Management Information Base) 324 RFC1314 (A File Format for the Exchange of Images in the Internet) 325 RFC1323 (TCP Extensions for High Performance) 326 RFC1328 (X.400 1988 to 1984 downgrading) 327 RFC1332 (The PPP Internet Protocol Control Protocol (IPCP)) 328 RFC1370 (Applicability Statement for OSPF) 329 RFC1372 (Telnet Remote Flow Control Option) 330 RFC1377 (The PPP OSI Network Layer Control Protocol (OSINLCP)) 331 RFC1378 (The PPP AppleTalk Control Protocol (ATCP)) 332 RFC1381 (SNMP MIB Extension for X.25 LAPB) 333 RFC1382 (SNMP MIB Extension for the X.25 Packet Layer) 334 RFC1397 (Default Route Advertisement In BGP2 and BGP3 Version of 335 The Border Gateway Protocol) 336 RFC1413 (Identification Protocol) 337 RFC1414 (Identification MIB) 338 RFC1415 (FTP-FTAM Gateway Specification) 339 RFC1418 (SNMP over OSI) 340 RFC1419 (SNMP over AppleTalk) 341 RFC1420 (SNMP over IPX) 342 RFC1421 (Privacy Enhancement for Internet Electronic Mail: Part I: 343 Message Encryption and Authentication Procedures) 344 RFC1422 (Privacy Enhancement for Internet Electronic Mail: Part 345 II: Certificate-Based Key Management) 346 RFC1423 (Privacy Enhancement for Internet Electronic Mail: Part 347 III: Algorithms, Modes, and Identifiers) 348 RFC1424 (Privacy Enhancement for Internet Electronic Mail: Part 349 IV: Key Certification and Related Services) 350 RFC1461 (SNMP MIB extension for Multiprotocol Interconnect over 351 X.25) 352 RFC1469 (IP Multicast over Token-Ring Local Area Networks) 353 RFC1471 (The Definitions of Managed Objects for the Link Control 354 Protocol of the Point-to-Point Protocol) 355 RFC1472 (The Definitions of Managed Objects for the Security 356 Protocols of the Point-to-Point Protocol) 357 RFC1473 (The Definitions of Managed Objects for the IP Network 358 Control Protocol of the Point-to-Point Protocol) 359 RFC1474 (The Definitions of Managed Objects for the Bridge Network 360 Control Protocol of the Point-to-Point Protocol) 361 RFC1478 (An Architecture for Inter-Domain Policy Routing) 362 RFC1479 (Inter-Domain Policy Routing Protocol Specification: 363 Version 1) 364 RFC1494 (Equivalences between 1988 X.400 and RFC-822 Message 365 Bodies) 366 RFC1496 (Rules for downgrading messages from X.400/88 to X.400/84) 367 RFC1502 (X.400 Use of Extended Character Sets) 368 RFC1510 (The Kerberos Network Authentication Service (V5)) 369 RFC1512 (FDDI Management Information Base) 370 RFC1513 (Token Ring Extensions to the Remote Network Monitoring 371 MIB) 372 RFC1517 (Applicability Statement for the Implementation of 373 Classless Inter-Domain Routing (CIDR)) 374 RFC1518 (An Architecture for IP Address Allocation with CIDR) 375 RFC1519 (Classless Inter-Domain Routing (CIDR): an Address 376 Assignment and Aggregation Strategy) 377 RFC1525 (Definitions of Managed Objects for Source Routing 378 Bridges) 379 RFC1552 (The PPP Internetworking Packet Exchange Control Protocol) 380 RFC1553 (Compressing IPX Headers Over WAN Media (CIPX)) 381 RFC1570 (PPP LCP Extensions) 382 RFC1572 (Telnet Environment Option) 383 RFC1582 (Extensions to RIP to Support Demand Circuits) 384 RFC1584 (Multicast Extensions to OSPF) 385 RFC1598 (PPP in X.25) 386 RFC1618 (PPP over ISDN) 387 RFC1628 (UPS Management Information Base) 388 RFC1648 (Postmaster Convention for X.400 Operations) 389 RFC1663 (PPP Reliable Transmission) 390 RFC1666 (Definitions of Managed Objects for SNA NAUs using SMIv2) 391 RFC1692 (Transport Multiplexing Protocol (TMux)) 392 RFC1696 (Modem Management Information Base (MIB) using SMIv2) 393 RFC1697 (Relational Database Management System (RDBMS) Management) 394 RFC1731 (IMAP4 Authentication Mechanisms) 395 RFC1734 (POP3 AUTHentication command) 396 RFC1738 (Uniform Resource Locators (URL)) 397 RFC1740 (MIME Encapsulation of Macintosh Files - MacMIME) 398 RFC1742 (AppleTalk Management Information Base II) 399 RFC1747 (Definitions of Managed Objects for SNA Data Link Control) 400 RFC1749 (IEEE 802.5 Station Source Routing MIB using SMIv2) 401 RFC1752 (The Recommendation for the IP Next Generation Protocol) 402 RFC1755 (ATM Signaling Support for IP over ATM) 403 RFC1763 (The PPP Banyan Vines Control Protocol (BVCP)) 404 RFC1764 (The PPP XNS IDP Control Protocol (XNSCP)) 405 RFC1767 (MIME Encapsulation of EDI Objects) 406 RFC1793 (Extending OSPF to Support Demand Circuits) 407 RFC1808 (Relative Uniform Resource Locators) 408 RFC1812 (Requirements for IP Version 4 Routers) 409 RFC1828 (IP Authentication using Keyed MD5) 410 RFC1829 (The ESP DES-CBC Transform) 411 RFC1831 (RPC: Remote Procedure Call Protocol Specification Version 412 2) 413 RFC1833 (Binding Protocols for ONC RPC Version 2) 414 RFC1835 (Architecture of the WHOIS++ service) 415 RFC1847 (Security Multiparts for MIME: Multipart/Signed and 416 Multipart/Encrypted) 417 RFC1848 (MIME Object Security Services) 418 RFC1913 (Architecture of the Whois++ Index Service) 419 RFC1914 (How to Interact with a Whois++ Mesh) 420 RFC1928 (SOCKS Protocol Version 5) 421 RFC1929 (Username/Password Authentication for SOCKS V5) 422 RFC1961 (GSS-API Authentication Method for SOCKS Version 5) 423 RFC1962 (The PPP Compression Control Protocol (CCP)) 424 RFC1964 (The Kerberos Version 5 GSS-API Mechanism) 425 RFC1968 (The PPP Encryption Control Protocol (ECP)) 426 RFC1973 (PPP in Frame Relay) 427 RFC1982 (Serial Number Arithmetic) 428 RFC1985 (SMTP Service Extension for Remote Message Queue Starting) 429 RFC1995 (Incremental Zone Transfer in DNS) 430 RFC1996 (A Mechanism for Prompt Notification of Zone Changes (DNS 431 NOTIFY)) 432 RFC1997 (BGP Communities Attribute) 434 Intellectual Property Statement 436 The IETF takes no position regarding the validity or scope of any 437 Intellectual Property Rights or other rights that might be claimed to 438 pertain to the implementation or use of the technology described in 439 this document or the extent to which any license under such rights 440 might or might not be available; nor does it represent that it has 441 made any independent effort to identify any such rights. Information 442 on the procedures with respect to rights in RFC documents can be 443 found in BCP 78 and BCP 79. 445 Copies of IPR disclosures made to the IETF Secretariat and any 446 assurances of licenses to be made available, or the result of an 447 attempt made to obtain a general license or permission for the use of 448 such proprietary rights by implementers or users of this 449 specification can be obtained from the IETF on-line IPR repository at 450 http://www.ietf.org/ipr. 452 The IETF invites any interested party to bring to its attention any 453 copyrights, patents or patent applications, or other proprietary 454 rights that may cover technology that may be required to implement 455 this standard. Please address the information to the IETF at 456 ietf-ipr@ietf.org. 458 Disclaimer of Validity 460 This document and the information contained herein are provided on an 461 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 462 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 463 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 464 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 465 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 466 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 468 Copyright Statement 470 Copyright (C) The Internet Society (2005). This document is subject 471 to the rights, licenses and restrictions contained in BCP 78, and 472 except as set forth therein, the authors retain all their rights. 474 Acknowledgment 476 Funding for the RFC Editor function is currently provided by the 477 Internet Society.