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




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.


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.

このプロセスは必須ではありません。 Internet-Draftsの作成者は、ドキュメントのプロセスを使用することを検討することをお勧めします。ワーキンググループは、プロセスをすべてのプロトコル仕様に適用することを検討するよう招待されます。このドキュメントは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(Internet Engineering Task Force)の製品です。 Internet Engineering Steering Group(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


Copyright Notice


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

Copyright(c)2016 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents ( 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トラストの法的規定(の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。

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
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として公開するための要件ではありません。実装なしのProposed Standard RFCとして公開されたプロトコル仕様を含むInternet-Draftsの多くの例があります。それらの一部は実装されない場合があります。

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]として公開する前に、1つ以上の実装が存在する必要があるという要件がありました。そのRFCは後に廃止され、実装の要件は解除されましたが、各ワーキンググループには独自の実装要件[RFC4794]を課す権限が与えられ、少なくとも1つのワーキンググループであるドメイン間ルーティング(IDR)は2つの独立した実装。

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.


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.


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.

この情報を適切と考えるように使用するのは個々のワーキンググループ次第ですが、1つの結果として、ドキュメントの優先的な扱いが可能になり、ドキュメントの処理速度が向上します。 RFCとして公開する前に、インターネットドラフトから実装ステータスセクションを削除することをお勧めします。そのため、ドキュメントの公開承認後にこのセクションを変更することは想定していません。たとえば、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.

このプロセスは必須ではありません。 Internet-Draftsの作成者は、ドキュメントのプロセスを使用することを検討することをお勧めします。ワーキンググループは、プロセスをすべてのプロトコル仕様に適用することを検討するよう招待されます。

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.

このプロセスの範囲は、IETFワーキンググループ内で作成されたか、外部のワーキンググループで作成されたかにかかわらず、IETFの合意を目的とした、実装可能な仕様を含むすべてのインターネットドラフト(I-D)です。 Independent Streamで公開された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.


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


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.

- 実装の名前または実装の説明が記載されているWebページへのリンク。

- A brief general description.

- 簡単な一般的な説明。

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

- 実装の成熟度レベル:研究、プロトタイプ、アルファ、ベータ、プロダクション、広く使用されているなど。

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

- カバレッジ:プロトコル仕様のどの部分が実装されているか。

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

- バージョンの互換性:Internet-Draftのどのバージョン/バージョンが実装されていることがわかっています。

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


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.


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:


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


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.


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.

- ワーキンググループのメンバー、議長、ADは、提供された情報を使用して、特定の問題を解決するためのいくつかの競合する提案がある場合など、I-Dの進捗を優先順位付けするのに役立ちます。

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

- この情報を公開し、WGの審議の一部を明確にすることで、参加者はプロトコルの提案を実装するように動機付けられ、プロトコルの欠陥を早期に発見するのに役立ちます。

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

- WGメンバーは、特に公開されている場合は、既知の実装との相互運用性テストを実行することを選択できます。

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


6. Informative References
6. 参考引用

[RFC1264] Hinden, R., "Internet Engineering Task Force Internet Routing Protocol Standardization Criteria", RFC 1264, DOI 10.17487/RFC1264, October 1991, <>.

[RFC1264] Hinden、R。、「Internet Engineering Task Force Internet Routing Protocol Standardization Criteria」、RFC 1264、DOI 10.17487 / RFC1264、1991年10月、<>。

[RFC1369] Kastenholz, F., "Implementation Notes and Experience for the Internet Ethernet MIB", RFC 1369, DOI 10.17487/RFC1369, October 1992, <>.

[RFC1369] Kastenholz、F。、「インターネットイーサネットMIBの実装に関する注意と経験」、RFC 1369、DOI 10.17487 / RFC1369、1992年10月、<>。

[RFC4794] Fenner, B., "RFC 1264 Is Obsolete", RFC 4794, DOI 10.17487/RFC4794, December 2006, <>.

[RFC4794] Fenner、B。、「RFC 1264 Is Obsolete」、RFC 4794、DOI 10.17487 / RFC4794、2006年12月、<>。

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

[RFC5080] Nelson、D。およびA. DeKok、「一般的なリモート認証ダイヤルインユーザーサービス(RADIUS)の実装の問題と推奨される修正」、RFC 5080、DOI 10.17487 / RFC5080、2007年12月、<http://www.rfc->。

[RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", RFC 6982, DOI 10.17487/RFC6982, July 2013, <>.

[RFC6982] Sheffer、Y。およびA. Farrel、「コードの実行に対する認識の向上:実装ステータスセクション」、RFC 6982、DOI 10.17487 / RFC6982、2013年7月、< / rfc6982>。

[Tao] Hoffman, P., Ed., "The Tao of IETF: A Novice's Guide to the Internet Engineering Task Force", 2012, <>.




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.

このトピックに対するコミュニティの関心を呼び起こしてくれたStephen Farrellに感謝します。 Loa Andersson、Dave Crocker、Ned Freed、Joel M. Halpern、Christer Holmberg、Denis Ovsienko、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

Yaron Sheffer Intuit


Adrian Farrel Juniper Networks