📄 rfc1310.txt
字号:
cognizant Working Group, a document that is expected to enter or advance in the Internet standardization process shall be made available as an Internet Draft. It shall remain as an Internet Draft for a period of time that permits useful community review, at least two weeks, before submission to the IESG. An Internet Draft that is published as an RFC is removed from the Internet Draft directory. A document that has remained unchanged in the Internet Drafts directory for more than six months without being recommended by the IESG for publication as an RFC is simply removed from the Internet Draft directory. At any time, anIAB [Page 6] RFC 1310 Internet Standards Process March 1992 Internet Draft may be replace by a more recent version of the same specification, restarting the six-month timeout period. An Internet Draft is NOT a means of "publishing" a specification; specifications are published through the RFC mechanism described in the next section. Internet Drafts have no formal status, and are not part of the permanent archival record of Internet activity, and they are subject to change or removal at any time. Under no circumstances should an Internet Draft be referenced by any paper, report, or Request for Proposal. 2.5. Internet Assigned Number Authority (IANA) Many protocol specifications include numbers, keywords, and other parameters that must be uniquely assigned. Examples include version numbers, protocol numbers, port numbers, and MIB numbers. The IAB has delegated to the Internet Assigned Numbers Authority (IANA) the task of assigning such protocol parameters for the Internet. The IANA publishes tables of all currently assigned numbers and parameters in RFCs titled "Assigned Numbers" [8]. Each category of assigned numbers typically arises from some protocol that is on the standards track or is an Internet Standard. For example, TCP port numbers are assigned because TCP is a Standard. A particular value within a category may be assigned in a variety of circumstances; the specification requiring the parameter may be in the standards track, it may be Experimental, or it may be private. Chaos could result from accidental conflicts of parameter values, so we urge that every protocol parameter, for either public or private usage, be explicitly assigned by the IANA. Private protocols often become public. Programmers are often tempted to choose a "random" value, or guess the next unassigned value of a parameter; both are hazardous. The IANA is tasked to avoid frivolous assignments and to distinguish different assignments uniquely. The IANA accomplishes both goals by requiring a technical description of each protocol or service to which a value is to be assigned. Judgment on the adequacy of the description resides with the IANA. In the case of a standards track or Experimental protocol, the corresponding technical specifications provide the required documentation for IANA. For a proprietary protocol, the IANA will keep confidential any writeup that is supplied, but at least a short (2 page) writeup is still required for an assignment. To contact the IANA for information or to request a number,IAB [Page 7] RFC 1310 Internet Standards Process March 1992 keyword or parameter assignment send an email message to "iana@isi.edu". 2.6. Review and Approval A standards action -- entering a particular specification into, or advancing it within, the standards track -- shall be recommended to the appropriate IETF Area Director, or to the Chairman of the IETF, by the individual or group that is responsible for the specification. Usually, the recommendation will come from an IETF Working Group. The Area Director or IETF chairman, in consultation with the IESG, shall determine if an independent technical review of the specification is required, and shall commission one if necessary. When a specification is sufficiently important in terms of its potential impact on the Internet or on the suite of Internet protocols, the IESG shall form a special review and analysis committee to prepare an evaluation of the specification. Such a committee is commissioned to provide an objective basis for agreement within the Internet community that the specification is ready for advancement. Furthermore, when the criteria for advancement along the standards track for an important class of specifications (e.g., routing protocols [6]) are not universally recognized, the IESG shall commission the development and publication of category-specific acceptance criteria. The IESG shall determine whether a specification satisfies the applicable criteria for the recommended action (see Sections 3.2 and 3.3 of this document) and shall communicate its findings to the IETF to permit a final review by the general Internet community. This IETF notification shall be via electronic mail to the IETF mailing list; in addition, there will often be a presentation or statement by the appropriate working group or Area Director during an IETF plenary meeting. Any significant issues that have not been resolved satisfactorily during the development of the specification may be raised at this time for final resolution by the IESG. The IESG shall communicate to the IAB its recommendation for action, with a citation to the most current version of the document. The IETF shall be notified by email of any such recommendation. If the IAB finds a significant problem, or needs clarification on a particular point, it shall resolve the matter with the Working Group and its chairperson and/or the document author, with the assistance and concurrence of the IESG and the relevant IETF Area Director.IAB [Page 8] RFC 1310 Internet Standards Process March 1992 Following IAB approval and any necessary editorial work, the RFC Editor shall publish the specification as an RFC. The specification shall then be removed from the Internet Drafts directory. 2.7. Entering the Standards Track A specification that is potentially an Internet Standard may originate from: (a) an IAB-sponsored effort (typically an IETF Working Group), (b) independent activity by individuals, or (c) an external organization. In cases (b) and (c), the work might be tightly integrated with the work of an existing IETF Working Group, or it might be offered for standardization without prior IETF involvement. In most cases, a specification resulting from an effort that took place outside of an IETF Working Group context will be submitted to an appropriate Working Group for evaluation and refinement; if necessary, an appropriate Working Group will be created. For externally-developed specifications that are well-integrated with existing Working Group efforts, a Working Group is assumed to afford adequate community review of the accuracy and applicability of the specification. If a Working Group is unable to resolve all technical and usage questions, additional independent review may be necessary. Such reviews may be done within a Working Group context, or by an ad hoc review committee established specifically for that purpose. It is the responsibility of the appropriate IETF Area Director to determine what, if any, review of an external specification is needed and how it shall be conducted. 2.8. Advancing in the Standards Track A specification shall remain at the Proposed Standard level for at least 6 months and at the Draft Standard level for at least 4 months. A specification may be (indeed, is likely to be) revised as it advances through the standards track. At each stage, the IESG shall determine the scope and significance of the revision to the specification, and, if necessary and appropriate, modify the recommended action. Minor revisions are expected, and they will not affect advancement through the standards track. A significant revision may require that the specification accumulate moreIAB [Page 9] RFC 1310 Internet Standards Process March 1992 experience at its current maturity level before progressing. Finally, if the specification has been changed very significantly, the IESG may decide to treat the revision as if it were a new document, re-entering the standards track at the beginning. A specification that has not reached the maturity level of Standard within twenty-four months of first becoming a Proposed Standard shall be reviewed for viability by the IESG, which shall recommend either termination or continuation of the development effort to the IAB. Such a recommendation shall be communicated to the IETF via electronic mail to the IETF mailing list, to allow the Internet community an opportunity to comment. This provision is not intended to threaten legitimate and active Working Group efforts, but rather to provide an administrative mechanism for terminating a moribund effort. 2.9. Revising a Standard A recommendation to revise an established Internet Standard shall be evaluated by the IESG with respect to the operational impact of introducing a new version while the previous version is still in use. If the IESG accepts the recommendation, the new version must progress through the full Internet standardization process as if it were a completely new specification. Once the new version has reached the Standard level, it may immediately replace the previous version. In some cases, both versions may remain as Internet Standards to honor the requirements of an installed base; however, the relationship between the previous and the new versions must be explicitly stated in the text of the new version or in another appropriate document (e.g., an Applicability Statement; see Section 3.1.2).3. NOMENCLATURE 3.1. Types of Specifications The specifications subject to the Internet standardization process fall into two categories: Technical Specifications (TS) and Applicability Statements (AS). 3.1.1. Technical Specification (TS) A Technical Specification is any description of a protocol, service, procedure, convention, or format. It may completely describe all of the relevant aspects of its subject, or it may leave one or more parameters or options unspecified. A TS may be completely self-contained, or it may incorporate materialIAB [Page 10] RFC 1310 Internet Standards Process March 1992 from other specifications by reference to other documents (which may or may not be Internet Standards). A TS shall include a statement of its scope and the general intent for its use (domain of applicability). Thus, a TS that is inherently specific to a particular context shall contain a statement to that effect. However, a TS does not specify requirements for its use within the Internet; these requirements, which depend on the particular context in which the TS is incorporated by different system configurations, is defined by an Applicability Statement. 3.1.2. Applicability Statement (AS) An Applicability Statement specifies how, and under what circumstances, one or more TSs are to be applied to support a particular Internet capability. An AS may specify uses for TSs that are not Internet Standards, as discussed in Section 4. An AS identifies the relevant TSs and the specific way in which they are to be combined, and may also specify particular values or ranges of TS parameters or subfunctions of a TS protocol that must be implemented. An AS also specifies the circumstances in which the use of a particular TS is required, recommended, or elective. An AS may describe particular methods of using a TS in a restricted "domain of applicability", such as Internet routers, terminal servers, Internet systems that interface to Ethernets, or datagram-based database servers. The broadest type of AS is a comprehensive conformance specification, commonly called a "requirements document", for a particular class of Internet systems [3,4,5], such as Internet routers or Internet hosts. An AS may not have a higher maturity level in the standards track than any TS to which the AS applies. For example, a TS at Draft Standard level may be referenced by an AS at the Proposed Standard or Draft Standard level, but not an AS at the Standard level. Like a TS, an AS does not come into effect until it reaches Standard level. Although TSs and ASs are conceptually separate, in practice an Internet Standard RFC may include elements of both an AS and one or more TSs in a single document. For example, Technical Specifications that are developed specifically and exclusively for some particular domain of applicability, e.g., for mail serverIAB [Page 11] RFC 1310 Internet Standards Process March 1992 hosts, often contain within a single specification all of the relevant AS and TS information. In such cases, no useful purpose would be served by deliberately distributing the information among several documents just to preserve the formal AS/TS distinction. However, a TS that is likely to apply to more than one domain of applicability should be developed in a modular fashion, to facilitate its incorporation by multiple ASs. 3.2. Standards Track Maturity Levels ASs and TSs go through stages of development, testing, and acceptance. Within the Internet standards process, these stages are formally labeled "maturity levels". This section describes the maturity levels and the expected characteristics of specifications at each level. The general procedures for developing a specification and processing it through the maturity levels along the standards track were discussed in Section 2 above. 3.2.1. Proposed Standard The entry-level maturity for the standards track is "Proposed Standard". A Proposed Standard specification is generally⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -