Internet Engineering Task Force (IETF)                        Y. Sheffer
Request for Comments: 7942                                        Intuit
BCP: 205                                                       A. Farrel
Obsoletes: 6982                                         Juniper Networks
Category: Best Current Practice                                July 2016
ISSN: 2070-1721
        
Internet Engineering Task Force (IETF)                        Y. Sheffer
Request for Comments: 7942                                        Intuit
BCP: 205                                                       A. Farrel
Obsoletes: 6982                                         Juniper Networks
Category: Best Current Practice                                July 2016
ISSN: 2070-1721
        

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草稿的作者通过包含一个实现状态部分来记录已知实现的状态。这将使评审员和工作组能够适当考虑那些有助于运行代码的文档,这些文档可以作为有价值的实验和反馈的证据,使实现的协议更加成熟。

This process is not mandatory. 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. This document obsoletes RFC 6982, advancing it to a Best Current Practice.

这个过程不是强制性的。鼓励互联网草案的作者考虑使用他们的文档的过程,并邀请工作组考虑将过程应用到他们所有的协议规范。本文件淘汰了RFC 6982,使其成为当前最佳实践。

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 has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on BCPs is available in Section 2 of RFC 7841.

本文件是互联网工程任务组(IETF)的产品。互联网工程指导小组(IESG)已批准将其出版。有关BCP的更多信息,请参见RFC 7841第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/rfc7942.

有关本文件当前状态、任何勘误表以及如何提供反馈的信息,请访问http://www.rfc-editor.org/info/rfc7942.

Copyright Notice

版权公告

Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.

版权所有(c)2016 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  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  The "Implementation Status" Section . . . . . . . . . . . . .   4
     2.1.  Introductory Text . . . . . . . . . . . . . . . . . . . .   5
   3.  Alternative Formats . . . . . . . . . . . . . . . . . . . . .   5
   4.  Benefits  . . . . . . . . . . . . . . . . . . . . . . . . . .   6
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   6.  Informative References  . . . . . . . . . . . . . . . . . . .   7
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8
        
   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  The "Implementation Status" Section . . . . . . . . . . . . .   4
     2.1.  Introductory Text . . . . . . . . . . . . . . . . . . . .   5
   3.  Alternative Formats . . . . . . . . . . . . . . . . . . . . .   5
   4.  Benefits  . . . . . . . . . . . . . . . . . . . . . . . . . .   6
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   6.  Informative References  . . . . . . . . . . . . . . . . . . .   7
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8
        
1. Introduction
1. 介绍

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 specifications 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勘误表流程不适用。

This process is not mandatory. 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 scope of this process 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 will be seen with Standards Track documents developed within working groups.

该过程的范围是包含可实施规范的所有互联网草案(I-D),无论是在IETF工作组内部还是外部工作组中产生的,但旨在达成IETF共识。独立流上发布的I-D明确超出范围。预计工作组内制定的标准跟踪文件将带来最大的好处。

This process was initially proposed as an experiment in [RFC6982]. That document is now obsoleted, and the process advanced to Best Current Practice.

这个过程最初是在[RFC6982]中作为实验提出的。该文件现已过时,该进程已发展到目前的最佳做法。

Historically, there have been other ways for experience based on protocol implementations to feed back into the IETF process. Many "implementation reports" have been published, in some cases several years after the protocol was originally published. Providing

历史上,基于协议实现的经验也有其他方式反馈到IETF过程中。许多“实施报告”已经发表,在某些情况下是在议定书最初发表几年之后。提供

feedback to published protocols is a related goal, but different from the current document's focus. Two notable examples of published implementation reports are [RFC1369] and [RFC5080].

对已发布协议的反馈是一个相关的目标,但与当前文档的重点不同。已发布实施报告的两个显著示例是[RFC1369]和[RFC5080]。

2. The "Implementation Status" Section
2. “执行情况”一节

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:

每个互联网草案可能包含一个标题为“执行情况”的章节。本节(如果出现)应位于“安全注意事项”部分之前,并包含每个现有实现的以下部分或全部内容:

- The organization responsible for the implementation, if any.

- 负责实施的组织(如有)。

- The implementation's name and/or a link to a web page where the implementation or a description of it can be found.

- 实现的名称和/或指向可在其中找到实现或其描述的网页的链接。

- A brief general description.

- 简要的概述。

- The implementation's level of maturity: research, prototype, alpha, beta, production, widely used, etc.

- 实现的成熟度:研究、原型、alpha、beta、生产、广泛使用等。

- Coverage: which parts of the protocol specification are implemented.

- 覆盖范围:实现了协议规范的哪些部分。

- Version compatibility: what version/versions of the Internet-Draft are known to be implemented.

- 版本兼容性:已知要实施的Internet草稿的版本。

- 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).

- 许可:可以使用实现的条款。例如:专有、特许权使用费许可、可自由分发并确认(BSD样式)、可自由分发并要求重新分发源(通用公共许可(GPL)样式)和其他(指定)。

- Implementation experience: any useful information the implementers want to share with the community.

- 实施经验:实施者希望与社区共享的任何有用信息。

- Contact information: ideally a person's name and email address, but possibly just a URL or mailing list.

- 联系信息:理想情况下是一个人的姓名和电子邮件地址,但可能只是一个URL或邮件列表。

- The date when information about this particular implementation was last updated.

- 上次更新有关此特定实施的信息的日期。

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编辑提交一份说明,要求在出版前删除该部分。

2.1. Introductory Text
2.1. 导言

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 7942. 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 7942中描述的提案。本节中的实施说明旨在帮助IETF在将草案提交至RFC的过程中进行决策。请注意,此处列出的任何单个实现并不意味着IETF的认可。此外,没有花费任何努力来验证此处提供的由IETF贡献者提供的信息。这不是,也不能解释为,可用实现或其功能的目录。建议读者注意,可能存在其他实现。

According to RFC 7942, "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 7942,“这将使评审员和工作组能够适当地考虑那些有助于运行代码的文档,这些文档可以作为有价值的实验和反馈的证据,使实现的协议更加成熟。由各工作组酌情使用这些信息”。

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 7942.

请作者在本节顶部向RFC编辑器添加注释,建议编辑器在出版前删除整个章节,以及参考RFC 7942。

3. Alternative Formats
3. 替代格式

Sometimes it can be advantageous to publish the implementation status separately from the base Internet-Draft, e.g., on the IETF wiki:

有时,将实施状态与基础互联网草案分开发布是有利的,例如,在IETF wiki上:

- When the Implementation Status section becomes too large to be conveniently managed within the document.

- 当“实施状态”部分变得太大而无法在文档中方便地管理时。

- When a working group decides to have implementors, rather than authors, keep the status of their implementations current.

- 当一个工作组决定让实现者而不是作者时,保持其实现的最新状态。

- When a working group already maintains an active wiki and prefers to use it for this purpose.

- 当一个工作组已经维护了一个活动的wiki并且更愿意为此目的使用它时。

- 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.

- 如果工作组认为在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分开发布,则该信息需要公开,无需认证、注册或访问控制,才能产生任何有用的效果。

4. Benefits
4. 利益

Publishing the information about implementations provides the working group with several benefits:

发布有关实施的信息为工作组提供了几个好处:

- 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.

- 工作组成员、主席和ADs可使用提供的信息帮助确定I-Ds进展的优先顺序,例如,当存在多个相互竞争的提案来解决特定问题时。

- Similarly, the information is useful when deciding whether the document should be progressed on a different track (individual submission, Experimental, etc.).

- 同样,在决定文档是否应在不同的轨道上进行(个人提交、实验等)时,这些信息也很有用。

- 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.

- 公开这些信息并将其作为工作组审议的一个明确部分,将激励参与者实施协议提案,从而有助于在早期发现协议缺陷。

- 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.

- 其他参与者可以使用该软件来评估协议功能的有用性、正确性(在一定程度上)以及其他属性,如弹性和可伸缩性。

- WG members may choose to perform interoperability testing with known implementations, especially when they are publicly available.

- 工作组成员可以选择使用已知的实现执行互操作性测试,特别是当这些实现公开可用时。

- 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.

- 在开源的情况下,人们可能希望研究代码以更好地理解协议及其局限性,确定实现是否符合协议规范,以及协议规范是否存在遗漏或歧义。

- 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.

- 最后,一些协议特性可能很难理解,对于这些特性,仅仅保证它们可以实现是有益的。但我们注意到,永远不应该使用代码来代替明确的规范。

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.

在这里,我们没有具体说明工作组是否以及在多大程度上会倾向于有“运行代码”的提案,而不是其他没有“运行代码”的提案。

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.

请工作组主席向其工作组中的文件编辑建议这一机制,并提请其工作组参与者注意现有的执行情况章节。

5. Security Considerations
5. 安全考虑

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协议的安全性产生直接影响。然而,经过更好审查的协议也可能更安全。

6. Informative References
6. 资料性引用

[RFC1264] Hinden, R., "Internet Engineering Task Force Internet Routing Protocol Standardization Criteria", RFC 1264, DOI 10.17487/RFC1264, October 1991, <http://www.rfc-editor.org/info/rfc1264>.

[RFC1264]Hinden,R.,“互联网工程任务组互联网路由协议标准化标准”,RFC 1264,DOI 10.17487/RFC1264,1991年10月<http://www.rfc-editor.org/info/rfc1264>.

[RFC1369] Kastenholz, F., "Implementation Notes and Experience for the Internet Ethernet MIB", RFC 1369, DOI 10.17487/RFC1369, October 1992, <http://www.rfc-editor.org/info/rfc1369>.

[RFC1369]Kastenholz,F.,“互联网以太网MIB的实施说明和经验”,RFC 1369,DOI 10.17487/RFC1369,1992年10月<http://www.rfc-editor.org/info/rfc1369>.

[RFC4794] Fenner, B., "RFC 1264 Is Obsolete", RFC 4794, DOI 10.17487/RFC4794, December 2006, <http://www.rfc-editor.org/info/rfc4794>.

[RFC4794]Fenner,B.,“RFC 1264已过时”,RFC 4794,DOI 10.17487/RFC4794,2006年12月<http://www.rfc-editor.org/info/rfc4794>.

[RFC5080] Nelson, D. and A. DeKok, "Common Remote Authentication Dial In User Service (RADIUS) Implementation Issues and Suggested Fixes", RFC 5080, DOI 10.17487/RFC5080, December 2007, <http://www.rfc-editor.org/info/rfc5080>.

[RFC5080]Nelson,D.和A.DeKok,“通用远程身份验证拨入用户服务(RADIUS)实施问题和建议修复”,RFC 5080,DOI 10.17487/RFC5080,2007年12月<http://www.rfc-editor.org/info/rfc5080>.

[RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", RFC 6982, DOI 10.17487/RFC6982, July 2013, <http://www.rfc-editor.org/info/rfc6982>.

[RFC6982]Sheffer,Y.和A.Farrel,“提高运行代码的意识:实现状态部分”,RFC 6982,DOI 10.17487/RFC6982,2013年7月<http://www.rfc-editor.org/info/rfc6982>.

[Tao] Hoffman, P., Ed., "The Tao of IETF: A Novice's Guide to the Internet Engineering Task Force", 2012, <http://www.ietf.org/tao.html>.

[Tao]Hoffman,P.,Ed.“IETF之道:互联网工程任务组新手指南”,2012年<http://www.ietf.org/tao.html>.

Acknowledgements

致谢

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, Joel M. Halpern, 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。

Authors' Addresses

作者地址

Yaron Sheffer Intuit

亚龙·谢弗·因图伊特

   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