Internet Engineering Task Force (IETF) Y. Sheffer
Request for Comments: 6982 Porticor
Category: Experimental A. Farrel
ISSN: 2070-1721 Juniper
July 2013
Internet Engineering Task Force (IETF) Y. Sheffer
Request for Comments: 6982 Porticor
Category: Experimental A. Farrel
ISSN: 2070-1721 Juniper
July 2013
Improving Awareness of Running Code: The Implementation Status Section
提高运行代码的意识：实现状态部分
Abstract
摘要
This document describes a simple process that allows authors of Internet-Drafts to record the status of known implementations by including an Implementation Status section. This will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature.
本文档描述了一个简单的过程，允许Internet草稿的作者通过包含一个实现状态部分来记录已知实现的状态。这将使评审员和工作组能够适当考虑那些有助于运行代码的文档，这些文档可以作为有价值的实验和反馈的证据，使实现的协议更加成熟。
The process in this document is offered as an experiment. Authors of Internet-Drafts are encouraged to consider using the process for their documents, and working groups are invited to think about applying the process to all of their protocol specifications. The authors of this document intend to collate experiences with this experiment and to report them to the community.
本文中的过程是作为实验提供的。鼓励互联网草案的作者考虑使用他们的文档的过程，并邀请工作组考虑将过程应用到他们所有的协议规范。本文件的作者打算整理这项实验的经验，并向社区报告。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
本文件不是互联网标准跟踪规范；它是为检查、实验实施和评估而发布的。
This document defines an Experimental Protocol for the Internet community. 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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文档为互联网社区定义了一个实验协议。本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见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/rfc6982.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6982.
Copyright Notice
版权公告
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2013 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许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. The "Implementation Status" Section . . . . . . . . . . . . . 4
2.1. Introductory Text . . . . . . . . . . . . . . . . . . . . . 5
3. Alternative Formats . . . . . . . . . . . . . . . . . . . . . 6
4. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Process Experiment . . . . . . . . . . . . . . . . . . . . . 7
5.1. Duration . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.2. Summary Report . . . . . . . . . . . . . . . . . . . . . . 8
5.3. Success Criteria . . . . . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
8. Informative References . . . . . . . . . . . . . . . . . . . 9
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. The "Implementation Status" Section . . . . . . . . . . . . . 4
2.1. Introductory Text . . . . . . . . . . . . . . . . . . . . . 5
3. Alternative Formats . . . . . . . . . . . . . . . . . . . . . 6
4. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Process Experiment . . . . . . . . . . . . . . . . . . . . . 7
5.1. Duration . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.2. Summary Report . . . . . . . . . . . . . . . . . . . . . . 8
5.3. Success Criteria . . . . . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
8. Informative References . . . . . . . . . . . . . . . . . . . 9
Most IETF participants are familiar with the saying "rough consensus and running code" [Tao] and can identify with its pragmatic approach. However, implementation is not a requirement for publication as an RFC. There are many examples of Internet-Drafts containing protocol specification that have gone through to publication as Proposed Standard RFCs without implementation. Some of them may never get implemented.
大多数IETF参与者熟悉“大致共识和运行代码”[Tao]，并能认同其务实方法。但是，实现并不是作为RFC发布的要求。有许多包含协议规范的互联网草案的例子，这些草案作为提议的标准RFC出版，但没有实施。其中一些可能永远无法实施。
Over time, a variety of policies have been applied within the IETF to consider running code. In the Routing Area, it used to be a requirement that one or more implementations must exist before an Internet-Draft could be published as a Proposed Standard RFC [RFC1264]. That RFC was later obsoleted and the requirement for implementation was lifted, but each working group was given the authority to impose its own implementation requirements [RFC4794] and at least one working group, Inter-Domain Routing (IDR), continues to require two independent implementations.
随着时间的推移，IETF中已经应用了各种策略来考虑运行代码。在路由领域，曾经有一项要求，即在互联网草案发布为拟议的标准RFC[RFC1264]之前，必须存在一个或多个实现。该RFC后来被废除，实施要求也被取消，但每个工作组都有权实施自己的实施要求[RFC4794]，至少一个工作组域间路由（IDR）继续要求两个独立的实施。
The hypothesis behind the current document is that there are benefits to the IETF standardization process of producing implementations of protocol specifications before publication as RFCs. These benefits, which include determining that the specification is comprehensible and that there is sufficient interest to implement, are further discussed in Section 4.
当前文件背后的假设是，IETF标准化过程在作为RFC发布之前产生协议规范的实现是有好处的。这些好处，包括确定规范是可理解的，并且有足够的兴趣实施，将在第4节中进一步讨论。
This document describes a simple mechanism that allows authors of Internet-Drafts to record and publicize the status of known implementations by including an Implementation Status section. The document defines (quite informally) the contents of this section to ensure that the relevant information is included. This will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature.
本文档描述了一种简单的机制，允许Internet草稿的作者记录和公布已知实现的状态，包括一个实现状态部分。本文件（相当非正式地）定义了本节的内容，以确保包含相关信息。这将使评审员和工作组能够适当考虑那些有助于运行代码的文档，这些文档可以作为有价值的实验和反馈的证据，使实现的协议更加成熟。
It is up to the individual working groups to use this information as they see fit, but one result might be the preferential treatment of documents, resulting in them being processed more rapidly. We recommend that the Implementation Status section should be removed from Internet-Drafts before they are published as RFCs. As a result, we do not envisage changes to this section after approval of the document for publication, e.g., the RFC errata process does not apply.
应由各工作组酌情使用这些信息，但其中一个结果可能是优先对待文件，从而使文件得到更快的处理。我们建议在作为RFC发布之前，从Internet草稿中删除“实施状态”部分。因此，我们不打算在批准文件发布后对本节进行更改，例如，RFC勘误表流程不适用。
The process in this document is offered as an experiment (though not as an [RFC3933] experiment; see Section 5). Authors of Internet-Drafts are encouraged to consider using the process for their documents, and working groups are invited to think about applying the process to all of their protocol specifications.
本文件中的过程是作为实验提供的（虽然不是[RFC3933]实验；参见第5节）。鼓励互联网草案的作者考虑使用他们的文档的过程，并邀请工作组考虑将过程应用到他们所有的协议规范。
The scope of the intended experiment is all Internet-Drafts (I-Ds) that contain implementable specifications, whether produced within IETF working groups or outside working groups but intended for IETF consensus. I-Ds published on the Independent Stream are explicitly out of scope. It is expected that the greatest benefit in the experiment will be seen with Standards Track documents developed within working groups.
预期实验的范围是包含可实施规范的所有互联网草案（I-D），无论是在IETF工作组内部还是外部工作组中产生，但旨在达成IETF共识。独立流上发布的I-D明确超出范围。预计该实验的最大好处将体现在工作组内制定的标准跟踪文件上。
The authors of this document intend to collate experiences with this experiment and to report them to the community.
本文件的作者打算整理这项实验的经验，并向社区报告。
Each Internet-Draft may contain a section entitled "Implementation Status". This section, if it appears, should be located just before the "Security Considerations" section and contain, for each existing implementation, some or all of the following:
每个互联网草案可能包含一个标题为“执行情况”的章节。本节（如果出现）应位于“安全注意事项”部分之前，并包含每个现有实现的以下部分或全部内容：
o The organization responsible for the implementation, if any.
o 负责实施的组织（如有）。
o The implementation's name and/or a link to a web page describing the implementation.
o 实现的名称和/或指向描述实现的网页的链接。
o A brief general description.
o 简要的概述。
o The implementation's level of maturity: research, prototype, alpha, beta, production, widely used, etc.
o 实现的成熟度：研究、原型、alpha、beta、生产、广泛使用等。
o Coverage: which parts of the protocol specification are implemented and which versions of the Internet-Draft were implemented.
o 覆盖范围：实施了协议规范的哪些部分，以及实施了互联网草案的哪些版本。
o Licensing: the terms under which the implementation can be used. For example: proprietary, royalty licensing, freely distributable with acknowledgement (BSD style), freely distributable with requirement to redistribute source (General Public License (GPL) style), and other (specify).
o 许可：可以使用实现的条款。例如：专有、特许权使用费许可、可自由分发并确认（BSD样式）、可自由分发并要求重新分发源（通用公共许可（GPL）样式）和其他（指定）。
o Implementation experience: any useful information the implementers want to share with the community.
o 实施经验：实施者希望与社区共享的任何有用信息。
o Contact information: ideally a person's name and email address, but possibly just a URL or mailing list.
o 联系信息：理想情况下是一个人的姓名和电子邮件地址，但可能只是一个URL或邮件列表。
In addition, this section can contain information about the interoperability of any or all of the implementations, including references to test-case descriptions and interoperability reports, when such exist.
此外，本节可以包含关于任何或所有实现的互操作性的信息，包括对测试用例描述和互操作性报告的引用（如果存在）。
Working group chairs and area directors (ADs) are requested to ensure that this section is not used as a marketing venue for specific implementations.
请工作组主席和区域主管（ADs）确保本节不被用作特定实施的营销场所。
Since this information is necessarily time dependent, it is inappropriate for inclusion in a published RFC. The authors should include a note to the RFC Editor requesting that the section be removed before publication.
由于此信息必须与时间相关，因此不适合包含在已发布的RFC中。作者应向RFC编辑提交一份说明，要求在出版前删除该部分。
The following boilerplate text is proposed to head the Implementation Status section:
建议以下样板文本作为实施状态部分的标题：
This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft, and is based on a proposal described in RFC 6982. The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs. Please note that the listing of any individual implementation here does not imply endorsement by the IETF. Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF contributors. This is not intended as, and must not be construed to be, a catalog of available implementations or their features. Readers are advised to note that other implementations may exist.
本节记录了发布本互联网草案时本规范定义的协议的已知实现状态，并基于RFC 6982中描述的提案。本节中的实施说明旨在帮助IETF在将草案提交至RFC的过程中进行决策。请注意，此处列出的任何单个实现并不意味着IETF的认可。此外，没有花费任何努力来验证此处提供的由IETF贡献者提供的信息。这不是，也不能解释为，可用实现或其功能的目录。建议读者注意，可能存在其他实现。
According to RFC 6982, "this will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. It is up to the individual working groups to use this information as they see fit".
根据RFC 6982，“这将使评审员和工作组能够适当地考虑那些有助于运行代码的文档，这些文档可以作为有价值的实验和反馈的证据，使实现的协议更加成熟。由各工作组酌情使用这些信息”。
Authors are requested to add a note to the RFC Editor at the top of this section, advising the Editor to remove the entire section before publication, as well as the reference to RFC 6982.
请作者在本节顶部向RFC编辑器添加注释，建议编辑器在出版前删除整个章节，以及参考RFC 6982。
Sometimes it can be advantageous to publish the implementation status separately from the base Internet-Draft, e.g., on the IETF wiki:
有时，将实施状态与基础互联网草案分开发布是有利的，例如，在IETF wiki上：
o When the Implementation Status section becomes too large to be conveniently managed within the document.
o 当“实施状态”部分变得太大而无法在文档中方便地管理时。
o When a working group decides to have implementors, rather than authors, keep the status of their implementations current.
o 当一个工作组决定让实现者而不是作者时，保持其实现的最新状态。
o When a working group already maintains an active wiki and prefers to use it for this purpose.
o 当一个工作组已经维护了一个活动的wiki并且更愿意为此目的使用它时。
o If the working group decides that the information is still valuable (and needs to be kept current) after the I-D is published as an RFC, and the Implementation Status section had been removed from it.
o 如果工作组认为在I-D作为RFC发布后，信息仍然有价值（并且需要保持最新），并且执行状态部分已从中删除。
It is highly desirable for all readers of the Internet-Draft to be made aware of this information. Initially, this can be done by replacing the Implementation Status section's contents with a URL pointing to the wiki. Later, the IETF Tools may support this functionality, e.g., by including such a link in the HTML file of the document, similar to the IPR link.
这是非常可取的互联网草案的所有读者都知道这一信息。最初，这可以通过用指向wiki的URL替换Implementation Status部分的内容来实现。稍后，IETF工具可以支持该功能，例如，通过在文档的HTML文件中包括类似于IPR链接的这样的链接。
If the implementation status is published separately from the I-D, then this information needs to be openly available without requiring authentication, registration, or access controls if it is to have any useful effects.
如果实施状态与I-D分开发布，则该信息需要公开，无需认证、注册或访问控制，才能产生任何有用的效果。
Publishing the information about implementations provides the working group with several benefits:
发布有关实施的信息为工作组提供了几个好处：
o Working group members, chairs, and ADs may use the information provided to help prioritize the progress of I-Ds, e.g., when there are several competing proposals to solve a particular problem.
o 工作组成员、主席和ADs可使用提供的信息帮助确定I-Ds进展的优先顺序，例如，当存在多个相互竞争的提案来解决特定问题时。
o Similarly, the information is useful when deciding whether the document should be progressed on a different track (individual submission, Experimental, etc.).
o 同样，在决定文档是否应在不同的轨道上进行（个人提交、实验等）时，这些信息也很有用。
o Making this information public and an explicit part of WG deliberations will motivate participants to implement protocol proposals, which in turn helps in discovering protocol flaws at an early stage.
o 公开这些信息并将其作为工作组审议的一个明确部分，将激励参与者实施协议提案，从而有助于在早期发现协议缺陷。
o Other participants can use the software to evaluate the usefulness of protocol features, its correctness (to some degree), and other properties, such as resilience and scalability.
o 其他参与者可以使用该软件来评估协议功能的有用性、正确性（在一定程度上）以及其他属性，如弹性和可伸缩性。
o WG members may choose to perform interoperability testing with known implementations, especially when they are publicly available.
o 工作组成员可以选择使用已知的实现执行互操作性测试，特别是当这些实现公开可用时。
o In the case of open source, people may want to study the code to better understand the protocol and its limitations, determine if the implementation matches the protocol specification, and whether the protocol specification has omissions or ambiguities.
o 在开源的情况下，人们可能希望研究代码以更好地理解协议及其局限性，确定实现是否符合协议规范，以及协议规范是否存在遗漏或歧义。
o And lastly, some protocol features may be hard to understand, and for such features, the mere assurance that they can be implemented is beneficial. We note though that code should never be used in lieu of a clear specification.
o 最后，一些协议特性可能很难理解，对于这些特性，仅仅保证它们可以实现是有益的。但我们注意到，永远不应该使用代码来代替明确的规范。
We do not specify here whether and to what degree working groups are expected to prefer proposals that have "running code" associated with them, over others that do not.
在这里，我们没有具体说明工作组是否以及在多大程度上会倾向于有“运行代码”的提案，而不是其他没有“运行代码”的提案。
The current proposal is proposed as an experiment. The inclusion of Implementation Status sections in Internet-Drafts is not mandatory, but the authors of this document wish to encourage authors of other Internet-Drafts to try out this simple mechanism to discover whether it is useful. Working group chairs are invited to suggest this mechanism to document editors in their working groups, and to draw the attention of their working group participants to Implementation Status sections where they exist.
目前的提议是作为实验提出的。在互联网草案中包含实施状态部分不是强制性的，但本文件的作者希望鼓励其他互联网草案的作者尝试这种简单的机制，以发现它是否有用。请工作组主席向其工作组中的文件编辑建议这一机制，并提请其工作组参与者注意现有的执行情况章节。
Following a community discussion, it was concluded that [RFC3933] is not an appropriate framework for this experiment, primarily because no change is required to any existing process.
经过社区讨论，得出结论认为[RFC3933]不是该实验的合适框架，主要是因为不需要对任何现有流程进行更改。
Given the typical time to produce an RFC (see [Stats]), we propose a duration of 18 months for the experiment. Thus, 18 months after the date of publication of this document as an RFC, the authors will report on the experiment as described in the next section.
考虑到产生RFC的典型时间（见[Stats]），我们建议实验的持续时间为18个月。因此，在本文件作为RFC出版之日起18个月后，作者将在下一节中报告实验情况。
I-D authors are obviously free to include Implementation Status sections in their documents even after the experiment has concluded.
I-D作者显然可以自由地在他们的文档中包括实现状态部分，即使实验已经结束。
The authors will summarize the results of the experiment at the end of the period assigned to the experiment (see Section 5.1). If nothing happens (no I-Ds or only a handful include an Implementation Status section), an email to the IETF list will be sufficient. This would obviously constitute a failure to adopt the idea and the authors will abandon the experiment.
作者将在分配给实验的时间结束时总结实验结果（见第5.1节）。如果什么也没有发生（没有I-D或只有少数包含实施状态部分），发送电子邮件到IETF列表就足够了。这显然将构成采纳该想法的失败，作者将放弃该实验。
If this idea is adopted by document authors, a summary I-D will be written containing the statistics of such adoption, as well as (necessarily subjective) reports by working group members, chairs, and area directors who have used this mechanism.
如果文件作者采纳了这一想法，则将编写一份I-D摘要，其中包含采纳情况的统计数据，以及使用该机制的工作组成员、主席和区域主管的（必要的主观）报告。
The authors may then propose more wide-scale use of the process and might suggest more formal adoption of the process by the IETF.
然后，作者可能建议更广泛地使用该过程，并可能建议IETF更正式地采用该过程。
The goal of this experiment is to improve the quality of IETF specifications. This is impossible to quantify, of course. We suggest that generally positive answers to the following questions would indicate that the experiment was successful:
本实验的目标是提高IETF规范的质量。当然，这是不可能量化的。我们建议，对以下问题的总体肯定回答将表明实验是成功的：
o Did the working group make decisions that were more informed when comparing multiple competing solutions for the same work item?
o 在比较同一工作项的多个竞争解决方案时，工作组是否做出了更明智的决定？
o Did authors significantly modify proposed protocols based on implementation experience?
o 作者是否根据实施经验对提议的协议进行了重大修改？
o Did disclosure of implementations encourage more interoperability testing than previously?
o 实现的公开是否比以前鼓励更多的互操作性测试？
o Did non-authors review documents based on interactions with running code and/or inspection of the code itself?
o 非作者是否根据与运行代码的交互和/或对代码本身的检查来审查文档？
This is a process document; therefore, it does not have a direct effect on the security of any particular IETF protocol. However, better-reviewed protocols are likely to also be more secure.
这是一个过程文件；因此，它不会对任何特定IETF协议的安全性产生直接影响。然而，经过更好审查的协议也可能更安全。
We would like to thank Stephen Farrell, who reawakened community interest in this topic. Several reviewers provided important input, including Loa Andersson, Dave Crocker, Ned Freed, Christer Holmberg, Denis Ovsienko, and Curtis Villamizar.
我们要感谢斯蒂芬·法雷尔，他重新唤起了社区对这个话题的兴趣。几位评论员提供了重要的意见，包括洛亚·安德森、戴夫·克罗克、内德·弗里德、克里斯特·霍姆伯格、丹尼斯·奥文科和柯蒂斯·维拉米扎。
This document was originally prepared using the lyx2rfc tool, and we would like to thank Nico Williams, its author.
本文档最初是使用lyx2rfc工具编写的，我们要感谢其作者Nico Williams。
[RFC1264] Hinden, R., "Internet Engineering Task Force Internet Routing Protocol Standardization Criteria", RFC 1264, October 1991.
[RFC1264]Hinden，R.，“互联网工程任务组互联网路由协议标准化标准”，RFC 1264，1991年10月。
[RFC3933] Klensin, J. and S. Dawkins, "A Model for IETF Process Experiments", BCP 93, RFC 3933, November 2004.
[RFC3933]Klensin，J.和S.Dawkins，“IETF过程实验的模型”，BCP 93，RFC 3933，2004年11月。
[RFC4794] Fenner, B., "RFC 1264 Is Obsolete", RFC 4794, December 2006.
[RFC4794]Fenner，B.，“RFC 1264已过时”，RFC 47942006年12月。
[Stats] Arkko, J., "Distribution of Processing Times", December 2012, <http://www.arkko.com/tools/lifecycle/wgdistr.html>.
[Stats]Arkko，J.，“处理时间分布”，2012年12月<http://www.arkko.com/tools/lifecycle/wgdistr.html>.
[Tao] Hoffman, P., Ed., "The Tao of IETF: A Novice's Guide to the Internet Engineering Task Force", November 2012, <http://www.ietf.org/tao.html>.
[Tao]Hoffman，P.，Ed.“IETF之道：互联网工程任务组新手指南”，2012年11月<http://www.ietf.org/tao.html>.
Authors' Addresses
作者地址
Yaron Sheffer Porticor
亚龙谢弗波蒂科酒店
EMail: yaronf.ietf@gmail.com
EMail: yaronf.ietf@gmail.com
Adrian Farrel Juniper Networks
Adrian Farrel Juniper Networks
EMail: adrian@olddog.co.uk
EMail: adrian@olddog.co.uk