[要約] 要約：RFC 6982は、実装状況セクションを通じて実行中のコードの認識を向上させることを目的としています。目的：実装状況セクションを使用して、実行中のコードの進行状況やサポート状況を明確にし、ユーザーに対して情報を提供することを目指しています。
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.
このドキュメントでは、インターネットドラフトの作成者が実装ステータスセクションを含めることにより、既知の実装のステータスを記録できるようにする簡単なプロセスについて説明します。これにより、レビュー担当者とワーキンググループは、コードを実行するメリットがあるドキュメントを適切に検討することができます。これは、実装されたプロトコルをより成熟させた貴重な実験とフィードバックの証拠として役立ちます。
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.
このドキュメントのプロセスは、実験として提供されています。 Internet-Draftsの作成者は、ドキュメントのプロセスを使用することを検討することをお勧めします。ワーキンググループは、プロセスをすべてのプロトコル仕様に適用することを検討するよう招待されます。このドキュメントの作成者は、この実験の経験を照合して、コミュニティに報告することを意図しています。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
このドキュメントはInternet Standards Trackの仕様ではありません。試験、実験、評価のために公開されています。
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（Internet Engineering Task Force）の製品です。これは、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.
Copyright（c）2013 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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 . . . . . . . . . . . . . . . . . . . . . . . . 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として公開するための要件ではありません。実装なしの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エラータプロセスは適用されません。
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を参照）。 Internet-Draftsの作成者は、ドキュメントのプロセスを使用することを検討することをお勧めします。ワーキンググループは、プロセスをすべてのプロトコル仕様に適用することを検討するよう招待されます。
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.
意図された実験の範囲は、IETFワーキンググループ内またはワーキンググループ外で作成され、IETFコンセンサスを対象とした実装可能な仕様を含むすべてのインターネットドラフト（I-D）です。 Independent Streamで公開された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 実装の名前および/または実装を説明するWebページへのリンク。
o A brief general description.
o 簡単な一般的な説明。
o The implementation's level of maturity: research, prototype, alpha, beta, production, widely used, etc.
o 実装の成熟度レベル：研究、プロトタイプ、アルファ、ベータ、製品、広く使用されているなど。
o Coverage: which parts of the protocol specification are implemented and which versions of the Internet-Draft were implemented.
o 適用範囲：プロトコル仕様のどの部分が実装され、どのバージョンのInternet-Draftが実装されたか。
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.
ワーキンググループの議長とエリアディレクター（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エディタへのメモを含める必要があります。
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ウィキなどで、基本的なインターネットドラフトとは別に実装ステータスを公開すると便利な場合があります。
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.
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とは別に公開されている場合、この情報は、有用な効果をもたらすために、認証、登録、またはアクセス制御を必要とせずにオープンに利用できる必要があります。
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 ワーキンググループのメンバー、議長、ADは、提供された情報を使用して、特定の問題を解決するためのいくつかの競合する提案がある場合など、I-Dの進捗を優先順位付けするのに役立ちます。
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 この情報を公開し、WGの審議の一部を明確にすることで、参加者はプロトコルの提案を実装するように動機付けられ、プロトコルの欠陥を早期に発見するのに役立ちます。
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 WGメンバーは、特に公開されている場合は、既知の実装との相互運用性テストを実行することを選択できます。
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を作成するための一般的な時間（[統計]を参照）を考慮して、実験には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.
このトピックに対するコミュニティの関心を呼び起こしてくれたStephen Farrellに感謝します。 Loa Andersson、Dave Crocker、Ned Freed、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に感謝します。
[RFC1264] Hinden, R., "Internet Engineering Task Force Internet Routing Protocol Standardization Criteria", RFC 1264, October 1991.
[RFC1264] Hinden、R。、「Internet Engineering Task Force Internet Routing Protocol Standardization Criteria」、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 Is Obsolete」、RFC 4794、2006年12月。
[Stats] Arkko, J., "Distribution of Processing Times", December 2012, <http://www.arkko.com/tools/lifecycle/wgdistr.html>.
[統計] Arkko、J。、「Distribution of Processing Times」、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>.
[タオ]ホフマン、P。、編、「IETFのタオ：インターネットエンジニアリングタスクフォースの初心者向けガイド」、2012年11月、<http://www.ietf.org/tao.html>。
Authors' Addresses
著者のアドレス
Yaron Sheffer Porticor
Yaron Sheffer Porticor
EMail: yaronf.ietf@gmail.com
Adrian Farrel Juniper Networks
エイドリアンファレルジュニパーネットワークス
EMail: adrian@olddog.co.uk