RFC 7942 - Improving Awareness of Running Code: The Implementation Status Section 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc7942
タイトル : RFC 7942 - 実行中のコードの認識の向上：実装ステータスセクション
翻訳編集 : 自動生成

[要約] RFC 7942は、実装状況セクションを通じて実行中のコードの認識を向上させることを目的としています。このRFCの要約は、実装状況セクションの目的と要約を示しています。

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.

このドキュメントでは、インターネットドラフトの作成者が実装ステータスセクションを含めることにより、既知の実装のステータスを記録できるようにする簡単なプロセスについて説明します。これにより、レビュー担当者とワーキンググループは、コードを実行するメリットがあるドキュメントを適切に検討することができます。これは、実装されたプロトコルをより成熟させた貴重な実験とフィードバックの証拠として役立ちます。

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 http://www.rfc-editor.org/info/rfc7942.

このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7942で入手できます。

著作権表示

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）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、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.

現在のドキュメントの背後にある仮説は、RFCとして公開する前にプロトコル仕様の実装を作成するIETF標準化プロセスには利点があるということです。仕様が包括的であり、実装するのに十分な関心があることの決定を含むこれらの利点については、セクション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エラータプロセスは適用されません。

このプロセスは必須ではありません。 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.

このプロセスは、当初[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 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].

これまで、プロトコルの実装に基づいて、IETFプロセスにフィードバックするための他の方法がありました。プロトコルが最初に公開されてから数年後に、多くの「実装レポート」が公開されています。公開されたプロトコルにフィードバックを提供することは関連する目標ですが、現在のドキュメントの焦点とは異なります。公開されている実装レポートの注目すべき2つの例は、[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.

- 実装の名前または実装の説明が記載されている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.

ワーキンググループの議長とエリアディレクター（AD）は、このセクションが特定の実装のマーケティングの場として使用されないようにする必要があります。

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ウィキなどで、基本的なインターネットドラフトとは別に実装ステータスを公開すると便利な場合があります。

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

Internet-Draftのすべての読者がこの情報を知っていることが非常に望ましいです。最初に、これは、実装状況セクションのコンテンツをWikiを指すURLに置き換えることで実行できます。その後、IETFツールは、たとえば、IPRリンクと同様に、ドキュメントのHTMLファイルにそのようなリンクを含めることにより、この機能をサポートします。

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.

- ワーキンググループのメンバー、議長、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.

これはプロセスドキュメントです。したがって、特定の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。、「Internet Engineering Task Force Internet Routing Protocol Standardization Criteria」、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 Is Obsolete」、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>.

[タオ]ホフマン、P。、編、「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.

このトピックに対するコミュニティの関心を呼び起こしてくれた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

   Email: yaronf.ietf@gmail.com

Adrian Farrel Juniper Networks

エイドリアンファレルジュニパーネットワークス

   Email: adrian@olddog.co.uk