idnits 2.17.1 draft-carpenter-rfc2026-practice-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 973. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 984. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 991. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 997. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 3 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 2, 2008) is 5775 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '5' on line 140 -- Looks like a reference, but probably isn't: '1' on line 753 -- Looks like a reference, but probably isn't: '4' on line 161 -- Obsolete informational reference (is this intentional?): RFC 1264 (Obsoleted by RFC 4794) -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) -- Obsolete informational reference (is this intentional?): RFC 3932 (Obsoleted by RFC 5742) -- Obsolete informational reference (is this intentional?): RFC 3978 (Obsoleted by RFC 5378) -- Obsolete informational reference (is this intentional?): RFC 3979 (Obsoleted by RFC 8179) -- Obsolete informational reference (is this intentional?): RFC 4071 (Obsoleted by RFC 8711) -- Obsolete informational reference (is this intentional?): RFC 4677 (Obsoleted by RFC 6722) -- Obsolete informational reference (is this intentional?): RFC 4844 (Obsoleted by RFC 8729) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 18 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Carpenter 3 Internet-Draft Univ. of Auckland 4 Intended status: Informational July 2, 2008 5 Expires: January 3, 2009 7 RFC 2026 in practice 8 draft-carpenter-rfc2026-practice-00 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on January 3, 2009. 35 Abstract 37 This document discusses how RFC 2026, the current description of the 38 IETF standards process, operates in practice. Its main purpose is to 39 document, for information only, how actual practice interprets the 40 formal rules. 42 Table of Contents 44 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 45 2. Detailed Commentary . . . . . . . . . . . . . . . . . . . . . 3 46 3. Security Considerations . . . . . . . . . . . . . . . . . . . 20 47 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 48 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 49 6. Change log . . . . . . . . . . . . . . . . . . . . . . . . . . 20 50 7. Informative References . . . . . . . . . . . . . . . . . . . . 21 51 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 22 52 Intellectual Property and Copyright Statements . . . . . . . . . . 23 54 1. Introduction 56 BCP 9 [RFC2026] has been the basis for the IETF standards process for 57 many years. This document is a review of how some aspects of the 58 process work in practice. The focus is mainly on how the community, 59 and the IESG in particular, interprets the formal rules in actual 60 practice. It is intended as a purely descriptive document and in no 61 way claims to change the formal rules. 63 Newcomers to the IETF should first read the Tao of the IETF 64 [RFC4677]. For a living guide to all IETF process documents, see 65 . While this 66 document mainly focuses on RFC 2026, many other documents form part 67 of the IETF rules. 69 Extracts from RFC 2026 are presented verbatim in quotation marks, 70 preceded and followed by the following markers: 71 "---------Begin Extract--------- 72 -----------End Extract---------" 74 Original pagination and administrative material have been ignored, 75 but the original section headings have been included where 76 convenient. 78 2. Detailed Commentary 80 "---------Begin Extract--------- 82 1.1 Internet Standards 83 ... 84 The Internet Standards Process described in this document is 85 concerned with all protocols, procedures, and conventions that are 86 used in or by the Internet, whether or not they are part of the 87 TCP/IP protocol suite. In the case of protocols developed and/or 88 standardized by non-Internet organizations, however, the Internet 89 Standards Process normally applies to the application of the protocol 90 or procedure in the Internet context, not to the specification of the 91 protocol itself. 93 -----------End Extract---------" 95 In practice, things are not as easily delimited as the above 96 paragraph suggests. Some IETF standards are quite interwoven with 97 standards from other organizations. Hence, liaison relationships 98 have become complex and important, dealing with mutually 99 interdependent standards. 101 "---------Begin Extract--------- 103 1.2 The Internet Standards Process 104 ... 105 o These procedures are explicitly aimed at recognizing and adopting 106 generally-accepted practices. Thus, a candidate specification 107 must be implemented and tested for correct operation and 108 interoperability by multiple independent parties and utilized in 109 increasingly demanding environments, before it can be adopted as 110 an Internet Standard. 112 -----------End Extract---------" 114 It is a fact that relatively few standards advance beyond the 115 Proposed Standard stage, and hence the mechanisms for documenting 116 interoperability are often not used. 118 "---------Begin Extract--------- 120 2.1 Requests for Comments (RFCs) 122 ... 124 The RFC series of documents on networking began in 1969 as part of 125 the original ARPA wide-area networking (ARPANET) project (see 126 Appendix A for glossary of acronyms). RFCs cover a wide range of 127 topics in addition to Internet Standards, from early discussion of 128 new research concepts to status memos about the Internet. RFC 129 publication is the direct responsibility of the RFC Editor, under the 130 general direction of the IAB. 132 -----------End Extract---------" 134 There is a general description in [RFC4844]. Today, the RFC Editor's 135 work for the IETF is also under the administrative management of the 136 IASA [RFC4071]. 138 "---------Begin Extract--------- 140 The rules for formatting and submitting an RFC are defined in [5]. 142 -----------End Extract---------" 144 Note that [I-D.rfc-editor-rfc2223bis] is applied today. 146 "---------Begin Extract--------- 147 The status of Internet protocol and service specifications is 148 summarized periodically in an RFC entitled "Internet Official 149 Protocol Standards" [1]. This RFC shows the level of maturity and 150 other helpful information for each Internet protocol or service 151 specification (see section 3). 153 -----------End Extract---------" 155 This was written before a hyperlinked index was available on line. 156 In recent years, this RFC has been updated very rarely. 158 "---------Begin Extract--------- 160 Some RFCs document Internet Standards. These RFCs form the 'STD' 161 subseries of the RFC series [4]. When a specification has been 162 adopted as an Internet Standard, it is given the additional label 163 "STDxxx", but it keeps its RFC number and its place in the RFC 164 series. (see section 4.1.3) 166 -----------End Extract---------" 168 Note that sometimes users do not readily know where to look for the 169 latest standard, since a DS may obsolete an STD, and a PS may 170 obsolete either. This is documented in the official RFC index and at 171 , but is 172 obscured at , where obsoleted 173 standards are not identified. 175 "---------Begin Extract--------- 177 Some RFCs standardize the results of community deliberations about 178 statements of principle or conclusions about what is the best way to 179 perform some operations or IETF process function. These RFCs form 180 the specification has been adopted as a BCP, it is given the 181 additional label "BCPxxx", but it keeps its RFC number and its place 182 in the RFC series. (see section 5) 184 Not all specifications of protocols or services for the Internet 185 should or will become Internet Standards or BCPs. Such non-standards 186 track specifications are not subject to the rules for Internet 187 standardization. Non-standards track specifications may be published 188 directly as "Experimental" or "Informational" RFCs at the discretion 189 of the RFC Editor in consultation with the IESG (see section 4.2). 191 -----------End Extract---------" 193 Factually, the RFC Editor does not have such discretion for IETF 194 documents - it's the IESG approval that defines the status of an IETF 195 RFC. IETF Experimental or Informational RFCs (see 196 ) are 197 distinct from independent submissions to the RFC Editor (see 198 [RFC4846]), which are processed under [RFC3932]. 200 "---------Begin Extract--------- 202 2.2 Internet-Drafts 204 During the development of a specification, draft versions of the 205 document are made available for informal review and comment by 206 placing them in the IETF's "Internet-Drafts" directory, which is 207 replicated on a number of Internet hosts. This makes an evolving 208 working document readily available to a wide audience, facilitating 209 the process of review and revision. 211 An Internet-Draft that is published as an RFC, or that has remained 212 unchanged in the Internet-Drafts directory for more than six months 213 without being recommended by the IESG for publication as an RFC, is 214 ... 216 -----------End Extract---------" 218 This is inaccurate. Expiry is inhibited when a draft enters IESG 219 consideration, not when it is approved. 221 "---------Begin Extract--------- 223 ... 224 simply removed from the Internet-Drafts directory. 226 -----------End Extract---------" 228 In practice today, 229 1. Drafts are also removed from the directory after publication as 230 an RFC. 231 2. All drafts are retained in the IETF archive for legal reasons, 232 such as for demonstrating claims of prior art. 233 3. Expired drafts are unofficially visible in many places. 234 4. Authors may request expired drafts to be removed from such 235 visibility (in some countries, this is a legal right). 237 It's also worth noting that the published RFC will not be textually 238 identical to the final version of the draft. Not only will the 239 boilerplate be finalized; the RFC Editor will also make editorial 240 corrections, and any minor technical changes following IESG review 241 will be applied. 243 "---------Begin Extract--------- 245 3.1 Technical Specification (TS) 247 A Technical Specification is any description of a protocol, service, 248 procedure, convention, or format. 250 -----------End Extract---------" 252 This has not been interpreted to limit a TS to defining a wire 253 protocol - it doesn't exclude APIs, for example (an API is a 254 convention), even though the IETF tends to avoid standardizing APIs. 255 It includes data definitions such as MIBs (a MIB is clearly a 256 format). It doesn't exclude a standard that only defines an IANA 257 registry (a registry is also a format). Yet all of these things have 258 led to debate in the IETF - for example we have seen debate about 259 whether a document that only defines a registry can become a Proposed 260 Standard. It is clear that a TS must be both implementable and 261 testable - but even this is subject to interpretation by the IESG. 262 Also see later comments on interoperability testing. 264 "---------Begin Extract--------- 266 3.2 Applicability Statement (AS) 268 An Applicability Statement specifies how, and under what 269 circumstances, one or more TSs may be applied to support a particular 270 Internet capability. An AS may specify uses for TSs that are not 271 Internet Standards, as discussed in Section 7. 273 An AS identifies the relevant TSs and the specific way in which they 274 are to be combined, and may also specify particular values or ranges 275 of TS parameters or subfunctions of a TS protocol that must be 276 implemented. An AS also specifies the circumstances in which the use 277 of a particular TS is required, recommended, or elective (see section 278 3.3). 280 An AS may describe particular methods of using a TS in a restricted 281 "domain of applicability", such as Internet routers, terminal 282 servers, Internet systems that interface to Ethernets, or datagram- 283 based database servers. 285 -----------End Extract---------" 287 The community rarely creates this sort of separate AS. The IETF has 288 been reluctant to put ASes on the standards track: they cannot be 289 implemented and tested. (See comments below on section 4.1.2.) 290 Today, an AS is typically included as a separate section in the 291 Technical Specification. 293 "---------Begin Extract--------- 295 The broadest type of AS is a comprehensive conformance specification, 297 -----------End Extract---------" 299 The IETF community has shown reluctance to be involved in conformance 300 specifications. 302 "---------Begin Extract--------- 304 commonly called a "requirements document", for a particular class of 305 Internet systems, such as Internet routers or Internet hosts. 307 -----------End Extract---------" 309 Today, we use the word "requirements" much more broadly, often as a 310 front-end document when a WG is starting out. 312 "---------Begin Extract--------- 314 An AS may not have a higher maturity level in the standards track 315 than any standards-track TS on which the AS relies (see section 4.1). 316 For example, a TS at Draft Standard level may be referenced by an AS 317 at the Proposed Standard or Draft Standard level, but not by an AS at 318 the Standard level. 320 -----------End Extract---------" 322 There is nothing specific to ASes in this rule; it is applied 323 globally wherever normative references occur. See comment below on 324 4.2.4. 326 "---------Begin Extract--------- 328 3.3 Requirement Levels 330 -----------End Extract---------" 332 This section provides the basis on which the IETF's normative 333 keywords [RFC2119] are built. 335 "---------Begin Extract--------- 337 ... 338 The "Official Protocol Standards" RFC (STD1) lists a general 339 requirement level for each TS, using the nomenclature defined in this 340 section. This RFC is updated periodically. In many cases, more 341 detailed descriptions of the requirement levels of particular 342 protocols and of individual features of the protocols will be found 343 in appropriate ASs. 345 -----------End Extract---------" 347 As noted, STD1 is rarely updated today. How this is really done in 348 the RFC archive is an operational matter. The concept and format of 349 STD1 long predated the availability of on-line hyperlinked 350 information. 352 "---------Begin Extract--------- 354 4. THE INTERNET STANDARDS TRACK 355 ... 356 4.1.1 Proposed Standard 357 ... 358 The IESG may require implementation and/or operational experience 359 prior to granting Proposed Standard status to a specification that 360 materially affects the core Internet protocols or that specifies 361 behavior that may have significant operational impact on the 362 Internet. 364 -----------End Extract---------" 366 Note that for many years the Routing Area essentially applied the 367 Draft Standard rules at Proposed Standard level [RFC1264], but 368 recently dropped this [RFC4794]. 370 "---------Begin Extract--------- 372 ... 373 Implementors should treat Proposed Standards as immature 374 specifications. It is desirable to implement them in order to gain 375 experience and to validate, test, and clarify the specification. 376 However, since the content of Proposed Standards may be changed if 377 problems are found or better solutions are identified, deploying 378 implementations of such standards into a disruption-sensitive 379 environment is not recommended. 381 -----------End Extract---------" 383 It is well known that to a large extent this warning has been 384 ignored, and that the Internet "runs on Proposed Standards." Also, 385 as the MIB doctors have observed, some types of spec may benefit from 386 being recycled at this level rather than being "promoted." In 387 reality today: 388 1. Proposed Standard (PS) is the preliminary level. 389 2. Implementors should be aware that a PS may be revised or even 390 withdrawn. 391 3. It is nevertheless common to use PS implementations 392 operationally. 393 4. Many documents spend their entire active life as PS. 394 5. Certain types of specification are likely to be recycled at PS as 395 they evolve rather than being promoted. (Sometimes this is 396 simply a result of complexity, but other times it's due to 397 intrinsic difficulties in interoperability testing and normative 398 dependencies.) 400 "---------Begin Extract--------- 402 4.1.2 Draft Standard 404 A specification from which at least two independent and interoperable 405 implementations from different code bases have been developed, and 406 for which sufficient successful operational experience has been 407 obtained, may be elevated to the "Draft Standard" level. For the 408 purposes of this section, "interoperable" means to be functionally 409 equivalent or interchangeable components of the system or process in 410 which they are used. If patented or otherwise controlled technology 411 is required for implementation, the separate implementations must 412 also have resulted from separate exercise of the licensing process. 413 Elevation to Draft Standard is a major advance in status, indicating 414 a strong belief that the specification is mature and will be useful. 416 The requirement for at least two independent and interoperable 417 implementations applies to all of the options and features of the 418 specification. 420 -----------End Extract---------" 422 At least four significant questions arise repeatedly in interpreting 423 this, which a WG or author may need to discuss with their AD while 424 preparing a document for DS status. 425 1. What is a "feature"? This can be interpreted in many ways. For 426 a TLV field is every separate type code a feature? Is every 427 normative keyword [RFC2119] a feature? 428 2. Is it acceptable if features A and B are shown to be 429 interoperable between implementations X and Y, and features C and 430 D are shown to be interoperable between implentations P and Q? 431 In that case we have shown interoperability of features A, B, C 432 and D but have not shown that any implementation successfully 433 interoperates with all of them. 435 At least for the strong security requirement of BCP 61 [RFC3365], 436 the Security Area, with the support of the IESG, has often 437 insisted that specifications include at least one mandatory-to- 438 implement strong security mechanism to guarantee universal 439 interoperability. 440 3. Is it acceptable if both implementations X and Y show 441 interoperability with implementation Q, but the implementor of Q 442 is not party to the tests and does not make any statements about 443 features supported? In other words Q has merely served as an 444 active mirror in the tests. 445 4. How should we handle the issue of "single-ended" technical 446 specifications such as data formats, where there is no new 447 protocol whose interoperation we can verify? A practical 448 solution for MIBs has been documented [RFC2438]. 450 "---------Begin Extract--------- 452 In cases in which one or more options or features 453 have not been demonstrated in at least two interoperable 454 implementations, the specification may advance to the Draft Standard 455 level only if those options or features are removed. 457 The Working Group chair is responsible for documenting the specific 458 implementations which qualify the specification for Draft or Internet 459 Standard status along with documentation about testing of the 460 interoperation of these implementations. The documentation must 461 include information about the support of each of the individual 462 options and features. This documentation should be submitted to the 463 Area Director with the protocol action request. (see Section 6) 465 -----------End Extract---------" 467 The database of reports collected over the years is at 468 . The quality is 469 highly variable and some are very sparse and uninformative. 471 "---------Begin Extract--------- 473 4.1.3 Internet Standard 474 ... 475 A specification that reaches the status of Standard is assigned a 476 number in the STD series while retaining its RFC number. 478 -----------End Extract---------" 480 There is sometimes also an acronym or mnemonic associated with an STD 481 designation, e.g. "SMTP" or "SNMP". However, there is no consistent 482 mechanism for assigning acronyms, and the STD numbers are not 483 associated with PS and DS documents that obsolete or update an STD 484 document. 486 "---------Begin Extract--------- 488 4.2.1 Experimental 490 The "Experimental" designation typically denotes a specification that 491 is part of some research or development effort. Such a specification 492 is published for the general information of the Internet technical 493 community and as an archival record of the work, subject only to 494 editorial considerations and to verification that there has been 495 adequate coordination with the standards process (see below). An 496 Experimental specification may be the output of an organized Internet 497 research effort (e.g., a Research Group of the IRTF), an IETF Working 498 Group, or it may be an individual contribution. 500 4.2.2 Informational 502 An "Informational" specification is published for the general 503 information of the Internet community, and does not represent an 504 Internet community consensus or recommendation. The Informational 505 designation is intended to provide for the timely publication of a 506 very broad range of responsible informational documents from many 507 sources, subject only to editorial considerations and to verification 508 that there has been adequate coordination with the standards process 509 (see section 4.2.3). 511 -----------End Extract---------" 513 The IESG has documented guidelines for classifying documents as 514 Informational vs Experimental at 515 . 517 In practice, some Informationals and Experimentals that are published 518 via IESG Approval are very close to being a TS and are evaluated 519 almost as carefully as a TS. They may also be precursors of BCPs in 520 areas where more operational experience is needed. 522 "---------Begin Extract--------- 524 Specifications that have been prepared outside of the Internet 525 community and are not incorporated into the Internet Standards 526 Process by any of the provisions of section 10 may be published as 527 Informational RFCs, with the permission of the owner and the 528 concurrence of the RFC Editor. 530 -----------End Extract---------" 532 This paragraph conflates "outside of the IETF process" and "outside 533 of the Internet community." Some specifications originate elsewhere 534 (for example, cryptographic algorithms). These are routinely 535 published as IESG-approved Informational RFCs, commonly sponsored by 536 an Area Director rather than being processed by a WG. See 537 . IAB and 538 IRTF documents are normally published as Informational or 539 Experimental too, without IESG approval [RFC4844]. Other 540 specifications, such as proprietary specifications or work that did 541 not find IETF sponsorship, are published as Informational or 542 Experimental RFCs after independent submission to the RFC Editor and 543 brief IESG review [RFC3932]. See [RFC4846] for a current 544 description. 546 "---------Begin Extract--------- 548 4.2.3 Procedures for Experimental and Informational RFCs 550 Unless they are the result of IETF Working Group action, documents 551 intended to be published with Experimental or Informational status 552 should be submitted directly to the RFC Editor. 554 -----------End Extract---------" 556 That's often not what happens. Many of them come via an AD through 557 the IESG because they are (for example) related to a recently closed 558 WG etc. These are processed and approved entirely within the IETF 559 . But as 560 noted, the independent submissions track is separate from the IETF 561 process. 563 "---------Begin Extract--------- 565 The RFC Editor will 566 publish any such documents as Internet-Drafts which have not already 567 been so published. 569 -----------End Extract---------" 571 That is inaccurate, i.e. they ask the authors to do so, except 572 possibly shortly prior to April 1st each year. 574 "---------Begin Extract--------- 576 In order to differentiate these Internet-Drafts 577 they will be labeled or grouped in the I-D directory so they are 578 easily recognizable. 580 -----------End Extract---------" 582 Not done in practice. 584 "---------Begin Extract--------- 586 The RFC Editor will wait two weeks after this 587 publication for comments before proceeding further. The RFC Editor 588 is expected to exercise his or her judgment concerning the editorial 589 suitability of a document for publication with Experimental or 590 Informational status, and may refuse to publish a document which, in 591 the expert opinion of the RFC Editor, is unrelated to Internet 592 activity or falls below the technical and/or editorial standard for 593 RFCs. 595 -----------End Extract---------" 597 The RFC Editor is assisted in this by an editorial board 598 . 600 "---------Begin Extract--------- 602 To ensure that the non-standards track Experimental and Informational 603 designations are not misused to circumvent the Internet Standards 604 Process, the IESG and the RFC Editor have agreed that the RFC Editor 605 will refer to the IESG any document submitted for Experimental or 606 Informational publication which, in the opinion of the RFC Editor, 607 may be related to work being done, or expected to be done, within the 608 IETF community. The IESG shall review such a referred document 609 within a reasonable period of time, and recommend either that it be 610 published as originally submitted or referred to the IETF as a 611 contribution to the Internet Standards Process. 613 -----------End Extract---------" 615 The current practice for this is defined in [RFC3932]; also see 616 [RFC4846]. 618 "---------Begin Extract--------- 620 4.2.4 Historic 622 A specification that has been superseded by a more recent 623 specification or is for any other reason considered to be obsolete is 624 assigned to the "Historic" level. (Purists have suggested that the 625 word should be "Historical"; however, at this point the use of 626 "Historic" is historical.) 628 Note: Standards track specifications normally must not depend on 629 other standards track specifications which are at a lower maturity 630 level or on non standards track specifications other than referenced 631 specifications from other standards bodies. (See Section 7.) 633 -----------End Extract---------" 635 The first paragraph has not been implemented consistently. In most 636 cases a standards track RFC that has been obsoleted by a more recent 637 version is not listed in the RFC Index as Historic. 639 The second paragraph is applied generally. Furthermore, a clear 640 distinction is now required between Normative and Informative 641 references. Also, the requirement for Normative references to be 642 published (i.e. not work in progress) is applied to all 643 specifications, not just the standards track. 645 Also note the procedures of [RFC3967] and [RFC4897] for allowing 646 normative reference to less mature documents. 648 "---------Begin Extract--------- 650 5. BEST CURRENT PRACTICE (BCP) RFCs 652 The BCP subseries of the RFC series is designed to be a way to 653 standardize practices and the results of community deliberations. A 654 BCP document is subject to the same basic set of procedures as 655 standards track documents and thus is a vehicle by which the IETF 656 community can define and ratify the community's best current thinking 657 on a statement of principle or on what is believed to be the best way 658 to perform some operations or IETF process function. 660 Historically Internet standards have generally been concerned with 661 the technical specifications for hardware and software required for 662 computer communication across interconnected networks. However, 663 since the Internet itself is composed of networks operated by a great 664 variety of organizations, with diverse goals and rules, good user 665 service requires that the operators and administrators of the 666 Internet follow some common guidelines for policies and operations. 667 While these guidelines are generally different in scope and style 668 from protocol standards, their establishment needs a similar process 669 for consensus building. 671 -----------End Extract---------" 673 It is sometimes unclear whether a given document should be standards 674 track, BCP or informational (and in the end, it may not really 675 matter). For example, how should the IESG classify a document which 676 recommends against a particular operational practice that has been 677 found to be damaging? It might amend a technical specification (by 678 removing a feature); it might limit the applicability of a protocol 679 (and therefore be an applicability statement); it might be a BCP 680 defining a "worst current practice"; or it might fit none of the 681 above. WGs or authors need to discuss this matter with their AD. 683 "---------Begin Extract--------- 685 While it is recognized that entities such as the IAB and IESG are 686 composed of individuals who may participate, as individuals, in the 687 technical work of the IETF, it is also recognized that the entities 688 themselves have an existence as leaders in the community. As leaders 689 in the Internet technical community, these entities should have an 690 outlet to propose ideas to stimulate work in a particular area, to 691 raise the community's sensitivity to a certain issue, to make a 692 statement of architectural principle, or to communicate their 693 thoughts on other matters. The BCP subseries creates a smoothly 694 structured way for these management entities to insert proposals into 695 the consensus-building machinery of the IETF while gauging the 696 community's view of that issue. 698 -----------End Extract---------" 700 Although it's not unknown for a BCP to have its origin in the IESG or 701 IAB, IETF consensus is still needed, as judged by the IESG. 703 "---------Begin Extract--------- 705 6.1.1 Initiation of Action 707 A specification that is intended to enter or advance in the Internet 708 standards track shall first be posted as an Internet-Draft (see 709 section 2.2) unless it has not changed since publication as an RFC. 710 It shall remain as an Internet-Draft for a period of time, not less 711 than two weeks, that permits useful community review, after which a 712 recommendation for action may be initiated. 714 A standards action is initiated by a recommendation by the IETF 715 Working group responsible for a specification to its Area Director, 716 copied to the IETF Secretariat or, in the case of a specification not 717 associated with a Working Group, a recommendation by an individual to 718 the IESG. 720 -----------End Extract---------" 722 In practice, individual submissions are recommended to and shepherded 723 by an AD, who brings them to the IESG just like a WG document. See 724 . 726 "---------Begin Extract--------- 728 6.1.3 Publication 730 If a standards action is approved, notification is sent to the RFC 731 Editor and copied to the IETF with instructions to publish the 732 specification as an RFC. The specification shall at that point be 733 removed from the Internet-Drafts directory. 735 -----------End Extract---------" 737 "At that point" refers to the moment of publication of the RFC. 739 "---------Begin Extract--------- 741 An official summary of standards actions completed and pending shall 742 appear in each issue of the Internet Society's newsletter. This 743 shall constitute the "publication of record" for Internet standards 744 actions. 746 -----------End Extract---------" 748 This is no longer done on paper. 750 "---------Begin Extract--------- 752 The RFC Editor shall publish periodically an "Internet Official 753 Protocol Standards" RFC [1], summarizing the status of all Internet 754 protocol and service specifications. 756 -----------End Extract---------" 758 As noted above, this has become infrequent. 760 "---------Begin Extract--------- 762 6.2 Advancing in the Standards Track 763 ... 764 Change of status shall result in republication of the specification 765 as an RFC, except in the rare case that there have been no changes at 766 all in the specification since the last publication. Generally, 767 desired changes will be "batched" for incorporation at the next level 768 in the standards track. However, deferral of changes to the next 769 standards action on the specification will not always be possible or 770 desirable; for example, an important typographical error, or a 771 technical error that does not represent a change in overall function 772 of the specification, may need to be corrected immediately. In such 773 cases, the IESG or RFC Editor may be asked to republish the RFC (with 774 a new number) with corrections, and this will not reset the minimum 775 time-at-level clock. 777 -----------End Extract---------" 779 Note that the RFC Editor maintains errata for published RFCs. 781 "---------Begin Extract--------- 782 When a standards-track specification has not reached the Internet 783 Standard level but has remained at the same maturity level for 784 twenty-four (24) months, and every twelve (12) months thereafter 785 until the status is changed, the IESG shall review the viability of 786 the standardization effort responsible for that specification and the 787 usefulness of the technology. Following each such review, the IESG 788 shall approve termination or continuation of the development effort, 789 at the same time the IESG shall decide to maintain the specification 790 at the same maturity level or to move it to Historic status. This 791 decision shall be communicated to the IETF by electronic mail to the 792 IETF Announce mailing list to allow the Internet community an 793 opportunity to comment. This provision is not intended to threaten a 794 legitimate and active Working Group effort, but rather to provide an 795 administrative mechanism for terminating a moribund effort. 797 -----------End Extract---------" 799 In practice, the IESG relies on working groups, or on initiatives by 800 members of the community, to propose promotion (or demotion) of 801 documents. A practical example of demotion is [RFC4450]. 803 "---------Begin Extract--------- 805 6.5 Conflict Resolution and Appeals 807 -----------End Extract---------" 809 It's possible to read this as applying only to IESG actions described 810 in this section 6. The IESG and IAB have preferred to read it as 811 applying to any IESG decision whatever. 813 "---------Begin Extract--------- 815 8. NOTICES AND RECORD KEEPING 816 ... 817 As a practical matter, the formal record of all Internet Standards 818 Process activities is maintained by the IETF Secretariat, and is the 819 responsibility of the IETF Secretariat except that each IETF Working 820 Group is expected to maintain their own email list archive and must 821 make a best effort to ensure that all traffic is captured and 822 included in the archives. Also, the Working Group chair is 823 responsible for providing the IETF Secretariat with complete and 824 accurate minutes of all Working Group meetings. Internet-Drafts that 825 have been removed (for any reason) from the Internet-Drafts 826 directories shall be archived by the IETF Secretariat for the sole 827 purpose of preserving an historical record of Internet standards 828 activity and thus are not retrievable except in special 829 circumstances. 831 -----------End Extract---------" 833 See comments on section 2.2. 835 "---------Begin Extract--------- 837 10. INTELLECTUAL PROPERTY RIGHTS 839 -----------End Extract---------" 841 This section is superseded by [RFC3978] and [RFC3979]. 843 3. Security Considerations 845 This document has no security implications for the Internet. 847 4. IANA Considerations 849 This document requires no action by the IANA. 851 5. Acknowledgements 853 Useful comments on earlier versions of this document were made by 854 Eric Gray, Luc Pardon, Pekka Savola, Magnus Westerlund, Jeff 855 Hutzelman, Mike Heard, Alfred Hoenes, Spencer Dawkins, Jari Arkko, 856 Sam Hartman and others. 858 This document was produced using the xml2rfc tool [RFC2629]. 860 6. Change log 862 draft-carpenter-rfc2026-practice-00: Back as a draft again when IONs 863 abolished 865 ion-2026-practice: Updated for IETF and IESG comments, 2007-10-08 867 ion-2026-practice: IONized version limited to factual description, 868 2007-06-27 870 draft-carpenter-rfc2026-critique-03: Clarifications and editorial 871 updates, 2007-04-20 873 draft-carpenter-rfc2026-critique-02: Changed title, changed tone from 874 critique to commentary, removed purely editorial comments, included 875 further substantive comments, 2006-08-10 877 draft-carpenter-rfc2026-critique-01: reduced personal statement, 878 included feedback comments, 2006-04-11 880 draft-carpenter-rfc2026-critique-00: original version, 2006-02-24 882 7. Informative References 884 [I-D.rfc-editor-rfc2223bis] 885 Reynolds, J. and R. Braden, "Instructions to Request for 886 Comments (RFC) Authors", draft-rfc-editor-rfc2223bis-08 887 (work in progress), July 2004. 889 [RFC1264] Hinden, R., "Internet Engineering Task Force Internet 890 Routing Protocol Standardization Criteria", RFC 1264, 891 October 1991. 893 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 894 3", BCP 9, RFC 2026, October 1996. 896 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 897 Requirement Levels", BCP 14, RFC 2119, March 1997. 899 [RFC2438] O'Dell, M., Alvestrand, H., Wijnen, B., and S. Bradner, 900 "Advancement of MIB specifications on the IETF Standards 901 Track", BCP 27, RFC 2438, October 1998. 903 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 904 June 1999. 906 [RFC3365] Schiller, J., "Strong Security Requirements for Internet 907 Engineering Task Force Standard Protocols", BCP 61, 908 RFC 3365, August 2002. 910 [RFC3932] Alvestrand, H., "The IESG and RFC Editor Documents: 911 Procedures", BCP 92, RFC 3932, October 2004. 913 [RFC3967] Bush, R. and T. Narten, "Clarifying when Standards Track 914 Documents may Refer Normatively to Documents at a Lower 915 Level", BCP 97, RFC 3967, December 2004. 917 [RFC3978] Bradner, S., "IETF Rights in Contributions", BCP 78, 918 RFC 3978, March 2005. 920 [RFC3979] Bradner, S., "Intellectual Property Rights in IETF 921 Technology", BCP 79, RFC 3979, March 2005. 923 [RFC4071] Austein, R. and B. Wijnen, "Structure of the IETF 924 Administrative Support Activity (IASA)", BCP 101, 925 RFC 4071, April 2005. 927 [RFC4450] Lear, E. and H. Alvestrand, "Getting Rid of the Cruft: 928 Report from an Experiment in Identifying and Reclassifying 929 Obsolete Standards Documents", RFC 4450, March 2006. 931 [RFC4677] Hoffman, P. and S. Harris, "The Tao of IETF - A Novice's 932 Guide to the Internet Engineering Task Force", RFC 4677, 933 September 2006. 935 [RFC4794] Fenner, B., "RFC 1264 Is Obsolete", RFC 4794, 936 December 2006. 938 [RFC4844] Daigle, L. and Internet Architecture Board, "The RFC 939 Series and RFC Editor", RFC 4844, July 2007. 941 [RFC4846] Klensin, J. and D. Thaler, "Independent Submissions to the 942 RFC Editor", RFC 4846, July 2007. 944 [RFC4897] Klensin, J. and S. Hartman, "Handling Normative References 945 to Standards-Track Documents", BCP 97, RFC 4897, 946 June 2007. 948 Author's Address 950 Brian Carpenter 951 Department of Computer Science 952 University of Auckland 953 PB 92019 954 Auckland, 1142 955 New Zealand 957 Email: brian.e.carpenter@gmail.com 959 Full Copyright Statement 961 Copyright (C) The IETF Trust (2008). 963 This document is subject to the rights, licenses and restrictions 964 contained in BCP 78, and except as set forth therein, the authors 965 retain all their rights. 967 This document and the information contained herein are provided on an 968 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 969 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 970 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 971 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 972 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 973 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 975 Intellectual Property 977 The IETF takes no position regarding the validity or scope of any 978 Intellectual Property Rights or other rights that might be claimed to 979 pertain to the implementation or use of the technology described in 980 this document or the extent to which any license under such rights 981 might or might not be available; nor does it represent that it has 982 made any independent effort to identify any such rights. Information 983 on the procedures with respect to rights in RFC documents can be 984 found in BCP 78 and BCP 79. 986 Copies of IPR disclosures made to the IETF Secretariat and any 987 assurances of licenses to be made available, or the result of an 988 attempt made to obtain a general license or permission for the use of 989 such proprietary rights by implementers or users of this 990 specification can be obtained from the IETF on-line IPR repository at 991 http://www.ietf.org/ipr. 993 The IETF invites any interested party to bring to its attention any 994 copyrights, patents or patent applications, or other proprietary 995 rights that may cover technology that may be required to implement 996 this standard. Please address the information to the IETF at 997 ietf-ipr@ietf.org.