idnits 2.17.1 draft-moonesamy-stds-process-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 8) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document obsoletes RFC2026, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 20, 2010) is 5051 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Obsolete informational reference (is this intentional?): RFC 4844 (Obsoleted by RFC 8729) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Individual Submission S. Moonesamy 3 Internet Draft June 20, 2010 4 Obsoletes: 2026 (if approved) 5 Intended status: Best Current Practice 6 Expires: December 19, 2010 8 The Internet Standards Process -- Revision 4 9 draft-moonesamy-stds-process-00 11 Abstract 13 This memo documents the process used by the Internet community for 14 the standardization of protocols and procedures. It defines the 15 stages in the standardization process, the requirements for moving a 16 document between stages and the types of documents used during this 17 process. 19 Status of this Memo 21 This Internet-Draft is submitted to IETF in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on December 19, 2010 42 Copyright Notice 44 Copyright (c) 2010 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 This document may contain material from IETF Documents or IETF 58 Contributions published or made publicly available before 59 November 10, 2008. The person(s) controlling the copyright in 60 some of this material may not have granted the IETF Trust the 61 right to allow modifications of such material outside the 62 IETF Standards Process. Without obtaining an adequate license 63 from the person(s) controlling the copyright in such materials, 64 this document may not be modified outside the IETF Standards 65 Process, and derivative works of it may not be created outside 66 the IETF Standards Process, except to format it for publication 67 as an RFC or to translate it into languages other than English. 69 Table of Contents 71 1. INTRODUCTION....................................................5 72 1.1 Internet Standards...........................................5 73 1.2 The Internet Standards Process...............................5 74 1.3 Organization of This Document................................7 75 2. INTERNET STANDARDS-RELATED PUBLICATIONS.........................7 76 2.1 Requests for Comments (RFCs).................................7 77 2.2 Internet-Drafts..............................................8 78 3. INTERNET STANDARD SPECIFICATIONS................................9 79 3.1 Technical Specification (TS).................................9 80 3.2 Applicability Statement (AS)................................10 81 3.3 Requirement Levels..........................................10 82 4. THE INTERNET STANDARDS TRACK...................................12 83 4.1 Standards Track Maturity Levels.............................12 84 4.1.1 Proposed Standard.......................................12 85 4.1.2 Draft Standard..........................................12 86 4.1.3 Internet Standard.......................................13 87 4.2 Non-Standards Track Maturity Levels.........................14 88 4.2.1 Experimental............................................14 89 4.2.2 Informational...........................................14 90 4.2.3 Procedures for Experimental and Informational RFCs......15 91 4.2.4 Historic................................................15 92 5. Best Current Practice (BCP) RFCs...............................16 93 5.1 BCP Review Process..........................................17 94 6. THE INTERNET STANDARDS PROCESS.................................17 95 6.1 Standards Actions...........................................17 96 6.1.1 Initiation of Action....................................18 97 6.1.2 IESG Review and Approval................................18 98 6.1.3 Publication.............................................19 99 6.2 Advancing in the Standards Track............................19 100 6.3 Revising a Standard.........................................20 101 6.4 Retiring a Standard.........................................21 102 6.5 Conflict Resolution and Appeals.............................21 103 6.5.1 Working Group Disputes...................................21 104 6.5.2 Process Failures.........................................22 105 6.5.3 Questions of Applicable Procedure........................23 106 6.5.4 Appeals Procedure........................................23 107 7. EXTERNAL STANDARDS AND SPECIFICATIONS..........................24 108 7.1 Use of External Specifications..............................24 109 7.1.1 Incorporation of an Open Standard.......................24 110 7.1.2 Incorporation of a Other Specifications.................25 111 7.1.3 Assumption..............................................25 112 8. NOTICES AND RECORD KEEPING......................................25 113 9. VARYING THE PROCESS.............................................26 114 9.1 The Variance Procedure.......................................26 115 9.2 Exclusions...................................................27 116 10. INTELLECTUAL PROPERTY RIGHTS..................................28 117 10.1. General Policy............................................28 118 10.2 Confidentiality Obligations...............................28 119 10.3. Standards Track Documents.................................28 120 10.4. Determination of Reasonable and 121 Non-discriminatory Terms..................................29 122 11. TRANSITION.....................................................29 123 12. SECURITY CONSIDERATIONS........................................29 124 13. IANA CONSIDERATIONS............................................29 125 14. ACKNOWLEDGMENTS................................................29 126 15. REFERENCES.....................................................29 127 AUTHOR'S ADDRESS...............................................29 128 APPENDIX A: DEFINITIONS OF TERMS...................................31 129 APPENDIX B: GLOSSARY OF ACRONYMS...................................31 131 1. Introduction 133 This memo documents the process currently used by the Internet 134 community for the standardization of protocols and procedures. The 135 Internet Standards process is managed on behalf of the Internet 136 community by the Internet Architecture Board (IAB) and the Internet 137 Engineering Steering Group (IESG). 139 1.1 Internet Standards 141 The Internet, a loosely-organized international collaboration of 142 autonomous, interconnected networks, supports host-to-host 143 communication through voluntary adherence to open protocols and 144 procedures defined by Internet Standards. There are also many 145 isolated interconnected networks, which are not connected to the 146 global Internet but use the Internet Standards. 148 The Internet Standards Process described in this document is 149 concerned with all protocols, procedures, and conventions that are 150 used in or by the Internet, whether or not they are part of the 151 TCP/IP protocol suite. In the case of protocols developed and/or 152 standardized by non-Internet organizations, however, the Internet 153 Standards Process normally applies to the application of the protocol 154 or procedure in the Internet context, not to the specification of the 155 protocol itself. 157 In general, an Internet Standard is a specification that is stable 158 and well-understood, is technically competent, has multiple, 159 independent, and interoperable implementations with substantial 160 operational experience, enjoys significant public support, and is 161 recognizably useful in some or all parts of the Internet. 163 1.2 The Internet Standards Process 165 In outline, the process of creating an Internet Standard is 166 straightforward: a specification undergoes a period of development 167 and several iterations of review by the Internet community and 168 revision based upon experience, is adopted as a Standard by the 169 appropriate body (see below), and is published. In practice, the 170 process is more complicated, due to (1) the difficulty of creating 171 specifications of high technical quality; (2) the need to consider 172 the interests of all of the affected parties; (3) the importance of 173 establishing widespread community consensus; and (4) the difficulty 174 of evaluating the utility of a particular specification for the 175 Internet community. 177 The goals of the Internet Standards Process are: o technical 178 excellence; o prior implementation and testing; o clear, concise, 179 and easily understood documentation; o openness and fairness; and o 180 timeliness. 182 The procedures described in this document are designed to be fair, 183 open, and objective; to reflect existing (proven) practice; and to 184 be flexible. 186 o These procedures are intended to provide a fair, open, and 187 objective basis for developing, evaluating, and adopting Internet 188 Standards. They provide ample opportunity for participation and 189 comment by all interested parties. At each stage of the 190 standardization process, a specification is repeatedly discussed and 191 its merits debated in open meetings and/or public electronic mailing 192 lists, and it is made available for review via world-wide on-line 193 directories. 195 o These procedures are explicitly aimed at recognizing and adopting 196 generally-accepted practices. Thus, a candidate specification must 197 be implemented and tested for correct operation and interoperability 198 by multiple independent parties and utilized in increasingly 199 demanding environments, before it can be adopted as an Internet 200 Standard. 202 o These procedures provide a great deal of flexibility to adapt to 203 the wide variety of circumstances that occur in the standardization 204 process. Experience has shown this flexibility to be vital in 205 achieving the goals listed above. 207 The goal of technical competence, the requirement for prior 208 implementation and testing, and the need to allow all interested 209 parties to comment all require significant time and effort. On the 210 other hand, today's rapid development of networking technology 211 demands timely development of standards. The Internet Standards 212 Process is intended to balance these conflicting goals. The process 213 is believed to be as short and simple as possible without sacrificing 214 technical excellence, thorough testing before adoption of a standard, 215 or openness and fairness. 217 From its inception, the Internet has been, and is expected to remain, 218 an evolving system whose participants regularly factor new 219 requirements and technology into its design and implementation. 220 Users of the Internet and providers of the equipment, software, and 221 services that support it should anticipate and embrace this evolution 222 as a major tenet of Internet philosophy. 224 The procedures described in this document are the result of a number 225 of years of evolution, driven both by the needs of the growing and 226 increasingly diverse Internet community, and by experience. 228 1.3 Organization of This Document 230 Section 2 describes the publications and archives of the Internet 231 Standards Process. Section 3 describes the types of Internet 232 standard specifications. Section 4 describes the Internet standards 233 specifications track. Section 5 describes Best Current Practice 234 RFCs. Section 6 describes the process and rules for Internet 235 standardization. Section 7 specifies the way in which externally- 236 sponsored specifications and practices, developed and controlled by 237 other standards bodies or by others, are handled within the Internet 238 Standards Process. Section 8 describes the requirements for notices 239 and record keeping Section 9 defines a variance process to allow 240 one-time exceptions to some of the requirements in this document 241 Section 14 includes acknowledgments of some of the people involved in 242 creation of this document. Appendix A contains definitions of some 243 of the terms used in this document. Appendix B contains a list of 244 frequently-used acronyms. 246 2. INTERNET STANDARDS-RELATED PUBLICATIONS 248 2.1 Request for Comments (RFCs) 250 Each distinct version of an IETF standards-related specification is 251 published as part of the RFC Series [RFC4844]. This archival series 252 is the official publication channel for Internet standards documents 253 and other publications of the IESG, IAB, IRTF and Internet community. 254 RFCs can be obtained from a number of Internet hosts using the World 255 Wide Web, and other Internet document-retrieval systems. 257 The RFC series of documents on networking began in 1969 as part of 258 the original ARPA wide-area networking (ARPANET) project (see 259 Appendix A for glossary of acronyms). RFCs cover a wide range of 260 topics in addition to Internet Standards, from early discussion of 261 new research concepts to status memos about the Internet. RFC 262 publication is the direct responsibility of the RFC Editor, under the 263 general direction of the IAB. 265 The rules for formatting and submitting an RFC are defined in the RFC 266 Series Style Guide. Every RFC is available in ASCII text. Some RFCs 267 are also available in other formats. The other versions of an RFC 268 may contain material (such as diagrams and figures) that is not 269 present in the ASCII version, and it may be formatted differently. 271 ********************************************************* 272 * * 273 * A stricter requirement applies to standards-track * 274 * specifications: the ASCII text version is the * 275 * definitive reference, and therefore it must be a * 276 * complete and accurate specification of the standard, * 277 * including all necessary diagrams and illustrations. * 278 * * 279 ********************************************************* 281 The status of Internet protocol and service specifications is 282 summarized periodically in an RFC entitled "Internet Official 283 Protocol Standards" [STD1]. This RFC shows the level of maturity and 284 other helpful information for each Internet protocol or service 285 specification (see section 3). 287 Some RFCs document Internet Standards. These RFCs form the 'STD' 288 subseries of the RFC series [RFC1311]. When a specification has been 289 adopted as an Internet Standard, it is given the additional label 290 "STDxxx", but it keeps its RFC number and its place in the RFC 291 series. (see section 4.1.3) 293 Some RFCs standardize the results of community deliberations about 294 statements of principle or conclusions about what is the best way to 295 perform some operations or IETF process function. These RFCs form 296 the specification has been adopted as a BCP, it is given the 297 additional label "BCPxxx", but it keeps its RFC number and its place 298 in the RFC series. (see section 5) 300 Not all specifications of protocols or services for the Internet 301 should or will become Internet Standards or BCPs. Such non-standards 302 track specifications are not subject to the rules for Internet 303 standardization. Non-standards track specifications may be published 304 directly as "Experimental" or "Informational" RFCs at the discretion 305 of the RFC Editor in consultation with the IESG (see section 4.2). 307 ******************************************************** 308 * * 309 * It is important to remember that not all RFCs * 310 * are standards track documents, and that not all * 311 * standards track documents reach the level of * 312 * Internet Standard. In the same way, not all RFCs * 313 * which describe current practices have been given * 314 * the review and approval to become BCPs. See * 315 * RFC 1796 [RFC1796] for further information. * 316 * * 317 * ****************************************************** 319 2.2 Internet-Drafts 321 During the development of a specification, draft versions of the 322 document are made available for informal review and comment by 323 placing them in the IETF's "Internet-Drafts" directory, which is 324 replicated on a number of Internet hosts. This makes an evolving 325 working document readily available to a wide audience, facilitating 326 the process of review and revision. 328 An Internet-Draft expires if it has remained unchanged in the 329 Internet-Drafts directory for more than six months without being 330 recommended by the IESG for publication as an RFC. At any time, an 331 Internet-Draft may be replaced by a more recent version of the same 332 specification, restarting the six-month timeout period. 334 An Internet-Draft is NOT a means of "publishing" a specification; 335 specifications are published through the RFC mechanism described in 336 the previous section. Internet-Drafts have no formal status, and are 337 subject to change or removal at any time. 339 ******************************************************** 340 * * 341 * Under no circumstances should an Internet-Draft * 342 * be referenced by any paper, report, or Request- * 343 * for-Proposal, nor should a vendor claim compliance * 344 * with an Internet-Draft. * 345 * * 346 ******************************************************** 348 Note: It is acceptable to reference a standards-track specification 349 that may reasonably be expected to be published as an RFC using the 350 phrase "Work in Progress" without referencing an Internet-Draft. 351 This may also be done in a standards track document itself as long as 352 the specification in which the reference is made would stand as a 353 complete and understandable document with or without the reference to 354 the "Work in Progress". 356 3. INTERNET STANDARD SPECIFICATIONS 358 Specifications subject to the Internet Standards Process fall into 359 one of two categories: Technical Specification (TS) and 360 Applicability Statement (AS). 362 3.1 Technical Specification (TS) 364 A Technical Specification is any description of a protocol, service, 365 procedure, convention, or format. It may completely describe all of 366 the relevant aspects of its subject, or it may leave one or more 367 parameters or options unspecified. A TS may be completely self- 368 contained, or it may incorporate material from other specifications 369 by reference to other documents (which might or might not be Internet 370 Standards). 372 A TS shall include a statement of its scope and the general intent 373 for its use (domain of applicability). Thus, a TS that is inherently 374 specific to a particular context shall contain a statement to that 375 effect. However, a TS does not specify requirements for its use 376 within the Internet; these requirements, which depend on the 377 particular context in which the TS is incorporated by different 378 system configurations, are defined by an Applicability Statement. 380 3.2 Applicability Statement (AS) 382 An Applicability Statement specifies how, and under what 383 circumstances, one or more TSs may be applied to support a particular 384 Internet capability. An AS may specify uses for TSs that are not 385 Internet Standards, as discussed in Section 7. 387 An AS identifies the relevant TSs and the specific way in which they 388 are to be combined, and may also specify particular values or ranges 389 of TS parameters or subfunctions of a TS protocol that must be 390 implemented. An AS also specifies the circumstances in which the use 391 of a particular TS is required, recommended, or elective (see section 392 3.3). 394 An AS may describe particular methods of using a TS in a restricted 395 "domain of applicability", such as Internet routers, terminal 396 servers, Internet systems that interface to Ethernets, or datagram- 397 based database servers. 399 The broadest type of AS is a comprehensive conformance specification, 400 commonly called a "requirements document", for a particular class of 401 Internet systems, such as Internet routers or Internet hosts. 403 An AS may not have a higher maturity level in the standards track 404 than any standards-track TS on which the AS relies (see section 4.1). 405 For example, a TS at Draft Standard level may not be referenced by an 406 AS at the Standard level. 408 3.3 Requirement Levels 410 An AS shall apply one of the following "requirement levels" to each 411 of the TSs to which it refers: 413 (a) Required: Implementation of the referenced TS, as specified by 414 the AS, is required to achieve minimal conformance. For example, IP 415 and ICMP must be implemented by all Internet systems using the TCP/IP 416 Protocol Suite. 418 (b) Recommended: Implementation of the referenced TS is not 419 required for minimal conformance, but experience and/or generally 420 accepted technical wisdom suggest its desirability in the domain of 421 applicability of the AS. Vendors are strongly encouraged to include 422 the functions, features, and protocols of Recommended TSs in their 423 products, and should omit them only if the omission is justified by 424 some special circumstance. For example, the TELNET protocol should be 425 implemented by all systems that would benefit from remote access. 427 (c) Elective: Implementation of the referenced TS is optional 428 within the domain of applicability of the AS; that is, the AS 429 creates no explicit necessity to apply the TS. However, a particular 430 vendor may decide to implement it, or a particular user may decide 431 that it is a necessity in a specific environment. For example, the 432 DECNET MIB could be seen as valuable in an environment where the 433 DECNET protocol is used. 435 As noted in section 4.1, there are TSs that are not in the standards 436 track or that have been retired from the standards track, and are 437 therefore not required, recommended, or elective. Two additional 438 "requirement level" designations are available for these TSs: 440 (d) Limited Use: The TS is considered to be appropriate for use 441 only in limited or unique circumstances. For example, the usage of a 442 protocol with the "Experimental" designation should generally be 443 limited to those actively involved with the experiment. 445 (e) Not Recommended: A TS that is considered to be inappropriate 446 for general use is labeled "Not Recommended". This may be because of 447 its limited functionality, specialized nature, or historic status. 449 Although TSs and ASs are conceptually separate, in practice a 450 standards-track document may combine an AS and one or more related 451 TSs. For example, Technical Specifications that are developed 452 specifically and exclusively for some particular domain of 453 applicability, e.g., for mail server hosts, often contain within a 454 single specification all of the relevant AS and TS information. In 455 such cases, no useful purpose would be served by deliberately 456 distributing the information among several documents just to preserve 457 the formal AS/TS distinction. However, a TS that is likely to apply 458 to more than one domain of applicability should be developed in a 459 modular fashion, to facilitate its incorporation by multiple ASs. 461 The "Official Protocol Standards" RFC (STD1) lists a general 462 requirement level for each TS, using the nomenclature defined in this 463 section. This RFC is updated periodically. In many cases, more 464 detailed descriptions of the requirement levels of particular 465 protocols and of individual features of the protocols will be found 466 in appropriate ASs. 468 4. THE INTERNET STANDARDS TRACK 470 Specifications that are intended to become Internet Standards evolve 471 through a set of maturity levels known as the "standards track". 472 These maturity levels -- "Draft Standard", and "Standard" -- are 473 defined and discussed in section 4.1. The way in which 474 specifications move along the standards track is described in section 475 6. 477 Even after a specification has been adopted as an Internet Standard, 478 further evolution often occurs based on experience and the 479 recognition of new requirements. The nomenclature and procedures of 480 Internet standardization provide for the replacement of old Internet 482 Standards with new ones, and the assignment of descriptive labels to 483 indicate the status of "retired" Internet Standards. A set of 484 maturity levels is defined in section 4.2 to cover these and other 485 specifications that are not considered to be on the standards track. 487 4.1 Standards Track Maturity Levels 489 Internet specifications go through stages of development, testing, 490 and acceptance. Within the Internet Standards Process, these stages 491 are formally labeled "maturity levels". 493 This section describes the maturity levels and the expected 494 characteristics of specifications at each level. 496 4.1.1 Draft Standard 498 The entry-level maturity for the standards track is "Draft Standard". 499 A specific action by the IESG is required to move a specification 500 onto the standards track at the "Draft Standard" level. 502 A Draft Standard specification is generally stable, has resolved 503 known design choices, is believed to be well-understood, has received 504 significant community review, and appears to enjoy enough community 505 interest to be considered valuable. However, further experience 506 might result in a change or even retraction of the specification 507 before it advances. 509 Usually, neither implementation nor operational experience is 510 required for the designation of a specification as a Proposed 511 Standard. However, such experience is highly desirable, and will 512 usually represent a strong argument in favor of a Draft Standard 513 designation. 515 The IESG may require implementation and/or operational experience 516 prior to granting Draft Standard status to a specification that 517 materially affects the core Internet protocols or that specifies 518 behavior that may have significant operational impact on the 519 Internet. 521 A Draft Standard should have no known technical omissions with 522 respect to the requirements placed upon it. However, the IESG may 523 waive this requirement in order to allow a specification to be 524 published with a Draft Standard status when it is considered to be 525 useful and necessary (and timely) even with known technical 526 omissions. 528 Implementors should treat Draft Standards as immature specifications. 529 It is desirable to implement them in order to gain experience and to 530 validate, test, and clarify the specification. However, since the 531 content of Draft Standards may be changed if problems are found or 532 better solutions are identified, deploying implementations of such 533 standards into a disruption-sensitive environment is not recommended. 535 4.1.2 Internet Standard 537 A specification for which significant implementation and successful 538 operational experience has been obtained may be elevated to the 539 Internet Standard level. An Internet Standard (which may simply be 540 referred to as a Standard) is characterized by a high degree of 541 technical maturity and by a generally held belief that the specified 542 protocol or service provides significant benefit to the Internet 543 community. 545 A specification that reaches the status of Standard is assigned a 546 number in the STD series while retaining its RFC number. 548 The specification must have at least two independent and 549 interoperable implementations from different code bases, and 550 sufficient successful operational experience must has been before it 551 obtained, before it may be elevated to the "Internet Standard" level. 552 For the purposes of this section, "interoperable" means to be 553 functionally equivalent or interchangeable components of the system 554 or process in which they are used. If patented or otherwise 555 controlled technology is required for implementation, the separate 556 implementations must also have resulted from separate exercise of the 557 licensing process. Elevation to Internet Standard indicates that 558 there is a strong belief that the specification is mature and will be 559 useful. 561 The requirement for at least two independent and interoperable 562 implementations applies to all of the options and features of the 563 specification. In cases in which one or more options or features 564 have not been demonstrated in at least two interoperable 565 implementations, the specification may advance to the Internet 566 Standard level only if those options or features are removed. 568 The Working Group chair is responsible for documenting the specific 569 implementations which qualify the specification for Internet Standard 570 status along with documentation about testing of the interoperation 571 of these implementations. The documentation must include information 572 about the support of each of the individual options and features. 573 This documentation should be submitted to the Area Director with the 574 protocol action request. (see Section 6) 576 4.2 Non-Standards Track Maturity Levels 578 Not every specification is on the standards track. A specification 579 may not be intended to be an Internet Standard, or it may be intended 580 for eventual standardization but not yet ready to enter the standards 581 track. A specification may have been superseded by a more recent 582 Internet Standard, or have otherwise fallen into disuse or disfavor. 584 Specifications that are not on the standards track are labeled with 585 one of three "off-track" maturity levels: "Experimental", 586 "Informational", or "Historic". The documents bearing these labels 587 are not Internet Standards in any sense. 589 4.2.1 Experimental 591 The "Experimental" designation typically denotes a specification that 592 is part of some research or development effort. Such a specification 593 is published for the general information of the Internet technical 594 community and as an archival record of the work, subject only to 595 editorial considerations and to verification that there has been 596 adequate coordination with the standards process (see below). An 597 Experimental specification may be the output of an organized Internet 598 research effort (e.g., a Research Group of the IRTF), an IETF Working 599 Group, or it may be an individual or independent submission. 601 4.2.2 Informational 603 An "Informational" specification is published for the general 604 information of the Internet community, and does not represent an 605 Internet community consensus or recommendation. The Informational 606 designation is intended to provide for the timely publication of a 607 very broad range of responsible informational documents from many 608 sources, subject only to editorial considerations and to verification 609 that there has been adequate coordination with the standards process 610 (see section 4.2.3). 612 Specifications that have been prepared outside of the Internet 613 community and are not incorporated into the Internet Standards 614 Process by any of the provisions of section 10 may be published as 615 Informational RFCs, with the permission of the owner and the 616 concurrence of the RFC Editor. 618 4.2.3 Procedures for Experimental and Informational RFCs 620 Unless they are the result of IETF Working Group action or an 621 individual submission, documents intended to be published with 622 Experimental or Informational status should be submitted directly to 623 the RFC Editor. The RFC Editor is expected to exercise his or her 624 judgment concerning the editorial suitability of a document for 625 publication with Experimental or Informational status, and may refuse 626 to publish a document which, in the expert opinion of the RFC Editor, 627 is unrelated to Internet activity or falls below the technical and/or 628 editorial standard for RFCs. 630 To ensure that the non-standards track Experimental and Informational 631 designations are not misused to circumvent the Internet Standards 632 Process, the IESG and the RFC Editor have agreed that the RFC Editor 633 will refer to the IESG any document submitted for Experimental or 634 Informational publication which, in the opinion of the RFC Editor, 635 may be related to work being done, or expected to be done, within the 636 IETF community. The IESG shall review such a referred document 637 within a reasonable period of time, and recommend either that it be 638 published as originally submitted or referred to the IETF as a 639 contribution to the Internet Standards Process. 641 If (a) the IESG recommends that the document be brought within the 642 IETF and progressed within the IETF context, but the author declines 643 to do so, or (b) the IESG considers that the document propose 644 something that conflicts with, or is actually inimical to, an 645 established IETF effort, the document may still be published as an 646 Experimental or Informational RFC. In these cases, however, the IESG 647 may insert appropriate "disclaimer" text into the RFC either in or 648 immediately following the "Status of this Memo" section in order to 649 make the circumstances of its publication clear to readers. 651 Documents proposed for Experimental and Informational RFCs by IETF 652 Working Groups or as individual submissions go through IESG review. 653 The review is initiated using the process described in section 6.1.1. 655 4.2.4 Historic 657 A specification that has been superseded by a more recent 658 specification or is for any other reason considered to be obsolete is 659 assigned to the "Historic" level. (Purists have suggested that the 660 word should be "Historical"; however, at this point the use of 661 "Historic" is historical.) 663 Note: Standards track specifications normally do not depend on other 664 standards track specifications which are at a lower maturity level or 665 on non standards track specifications other than referenced 666 specifications from other standards bodies. (See Section 7.) 668 5. BEST CURRENT PRACTICE (BCP) RFCs 670 The BCP subseries of the RFC series is designed to be a way to 671 standardize practices and the results of community deliberations. A 672 BCP document is subject to the same basic set of procedures as 673 standards track documents and thus is a vehicle by which the IETF 674 community can define and ratify the community's best current thinking 675 on a statement of principle or on what is believed to be the best way 676 to perform some operations or IETF process function. 678 Historically Internet standards have generally been concerned with 679 the technical specifications for hardware and software required for 680 computer communication across interconnected networks. However, 681 since the Internet itself is composed of networks operated by a great 682 variety of organizations, with diverse goals and rules, good user 683 service requires that the operators and administrators of the 684 Internet follow some common guidelines for policies and operations. 685 While these guidelines are generally different in scope and style 686 from protocol standards, their establishment needs a similar process 687 for consensus building. 689 While it is recognized that entities such as the IAB and IESG are 690 composed of individuals who may participate, as individuals, in the 691 technical work of the IETF, it is also recognized that the entities 692 themselves have an existence as leaders in the community. As leaders 693 in the Internet technical community, these entities should have an 694 outlet to propose ideas to stimulate work in a particular area, to 695 raise the community's sensitivity to a certain issue, to make a 696 statement of architectural principle, or to communicate their 697 thoughts on other matters. The BCP subseries creates a smoothly 698 structured way for these management entities to insert proposals into 699 the consensus-building machinery of the IETF while gauging the 700 community's view of that issue. 702 Finally, the BCP series may be used to document the operation of the 703 IETF itself. For example, this document defines the IETF Standards 704 Process and is published as a BCP. 706 5.1 BCP Review Process 708 Unlike standards-track documents, the mechanisms described in BCPs 709 are not well suited to the phased roll-in nature of the three stage 710 standards track and instead generally only make sense for full and 711 immediate instantiation. 713 The BCP process is similar to that for proposed standards. The BCP 714 is submitted to the IESG for review, (see section 6.1.1) and the 715 existing review process applies, including a Last-Call on the IETF 716 Announce mailing list. However, once the IESG has approved the 717 document, the process ends and the document is published. The 718 resulting document is viewed as having the technical approval of the 719 IETF. 721 Specifically, a document to be considered for the status of BCP must 722 undergo the procedures outlined in sections 6.1, and 6.4 of this 723 document. The BCP process may be appealed according to the procedures 724 in section 6.5. 726 Because BCPs are meant to express community consensus but are arrived 727 at more quickly than standards, BCPs require particular care. 728 Specifically, BCPs should not be viewed simply as stronger 729 Informational RFCs, but rather should be viewed as documents suitable 730 for a content different from Informational RFCs. 732 A specification, or group of specifications, that has, or have been 733 approved as a BCP is assigned a number in the BCP series while 734 retaining its RFC number(s). 736 6. THE INTERNET STANDARDS PROCESS 738 The mechanics of the Internet Standards Process involve decisions of 739 the IESG concerning the elevation of a specification onto the 740 standards track or the movement of a standards-track specification 741 from one maturity level to another. Although a number of reasonably 742 objective criteria (described below and in section 4) are available 743 to guide the IESG in making a decision to move a specification onto, 744 along, or off the standards track, there is no algorithmic guarantee 745 of elevation to or progression along the standards track for any 746 specification. The experienced collective judgment of the IESG 747 concerning the technical quality of a specification proposed for 748 elevation to or advancement in the standards track is an essential 749 component of the decision-making process. 751 6.1 Standards Actions 753 A "standards action" -- entering a particular specification into, 754 advancing it within, or removing it from, the standards track -- must 755 be approved by the IESG. 757 6.1.1 Initiation of Action 759 A specification that is intended to enter or advance in the Internet 760 standards track shall first be posted as an Internet-Draft (see 761 section 2.2) unless it has not changed since publication as an RFC. 762 It shall remain as an Internet-Draft for a period of time, not less 763 than two weeks, that permits useful community review, after which a 764 recommendation for action may be initiated. 766 A standards action is initiated by a recommendation by the IETF 767 Working group responsible for a specification to its Area Director, 768 copied to the IETF Secretariat or, in the case of a specification not 769 associated with a Working Group, a recommendation by an individual to 770 the IESG. 772 6.1.2 IESG Review and Approval 774 The IESG shall determine whether or not a specification submitted to 775 it according to section 6.1.1 satisfies the applicable criteria for 776 the recommended action (see sections 4.1 and 4.2), and shall in 777 addition determine whether or not the technical quality and clarity 778 of the specification is consistent with that expected for the 779 maturity level to which the specification is recommended. 781 In order to obtain all of the information necessary to make these 782 determinations, particularly when the specification is considered by 783 the IESG to be extremely important in terms of its potential impact 784 on the Internet or on the suite of Internet protocols, the IESG may, 785 at its discretion, commission an independent technical review of the 786 specification. 788 The IESG will send notice to the IETF of the pending IESG 789 consideration of the document(s) to permit a final review by the 790 general Internet community. This "Last-Call" notification shall be 791 via electronic mail to the IETF Announce mailing list. Comments on a 792 Last-Call shall be accepted from anyone, and should be sent as 793 directed in the Last-Call announcement. 795 The Last-Call period shall be no shorter than two weeks except in 796 those cases where the proposed standards action was not initiated by 797 an IETF Working Group, in which case the Last-Call period shall be no 798 shorter than four weeks. If the IESG believes that the community 799 interest would be served by allowing more time for comment, it may 800 decide on a longer Last-Call period or to explicitly lengthen a 801 current Last-Call period. 803 The IESG is not bound by the action recommended when the 804 specification was submitted. For example, the IESG may decide to 805 consider the specification for publication in a different category 806 than that requested. If the IESG determines this before the Last- 807 Call is issued then the Last-Call should reflect the IESG's view. 808 The IESG could also decide to change the publication category based 809 on the response to a Last-Call. If this decision would result in a 810 specification being published at a "higher" level than the original 811 Last-Call was for, a new Last-Call should be issued indicating the 812 IESG recommendation. In addition, the IESG may decide to recommend 813 the formation of a new Working Group in the case of significant 814 controversy in response to a Last-Call for specification not 815 originating from an IETF Working Group. 817 In a timely fashion after the expiration of the Last-Call period, the 818 IESG shall make its final determination of whether or not to approve 819 the standards action, and shall notify the IETF of its decision via 820 electronic mail to the IETF Announce mailing list. 822 An official summary of standards actions completed and pending shall 823 appear in each issue of the Internet Society's newsletter. This 824 shall constitute the "publication of record" for Internet standards 825 actions. 827 The RFC Editor shall publish periodically an "Internet Official 828 Protocol Standards" RFC [STD1], summarizing the status of all 829 Internet protocol and service specifications. 831 6.1.3 Publication 833 If a standards action is approved, notification is sent to the RFC 834 Editor and copied to the IETF with instructions to publish the 835 specification as an RFC. 837 6.2 Advancing in the Standards Track 839 The procedure described in section 6.1 is followed for each action 840 that attends the advancement of a specification along the standards 841 track. 843 A specification shall remain at the Draft Standard level for at least 844 six (6) months. 846 The minimum period is intended to ensure adequate opportunity for 847 community review without severely impacting timeliness. The interval 848 shall be measured from the date of publication of the corresponding 849 RFC(s), or, if the action does not result in RFC publication, the 850 date of the announcement of the IESG approval of the action. 852 A specification may be (indeed, is likely to be) revised as it 853 advances through the standards track. The IESG shall determine the 854 scope and significance of the revision to the specification, and, if 855 necessary and appropriate, modify the recommended action. Minor 856 revisions are expected, but a significant revision may require that 857 the specification accumulate more experience at its current maturity 858 level before progressing. Finally, if the specification has been 859 changed very significantly, the IESG may recommend that the revision 860 be treated as a new document, re-entering the standards track at the 861 beginning. 863 Change of status shall result in republication of the specification 864 as an RFC, except in the rare case that there have been no changes at 865 all in the specification since the last publication. Generally, 866 desired changes will be "batched" for incorporation at the next level 867 in the standards track. However, deferral of changes to the next 868 standards action on the specification will not always be possible or 869 desirable; for example, an important typographical error, or a 870 technical error that does not represent a change in overall function 871 of the specification, may need to be corrected immediately. In such 872 cases, the IESG or RFC Editor may be asked to republish the RFC (with 873 a new number) with corrections, and this will not reset the minimum 874 time-at-level clock. 876 When a standards-track specification has not reached the Internet 877 Standard level but has remained at the same maturity level for forty- 878 eight (48) months, and every twelve (12) months thereafter until the 879 status is changed, the IESG shall review the viability of the 880 standardization effort responsible for that specification and the 881 usefulness of the technology. Following each such review, the IESG 882 shall approve termination or continuation of the development effort, 883 at the same time the IESG shall decide to maintain the specification 884 at the same maturity level or to move it to Historic status. This 885 decision shall be communicated to the IETF by electronic mail to the 886 IETF Announce mailing list to allow the Internet community an 887 opportunity to comment. This provision is not intended to threaten a 888 legitimate and active Working Group effort, but rather to provide an 889 administrative mechanism for terminating a moribund effort. 891 6.3 Revising a Standard 893 A new version of an established Internet Standard must progress 894 through the full Internet standardization process as if it were a 895 completely new specification. Once the new version has reached the 896 Standard level, it will usually replace the previous version, which 897 will be moved to Historic status. However, in some cases both 898 versions may remain as Internet Standards to honor the requirements 899 of an installed base. In this situation, the relationship between 900 the previous and the new versions must be explicitly stated in the 901 text of the new version or in another appropriate document (e.g., an 902 Applicability Statement; see section 3.2). 904 6.4 Retiring a Standard 906 As the technology changes and matures, it is possible for a new 907 Standard specification to be so clearly superior technically that one 908 or more existing standards track specifications for the same function 909 should be retired. In this case, or when it is felt for some other 910 reason that an existing standards track specification should be 911 retired, the IESG shall approve a change of status of the old 912 specification(s) to Historic. This recommendation shall be issued 913 with the same Last-Call and notification procedures used for any 914 other standards action. A request to retire an existing standard can 915 originate from a Working Group, an Area Director or some other 916 interested party. 918 6.5 Conflict Resolution and Appeals 920 Disputes are possible at various stages during the IETF process. As 921 much as possible the process is designed so that compromises can be 922 made, and genuine consensus achieved, however there are times when 923 even the most reasonable and knowledgeable people are unable to 924 agree. To achieve the goals of openness and fairness, such conflicts 925 must be resolved by a process of open review and discussion. This 926 section specifies the procedures that shall be followed to deal with 927 Internet standards issues that cannot be resolved through the normal 928 processes whereby IETF Working Groups and other Internet Standards 929 Process participants ordinarily reach consensus. 931 6.5.1 Working Group Disputes 933 An individual (whether a participant in the relevant Working Group or 934 not) may disagree with a Working Group recommendation based on his or 935 her belief that either (a) his or her own views have not been 936 adequately considered by the Working Group, or (b) the Working Group 937 has made an incorrect technical choice which places the quality 938 and/or integrity of the Working Group's product(s) in significant 939 jeopardy. The first issue is a difficulty with Working Group 940 process; the latter is an assertion of technical error. These two 941 types of disagreement are quite different, but both are handled by 942 the same process of review. 944 A person who disagrees with a Working Group recommendation shall 945 always first discuss the matter with the Working Group's chair(s), 946 who may involve other members of the Working Group (or the Working 947 Group as a whole) in the discussion. 949 If the disagreement cannot be resolved in this way, any of the 950 parties involved may bring it to the attention of the Area 951 Director(s) for the area in which the Working Group is chartered. 952 The Area Director(s) shall attempt to resolve the dispute. 954 If the disagreement cannot be resolved by the Area Director(s) any of 955 the parties involved may then appeal to the IESG as a whole. The 956 IESG shall then review the situation and attempt to resolve it in a 957 manner of its own choosing. 959 If the disagreement is not resolved to the satisfaction of the 960 parties at the IESG level, any of the parties involved may appeal the 961 decision to the IAB. The IAB shall then review the situation and 962 attempt to resolve it in a manner of its own choosing. 964 The IAB decision is final with respect to the question of whether or 965 not the Internet standards procedures have been followed and with 966 respect to all questions of technical merit. 968 6.5.2 Process Failures 970 This document sets forward procedures required to be followed to 971 ensure openness and fairness of the Internet Standards Process, and 972 the technical viability of the standards created. The IESG is the 973 principal agent of the IETF for this purpose, and it is the IESG that 974 is charged with ensuring that the required procedures have been 975 followed, and that any necessary prerequisites to a standards action 976 have been met. 978 If an individual should disagree with an action taken by the IESG in 979 this process, that person should first discuss the issue with the 980 IESG Chair. If the IESG Chair is unable to satisfy the complainant 981 then the IESG as a whole should re-examine the action taken, along 982 with input from the complainant, and determine whether any further 983 action is needed. The IESG shall issue a report on its review of the 984 complaint to the IETF. 986 Should the complainant not be satisfied with the outcome of the IESG 987 review, an appeal may be lodged to the IAB. The IAB shall then review 988 the situation and attempt to resolve it in a manner of its own 989 choosing and report to the IETF on the outcome of its review. 991 If circumstances warrant, the IAB may direct that an IESG decision be 992 annulled, and the situation shall then be as it was before the IESG 993 decision was taken. The IAB may also recommend an action to the IESG, 994 or make such other recommendations as it deems fit. The IAB may not, 995 however, pre-empt the role of the IESG by issuing a decision which 996 only the IESG is empowered to make. 998 The IAB decision is final with respect to the question of whether or 999 not the Internet standards procedures have been followed. 1001 6.5.3 Questions of Applicable Procedure 1003 Further recourse is available only in cases in which the procedures 1004 themselves (i.e., the procedures described in this document) are 1005 claimed to be inadequate or insufficient to the protection of the 1006 rights of all parties in a fair and open Internet Standards Process. 1007 Claims on this basis may be made to the Internet Society Board of 1008 Trustees. The President of the Internet Society shall acknowledge 1009 such an appeal within two weeks, and shall at the time of 1010 acknowledgment advise the petitioner of the expected duration of the 1011 Trustees' review of the appeal. The Trustees shall review the 1012 situation in a manner of its own choosing and report to the IETF on 1013 the outcome of its review. 1015 The Trustees' decision upon completion of their review shall be final 1016 with respect to all aspects of the dispute. 1018 6.5.4 Appeals Procedure 1020 All appeals must include a detailed and specific description of the 1021 facts of the dispute. 1023 All appeals must be initiated within two months of the public 1024 knowledge of the action or decision to be challenged. 1026 At all stages of the appeals process, the individuals or bodies 1027 responsible for making the decisions have the discretion to define 1028 the specific procedures they will follow in the process of making 1029 their decision. 1031 In all cases a decision concerning the disposition of the dispute, 1032 and the communication of that decision to the parties involved, must 1033 be accomplished within a reasonable period of time. 1035 [NOTE: These procedures intentionally and explicitly do not 1036 establish a fixed maximum time period that shall be considered 1037 "reasonable" in all cases. The Internet Standards Process places a 1038 premium on consensus and efforts to achieve it, and deliberately 1039 foregoes deterministically swift execution of procedures in favor of 1040 a latitude within which more genuine technical agreements may be 1041 reached.] 1043 7. EXTERNAL STANDARDS AND SPECIFICATIONS 1045 Many standards groups other than the IETF create and publish 1046 standards documents for network protocols and services. When these 1047 external specifications play an important role in the Internet, it is 1048 desirable to reach common agreements on their usage -- i.e., to 1049 establish Internet Standards relating to these external 1050 specifications. 1052 There are two categories of external specifications: 1054 (1) Open Standards 1056 Various national and international standards bodies, such as ANSI, 1057 ISO, IEEE, and ITU-T, develop a variety of protocol and service 1058 specifications that are similar to Technical Specifications defined 1059 here. National and international groups also publish "implementors' 1060 agreements" that are analogous to Applicability Statements, capturing 1061 a body of implementation-specific detail concerned with the practical 1062 application of their standards. All of these are considered to be 1063 "open external standards" for the purposes of the Internet Standards 1064 Process. 1066 (2) Other Specifications 1068 Other proprietary specifications that have come to be widely used in 1069 the Internet may be treated by the Internet community as if they were 1070 a "standards". Such a specification is not generally developed in an 1071 open fashion, is typically proprietary, and is controlled by the 1072 vendor, vendors, or organization that produced it. 1074 7.1 Use of External Specifications 1076 To avoid conflict between competing versions of a specification, the 1077 Internet community will not standardize a specification that is 1078 simply an "Internet version" of an existing external specification 1079 unless an explicit cooperative arrangement to do so has been made. 1080 However, there are several ways in which an external specification 1081 that is important for the operation and/or evolution of the Internet 1082 may be adopted for Internet use. 1084 7.1.1 Incorporation of an Open Standard 1086 An Internet Standard TS or AS may incorporate an open external 1087 standard by reference. For example, many Internet Standards 1088 incorporate by reference the ANSI standard character set "ASCII" 1089 [ASCII]. Whenever possible, the referenced specification shall be 1090 available online. 1092 7.1.2 Incorporation of Other Specifications 1094 Other proprietary specifications may be incorporated by reference to 1095 a version of the specification as long as the proprietor meets the 1096 requirements of section 10. If the other proprietary specification 1097 is not widely and readily available, the IESG may request that it be 1098 published as an Informational RFC. 1100 The IESG generally should not favor a particular proprietary 1101 specification over technically equivalent and competing 1102 specification(s) by making any incorporated vendor specification 1103 "required" or "recommended". 1105 7.1.3 Assumption 1107 An IETF Working Group may start from an external specification and 1108 develop it into an Internet specification. This is acceptable if (1) 1109 the specification is provided to the Working Group in compliance with 1110 the requirements of section 10, and (2) change control has been 1111 conveyed to IETF by the original developer of the specification for 1112 the specification or for specifications derived from the original 1113 specification. 1115 8. NOTICES AND RECORD KEEPING 1117 Each of the organizations involved in the development and approval of 1118 Internet Standards shall publicly announce, and shall maintain a 1119 publicly accessible record of, every activity in which it engages, to 1120 the extent that the activity represents the prosecution of any part 1121 of the Internet Standards Process. For purposes of this section, the 1122 organizations involved in the development and approval of Internet 1123 Standards includes the IETF, the IESG, the IAB, all IETF Working 1124 Groups, and the Internet Society Board of Trustees. 1126 For IETF and Working Group meetings announcements shall be made by 1127 electronic mail to the IETF Announce mailing list and shall be made 1128 sufficiently far in advance of the activity to permit all interested 1129 parties to effectively participate. The announcement shall contain 1130 (or provide pointers to) all of the information that is necessary to 1131 support the participation of any interested individual. In the case 1132 of a meeting, for example, the announcement shall include an agenda 1133 that specifies the standards-related issues that will be discussed. 1135 The formal record of an organization's standards-related activity 1136 shall include at least the following: 1138 o the charter of the organization (or a defining document equivalent 1139 to a charter); o complete and accurate minutes of meetings; o the 1140 archives of Working Group electronic mail mailing lists; and o all 1141 written contributions from participants that pertain to the 1142 organization's standards-related activity. 1144 As a practical matter, the formal record of all Internet Standards 1145 Process activities is maintained by the IETF Secretariat, and is the 1146 responsibility of the IETF Secretariat except that each IETF Working 1147 Group is expected to maintain their own email list archive and must 1148 make a best effort to ensure that all traffic is captured and 1149 included in the archives. Also, the Working Group chair is 1150 responsible for providing the IETF Secretariat with complete and 1151 accurate minutes of all Working Group meetings. Internet-Drafts 1152 shall be archived by the IETF Secretariat for the sole purpose of 1153 preserving an historical record of Internet standards activity. 1155 9. VARYING THE PROCESS 1157 This document, which sets out the rules and procedures by which 1158 Internet Standards and related documents are made is itself a product 1159 of the Internet Standards Process (as a BCP, as described in section 1160 5). It replaces a previous version, and in time, is likely itself to 1161 be replaced. 1163 While, when published, this document represents the community's view 1164 of the proper and correct process to follow, and requirements to be 1165 met, to allow for the best possible Internet Standards and BCPs, it 1166 cannot be assumed that this will always remain the case. From time to 1167 time there may be a desire to update it, by replacing it with a new 1168 version. Updating this document uses the same open procedures as are 1169 used for any other BCP. 1171 In addition, there may be situations where following the procedures 1172 leads to a deadlock about a specific specification, or there may be 1173 situations where the procedures provide no guidance. In these cases 1174 it may be appropriate to invoke the variance procedure described 1175 below. 1177 9.1 The Variance Procedure 1179 Upon the recommendation of the responsible IETF Working Group (or, if 1180 no Working Group is constituted, upon the recommendation of an ad hoc 1181 committee), the IESG may enter a particular specification into, or 1182 advance it within, the standards track even though some of the 1183 requirements of this document have not or will not be met. The IESG 1184 may approve such a variance, however, only if it first determines 1185 that the likely benefits to the Internet community are likely to 1186 outweigh any costs to the Internet community that result from 1187 noncompliance with the requirements in this document. In exercising 1188 this discretion, the IESG shall at least consider (a) the technical 1189 merit of the specification, (b) the possibility of achieving the 1190 goals of the Internet Standards Process without granting a variance, 1191 (c) alternatives to the granting of a variance, (d) the collateral 1192 and precedential effects of granting a variance, and (e) the IESG's 1193 ability to craft a variance that is as narrow as possible. In 1194 determining whether to approve a variance, the IESG has discretion to 1195 limit the scope of the variance to particular parts of this document 1196 and to impose such additional restrictions or limitations as it 1197 determines appropriate to protect the interests of the Internet 1198 community. 1200 The proposed variance must detail the problem perceived, explain the 1201 precise provision of this document which is causing the need for a 1202 variance, and the results of the IESG's considerations including 1203 consideration of points (a) through (d) in the previous paragraph. 1204 The proposed variance shall be issued as an Internet Draft. The IESG 1205 shall then issue an extended Last-Call, of no less than 4 weeks, to 1206 allow for community comment upon the proposal. 1208 In a timely fashion after the expiration of the Last-Call period, the 1209 IESG shall make its final determination of whether or not to approve 1210 the proposed variance, and shall notify the IETF of its decision via 1211 electronic mail to the IETF Announce mailing list. If the variance 1212 is approved it shall be forwarded to the RFC Editor with a request 1213 that it be published as a BCP. 1215 This variance procedure is for use when a one-time waiving of some 1216 provision of this document is felt to be required. Permanent changes 1217 to this document shall be accomplished through the normal BCP 1218 process. 1220 The appeals process in section 6.5 applies to this process. 1222 9.2 Exclusions 1224 No use of this procedure may lower any specified delays, nor exempt 1225 any proposal from the requirements of openness, fairness, or 1226 consensus, nor from the need to keep proper records of the meetings 1227 and mailing list discussions. 1229 Specifically, the following sections of this document must not be 1230 subject of a variance: 5.1, 6.1, 6.1.1 (first paragraph), 6.1.2, 6.3 1231 (first sentence), 6.5 and 9. 1233 10. INTELLECTUAL PROPERTY RIGHTS 1235 10.1 General Policy 1237 In all matters of intellectual property rights and procedures, the 1238 intention is to benefit the Internet community and the public at 1239 large, while respecting the legitimate rights of others. 1241 10.2 Confidentiality Obligations 1243 No information or document that is subject to any requirement of 1244 confidentiality or any restriction on its dissemination may be 1245 submitted as a Contribution or otherwise considered in any part of 1246 the IETF Standards Process, and there must be no assumption of any 1247 confidentiality obligation with respect to any Contribution. Each 1248 Contributor agrees that any statement in a Contribution, whether 1249 generated automatically or otherwise, that states or implies that the 1250 Contribution is confidential or subject to any privilege, can be 1251 disregarded for all purposes, and will be of no force or effect. 1253 10.3 Standards Track Documents 1255 (A) Where any patents, patent applications, or other proprietary 1256 rights are known, or claimed, with respect to any specification on 1257 the standards track, and brought to the attention of the IESG, the 1258 IESG shall not advance the specification without including in the 1259 document a note indicating the existence of such rights, or claimed 1260 rights. Where implementations are required before advancement of a 1261 specification, only implementations that have, by statement of the 1262 implementors, taken adequate steps to comply with any such rights, or 1263 claimed rights, shall be considered for the purpose of showing the 1264 adequacy of the specification. 1266 (B) The IESG disclaims any responsibility for identifying the 1267 existence of or for evaluating the applicability of any claimed 1268 copyrights, patents, patent applications, or other rights in the 1269 fulfilling of the its obligations under (A), and will take no 1270 position on the validity or scope of any such rights. 1272 (C) Where the IESG knows of rights, or claimed rights under (A), the 1273 IETF Trust shall attempt to obtain from the claimant of such rights, 1274 a written assurance that upon approval by the IESG of the relevant 1275 Internet standards track specification(s), any party will be able to 1276 obtain the right to implement, use and distribute the technology or 1277 works when implementing, using or distributing technology based upon 1278 the specific specification(s) under openly specified, reasonable, 1279 non-discriminatory terms. The Working Group proposing the use of the 1280 technology with respect to which the proprietary rights are claimed 1281 may assist the IETF Trust in this effort. The results of this 1282 procedure shall not affect advancement of a specification along the 1283 standards track, except that the IESG may defer approval where a 1284 delay may facilitate the obtaining of such assurances. The results 1285 will, however, be recorded by the IETF Trust, and made available. 1286 The IESG may also direct that a summary of the results be included in 1287 any RFC published containing the specification. 1289 10.4 Determination of Reasonable and Non-discriminatory Terms 1291 The IESG will not make any explicit determination that the assurance 1292 of reasonable and non-discriminatory terms for the use of a 1293 technology has been fulfilled in practice. It will instead use the 1294 normal requirements for the advancement of Internet Standards to 1295 verify that the terms for use are reasonable. If the two unrelated 1296 implementations of the specification that are required to advance 1297 from Draft Standard to Internet Standard have been produced by 1298 different organizations or individuals or if the "significant 1299 implementation and successful operational experience" required to 1300 advance from Draft Standard to Standard has been achieved the 1301 assumption is that the terms must be reasonable and to some degree, 1302 non-discriminatory. This assumption may be challenged during the 1303 Last-Call period. 1305 11. Transition 1307 As a transition mechanism, RFCs with a Proposed Standard status are 1308 automatically reclassified as Draft Standard. RFCs which have held 1309 the status of Draft Standard for at least twenty-four (24) months are 1310 automatically reclassified as Internet Standard. 1312 12. Security Considerations 1314 This memo relates to the Internet Standards Process, not any 1315 particular technology. There are security considerations when 1316 adopting any technology, but there are no known issues of security 1317 with the Internet Standards Process. 1319 13. IANA Considerations 1321 This document does not require the IANA to take any action. 1323 14. Acknowledgements 1325 There have been a number of people involved with the development of 1326 the documents defining the IETF Standards Process over the years. 1327 The process was first described in RFC 1310 then revised in RFC 1602 1328 before the current effort (which relies heavily on its predecessors). 1330 Specific acknowledgments must be extended to Lyman Chapin, Phill 1331 Gross and Christian Huitema as the editors of the previous versions, 1332 to Jon Postel and Dave Crocker for their inputs to those versions, to 1333 Andy Ireland, Geoff Stewart, Jim Lampert, and Dick Holleman for their 1334 reviews of the legal aspects of the procedures described herein, and 1335 to John Stewart, Robert Elz and Steve Coya for their extensive input 1336 on the final version. 1338 In addition much of the credit for the refinement of the details of 1339 the IETF processes belongs to the many members of the various 1340 incarnations of the POISED Working Group. 1342 Most of the text in this document has been copied from RFC 2606 which 1343 was written by Scott O. Bradner. 1345 15. References 1347 15.1. Informative References 1349 [STD1] Postel, J., "Internet Official Protocol Standards", STD 1, 1350 USC/Information Sciences Institute, March 1996. 1352 [ASCII] ANSI, Coded Character Set -- 7-Bit American Standard Code 1353 for Information Interchange, ANSI X3.4-1986. 1355 [RFC1311] Postel, J., "Introduction to the STD Notes", RFC 1311, 1356 USC/Information Sciences Institute, March 1992. 1358 [RFC1796] Huitema, C., J. Postel, and S. Crocker "Not All RFCs are 1359 Standards", RFC 1796, April 1995. 1361 [RFC4844] Daigle, L., "The RFC Series and RFC Editor", RFC 4844, 1362 July 2007. 1364 Author's Address 1366 S. Moonesamy 1367 76, Ylang Ylang Avenue 1368 Quatre Bornes 1369 Mauritius 1371 Email: sm+ietf@elandsys.com 1373 Appendix A: Definitions of Terms 1375 IETF Area - A management division within the IETF. An Area consists 1376 of Working Groups related to a general topic such as routing. An 1377 Area is managed by one or two Area Directors. 1379 Area Director - The manager of an IETF Area. The Area Directors 1380 along with the IETF Chair comprise the Internet Engineering Steering 1381 Group (IESG). 1383 Internet Architecture Board (IAB) - An appointed group that assists 1384 in the management of the IETF standards process. 1386 Internet Engineering Steering Group (IESG) - A group comprised of the 1388 IETF Area Directors and the IETF Chair. The IESG is responsible for 1389 the management, along with the IAB, of the IETF and is the standards 1390 approval board for the IETF. 1392 interoperable - For the purposes of this document, "interoperable" 1393 means to be able to interoperate over a data communications path. 1395 Last-Call - A public comment period used to gage the level of 1396 consensus about the reasonableness of a proposed standards action. 1397 (see section 6.1.2) 1399 Appendix B: Glossary of Acronyms 1401 ANSI: American National Standards Institute 1402 ARPA: (U.S.) Advanced Research Projects Agency 1403 AS: Applicability Statement 1404 ASCII: American Standard Code for Information Interchange 1405 ITU-T: Telecommunications Standardization sector of the 1406 International Telecommunication Union (ITU), a UN 1407 treaty organization; ITU-T was formerly called CCITT. 1408 IAB: Internet Architecture Board 1409 IANA: Internet Assigned Numbers Authority 1410 IEEE: Institute of Electrical and Electronics Engineers 1411 ICMP: Internet Control Message Protocol 1412 IESG: Internet Engineering Steering Group 1413 IETF: Internet Engineering Task Force 1414 IP: Internet Protocol 1415 IRSG Internet Research Steering Group 1416 IRTF: Internet Research Task Force 1417 ISO: International Organization for Standardization 1418 ISOC: Internet Society 1419 MIB: Management Information Base 1420 OSI: Open Systems Interconnection 1421 TCP: Transmission Control Protocol 1422 TS: Technical Specification 1423 WWW: World Wide Web