idnits 2.17.00 (12 Aug 2021) /tmp/idnits53056/draft-ietf-poised95-std-proc-3-06.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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 334 has weird spacing: '... itself as lo...' == Line 1397 has weird spacing: '... to perta...' == Line 1437 has weird spacing: '...for the purpo...' -- 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 (April 1996) is 9525 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) == Unused Reference: '3' is defined on line 1494, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' ** Downref: Normative reference to an Informational RFC: RFC 1311 (ref. '4') ** Obsolete normative reference: RFC 1543 (ref. '5') (Obsoleted by RFC 2223) ** Downref: Normative reference to an Informational RFC: RFC 1796 (ref. '6') Summary: 11 errors (**), 0 flaws (~~), 5 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group S. Bradner 2 Internet-Draft Harvard University 3 Editor 4 April 1996 6 The Internet Standards Process -- Revision 3 8 a proposed revision of part of RFC 1602 10 12 Status of this Memo 14 This document is an Internet-Draft. Internet-Drafts are working 15 documents of the Internet Engineering Task Force (IETF), its areas, 16 and its Working Groups. Note that other groups may also distribute 17 working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as ``work in progress.'' 24 To learn the current status of any Internet-Draft, please check the 25 1id- abstracts.txt listing contained in the Internet-Drafts Shadow 26 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 27 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 28 ftp.isi.edu (US West Coast). 30 Abstract 32 This memo documents the process used by the Internet community for 33 the standardization of protocols and procedures. It defines the 34 stages in the standardization process, the requirements for moving a 35 document between stages and the types of documents used during this 36 process. It also addresses the intellectual property rights and 37 copyright issues associated with the standards process. 39 Table of Contents 41 Status of this Memo.................................................1 42 Abstract............................................................1 43 1. INTRODUCTION....................................................3 44 1.1 Internet Standards...........................................3 45 1.2 The Internet Standards Process...............................4 46 1.3 Organization of This Document................................5 47 2. INTERNET STANDARDS-RELATED PUBLICATIONS.........................6 48 2.1 Requests for Comments (RFCs).................................6 49 2.2 Internet-Drafts..............................................7 50 3. INTERNET STANDARD SPECIFICATIONS................................8 51 3.1 Technical Specification (TS).................................8 52 3.2 Applicability Statement (AS).................................8 53 3.3 Requirement Levels...........................................9 54 4. THE INTERNET STANDARDS TRACK...................................10 55 4.1 Standards Track Maturity Levels.............................11 56 4.1.1 Proposed Standard.......................................11 57 4.1.2 Draft Standard..........................................12 58 4.1.3 Internet Standard.......................................12 59 4.2 Non-Standards Track Maturity Levels.........................12 60 4.2.1 Experimental............................................13 61 4.2.2 Informational...........................................13 62 4.2.3 Procedures for Experimental and Informational RFCs......13 63 4.2.4 Historic................................................14 64 5. Best Current Practice (BCP) RFCs...............................14 65 5.1 BCP Review Process..........................................15 66 6. THE INTERNET STANDARDS PROCESS.................................16 67 6.1 Standards Actions...........................................16 68 6.1.1 Initiation of Action....................................16 69 6.1.2 IESG Review and Approval................................17 70 6.1.3 Publication.............................................18 71 6.2 Advancing in the Standards Track............................18 72 6.3 Revising a Standard.........................................19 73 6.4 Retiring a Standard.........................................19 74 6.5 Conflict Resolution and Appeals.............................20 75 6.5.1 Working Group Disputes...................................20 76 6.5.2 Process Failures.........................................21 77 6.5.3 Questions of Applicable Procedure........................21 78 6.5.4 Appeals Procedure........................................22 79 7. EXTERNAL STANDARDS AND SPECIFICATIONS..........................22 80 7.1 Use of External Specifications..............................23 81 7.1.1 Incorporation of an Open Standard.......................23 82 7.1.2 Incorporation of a Other Specifications.................23 83 7.1.3 Assumption..............................................24 84 8. NOTICES AND RECORD KEEPING......................................24 85 9. VARYING THE PROCESS.............................................25 86 9.1 The Variance Procedure.......................................25 87 9.2 Exclusions...................................................26 88 10. INTELLECTUAL PROPERTY RIGHTS..................................26 89 10.1. General Policy............................................26 90 10.2 Confidentiality Obligations...............................27 91 10.3. Rights and Permissions....................................27 92 10.3.1. All Contributions......................................27 93 10.3.2. Standards Track Documents..............................28 94 10.3.3 Determination of Reasonable and 95 Non-discriminatory Terms................................28 96 10.4. Notices...................................................29 97 11. ACKNOWLEDGMENTS................................................30 98 12. SECURITY CONSIDERATIONS........................................30 99 13. REFERENCES.....................................................30 100 14. DEFINITIONS OF TERMS...........................................31 101 15 .AUTHORS' ADDRESS...............................................32 103 APPENDIX A: GLOSSARY OF ACRONYMS...................................32 105 1. INTRODUCTION 107 This memo documents the process currently used by the Internet 108 community for the standardization of protocols and procedures. The 109 Internet Standards process is an activity of the Internet Society 110 that is organized and managed on behalf of the Internet community by 111 the Internet Architecture Board (IAB) and the Internet Engineering 112 Steering Group (IESG). 114 1.1 Internet Standards 116 The Internet, a loosely-organized international collaboration of 117 autonomous, interconnected networks, supports host-to-host 118 communication through voluntary adherence to open protocols and 119 procedures defined by Internet Standards. There are also many 120 isolated interconnected networks, which are not connected to the 121 global Internet but use the Internet Standards. 123 The Internet Standards Process described in this document is 124 concerned with all protocols, procedures, and conventions that are 125 used in or by the Internet, whether or not they are part of the 126 TCP/IP protocol suite. In the case of protocols developed and/or 127 standardized by non-Internet organizations, however, the Internet 128 Standards Process normally applies to the application of the protocol 129 or procedure in the Internet context, not to the specification of the 130 protocol itself. 132 In general, an Internet Standard is a specification that is stable 133 and well-understood, is technically competent, has multiple, 134 independent, and interoperable implementations with substantial 135 operational experience, enjoys significant public support, and is 136 recognizably useful in some or all parts of the Internet. 138 1.2 The Internet Standards Process 140 In outline, the process of creating an Internet Standard is 141 straightforward: a specification undergoes a period of development 142 and several iterations of review by the Internet community and 143 revision based upon experience, is adopted as a Standard by the 144 appropriate body (see below), and is published. In practice, the 145 process is more complicated, due to (1) the difficulty of creating 146 specifications of high technical quality; (2) the need to consider 147 the interests of all of the affected parties; (3) the importance of 148 establishing widespread community consensus; and (4) the difficulty 149 of evaluating the utility of a particular specification for the 150 Internet community. 152 The goals of the Internet Standards Process are: 153 o technical excellence; 154 o prior implementation and testing; 155 o clear, concise, and easily understood documentation; 156 o openness and fairness; and 157 o timeliness. 159 The procedures described in this document are designed to be fair, 160 open, and objective; to reflect existing (proven) practice; and to 161 be flexible. 163 o These procedures are intended to provide a fair, open, and 164 objective basis for developing, evaluating, and adopting Internet 165 Standards. They provide ample opportunity for participation and 166 comment by all interested parties. At each stage of the 167 standardization process, a specification is repeatedly discussed 168 and its merits debated in open meetings and/or public electronic 169 mailing lists, and it is made available for review via world-wide 170 on-line directories. 172 o These procedures are explicitly aimed at recognizing and adopting 173 generally-accepted practices. Thus, a candidate specification 174 must be implemented and tested for correct operation and 175 interoperability by multiple independent parties and utilized in 176 increasingly demanding environments, before it can be adopted as 177 an Internet Standard. 179 o These procedures provide a great deal of flexibility to adapt to 180 the wide variety of circumstances that occur in the 181 standardization process. Experience has shown this flexibility to 182 be vital in achieving the goals listed above. 184 The goal of technical competence, the requirement for prior 185 implementation and testing, and the need to allow all interested 186 parties to comment all require significant time and effort. On the 187 other hand, today's rapid development of networking technology 188 demands timely development of standards. The Internet Standards 189 Process is intended to balance these conflicting goals. The process 190 is believed to be as short and simple as possible without sacrificing 191 technical excellence, thorough testing before adoption of a standard, 192 or openness and fairness. 194 From its inception, the Internet has been, and is expected to remain, 195 an evolving system whose participants regularly factor new 196 requirements and technology into its design and implementation. Users 197 of the Internet and providers of the equipment, software, and 198 services that support it should anticipate and embrace this evolution 199 as a major tenet of Internet philosophy. 201 The procedures described in this document are the result of a number 202 of years of evolution, driven both by the needs of the growing and 203 increasingly diverse Internet community, and by experience. 205 1.3 Organization of This Document 207 Section 2 describes the publications and archives of the Internet 208 Standards Process. Section 3 describes the types of Internet 209 standard specifications. Section 4 describes the Internet standards 210 specifications track. Section 5 describes Best Current Practice 211 RFCs. Section 6 describes the process and rules for Internet 212 standardization. Section 7 specifies the way in which externally- 213 sponsored specifications and practices, developed and controlled by 214 other standards bodies or by others, are handled within the Internet 215 Standards Process. Section 8 describes the requirements for notices 216 and record keeping Section 9 defines a variance process to allow 217 one-time exceptions to some of the requirements in this document 218 Section 10 presents the rules that are required to protect 219 intellectual property rights in the context of the development and 220 use of Internet Standards. Section 11 includes acknowledgments of 221 some of the people involved in creation of this document. Section 12 222 notes that security issues are not dealt with by this document. 223 Section 13 contains a list of numbered references. Section 14 224 contains definitions of some of the terms used in this document. 225 Section 15 lists the author's email and postal addresses. Appendix A 226 contains a list of frequently-used acronyms. 228 2. INTERNET STANDARDS-RELATED PUBLICATIONS 229 2.1 Requests for Comments (RFCs) 231 Each distinct version of an Internet standards-related specification 232 is published as part of the "Request for Comments" (RFC) document 233 series. This archival series is the official publication channel for 234 Internet standards documents and other publications of the IESG, IAB, 235 and Internet community. RFCs can be obtained from a number of 236 Internet hosts using anonymous FTP, gopher, World Wide Web, and other 237 Internet document-retrieval systems. 239 The RFC series of documents on networking began in 1969 as part of 240 the original ARPA wide-area networking (ARPANET) project (see 241 Appendix A for glossary of acronyms). RFCs cover a wide range of 242 topics in addition to Internet Standards, from early discussion of 243 new research concepts to status memos about the Internet. RFC 244 publication is the direct responsibility of the RFC Editor, under the 245 general direction of the IAB. 247 The rules for formatting and submitting an RFC are defined in [5]. 248 Every RFC is available in ASCII text. Some RFCs are also available 249 in other formats. The other versions of an RFC may contain material 250 (such as diagrams and figures) that is not present in the ASCII 251 version, and it may be formatted differently. 253 ********************************************************* 254 * * 255 * A stricter requirement applies to standards-track * 256 * specifications: the ASCII text version is the * 257 * definitive reference, and therefore it must be a * 258 * complete and accurate specification of the standard, * 259 * including all necessary diagrams and illustrations. * 260 * * 261 ********************************************************* 263 The status of Internet protocol and service specifications is 264 summarized periodically in an RFC entitled "Internet Official 265 Protocol Standards" [1]. This RFC shows the level of maturity and 266 other helpful information for each Internet protocol or service 267 specification (see section 3). 269 Some RFCs document Internet Standards. These RFCs form the 'STD' 270 subseries of the RFC series [4]. When a specification has been 271 adopted as an Internet Standard, it is given the additional label 272 "STDxxx", but it keeps its RFC number and its place in the RFC 273 series. (see section 4.1.3) 275 Some RFCs standardize the results of community deliberations about 276 statements of principle or conclusions about what is the best way to 277 perform some operations or IETF process function. These RFCs form 278 the specification has been adopted as a BCP, it is given the 279 additional label "BCPxxx", but it keeps its RFC number and its place 280 in the RFC series. (see section 5) 282 Not all specifications of protocols or services for the Internet 283 should or will become Internet Standards or BCPs. Such non-standards 284 track specifications are not subject to the rules for Internet 285 standardization. Non-standards track specifications may be published 286 directly as "Experimental" or "Informational" RFCs at the discretion 287 of the RFC Editor in consultation with the IESG (see section 4.2). 289 ******************************************************** 290 * * 291 * It is important to remember that not all RFCs * 292 * are standards track documents, and that not all * 293 * standards track documents reach the level of * 294 * Internet Standard. In the same way, not all RFCs * 295 * which describe current practices have been given * 296 * the review and approval to become BCPs. See * 297 * RFC-1796 [6] for further information. * 298 * * 299 ******************************************************** 301 2.2 Internet-Drafts 303 During the development of a specification, draft versions of the 304 document are made available for informal review and comment by 305 placing them in the IETF's "Internet-Drafts" directory, which is 306 replicated on a number of Internet hosts. This makes an evolving 307 working document readily available to a wide audience, facilitating 308 the process of review and revision. 310 An Internet-Draft that is published as an RFC, or that has remained 311 unchanged in the Internet-Drafts directory for more than six months 312 without being recommended by the IESG for publication as an RFC, is 313 simply removed from the Internet-Drafts directory. At any time, an 314 Internet-Draft may be replaced by a more recent version of the same 315 specification, restarting the six-month timeout period. 317 An Internet-Draft is NOT a means of "publishing" a specification; 318 specifications are published through the RFC mechanism described in 319 the previous section. Internet-Drafts have no formal status, and are 320 subject to change or removal at any time. 322 ******************************************************** 323 * * 324 * Under no circumstances should an Internet-Draft * 325 * be referenced by any paper, report, or Request- * 326 * for-Proposal, nor should a vendor claim compliance * 327 * with an Internet-Draft. * 328 * * 329 ******************************************************** 331 Note: It is acceptable to reference a standards-track specification 332 that may reasonably be expected to be published as an RFC using the 333 phrase "Work in Progress" without referencing an Internet-Draft. 334 This may also be done in a standards track document itself as long 335 as the specification in which the reference is made would stand as a 336 complete and understandable document with or without the reference to 337 the "Work in Progress". 339 3. INTERNET STANDARD SPECIFICATIONS 341 Specifications subject to the Internet Standards Process fall into 342 one of two categories: Technical Specification (TS) and 343 Applicability Statement (AS). 345 3.1 Technical Specification (TS) 347 A Technical Specification is any description of a protocol, service, 348 procedure, convention, or format. It may completely describe all of 349 the relevant aspects of its subject, or it may leave one or more 350 parameters or options unspecified. A TS may be completely self- 351 contained, or it may incorporate material from other specifications 352 by reference to other documents (which might or might not be Internet 353 Standards). 355 A TS shall include a statement of its scope and the general intent 356 for its use (domain of applicability). Thus, a TS that is inherently 357 specific to a particular context shall contain a statement to that 358 effect. However, a TS does not specify requirements for its use 359 within the Internet; these requirements, which depend on the 360 particular context in which the TS is incorporated by different 361 system configurations, are defined by an Applicability Statement. 363 3.2 Applicability Statement (AS) 365 An Applicability Statement specifies how, and under what 366 circumstances, one or more TSs may be applied to support a particular 367 Internet capability. An AS may specify uses for TSs that are not 368 Internet Standards, as discussed in Section 7. 370 An AS identifies the relevant TSs and the specific way in which they 371 are to be combined, and may also specify particular values or ranges 372 of TS parameters or subfunctions of a TS protocol that must be 373 implemented. An AS also specifies the circumstances in which the use 374 of a particular TS is required, recommended, or elective (see section 375 3.3). 377 An AS may describe particular methods of using a TS in a restricted 378 "domain of applicability", such as Internet routers, terminal 379 servers, Internet systems that interface to Ethernets, or datagram- 380 based database servers. 382 The broadest type of AS is a comprehensive conformance specification, 383 commonly called a "requirements document", for a particular class of 384 Internet systems, such as Internet routers or Internet hosts. 386 An AS may not have a higher maturity level in the standards track 387 than any standards-track TS on which the AS relies (see section 4.1). 388 For example, a TS at Draft Standard level may be referenced by an AS 389 at the Proposed Standard or Draft Standard level, but not by an AS at 390 the Standard level. 392 3.3 Requirement Levels 394 An AS shall apply one of the following "requirement levels" to each 395 of the TSs to which it refers: 397 (a) Required: Implementation of the referenced TS, as specified by 398 the AS, is required to achieve minimal conformance. For example, 399 IP and ICMP must be implemented by all Internet systems using the 400 TCP/IP Protocol Suite. 402 (b) Recommended: Implementation of the referenced TS is not 403 required for minimal conformance, but experience and/or generally 404 accepted technical wisdom suggest its desirability in the domain 405 of applicability of the AS. Vendors are strongly encouraged to 406 include the functions, features, and protocols of Recommended TSs 407 in their products, and should omit them only if the omission is 408 justified by some special circumstance. For example, the TELNET 409 protocol should be implemented by all systems that would benefit 410 from remote access. 412 (c) Elective: Implementation of the referenced TS is optional 413 within the domain of applicability of the AS; that is, the AS 414 creates no explicit necessity to apply the TS. However, a 415 particular vendor may decide to implement it, or a particular user 416 may decide that it is a necessity in a specific environment. For 417 example, the DECNET MIB could be seen as valuable in an 418 environment where the DECNET protocol is used. 420 As noted in section 4.1, there are TSs that are not in the 421 standards track or that have been retired from the standards 422 track, and are therefore not required, recommended, or elective. 423 Two additional "requirement level" designations are available for 424 these TSs: 426 (d) Limited Use: The TS is considered to be appropriate for use 427 only in limited or unique circumstances. For example, the usage 428 of a protocol with the "Experimental" designation should generally 429 be limited to those actively involved with the experiment. 431 (e) Not Recommended: A TS that is considered to be inappropriate 432 for general use is labeled "Not Recommended". This may be because 433 of its limited functionality, specialized nature, or historic 434 status. 436 Although TSs and ASs are conceptually separate, in practice a 437 standards- track document may combine an AS and one or more related 438 TSs. For example, Technical Specifications that are developed 439 specifically and exclusively for some particular domain of 440 applicability, e.g., for mail server hosts, often contain within a 441 single specification all of the relevant AS and TS information. In 442 such cases, no useful purpose would be served by deliberately 443 distributing the information among several documents just to preserve 444 the formal AS/TS distinction. However, a TS that is likely to apply 445 to more than one domain of applicability should be developed in a 446 modular fashion, to facilitate its incorporation by multiple ASs. 448 The "Official Protocol Standards" RFC (STD1) lists a general 449 requirement level for each TS, using the nomenclature defined in this 450 section. This RFC is updated periodically. In many cases, more 451 detailed descriptions of the requirement levels of particular 452 protocols and of individual features of the protocols will be found 453 in appropriate ASs. 455 4. THE INTERNET STANDARDS TRACK 457 Specifications that are intended to become Internet Standards evolve 458 through a set of maturity levels known as the "standards track". 459 These maturity levels -- "Proposed Standard", "Draft Standard", and 460 "Standard" -- are defined and discussed in section 4.1. The way in 461 which specifications move along the standards track is described in 462 section 6. 464 Even after a specification has been adopted as an Internet Standard, 465 further evolution often occurs based on experience and the 466 recognition of new requirements. The nomenclature and procedures of 467 Internet standardization provide for the replacement of old Internet 468 Standards with new ones, and the assignment of descriptive labels to 469 indicate the status of "retired" Internet Standards. A set of 470 maturity levels is defined in section 4.2 to cover these and other 471 specifications that are not considered to be on the standards track. 473 4.1 Standards Track Maturity Levels 475 Internet specifications go through stages of development, testing, 476 and acceptance. Within the Internet Standards Process, these stages 477 are formally labeled "maturity levels". 479 This section describes the maturity levels and the expected 480 characteristics of specifications at each level. 482 4.1.1 Proposed Standard 484 The entry-level maturity for the standards track is "Proposed 485 Standard". A specific action by the IESG is required to move a 486 specification onto the standards track at the "Proposed Standard" 487 level. 489 A Proposed Standard specification is generally stable, has resolved 490 known design choices, is believed to be well-understood, has received 491 significant community review, and appears to enjoy enough community 492 interest to be considered valuable. However, further experience 493 might result in a change or even retraction of the specification 494 before it advances. 496 Usually, neither implementation nor operational experience is 497 required for the designation of a specification as a Proposed 498 Standard. However, such experience is highly desirable, and will 499 usually represent a strong argument in favor of a Proposed Standard 500 designation. 502 The IESG may require implementation and/or operational experience 503 prior to granting Proposed Standard status to a specification that 504 materially affects the core Internet protocols or that specifies 505 behavior that may have significant operational impact on the 506 Internet. 508 A Proposed Standard should have no known technical omissions with 509 respect to the requirements placed upon it. However, the IESG may 510 waive this requirement in order to allow a specification to advance 511 to the Proposed Standard state when it is considered to be useful and 512 necessary (and timely) even with known technical omissions. 514 Implementors should treat Proposed Standards as immature 515 specifications. It is desirable to implement them in order to gain 516 experience and to validate, test, and clarify the specification. 518 However, since the content of Proposed Standards may be changed if 519 problems are found or better solutions are identified, deploying 520 implementations of such standards into a disruption-sensitive 521 environment is not recommended. 523 4.1.2 Draft Standard 525 A specification from which at least two independent and interoperable 526 implementations from different code bases have been developed, and 527 for which sufficient successful operational experience has been 528 obtained, may be elevated to the "Draft Standard" level. For the 529 purposes of this section, "interoperable" means to be functionally 530 equivalent or interchangeable components of the system or process in 531 which they are used. If patented or otherwise controlled technology 532 is required for implementation, the separate implementations must 533 also have resulted from separate exercise of the licensing process. 534 Elevation to Draft Standard is a major advance in status, indicating 535 a strong belief that the specification is mature and will be useful. 537 The requirement for at least two independent and interoperable 538 implementations applies to all of the options and features of the 539 specification. In cases in which one or more options or features 540 have not been demonstrated in at least two interoperable 541 implementations, the specification may advance to the Draft Standard 542 level only if those options or features are removed. 544 The Working Group chair is responsible for documenting the specific 545 implementations which qualify the specification for Draft or Internet 546 Standard status along with documentation about testing of the 547 interoperation of these implementations. The documentation must 548 include information about the support of each of the individual 549 options and features. This documentation should be submitted to the 550 Area Director with the protocol action request. (see Section 6) 552 A Draft Standard must be well-understood and known to be quite 553 stable, both in its semantics and as a basis for developing an 554 implementation. A Draft Standard may still require additional or 555 more widespread field experience, since it is possible for 556 implementations based on Draft Standard specifications to demonstrate 557 unforeseen behavior when subjected to large-scale use in production 558 environments. 560 A Draft Standard is normally considered to be a final specification, 561 and changes are likely to be made only to solve specific problems 562 encountered. In most circumstances, it is reasonable for vendors to 563 deploy implementations of Draft Standards into a disruption sensitive 564 environment. 566 4.1.3 Internet Standard 568 A specification for which significant implementation and successful 569 operational experience has been obtained may be elevated to the 570 Internet Standard level. An Internet Standard (which may simply be 571 referred to as a Standard) is characterized by a high degree of 572 technical maturity and by a generally held belief that the specified 573 protocol or service provides significant benefit to the Internet 574 community. 576 A specification that reaches the status of Standard is assigned a 577 number in the STD series while retaining its RFC number. 579 4.2 Non-Standards Track Maturity Levels 581 Not every specification is on the standards track. A specification 582 may not be intended to be an Internet Standard, or it may be intended 583 for eventual standardization but not yet ready to enter the standards 584 track. A specification may have been superseded by a more recent 585 Internet Standard, or have otherwise fallen into disuse or disfavor. 587 Specifications that are not on the standards track are labeled with 588 one of three "off-track" maturity levels: "Experimental", 589 "Informational", or "Historic". The documents bearing these labels 590 are not Internet Standards in any sense. 592 4.2.1 Experimental 594 The "Experimental" designation typically denotes a specification that 595 is part of some research or development effort. Such a specification 596 is published for the general information of the Internet technical 597 community and as an archival record of the work, subject only to 598 editorial considerations and to verification that there has been 599 adequate coordination with the standards process (see below). An 600 Experimental specification may be the output of an organized Internet 601 research effort (e.g., a Research Group of the IRTF), an IETF Working 602 Group, or it may be an individual contribution. 604 4.2.2 Informational 606 An "Informational" specification is published for the general 607 information of the Internet community, and does not represent an 608 Internet community consensus or recommendation. The Informational 609 designation is intended to provide for the timely publication of a 610 very broad range of responsible informational documents from many 611 sources, subject only to editorial considerations and to verification 612 that there has been adequate coordination with the standards process 613 (see section 4.2.3). 615 Specifications that have been prepared outside of the Internet 616 community and are not incorporated into the Internet Standards 617 Process by any of the provisions of section 10 may be published as 618 Informational RFCs, with the permission of the owner and the 619 concurrence of the RFC Editor. 621 4.2.3 Procedures for Experimental and Informational RFCs 623 Unless they are the result of IETF Working Group action, documents 624 intended to be published with Experimental or Informational status 625 should be submitted directly to the RFC Editor. The RFC Editor will 626 publish any such documents as Internet-Drafts which have not already 627 been so published. In order to differentiate these Internet-Drafts 628 they will be labeled or grouped in the I-D directory so they are 629 easily recognizable. The RFC Editor will wait two weeks after this 630 publication for comments before proceeding further. The RFC Editor 631 is expected to exercise his or her judgment concerning the editorial 632 suitability of a document for publication with Experimental or 633 Informational status, and may refuse to publish a document which, in 634 the expert opinion of the RFC Editor, is unrelated to Internet 635 activity or falls below the technical and/or editorial standard for 636 RFCs. 638 To ensure that the non-standards track Experimental and Informational 639 designations are not misused to circumvent the Internet Standards 640 Process, the IESG and the RFC Editor have agreed that the RFC Editor 641 will refer to the IESG any document submitted for Experimental or 642 Informational publication which, in the opinion of the RFC Editor, 643 may be related to work being done, or expected to be done, within the 644 IETF community. The IESG shall review such a referred document 645 within a reasonable period of time, and recommend either that it be 646 published as originally submitted or referred to the IETF as a 647 contribution to the Internet Standards Process. 649 If (a) the IESG recommends that the document be brought within the 650 IETF and progressed within the IETF context, but the author declines 651 to do so, or (b) the IESG considers that the document proposes 652 something that conflicts with, or is actually inimical to, an 653 established IETF effort, the document may still be published as an 654 Experimental or Informational RFC. In these cases, however, the IESG 655 may insert appropriate "disclaimer" text into the RFC either in or 656 immediately following the "Status of this Memo" section in order to 657 make the circumstances of its publication clear to readers. 659 Documents proposed for Experimental and Informational RFCs by IETF 660 Working Groups go through IESG review. The review is initiated using 661 the process described in section 6.1.1. 663 4.2.4 Historic 665 A specification that has been superseded by a more recent 666 specification or is for any other reason considered to be obsolete is 667 assigned to the "Historic" level. (Purists have suggested that the 668 word should be "Historical"; however, at this point the use of 669 "Historic" is historical.) 671 Note: Standards track specifications normally must not depend on 672 other standards track specifications which are at a lower maturity 673 level or on non standards track specifications other than referenced 674 specifications from other standards bodies. (See Section 7.) 676 5. BEST CURRENT PRACTICE (BCP) RFCs 678 The BCP subseries of the RFC series is designed to be a way to 679 standardize practices and the results of community deliberations. A 680 BCP document is subject to the same basic set of procedures as 681 standards track documents and thus is a vehicle by which the IETF 682 community can define and ratify the community's best current thinking 683 on a statement of principle or on what is believed to be the best way 684 to perform some operations or IETF process function. 686 Historically Internet standards have generally been concerned with 687 the technical specifications for hardware and software required for 688 computer communication across interconnected networks. However, 689 since the Internet itself is composed of networks operated by a great 690 variety of organizations, with diverse goals and rules, good user 691 service requires that the operators and administrators of the 692 Internet follow some common guidelines for policies and operations. 693 While these guidelines are generally different in scope and style 694 from protocol standards, their establishment needs a similar process 695 for consensus building. 697 While it is recognized that entities such as the IAB and IESG are 698 composed of individuals who may participate, as individuals, in the 699 technical work of the IETF, it is also recognized that the entities 700 themselves have an existence as leaders in the community. As leaders 701 in the Internet technical community, these entities should have an 702 outlet to propose ideas to stimulate work in a particular area, to 703 raise the community's sensitivity to a certain issue, to make a 704 statement of architectural principle, or to communicate their 705 thoughts on other matters. The BCP subseries creates a smoothly 706 structured way for these management entities to insert proposals into 707 the consensus-building machinery of the IETF while gauging the 708 community's view of that issue. 710 Finally, the BCP series may be used to document the operation of the 711 IETF itself. For example, this document defines the IETF Standards 712 Process and is published as a BCP. 714 5.1 BCP Review Process 716 Unlike standards-track documents, the mechanisms described in BCPs 717 are not well suited to the phased roll-in nature of the three stage 718 standards track and instead generally only make sense for full and 719 immediate instantiation. 721 The BCP process is similar to that for proposed standards. The BCP 722 is submitted to the IESG for review, (see section 6.1.1) and the 723 existing review process applies, including a Last-Call on the IETF 724 Announce mailing list. However, once the IESG has approved the 725 document, the process ends and the document is published. The 726 resulting document is viewed as having the technical approval of the 727 IETF. 729 Specifically, a document to be considered for the status of BCP must 730 undergo the procedures outlined in sections 6.1, and 6.4 of this 731 document. The BCP process may be appealed according to the procedures 732 in section 6.5. 734 Because BCPs are meant to express community consensus but are arrived 735 at more quickly than standards, BCPs require particular care. 736 Specifically, BCPs should not be viewed simply as stronger 737 Informational RFCs, but rather should be viewed as documents suitable 738 for a content different from Informational RFCs. 740 A specification, or group of specifications, that has, or have been 741 approved as a BCP is assigned a number in the BCP series while 742 retaining its RFC number(s). 744 6. THE INTERNET STANDARDS PROCESS 746 The mechanics of the Internet Standards Process involve decisions of 747 the IESG concerning the elevation of a specification onto the 748 standards track or the movement of a standards-track specification 749 from one maturity level to another. Although a number of reasonably 750 objective criteria (described below and in section 4) are available 751 to guide the IESG in making a decision to move a specification onto, 752 along, or off the standards track, there is no algorithmic guarantee 753 of elevation to or progression along the standards track for any 754 specification. The experienced collective judgment of the IESG 755 concerning the technical quality of a specification proposed for 756 elevation to or advancement in the standards track is an essential 757 component of the decision-making process. 759 6.1 Standards Actions 761 A "standards action" -- entering a particular specification into, 762 advancing it within, or removing it from, the standards track -- must 763 be approved by the IESG. 765 6.1.1 Initiation of Action 767 A specification that is intended to enter or advance in the Internet 768 standards track shall first be posted as an Internet-Draft (see 769 section 2.2) unless it has not changed since publication as an RFC. 770 It shall remain as an Internet-Draft for a period of time, not less 771 than two weeks, that permits useful community review, after which a 772 recommendation for action may be initiated. 774 A standards action is initiated by a recommendation by the IETF 775 Working group responsible for a specification to its Area Director, 776 copied to the IETF Secretariat or, in the case of a specification not 777 associated with a Working Group, a recommendation by an individual to 778 the IESG. 780 6.1.2 IESG Review and Approval 782 The IESG shall determine whether or not a specification submitted to 783 it according to section 6.1.1 satisfies the applicable criteria for 784 the recommended action (see sections 4.1 and 4.2), and shall in 785 addition determine whether or not the technical quality and clarity 786 of the specification is consistent with that expected for the 787 maturity level to which the specification is recommended. 789 In order to obtain all of the information necessary to make these 790 determinations, particularly when the specification is considered by 791 the IESG to be extremely important in terms of its potential impact 792 on the Internet or on the suite of Internet protocols, the IESG may, 793 at its discretion, commission an independent technical review of the 794 specification. 796 The IESG will send notice to the IETF of the pending IESG 797 consideration of the document(s) to permit a final review by the 798 general Internet community. This "Last-Call" notification shall be 799 via electronic mail to the IETF Announce mailing list. Comments on a 800 Last-Call shall be accepted from anyone, and should be sent as 801 directed in the Last-Call announcement. 803 The Last-Call period shall be no shorter than two weeks except in 804 those cases where the proposed standards action was not initiated by 805 an IETF Working Group, in which case the Last-Call period shall be no 806 shorter than four weeks. If the IESG believes that the community 807 interest would be served by allowing more time for comment, it may 808 decide on a longer Last-Call period or to explicitly lengthen a 809 current Last-Call period. 811 The IESG is not bound by the action recommended when the 812 specification was submitted. For example, the IESG may decide to 813 consider the specification for publication in a different category 814 than that requested. If the IESG determines this before the Last- 815 Call is issued then the Last-Call should reflect the IESG's view. 816 The IESG could also decide to change the publication category based 817 on the response to a Last-Call. If this decision would result in a 818 specification being published at a "higher" level than the original 819 Last-Call was for, a new Last-Call should be issued indicating the 820 IESG recommendation. In addition, the IESG may decide to recommend 821 the formation of a new Working Group in the case of significant 822 controversy in response to a Last-Call for specification not 823 originating from an IETF Working Group. 825 In a timely fashion after the expiration of the Last-Call period, the 826 IESG shall make its final determination of whether or not to approve 827 the standards action, and shall notify the IETF of its decision via 828 electronic mail to the IETF Announce mailing list. 830 6.1.3 Publication 832 If a standards action is approved, notification is sent to the RFC 833 Editor and copied to the IETF with instructions to publish the 834 specification as an RFC. The specification shall at that point be 835 removed from the Internet-Drafts directory. 837 An official summary of standards actions completed and pending shall 838 appear in each issue of the Internet Society's newsletter. This 839 shall constitute the "publication of record" for Internet standards 840 actions. 842 The RFC Editor shall publish periodically an "Internet Official 843 Protocol Standards" RFC [1], summarizing the status of all Internet 844 protocol and service specifications. 846 6.2 Advancing in the Standards Track 848 The procedure described in section 6.1 is followed for each action 849 that attends the advancement of a specification along the standards 850 track. 852 A specification shall remain at the Proposed Standard level for at 853 least six (6) months. 855 A specification shall remain at the Draft Standard level for at least 856 four (4) months, or until at least one IETF meeting has occurred, 857 whichever comes later. 859 These minimum periods are intended to ensure adequate opportunity for 860 community review without severely impacting timeliness. These 861 intervals shall be measured from the date of publication of the 862 corresponding RFC(s), or, if the action does not result in RFC 863 publication, the date of the announcement of the IESG approval of the 864 action. 866 A specification may be (indeed, is likely to be) revised as it 867 advances through the standards track. At each stage, the IESG shall 868 determine the scope and significance of the revision to the 869 specification, and, if necessary and appropriate, modify the 870 recommended action. Minor revisions are expected, but a significant 871 revision may require that the specification accumulate more 872 experience at its current maturity level before progressing. Finally, 873 if the specification has been changed very significantly, the IESG 874 may recommend that the revision be treated as a new document, re- 875 entering the standards track at the beginning. 877 Change of status shall result in republication of the specification 878 as an RFC, except in the rare case that there have been no changes at 879 all in the specification since the last publication. Generally, 880 desired changes will be "batched" for incorporation at the next level 881 in the standards track. However, deferral of changes to the next 882 standards action on the specification will not always be possible or 883 desirable; for example, an important typographical error, or a 884 technical error that does not represent a change in overall function 885 of the specification, may need to be corrected immediately. In such 886 cases, the IESG or RFC Editor may be asked to republish the RFC (with 887 a new number) with corrections, and this will not reset the minimum 888 time-at-level clock. 890 When a standards-track specification has not reached the Internet 891 Standard level but has remained at the same maturity level for 892 twenty- four (24) months, and every twelve (12) months thereafter 893 until the status is changed, the IESG shall review the viability of 894 the standardization effort responsible for that specification and the 895 usefulness of the technology. Following each such review, the IESG 896 shall approve termination or continuation of the development effort, 897 at the same time the IESG shall decide to maintain the specification 898 at the same maturity level or to move it to Historic status. This 899 decision shall be communicated to the IETF by electronic mail to the 900 IETF Announce mailing list to allow the Internet community an 901 opportunity to comment. This provision is not intended to threaten a 902 legitimate and active Working Group effort, but rather to provide an 903 administrative mechanism for terminating a moribund effort. 905 6.3 Revising a Standard 907 A new version of an established Internet Standard must progress 908 through the full Internet standardization process as if it were a 909 completely new specification. Once the new version has reached the 910 Standard level, it will usually replace the previous version, which 911 will be moved to Historic status. However, in some cases both 912 versions may remain as Internet Standards to honor the requirements 913 of an installed base. In this situation, the relationship between 914 the previous and the new versions must be explicitly stated in the 915 text of the new version or in another appropriate document (e.g., an 916 Applicability Statement; see section 3.2). 918 6.4 Retiring a Standard 920 As the technology changes and matures, it is possible for a new 921 Standard specification to be so clearly superior technically that one 922 or more existing standards track specifications for the same function 923 should be retired. In this case, or when it is felt for some other 924 reason that an existing standards track specification should be 925 retired, the IESG shall approve a change of status of the old 926 specification(s) to Historic. This recommendation shall be issued 927 with the same Last-Call and notification procedures used for any 928 other standards action. A request to retire an existing standard can 929 originate from a Working Group, an Area Director or some other 930 interested party. 932 6.5 Conflict Resolution and Appeals 934 Disputes are possible at various stages during the IETF process. As 935 much as possible the process is designed so that compromises can be 936 made, and genuine consensus achieved, however there are times when 937 even the most reasonable and knowledgeable people are unable to 938 agree. To achieve the goals of openness and fairness, such conflicts 939 must be resolved by a process of open review and discussion. This 940 section specifies the procedures that shall be followed to deal with 941 Internet standards issues that cannot be resolved through the normal 942 processes whereby IETF Working Groups and other Internet Standards 943 Process participants ordinarily reach consensus. 945 6.5.1 Working Group Disputes 947 An individual (whether a participant in the relevant Working Group or 948 not) may disagree with a Working Group recommendation based on his or 949 her belief that either (a) his or her own views have not been 950 adequately considered by the Working Group, or (b) the Working Group 951 has made an incorrect technical choice which places the quality 952 and/or integrity of the Working Group's product(s) in significant 953 jeopardy. The first issue is a difficulty with Working Group 954 process; the latter is an assertion of technical error. These two 955 types of disagreement are quite different, but both are handled by 956 the same process of review. 958 A person who disagrees with a Working Group recommendation shall 959 always first discuss the matter with the Working Group's chair(s), 960 who may involve other members of the Working Group (or the Working 961 Group as a whole) in the discussion. 963 If the disagreement cannot be resolved in this way, any of the 964 parties involved may bring it to the attention of the Area 965 Director(s) for the area in which the Working Group is chartered. 966 The Area Director(s) shall attempt to resolve the dispute. 968 If the disagreement cannot be resolved by the Area Director(s) any of 969 the parties involved may then appeal to the IESG as a whole. The 970 IESG shall then review the situation and attempt to resolve it in a 971 manner of its own choosing. 973 If the disagreement is not resolved to the satisfaction of the 974 parties at the IESG level, any of the parties involved may appeal the 975 decision to the IAB. The IAB shall then review the situation and 976 attempt to resolve it in a manner of its own choosing. 978 The IAB decision is final with respect to the question of whether or 979 not the Internet standards procedures have been followed and with 980 respect to all questions of technical merit. 982 6.5.2 Process Failures 984 This document sets forward procedures required to be followed to 985 ensure openness and fairness of the Internet Standards Process, and 986 the technical viability of the standards created. The IESG is the 987 principal agent of the IETF for this purpose, and it is the IESG that 988 is charged with ensuring that the required procedures have been 989 followed, and that any necessary prerequisites to a standards action 990 have been met. 992 If an individual should disagree with an action taken by the IESG in 993 this process, that person should first discuss the issue with the 994 ISEG Chair. If the IESG Chair is unable to satisfy the complainant 995 then the IESG as a whole should re-examine the action taken, along 996 with input from the complainant, and determine whether any further 997 action is needed. The IESG shall issue a report on its review of the 998 complaint to the IETF. 1000 Should the complainant not be satisfied with the outcome of the IESG 1001 review, an appeal may be lodged to the IAB. The IAB shall then review 1002 the situation and attempt to resolve it in a manner of its own 1003 choosing and report to the IETF on the outcome of its review. 1005 If circumstances warrant, the IAB may direct that an IESG decision be 1006 annulled, and the situation shall then be as it was before the IESG 1007 decision was taken. The IAB may also recommend an action to the IESG, 1008 or make such other recommendations as it deems fit. The IAB may not, 1009 however, pre-empt the role of the IESG by issuing a decision which 1010 only the IESG is empowered to make. 1012 The IAB decision is final with respect to the question of whether or 1013 not the Internet standards procedures have been followed. 1015 6.5.3 Questions of Applicable Procedure 1017 Further recourse is available only in cases in which the procedures 1018 themselves (i.e., the procedures described in this document) are 1019 claimed to be inadequate or insufficient to the protection of the 1020 rights of all parties in a fair and open Internet Standards Process. 1021 Claims on this basis may be made to the Internet Society Board of 1022 Trustees. The President of the Internet Society shall acknowledge 1023 such an appeal within two weeks, and shall at the time of 1024 acknowledgment advise the petitioner of the expected duration of the 1025 Trustees' review of the appeal. The Trustees shall review the 1026 situation in a manner of its own choosing and report to the IETF on 1027 the outcome of its review. 1029 The Trustees' decision upon completion of their review shall be final 1030 with respect to all aspects of the dispute. 1032 6.5.4 Appeals Procedure 1034 All appeals must include a detailed and specific description of the 1035 facts of the dispute. 1037 All appeals must be initiated within two months of the public 1038 knowledge of the action or decision to be challenged. 1040 At all stages of the appeals process, the individuals or bodies 1041 responsible for making the decisions have the discretion to define 1042 the specific procedures they will follow in the process of making 1043 their decision. 1045 In all cases a decision concerning the disposition of the dispute, 1046 and the communication of that decision to the parties involved, must 1047 be accomplished within a reasonable period of time. 1049 [NOTE: These procedures intentionally and explicitly do not 1050 establish a fixed maximum time period that shall be considered 1051 "reasonable" in all cases. The Internet Standards Process places a 1052 premium on consensus and efforts to achieve it, and deliberately 1053 foregoes deterministically swift execution of procedures in favor of 1054 a latitude within which more genuine technical agreements may be 1055 reached.] 1057 7. EXTERNAL STANDARDS AND SPECIFICATIONS 1059 Many standards groups other than the IETF create and publish 1060 standards documents for network protocols and services. When these 1061 external specifications play an important role in the Internet, it is 1062 desirable to reach common agreements on their usage -- i.e., to 1063 establish Internet Standards relating to these external 1064 specifications. 1066 There are two categories of external specifications: 1068 (1) Open Standards 1070 Various national and international standards bodies, such as ANSI, 1071 ISO, IEEE, and ITU-T, develop a variety of protocol and service 1072 specifications that are similar to Technical Specifications 1073 defined here. National and international groups also publish 1074 "implementors' agreements" that are analogous to Applicability 1075 Statements, capturing a body of implementation-specific detail 1076 concerned with the practical application of their standards. All 1077 of these are considered to be "open external standards" for the 1078 purposes of the Internet Standards Process. 1080 (2) Other Specifications 1082 Other proprietary specifications that have come to be widely used 1083 in the Internet may be treated by the Internet community as if 1084 they were a "standards". Such a specification is not generally 1085 developed in an open fashion, is typically proprietary, and is 1086 controlled by the vendor, vendors, or organization that produced 1087 it. 1089 7.1 Use of External Specifications 1091 To avoid conflict between competing versions of a specification, the 1092 Internet community will not standardize a specification that is 1093 simply an "Internet version" of an existing external specification 1094 unless an explicit cooperative arrangement to do so has been made. 1095 However, there are several ways in which an external specification 1096 that is important for the operation and/or evolution of the Internet 1097 may be adopted for Internet use. 1099 7.1.1 Incorporation of an Open Standard 1101 An Internet Standard TS or AS may incorporate an open external 1102 standard by reference. For example, many Internet Standards 1103 incorporate by reference the ANSI standard character set "ASCII" 1104 [2]. Whenever possible, the referenced specification shall be 1105 available online. 1107 7.1.2 Incorporation of Other Specifications 1109 Other proprietary specifications may be incorporated by reference 1110 to a version of the specification as long as the proprietor meets 1111 the requirements of section 10. If the other proprietary 1112 specification is not widely and readily available, the IESG may 1113 request that it be published as an Informational RFC. 1115 The IESG generally should not favor a particular proprietary 1116 specification over technically equivalent and competing 1117 specification(s) by making any incorporated vendor specification 1118 "required" or "recommended". 1120 7.1.3 Assumption 1122 An IETF Working Group may start from an external specification and 1123 develop it into an Internet specification. This is acceptable if 1124 (1) the specification is provided to the Working Group in 1125 compliance with the requirements of section 10, and (2) change 1126 control has been conveyed to IETF by the original developer of the 1127 specification for the specification or for specifications derived 1128 from the original specification. 1130 8. NOTICES AND RECORD KEEPING 1132 Each of the organizations involved in the development and approval 1133 of Internet Standards shall publicly announce, and shall maintain 1134 a publicly accessible record of, every activity in which it 1135 engages, to the extent that the activity represents the 1136 prosecution of any part of the Internet Standards Process. For 1137 purposes of this section, the organizations involved in the 1138 development and approval of Internet Standards includes the IETF, 1139 the IESG, the IAB, all IETF Working Groups, and the Internet 1140 Society Board of Trustees. 1142 For IETF and Working Group meetings announcements shall be made by 1143 electronic mail to the IETF Announce mailing list and shall be 1144 made sufficiently far in advance of the activity to permit all 1145 interested parties to effectively participate. The announcement 1146 shall contain (or provide pointers to) all of the information that 1147 is necessary to support the participation of any interested 1148 individual. In the case of a meeting, for example, the 1149 announcement shall include an agenda that specifies the standards- 1150 related issues that will be discussed. 1152 The formal record of an organization's standards-related activity 1153 shall include at least the following: 1155 o the charter of the organization (or a defining document equivalent 1156 to a charter); 1157 o complete and accurate minutes of meetings; 1158 o the archives of Working Group electronic mail mailing lists; and 1159 o all written contributions from participants that pertain to the 1160 organization's standards-related activity. 1162 As a practical matter, the formal record of all Internet Standards 1163 Process activities is maintained by the IETF Secretariat, and is the 1164 responsibility of the IETF Secretariat except that each IETF Working 1165 Group is expected to maintain their own email list archive and must 1166 make a best effort to ensure that all traffic is captured and 1167 included in the archives. Also, the Working Group chair is 1168 responsible for providing the IETF Secretariat with complete and 1169 accurate minutes of all Working Group meetings. Internet-Drafts that 1170 have been removed (for any reason) from the Internet-Drafts 1171 directories shall be archived by the IETF Secretariat for the sole 1172 purpose of preserving an historical record of Internet standards 1173 activity and thus are not retrievable except in special 1174 circumstances. 1176 9. VARYING THE PROCESS 1178 This document, which sets out the rules and procedures by which 1179 Internet Standards and related documents are made is itself a product 1180 of the Internet Standards Process (as a BCP, as described in section 1181 5). It replaces a previous version, and in time, is likely itself to 1182 be replaced. 1184 While, when published, this document represents the community's view 1185 of the proper and correct process to follow, and requirements to be 1186 met, to allow for the best possible Internet Standards and BCPs, it 1187 cannot be assumed that this will always remain the case. From time to 1188 time there may be a desire to update it, by replacing it with a new 1189 version. Updating this document uses the same open procedures as are 1190 used for any other BCP. 1192 In addition, there may be situations where following the procedures 1193 leads to a deadlock about a specific specification, or there may be 1194 situations where the procedures provide no guidance. In these cases 1195 it may be appropriate to invoke the variance procedure described 1196 below. 1198 9.1 The Variance Procedure 1200 Upon the recommendation of the responsible IETF Working Group (or, if 1201 no Working Group is constituted, upon the recommendation of an ad hoc 1202 committee), the IESG may enter a particular specification into, or 1203 advance it within, the standards track even though some of the 1204 requirements of this document have not or will not be met. The IESG 1205 may approve such a variance, however, only if it first determines 1206 that the likely benefits to the Internet community are likely to 1207 outweigh any costs to the Internet community that result from 1208 noncompliance with the requirements in this document. In exercising 1209 this discretion, the IESG shall at least consider (a) the technical 1210 merit of the specification, (b) the possibility of achieving the 1211 goals of the Internet Standards Process without granting a variance, 1212 (c) alternatives to the granting of a variance, (d) the collateral 1213 and precedential effects of granting a variance, and (e) the IESG's 1214 ability to craft a variance that is as narrow as possible. In 1215 determining whether to approve a variance, the IESG has discretion to 1216 limit the scope of the variance to particular parts of this document 1217 and to impose such additional restrictions or limitations as it 1218 determines appropriate to protect the interests of the Internet 1219 community. 1221 The proposed variance must detail the problem perceived, explain the 1222 precise provision of this document which is causing the need for a 1223 variance, and the results of the IESG's considerations including 1224 consideration of points (a) through (d) in the previous paragraph. 1225 The proposed variance shall be issued as an Internet Draft. The IESG 1226 shall then issue an extended Last-Call, of no less than 4 weeks, to 1227 allow for community comment upon the proposal. 1229 In a timely fashion after the expiration of the Last-Call period, the 1230 IESG shall make its final determination of whether or not to approve 1231 the proposed variance, and shall notify the IETF of its decision via 1232 electronic mail to the IETF Announce mailing list. If the variance 1233 is approved it shall be forwarded to the RFC Editor with a request 1234 that it be published as a BCP. 1236 This variance procedure is for use when a one-time waving of some 1237 provision of this document is felt to be required. Permanent changes 1238 to this document shall be accomplished through the normal BCP 1239 process. 1241 The appeals process in section 6.5 applies to this process. 1243 9.2 Exclusions 1245 No use of this procedure may lower any specified delays, nor exempt 1246 any proposal from the requirements of openness, fairness, or 1247 consensus, nor from the need to keep proper records of the meetings 1248 and mailing list discussions. 1250 Specifically, the following sections of this document must not be 1251 subject of a variance: 5.1, 6.1, 6.1.1 (first paragraph), 6.1.2, 6.3 1252 (first sentence), 6.5 and 9. 1254 10. INTELLECTUAL PROPERTY RIGHTS 1256 10.1. General Policy 1258 In all matters of intellectual property rights and procedures, the 1259 intention is to benefit the Internet community and the public at 1260 large, while respecting the legitimate rights of others. 1262 10.2 Confidentiality Obligations 1264 No contribution that is subject to any requirement of confidentiality 1265 or any restriction on its dissemination may be considered in any part 1266 of the Internet Standards Process, and there must be no assumption of 1267 any confidentiality obligation with respect to any such contribution. 1269 10.3. Rights and Permissions 1271 In the course of standards work, the IETF receives contributions in 1272 various forms and from many persons. To best facilitate the 1273 dissemination of these contributions, it is necessary to understand 1274 any intellectual property rights (IPR) relating to the contributions. 1276 10.3.1. All Contributions 1278 By submission of a contribution, each person actually submitting the 1279 contribution is deemed to agree to the following terms and conditions 1280 on his own behalf, on behalf of the organization (if any) he 1281 represents and on behalf of the owners of any propriety rights in the 1282 contribution.. Where a submission identifies contributors in 1283 addition to the contributor(s) who provide the actual submission, the 1284 actual submitter(s) represent that each other named contributor was 1285 made aware of and agreed to accept the same terms and conditions on 1286 his own behalf, on behalf of any organization he may represent and 1287 any known owner of any proprietary rights in the contribution. 1289 l. Some works (e.g. works of the U.S. Government) are not subject to 1290 copyright. However, to the extent that the submission is or may 1291 be subject to copyright, the contributor, the organization he 1292 represents (if any) and the owners of any proprietary rights in 1293 the contribution, grant an unlimited perpetual, non-exclusive, 1294 royalty-free, world-wide right and license to the ISOC and the 1295 IETF under any copyrights in the contribution. This license 1296 includes the right to copy, publish and distribute the 1297 contribution in any way, and to prepare derivative works that are 1298 based on or incorporate all or part of the contribution, the 1299 license to such derivative works to be of the same scope as the 1300 license of the original contribution. 1302 2. The contributor acknowledges that the ISOC and IETF have no duty 1303 to publish or otherwise use or disseminate any contribution. 1305 3. The contributor grants permission to reference the name(s) and 1306 address(es) of the contributor(s) and of the organization(s) he 1307 represents (if any). 1309 4. The contributor represents that contribution properly acknowledge 1310 major contributors. 1312 5. The contribuitor, the organization (if any) he represents and the 1313 owners of any proprietary rights in the contribution, agree that 1314 no information in the contribution is confidential and that the 1315 ISOC and its affiliated organizations may freely disclose any 1316 information in the contribution. 1318 6. The contributor represents that he has disclosed the existence of 1319 any proprietary or intellectual property rights in the 1320 contribution that are reasonably and personally known to the 1321 contributor. The contributor does not represent that he 1322 personally knows of all potentially pertinent proprietary and 1323 intellectual property rights owned or claimed by the organization 1324 he represents (if any) or third parties. 1326 7. The contributor represents that there are no limits to the 1327 contributor's ability to make the grants acknowledgments and 1328 agreements above that are reasonably and personally known to the 1329 contributor. 1331 By ratifying this description of the IETF process the Internet 1332 Society warrants that it will not inhibit the traditional open and 1333 free access to IETF documents for which license and right have 1334 been assigned according to the procedures set forth in this 1335 section, including Internet-Drafts and RFCs. This warrant is 1336 perpetual and will not be revoked by the Internet Society or its 1337 successors or assigns. 1339 10.3.2. Standards Track Documents 1341 (A) Where any patents, patent applications, or other proprietary 1342 rights are known, or claimed, with respect to any specification on 1343 the standards track, and brought to the attention of the IESG, the 1344 IESG shall not advance the specification without including in the 1345 document a note indicating the existence of such rights, or 1346 claimed rights. Where implementations are required before 1347 advancement of a specification, only implementations that have, by 1348 statement of the implementors, taken adequate steps to comply with 1349 any such rights, or claimed rights, shall be considered for the 1350 purpose of showing the adequacy of the specification. 1351 (B) The IESG disclaims any responsibility for identifying the 1352 existence of or for evaluating the applicability of any claimed 1353 copyrights, patents, patent applications, or other rights in the 1354 fulfilling of the its obligations under (A), and will take no 1355 position on the validity or scope of any such rights. 1356 (C) Where the IESG knows of rights, or claimed rights under (A), the 1357 IETF Executive Director shall attempt to obtain from the claimant 1358 of such rights, a written assurance that upon approval by the IESG 1359 of the relevant Internet standards track specification(s), any 1360 party will be able to obtain the right to implement, use and 1361 distribute the technology or works when implementing, using or 1362 distributing technology based upon the specific specification(s) 1363 under openly specified, reasonable, non- discriminatory terms. 1364 The Working Group proposing the use of the technology with respect 1365 to which the proprietary rights are claimed may assist the IETF 1366 Executive Director in this effort. The results of this procedure 1367 shall not affect advancement of a specification along the 1368 standards track, except that the IESG may defer approval where a 1369 delay may facilitate the obtaining of such assurances. The 1370 results will, however, be recorded by the IETF Executive Director, 1371 and made available. The IESG may also direct that a summary of 1372 the results be included in any RFC published containing the 1373 specification. 1375 10.3.3 Determination of Reasonable and Non-discriminatory Terms 1377 The IESG will not make any explicit determination that the assurance 1378 of reasonable and non-discriminatory terms for the use of a 1379 technology has been fulfilled in practice. It will instead use the 1380 normal requirements for the advancement of Internet Standards to 1381 verify that the terms for use are reasonable. If the two unrelated 1382 implementations of the specification that are required to advance 1383 from Proposed Standard to Draft Standard have been produced by 1384 different organizations or individuals or if the "significant 1385 implementation and successful operational experience" required to 1386 advance from Draft Standard to Standard has been achieved the 1387 assumption is that the terms must be reasonable and to some degree, 1388 non-discriminatory. This assumption may be challenged during the 1389 Last-Call period. 1391 10.4. Notices 1393 (A) Standards track documents shall include the following notice: 1395 "The IETF takes no position regarding the validity or scope of 1396 any intellectual property or other rights that might be claimed 1397 to pertain to the implementation or use of the technology 1398 described in this document or the extent to which any license 1399 under such rights might or might not be available; neither does 1400 it represent that it has made any effort to identify any such 1401 rights. Information on the IETF's procedures with respect to 1402 rights in standards-track and standards- related documentation 1403 can be found in BCP-xxx, dated in the future. Copies of claims 1404 of rights made available for publication and any assurances of 1405 licenses to be made available, or the result of an attempt made 1406 to obtain a general license or permission for the use of such 1407 proprietary rights by implementors or users of this 1408 specification can be obtained from the IETF Secretariat." 1410 (B) The IETF encourages all interested parties to bring to its 1411 attention, at the earliest possible time, the existence of any 1412 intellectual property rights pertaining to Internet Standards. 1413 For this purpose, each standards document shall include the 1414 following invitation: 1416 "The IETF invites any interested party to bring to its 1417 attention any copyrights, patents or patent applications, or 1418 other proprietary rights which may cover technology that may be 1419 required to practice this standard. Please address the 1420 information to the IETF Executive Director." 1422 (C) The following copyright notice and disclaimer shall be included 1423 in all ISOC standards-related documentation: 1425 "Copyright (C) The Internet Society (date). All Rights 1426 Reserved. 1428 This document and translations of it may be copied and 1429 furnished to others, and derivative works that comment on or 1430 otherwise explain it or assist in its implmentation may be 1431 prepared, copied, published and distributed, in whole or in 1432 part, without restriction of any kind, provided that the above 1433 copyright notice and this paragraph are included on all such 1434 copies and derivative works. However, this document itself may 1435 not be modified in any way, such as by removing the copyright 1436 notice or references to the Internet Society or other Internet 1437 organizations, except as needed for the purpose of developing 1438 Internet standards in which case the procedures for copyrights 1439 defined in the Internet Standards process must be followed, or 1440 as required to translate it into languages other than English. 1442 The limited permissions granted above are perpetual and will 1443 not be revoked by the Internet Society or its successors or 1444 assigns. 1446 This document and the information contained herein is provided 1447 on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 1448 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 1449 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE 1450 OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY 1451 IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 1452 PARTICULAR PURPOSE." 1454 (D) Where the IESG is aware at the time of publication of 1455 proprietary rights claimed with respect to a standards track 1456 document, or the technology described or referenced therein, such 1457 document shall contain the following notice: 1459 "The IETF has been notified of intellectual property rights 1460 claimed in regard to some or all of the specification contained 1461 in this document. For more information consult the online list 1462 of claimed rights." 1464 11. ACKNOWLEDGMENTS 1466 There have been a number of people involved with the development of 1467 the documents defining the IETF Standards Process over the years. 1468 The process was first described in RFC 1310 then revised in RFC 1602 1469 before the current effort (which relies heavily on its predecessors). 1470 Specific acknowledgments must be extended to Lyman Chapin, Phill 1471 Gross and Christian Huitema as the editors of the previous versions, 1472 to Jon Postel and Dave Crocker for their inputs to those versions, to 1473 Andy Ireland, Geoff Stewart, Jim Lampert, and Dick Holleman for their 1474 reviews of the legal aspects of the procedures described herein, and 1475 to John Stewart, Robert Elz and Steve Coya for their extensive input 1476 on the final version. 1478 In addition much of the credit for the refinement of the details of 1479 the IETF processes belongs to the many members of the various 1480 incarnations of the POISED Working Group. 1482 12. SECURITY CONSIDERATIONS 1484 Security issues are not discussed in this memo. 1486 13. REFERENCES 1488 [1] Postel, J., "Internet Official Protocol Standards", STD 1, 1489 USC/Information Sciences Institute, November 1995. 1491 [2] ANSI, Coded Character Set -- 7-Bit American Standard Code for 1492 Information Interchange, ANSI X3.4-1986. 1494 [3] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, 1495 USC/Information Sciences Institute, October 1994. 1497 [4] Postel, J., "Introduction to the STD Notes", RFC 1311, 1498 USC/Information Sciences Institute, March 1992. 1500 [5] Postel, J., "Instructions to RFC Authors", RFC 1543, 1501 USC/Information Sciences Institute, October 1993. 1503 [6] Huitema, C., J. Postel, and S. Crocker "Not All RFCs are 1504 Standards", RFC 1796, April 1995 1506 14. DEFINITIONS OF TERMS 1508 IETF Area - A management division within the IETF. An Area consists 1509 of Working Groups related to a general topic such as routing. An 1510 Area is managed by one or two Area Directors. 1511 Area Director - The manager of an IETF Area. The Area Directors 1512 along with the IETF Chair comprise the Internet Engineering 1513 Steering Group (IESG). 1514 File Transfer Protocol (FTP) - An Internet application used to 1515 transfer files in a TCP/IP network. 1516 gopher - An Internet application used to interactively select and 1517 retrieve files in a TCP/IP network. 1518 Internet Architecture Board (IAB) - An appointed group that assists 1519 in the management of the IETF standards process. 1520 Internet Engineering Steering Group (IESG) - A group comprised of the 1521 IETF Area Directors and the IETF Chair. The IESG is responsible 1522 for the management, along with the IAB, of the IETF and is the 1523 standards approval board for the IETF. 1524 IETF Secretariat - 1525 interoperable - For the purposes of this document, "interoperable" 1526 means to be able to interoperate over a data communications path. 1527 Last-Call - A public comment period used to gage the level of 1528 consensus about the reasonableness of a proposed standards action. 1529 (see section 6.1.2) 1530 online - Relating to information made available over the Internet. 1531 When referenced in this document material is said to be online 1532 when it is retrievable without restriction or undue fee using 1533 standard Internet applications such as anonymous FTP, gopher or 1534 the WWW. 1535 Working Group - A group chartered by the IESG and IAB to work on a 1536 specific specification, set of specifications or topic. 1538 15. AUTHOR'S ADDRESS 1540 Scott O. Bradner 1541 Harvard University 1542 Holyoke Center, Room 813 1543 1350 Mass. Ave. 1544 Cambridge, MA 02138 1545 USA +1 617 495 3864 1547 sob@harvard.edu 1549 APPENDIX A: GLOSSARY OF ACRONYMS 1551 ANSI: American National Standards Institute 1552 ARPA: (U.S.) Advanced Research Projects Agency 1553 AS: Applicability Statement 1554 FTP: File Transfer Protocol 1555 ASCII: American Standard Code for Information Interchange 1556 ITU-T: Telecommunications Standardization sector of the 1557 International Telecommunication Union (ITU), a UN 1558 treaty organization; ITU-T was formerly called CCITT. 1559 IAB: Internet Architecture Board 1560 IANA: Internet Assigned Numbers Authority 1561 IEEE: Institute of Electrical and Electronics Engineers 1562 ICMP: Internet Control Message Protocol 1563 IESG: Internet Engineering Steering Group 1564 IETF: Internet Engineering Task Force 1565 IP: Internet Protocol 1566 IRSG Internet Research Steering Group 1567 IRTF: Internet Research Task Force 1568 ISO: International Organization for Standardization 1569 ISOC: Internet Society 1570 MIB: Management Information Base 1571 OSI: Open Systems Interconnection 1572 RFC: Request for Comments 1573 TCP: Transmission Control Protocol 1574 TS: Technical Specification 1575 WWW: World Wide Web 1577 Expire in six months