Internet Engineering Task Force (IETF) R. Housley
Request for Comments: 6410 Vigil Security
BCP: 9 D. Crocker
Updates: 2026 Brandenburg InternetWorking
Category: Best Current Practice E. Burger
ISSN: 2070-1721 Georgetown University
October 2011
Reducing the Standards Track to Two Maturity Levels
Abstract
抽象
This document updates the Internet Engineering Task Force (IETF) Standards Process defined in RFC 2026. Primarily, it reduces the Standards Process from three Standards Track maturity levels to two.
この文書では、主にRFC 2026で定義されているIETF（Internet Engineering Task Force）の標準化プロセスを更新し、それが3つの標準化過程の成熟度レベルから2に標準化プロセスを低減します。
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 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). Further information on BCPs is available in Section 2 of RFC 5741.
このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。 BCPの詳細については、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/rfc6410.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6410で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2011 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ドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
This document changes the Internet Standards Process defined in RFC 2026 [1]. In recent years, the Internet Engineering Task Force (IETF) witnessed difficulty advancing documents through the maturity levels: Proposed Standard, Draft Standard, and finally Standard. These changes are designed to simplify the Standards Process and reduce impediments to standards progression while preserving the most important benefits of the IETF engineering approach. In addition, the requirement for annual review of Standards Track documents that have not reached the top of the maturity ladder is removed from the Internet Standards Process.
この文書では、[1] RFC 2026で定義されたインターネット標準化プロセスを変更します。近年では、IETF（Internet Engineering Task Force）は難易度の成熟度レベルを介して文書を進めるのを目撃：標準、ドラフト標準、そして最終的に標準を提案しました。これらの変更は、IETF工学的アプローチの最も重要な利点を維持しながら、標準化プロセスを簡素化し、標準化の進行に支障を軽減するために設計されています。また、満期ラダーのトップに達していない標準化過程文書の年次レビューのための要件は、インターネット標準プロセスから除去されます。
Over the years, there have been many proposals for refining the Internet Standards Process to reduce impediments to standards progression. During May 2010, the Internet Engineering Steering Group (IESG) discussed many of these proposals. Then, a plenary discussion at IETF 78 in July 2010 demonstrated significant support for transition from a three-tier maturity ladder to one with two tiers.
長年にわたり、標準化の進行に支障を軽減するために、インターネット標準化プロセスを改良するための多くの提案がなされています。 2010年5月の間に、インターネットエンジニアリング運営グループ（IESG）は、これらの提案の多くを議論しました。その後、2010年7月IETF 78に本会議の議論は、3層満期ラダーから2段を有するものへの移行のための重要なサポートを実証しました。
In the Internet Standards Process, experience with a Proposed Standard is expected to motivate revisions that clarify, modify, enhance, or remove features. However, in recent years, the vast majority of Standards Track documents are published as Proposed Standards and never advance to a higher maturity level. Very few specifications have advanced on the maturity ladder in the last decade. Changing the Internet Standards Process from three maturity levels to two is intended to create an environment where lessons from implementation and deployment experience are used to improve specifications.
インターネット標準化プロセスでは、標準化提案の経験は、明確に改訂をやる気修正し、強化する、または機能を削除することが期待されます。しかし、近年では、標準化過程文書の大半は、提案された標準として公開され、より高い成熟度のレベルに進むことはありません。非常に少数の仕様は10年で満期ラダーに進んでいます。 2〜3つの成熟度レベルから、インターネット標準プロセスを変更すると、実装と展開の経験からの教訓は、仕様を改善するために使用されている環境を作成することを意図しています。
The primary aspect of this change is to revise the requirements for advancement beyond Proposed Standard. RFC 2026 [1] requires a report that documents interoperability between at least two implementations from different code bases as an interim step ("Draft Standard") before a specification can be advanced further to the third and final maturity level ("Standard") based on widespread deployment and use. In contrast, this document requires measuring interoperability through widespread deployment of multiple implementations from different code bases, thus condensing the two separate metrics into one.
この変更の主な特徴は、提案された標準を超えた発展のための要件を改訂することです。 RFC 2026 [1]中間工程（「ドラフト標準」）のような異なるコードベースから少なくとも2つの実装の間で文書の相互運用性仕様は基づいて第3および最終の成熟レベル（「標準」）にさらに前進させることができる前に、という報告が必要広範囲の展開と使用に関する。対照的に、この文書は、このように一つに二つの別個のメトリックを凝縮、異なるコードベースから複数の実装の広範囲の展開を通じて相互運用性を測定することが必要です。
The result of this change is expected to be maturity-level advancement based on achieving widespread deployment of quality specifications. Additionally, the change will result in the incorporation of lessons from implementation and deployment experience, and recognition that protocols are improved by removing complexity associated with unused features.
この変更の結果は、品質仕様の広範な展開を達成することに基づく成熟度レベルの進歩であると期待されます。また、変更は、プロトコルが使用されていない機能に関連した複雑さを取り除くことによって改善されている実装と展開の経験、および認識から教訓を組み込むことになります。
In RFC 2026 [1], widespread deployment is essentially the metric used for advancement from Draft Standard to Standard. The use of this same metric for advancement beyond Proposed Standard means that there is no longer a useful distinction between the top two tiers of the maturity ladder. Thus, the maturity ladder is reduced to two tiers.
RFC 2026 [1]において、広範囲の展開は、本質的に、標準のドラフト標準からの前進のために使用されるメトリックです。 Proposed Standardを超えた発展のために、この同じメトリックの使用は満期梯子の上の2つの層の間に有用な区別がなくなったことを意味しません。したがって、満期ラダーは、2つの層にまで低減されます。
In addition, RFC 2026 [1] requires annual review of specifications that have not achieved the top maturity level. This review is no longer required.
また、RFC 2026 [1]最成熟度レベルを達成していない仕様の年次見直しが必要になります。このレビューは、もはや必要とされません。
This document replaces the three-tier maturity ladder defined in RFC 2026 [1] with a two-tier maturity ladder. Specifications become Internet Standards through a set of two maturity levels known as the "Standards Track". These maturity levels are "Proposed Standard" and "Internet Standard".
この文書では、2層満期ラダーと[1] RFC 2026で定義された3層満期ラダーを置き換えます。仕様は「標準化過程」として知られている2つの成熟度レベルのセットを介してインターネット標準になります。これらの成熟度レベルがされている「のProposed Standard」と「インターネット標準」。
A specification may be, and indeed, is likely to be, revised as it advances from Proposed Standard to Internet Standard. When a revised specification is proposed for advancement to Internet Standard, the IESG shall determine the scope and significance of the changes to the specification, and, if necessary and appropriate, modify the recommended action. Minor revisions and the removal of unused features are expected, but a significant revision may require that the specification accumulate more experience at Proposed Standard before progressing.
それはインターネット標準へのProposed Standardから進めて仕様があること、そして確かに、である可能性が高いことが、改訂されました。改訂された仕様は、インターネット標準の前進のために提案されている場合、IESGは仕様への変更の範囲および意義を決定しなければならない、そして、必要かつ適切な場合、推奨されるアクションを変更します。マイナーリビジョンと未使用の機能の除去が期待されていますが、重要な改正は、仕様が進行する前に標準化提案でより多くの経験を蓄積することを必要とするかもしれません。
The stated requirements for Proposed Standard are not changed; they remain exactly as specified in RFC 2026 [1]. No new requirements are introduced; no existing published requirements are relaxed.
Proposed Standardについて述べた要件が変更されません。彼らは、[1] RFC 2026で指定されたとおりに残ります。新しい要件が導入されません。既存の公表要件は緩和されません。
This maturity level is a merger of Draft Standard and Standard as specified in RFC 2026 [1]. The chosen name avoids confusion between "Draft Standard" and "Internet-Draft".
この成熟度レベルは、RFC 2026で指定されるようにドラフト標準および標準の合併である[1]。選択した名前は「ドラフト標準」および「インターネットドラフト」との混同を避けることができます。
The characterization of an Internet Standard remains as described in RFC 2026 [1], which says:
RFC 2026に記載されているように、インターネット標準の特徴は述べていた、[1]のまま：
An Internet Standard is characterized by a high degree of technical maturity and by a generally held belief that the specified protocol or service provides significant benefit to the Internet community.
インターネット標準は、技術的な成熟度が高いことで、指定したプロトコルやサービスは、インターネットコミュニティに大きな利点を提供し、一般的に開催された信念によって特徴付けられます。
The IESG, in an IETF-wide Last Call of at least four weeks, confirms that a document advances from Proposed Standard to Internet Standard. The request for reclassification is sent to the IESG along with an explanation of how the criteria have been met. The criteria are:
IESGは、少なくとも4週間のIETFワイドラストコールでは、ドキュメントはインターネット標準へのProposed Standardから進めていることを確認します。再分類のための要求は、基準が満たされたかの説明と一緒にIESGに送信されます。基準は以下のとおりです。
(1) There are at least two independent interoperating implementations with widespread deployment and successful operational experience.
（1）広範囲の展開と成功の運用経験を持つ少なくとも2つの独立した相互運用する実装があります。
(2) There are no errata against the specification that would cause a new implementation to fail to interoperate with deployed ones.
（2）新しい実装が展開されたものとの相互運用に失敗する原因となる仕様に対して一切のエラッタはありません。
(3) There are no unused features in the specification that greatly increase implementation complexity.
（3）大幅な実装の複雑さを増加させる仕様に未使用の機能がありません。
(4) If the technology required to implement the specification requires patented or otherwise controlled technology, then the set of implementations must demonstrate at least two independent, separate and successful uses of the licensing process.
仕様を実装するために必要な技術は、特許取得済みの、またはそうでなければ制御技術を必要とする場合（4）、次いで、実装のセットは、ライセンス処理の少なくとも2つの独立した別々の成功した使用を実証しなければなりません。
After review and consideration of significant errata, the IESG will perform an IETF-wide Last Call of at least four weeks on the requested reclassification. If there is consensus for reclassification, the RFC will be reclassified without publication of a new RFC.
重要な正誤表の見直しと検討した後、IESGは、要求された再分類に少なくとも4週間のIETFワイドラストコールを実行します。再分類のためのコンセンサスがある場合は、RFCは、新しいRFCの公表せずに再分類されます。
As stated in RFC 2026 [1], in a timely fashion after the expiration of the Last Call period, the IESG shall make its final determination and notify the IETF of its decision via electronic mail to the IETF Announce mailing list. No changes are made to Section 6.1.2 of RFC 2026 [1].
RFC 2026に記載されているように、[1]、ラストコール期間の満了後にタイムリーに、IESGは、最終的な決意をしなければならないし、メーリングリストを発表IETFに電子メールを経由して、その決定のIETFに通知します。変更はRFC 2026のセクション6.1.2に行われていない[1]。
Any protocol or service that is currently at the Proposed Standard maturity level remains so.
提案された標準的な成熟度レベルで現在任意のプロトコルまたはサービスがそう残ります。
Any protocol or service that is currently at the Standard maturity level shall be immediately reclassified as an Internet Standard.
標準的な成熟度レベルで現在任意のプロトコルまたはサービスが直ちにインターネット標準として再分類されなければなりません。
Any protocol or service that is currently at the abandoned Draft Standard maturity level will retain that classification, absent explicit actions. Two possible actions are available:
放棄されたドラフト標準成熟レベルで現在任意のプロトコルまたはサービスがその分類、存在しない、明示的アクションを保持します。二つの可能なアクションが用意されています。
(1) A Draft Standard may be reclassified as an Internet Standard as soon as the criteria in Section 2.2 are satisfied.
（1）ドラフト標準とすぐに、セクション2.2で基準が満たされるようにインターネット標準として再分類されてもよいです。
(2) At any time after two years from the approval of this document as a BCP, the IESG may choose to reclassify any Draft Standard document as Proposed Standard.
（2）BCPとして、この文書の承認から2年後の任意の時点で、IESGは、提案された標準として任意の規格案の文書を再分類することもできます。
In practice, the annual review of Proposed Standard and Draft Standard documents after two years (called for in RFC 2026 [1]) has not taken place. Lack of this review has not revealed any ill effects on the Internet Standards Process. As a result, the requirement for this review is dropped. No review cycle is imposed on Standards Track documents at any maturity level.
実際には、2年後のProposed Standardとドラフト標準文書の年次レビューを取られていない場所（RFC 2026 [1]のために呼ばれます）。このレビューの欠如は、インターネット標準プロセス上の任意の悪影響が明らかになっていません。その結果、このレビューのための要件が削除されます。いいえレビューサイクルは、任意の成熟度レベルで標準化過程文書に課されていません。
Testing for interoperability is a long tradition in the development of Internet protocols and remains important for reliable deployment of services. The IETF Standards Process no longer requires a formal interoperability report, recognizing that deployment and use is sufficient to show interoperability.
相互運用性のためにテストすることは、インターネット・プロトコルの開発の長い伝統である、サービスの信頼性の高い展開のための重要なまま。 IETF標準化プロセスは、もはや展開と使用は相互運用性を示すのに十分であることを認識し、正式な相互運用性のレポートを必要としません。
Although no longer required by the IETF Standards Processes, RFC 5657 [2] can be helpful to conduct interoperability testing.
もはや、IETF標準化プロセスで必要とされるが、RFC 5657 [2]は、相互運用性テストを実施するために役立つことはできません。
This document does not directly affect the security of the Internet.
この文書は、直接インターネットのセキュリティに影響を与えません。
A two-tier Standards Track has been proposed many times. Spencer Dawkins, Charlie Perkins, and Dave Crocker made a proposal in 2003. Additional proposals were made by Scott Bradner in 2004, Brian Carpenter in June 2005, and Ran Atkinson in 2006. This document takes ideas from many of these prior proposals; it also incorporates ideas from the IESG discussion in May 2010, the IETF 78 plenary discussion in July 2010, and yet another proposal submitted by Spencer Dawkins, Dave Crocker, Eric Burger, and Peter Saint-Andre in November 2010.
2層標準化過程は何度も提案されています。スペンサードーキンス、チャーリーパーキンス、とDaveクロッカーは、2003年の追加案で提案をした2005年6月ブライアン・カーペンター、2004年にスコット・ブラッドナーによって作られた、そしてこの文書では、これらの従来の提案の多くからのアイデアを取り、2006年にアトキンソン蘭ました。それはまた、2010年5月、2010年11月にスペンサードーキンスデイブ・クロッカー、エリックバーガー、そしてピーター・サン・アンドレが提出した2010年7月IETF 78本会議の議論、およびさらに別の提案にIESGの議論からアイデアを採用しています。
[1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[1]ブラドナーの、S.、 "インターネット標準化プロセス - リビジョン3"、BCP 9、RFC 2026、1996年10月。
[2] Dusseault, L. and R. Sparks, "Guidance on Interoperation and Implementation Reports for Advancement to Draft Standard", BCP 9, RFC 5657, September 2009.
[2] Dusseault、L.とR.スパークスは、BCP 9、RFC 5657、2009年9月 "推進のための相互運用上の指針と実装レポートは、標準の起草します"。
Author's Address
著者のアドレス
Russell Housley Vigil Security, LLC EMail: housley@vigilsec.com
ラッセルHousley氏ビジルセキュリティ、LLCメール：housley@vigilsec.com
Dave Crocker Brandenburg InternetWorking EMail: dcrocker@bbiw.net
デイブ・クロッカーブランデンブルクインターネットワーキングメール：dcrocker@bbiw.net
Eric W. Burger Georgetown University EMail: eburger@standardstrack.com URI: http://www.standardstrack.com
エリック・W.バーガージョージタウン大学の電子メール：eburger@standardstrack.com URI：http://www.standardstrack.com