Internet Engineering Task Force (IETF) R. Housley
Request for Comments: 6410 Vigil Security
BCP: 9 D. Crocker
Updates: 2026 Brandenburg InternetWorking
Category: Best Current Practice E. Burger
ISSN: 2070-1721 Georgetown University
October 2011
Internet Engineering Task Force (IETF) R. Housley
Request for Comments: 6410 Vigil Security
BCP: 9 D. Crocker
Updates: 2026 Brandenburg InternetWorking
Category: Best Current Practice E. Burger
ISSN: 2070-1721 Georgetown University
October 2011
Reducing the Standards Track to Two Maturity Levels
将标准跟踪减少到两个成熟度级别
Abstract
摘要
This document updates the Internet Engineering Task Force (IETF) Standards Process defined in RFC 2026. Primarily, it reduces the Standards Process from three Standards Track maturity levels to two.
本文件更新了RFC 2026中定义的互联网工程任务组（IETF）标准流程。首先，它将标准流程从三个标准跟踪成熟度级别减少到两个。
Status of This Memo
关于下段备忘
This memo documents an Internet Best Current Practice.
本备忘录记录了互联网最佳实践。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on BCPs is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关BCP的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6410.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6410.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
This document changes the Internet Standards Process defined in RFC 2026 [1]. In recent years, the Internet Engineering Task Force (IETF) witnessed difficulty advancing documents through the maturity levels: Proposed Standard, Draft Standard, and finally Standard. These changes are designed to simplify the Standards Process and reduce impediments to standards progression while preserving the most important benefits of the IETF engineering approach. In addition, the requirement for annual review of Standards Track documents that have not reached the top of the maturity ladder is removed from the Internet Standards Process.
本文件更改了RFC 2026[1]中定义的互联网标准流程。近年来，互联网工程任务组（IETF）见证了在成熟度级别上推进文档的困难：建议标准、标准草案和最终标准。这些变更旨在简化标准过程，减少标准进展的障碍，同时保留IETF工程方法的最重要优点。此外，对尚未达到成熟度阶梯顶端的标准跟踪文件进行年度审查的要求已从互联网标准流程中删除。
Over the years, there have been many proposals for refining the Internet Standards Process to reduce impediments to standards progression. During May 2010, the Internet Engineering Steering Group (IESG) discussed many of these proposals. Then, a plenary discussion at IETF 78 in July 2010 demonstrated significant support for transition from a three-tier maturity ladder to one with two tiers.
多年来，有许多关于改进互联网标准过程以减少标准进展障碍的建议。2010年5月，互联网工程指导小组（IESG）讨论了其中许多提案。然后，2010年7月IETF 78的一次全体讨论表明了对从三层成熟度阶梯过渡到两层成熟度阶梯的重大支持。
In the Internet Standards Process, experience with a Proposed Standard is expected to motivate revisions that clarify, modify, enhance, or remove features. However, in recent years, the vast majority of Standards Track documents are published as Proposed Standards and never advance to a higher maturity level. Very few specifications have advanced on the maturity ladder in the last decade. Changing the Internet Standards Process from three maturity levels to two is intended to create an environment where lessons from implementation and deployment experience are used to improve specifications.
在互联网标准制定过程中，对拟定标准的经验预计将推动修订，以澄清、修改、增强或删除特征。然而，近年来，绝大多数标准跟踪文档都是作为建议的标准发布的，从未升级到更高的成熟度级别。在过去十年中，在成熟度阶梯上进步的规范很少。将Internet标准流程从三个成熟度级别更改为两个成熟度级别，旨在创建一个环境，利用实施和部署经验中的经验教训改进规范。
The primary aspect of this change is to revise the requirements for advancement beyond Proposed Standard. RFC 2026 [1] requires a report that documents interoperability between at least two implementations from different code bases as an interim step ("Draft Standard") before a specification can be advanced further to the third and final maturity level ("Standard") based on widespread deployment and use. In contrast, this document requires measuring interoperability through widespread deployment of multiple implementations from different code bases, thus condensing the two separate metrics into one.
这一变化的主要方面是修订超出拟议标准的晋升要求。RFC 2026[1]需要一份报告，记录来自不同代码库的至少两个实现之间的互操作性，作为过渡步骤（“标准草案”），然后才能基于广泛的部署和使用将规范进一步提升到第三个也是最终的成熟度级别（“标准”）。相反，本文档要求通过广泛部署来自不同代码库的多个实现来度量互操作性，从而将两个单独的度量浓缩为一个。
The result of this change is expected to be maturity-level advancement based on achieving widespread deployment of quality specifications. Additionally, the change will result in the incorporation of lessons from implementation and deployment
这一变化的结果预计将是在广泛部署质量规范的基础上提高成熟度级别。此外，这一变化将导致纳入实施和部署的经验教训
experience, and recognition that protocols are improved by removing complexity associated with unused features.
经验，以及通过消除与未使用功能相关的复杂性来改进协议的认识。
In RFC 2026 [1], widespread deployment is essentially the metric used for advancement from Draft Standard to Standard. The use of this same metric for advancement beyond Proposed Standard means that there is no longer a useful distinction between the top two tiers of the maturity ladder. Thus, the maturity ladder is reduced to two tiers.
在RFC 2026[1]中，广泛部署基本上是用于从草案标准升级到标准的度量标准。使用相同的指标来衡量是否超出拟议标准意味着在成熟度阶梯的前两层之间不再存在有用的区别。因此，成熟度阶梯减少到两层。
In addition, RFC 2026 [1] requires annual review of specifications that have not achieved the top maturity level. This review is no longer required.
此外，RFC 2026[1]要求对尚未达到最高成熟度水平的规范进行年度审查。不再需要进行这种审查。
This document replaces the three-tier maturity ladder defined in RFC 2026 [1] with a two-tier maturity ladder. Specifications become Internet Standards through a set of two maturity levels known as the "Standards Track". These maturity levels are "Proposed Standard" and "Internet Standard".
本文件将RFC 2026[1]中定义的三层到期阶梯替换为两层到期阶梯。规范通过一组称为“标准轨道”的两个成熟度级别成为互联网标准。这些成熟度级别是“建议标准”和“互联网标准”。
A specification may be, and indeed, is likely to be, revised as it advances from Proposed Standard to Internet Standard. When a revised specification is proposed for advancement to Internet Standard, the IESG shall determine the scope and significance of the changes to the specification, and, if necessary and appropriate, modify the recommended action. Minor revisions and the removal of unused features are expected, but a significant revision may require that the specification accumulate more experience at Proposed Standard before progressing.
随着规范从提议的标准发展到互联网标准，规范可能会被修订，事实上，也可能会被修订。当建议修订规范以提高互联网标准时，IESG应确定规范变更的范围和重要性，并在必要和适当的情况下修改建议措施。预计会进行较小的修订并删除未使用的特性，但重大修订可能要求规范在进展之前积累更多的拟定标准经验。
The stated requirements for Proposed Standard are not changed; they remain exactly as specified in RFC 2026 [1]. No new requirements are introduced; no existing published requirements are relaxed.
拟定标准的规定要求未变更；它们完全符合RFC 2026[1]中的规定。没有提出新的要求；没有放松现有的已发布要求。
This maturity level is a merger of Draft Standard and Standard as specified in RFC 2026 [1]. The chosen name avoids confusion between "Draft Standard" and "Internet-Draft".
该成熟度水平是标准草案和RFC 2026[1]中规定的标准的合并。所选名称避免了“标准草案”和“互联网草案”之间的混淆。
The characterization of an Internet Standard remains as described in RFC 2026 [1], which says:
互联网标准的特征仍如RFC 2026[1]所述，其中规定：
An Internet Standard is characterized by a high degree of technical maturity and by a generally held belief that the specified protocol or service provides significant benefit to the Internet community.
互联网标准的特点是技术高度成熟，并且普遍认为指定的协议或服务为互联网社区提供了重大利益。
The IESG, in an IETF-wide Last Call of at least four weeks, confirms that a document advances from Proposed Standard to Internet Standard. The request for reclassification is sent to the IESG along with an explanation of how the criteria have been met. The criteria are:
IESG在IETF范围内至少四周的最后一次通话中确认，文件从提议的标准发展到互联网标准。重新分类的请求连同如何满足标准的解释一起发送给IESG。这些准则是：
(1) There are at least two independent interoperating implementations with widespread deployment and successful operational experience.
(1) 至少有两个独立的互操作实现，具有广泛的部署和成功的操作经验。
(2) There are no errata against the specification that would cause a new implementation to fail to interoperate with deployed ones.
(2) 规范中没有会导致新实现无法与已部署实现互操作的勘误表。
(3) There are no unused features in the specification that greatly increase implementation complexity.
(3) 规范中没有未使用的特性会大大增加实现的复杂性。
(4) If the technology required to implement the specification requires patented or otherwise controlled technology, then the set of implementations must demonstrate at least two independent, separate and successful uses of the licensing process.
(4) 如果实施本规范所需的技术需要专利技术或其他受控技术，则实施集必须证明至少两个独立、独立和成功地使用了许可过程。
After review and consideration of significant errata, the IESG will perform an IETF-wide Last Call of at least four weeks on the requested reclassification. If there is consensus for reclassification, the RFC will be reclassified without publication of a new RFC.
在审查和考虑重大勘误表后，IESG将对请求的重新分类进行至少四周的IETF范围内的最后一次呼叫。如果就重新分类达成共识，则将重新分类RFC，而不公布新的RFC。
As stated in RFC 2026 [1], in a timely fashion after the expiration of the Last Call period, the IESG shall make its final determination and notify the IETF of its decision via electronic mail to the IETF Announce mailing list. No changes are made to Section 6.1.2 of RFC 2026 [1].
如RFC 2026[1]所述，在最后一次通话结束后，IESG应及时做出最终决定，并通过电子邮件向IETF公告邮件列表通知IETF其决定。RFC 2026[1]第6.1.2节未作任何更改。
Any protocol or service that is currently at the Proposed Standard maturity level remains so.
目前处于建议的标准成熟度级别的任何协议或服务仍然如此。
Any protocol or service that is currently at the Standard maturity level shall be immediately reclassified as an Internet Standard.
目前处于标准成熟度水平的任何协议或服务应立即重新归类为互联网标准。
Any protocol or service that is currently at the abandoned Draft Standard maturity level will retain that classification, absent explicit actions. Two possible actions are available:
目前处于废弃草案标准成熟度级别的任何协议或服务都将保留该分类，没有明确的操作。有两种可能的操作：
(1) A Draft Standard may be reclassified as an Internet Standard as soon as the criteria in Section 2.2 are satisfied.
(1) 一旦满足第2.2节中的标准，标准草案可重新归类为互联网标准。
(2) At any time after two years from the approval of this document as a BCP, the IESG may choose to reclassify any Draft Standard document as Proposed Standard.
(2) 在本文件作为BCP获得批准两年后的任何时候，IESG可选择将任何标准草案重新归类为拟定标准。
In practice, the annual review of Proposed Standard and Draft Standard documents after two years (called for in RFC 2026 [1]) has not taken place. Lack of this review has not revealed any ill effects on the Internet Standards Process. As a result, the requirement for this review is dropped. No review cycle is imposed on Standards Track documents at any maturity level.
实际上，两年后（RFC 2026[1]中要求）未对拟定标准和标准文件草案进行年度审查。缺乏这一审查并没有显示出对互联网标准进程的任何不良影响。因此，取消了该审查的要求。任何成熟度级别的标准跟踪文档都没有审查周期。
Testing for interoperability is a long tradition in the development of Internet protocols and remains important for reliable deployment of services. The IETF Standards Process no longer requires a formal interoperability report, recognizing that deployment and use is sufficient to show interoperability.
互操作性测试是Internet协议开发中的一项长期传统，对于可靠部署服务仍然很重要。IETF标准过程不再需要正式的互操作性报告，认识到部署和使用足以显示互操作性。
Although no longer required by the IETF Standards Processes, RFC 5657 [2] can be helpful to conduct interoperability testing.
尽管IETF标准过程不再要求RFC 5657[2]，但它有助于进行互操作性测试。
This document does not directly affect the security of the Internet.
本文件不会直接影响互联网的安全。
A two-tier Standards Track has been proposed many times. Spencer Dawkins, Charlie Perkins, and Dave Crocker made a proposal in 2003. Additional proposals were made by Scott Bradner in 2004, Brian Carpenter in June 2005, and Ran Atkinson in 2006. This document takes ideas from many of these prior proposals; it also incorporates ideas from the IESG discussion in May 2010, the IETF 78 plenary discussion in July 2010, and yet another proposal submitted by Spencer Dawkins, Dave Crocker, Eric Burger, and Peter Saint-Andre in November 2010.
两级标准轨道已被多次提出。斯宾塞·道金斯、查理·帕金斯和戴夫·克罗克在2003年提出了一项建议。斯科特·布拉德纳（Scott Bradner）于2004年、布赖恩·卡彭特（Brian Carpenter）于2005年6月和阿特金森（Atkinson）于2006年分别提出了其他提案。本文件借鉴了许多先前的建议；它还结合了2010年5月IESG讨论会、2010年7月IETF 78全体会议讨论会以及斯宾塞·道金斯、戴夫·克罗克、埃里克·伯格和彼得·圣安德烈于2010年11月提交的另一份提案中的观点。
[1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[1] Bradner，S.，“互联网标准过程——第3版”，BCP 9，RFC 2026，1996年10月。
[2] Dusseault, L. and R. Sparks, "Guidance on Interoperation and Implementation Reports for Advancement to Draft Standard", BCP 9, RFC 5657, September 2009.
[2] Dusseault，L.和R.Sparks，“推进标准草案的互操作和实施报告指南”，BCP 9，RFC 5657，2009年9月。
Author's Address
作者地址
Russell Housley Vigil Security, LLC EMail: housley@vigilsec.com
Russell Housley Vigil Security，LLC电子邮件：housley@vigilsec.com
Dave Crocker Brandenburg InternetWorking EMail: dcrocker@bbiw.net
Dave Crocker Brandenburg互联网电子邮件：dcrocker@bbiw.net
Eric W. Burger
Georgetown University
EMail: eburger@standardstrack.com
URI: http://www.standardstrack.com
Eric W. Burger
Georgetown University
EMail: eburger@standardstrack.com
URI: http://www.standardstrack.com