[要約] RFC 6410は、標準化プロセスの成熟度レベルを2つに減らすことを提案しています。このRFCの目的は、標準化プロセスを簡素化し、効率を向上させることです。
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
標準を削減すると、2つの成熟度レベルになります
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）標準プロセスを更新します。主に、標準プロセスを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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2011 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ドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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.
このドキュメントは、RFC 2026 [1]で定義されているインターネット標準プロセスを変更します。近年、インターネットエンジニアリングタスクフォース（IETF）は、成熟度レベルを通じて文書を進めるのが難しいことを目撃しました：提案された標準、ドラフト標準、および最終的な標準。これらの変更は、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つの層の1つへの移行に対する重要なサポートを示しました。
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年間で、満期のはしごで進歩した仕様はほとんどありませんでした。インターネット標準のプロセスを3つの成熟レベルから2に変更することは、実装と展開エクスペリエンスからレッスンが仕様を改善するために使用される環境を作成することを目的としています。
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]では、仕様を3番目および最終成熟レベル（「標準」）に基づいてさらに進めることができる前に、異なるコードベースからの少なくとも2つの実装間の相互運用性を文書化するレポートが暫定ステップ（「ドラフト標準」）として文書化されるレポートが必要です。広範囲にわたる展開と使用。対照的に、このドキュメントでは、異なるコードベースからの複数の実装の広範な展開を通じて相互運用性を測定する必要があり、2つの個別のメトリックを1つに凝縮します。
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]では、広範囲にわたる展開は基本的に、ドラフト標準から標準への進歩に使用されるメトリックです。提案された基準を超えたこの同じメトリックを使用することは、成熟したはしごの上位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".
このドキュメントでは、RFC 2026 [1]で定義された3層の成熟したはしごを2層の成熟したはしごに置き換えます。仕様は、「標準トラック」として知られる2つの成熟度レベルのセットを通じてインターネット標準になります。これらの成熟レベルは、「提案された標準」および「インターネット標準」です。
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.
仕様は、提案された基準からインターネット標準に至るまで進歩するにつれて修正される可能性があります。インターネット標準への進歩のために改訂された仕様が提案された場合、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.
提案された標準の指定された要件は変更されません。それらは、RFC 2026 [1]で指定されたとおりのままです。新しい要件は導入されていません。既存の公開された要件は緩和されていません。
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全体の最後の呼び出しで、ドキュメントが提案された標準からインターネット標準に進むことを確認しています。再分類の要求は、基準がどのように満たされているかの説明とともに、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にIETFを介してIETFアナウンスメーリングリストに通知します。RFC 2026 [1]のセクション6.1.2に変更は行われません。
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:
現在放棄されたドラフト標準の成熟度レベルにあるプロトコルまたはサービスは、明示的なアクションがない場合、その分類を保持します。2つの可能なアクションが利用可能です。
(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年後に提案された標準およびドラフト標準文書の年次レビュー（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層の標準トラックが何度も提案されています。スペンサー・ドーキンス、チャーリー・パーキンス、およびデイブ・クロッカーは2003年に提案をしました。2004年にスコット・ブラッドナーによって追加の提案が行われ、2005年6月にブライアン・カーペンター、2006年にアトキンソンを運営しました。また、2010年5月のIESGディスカッション、2010年7月のIETF 78プレナリーディスカッションのアイデア、および2010年11月にスペンサードーキンス、デイブクロッカー、エリックバーガー、ピーターセントドレが提出した別の提案も組み込まれています。
[1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[1] Bradner、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. Sparks、「標準のドラフトへの進歩のための相互操作と実装レポートに関するガイダンス」、BCP 9、RFC 5657、2009年9月。
Author's Address
著者の連絡先
Russell Housley Vigil Security, LLC EMail: housley@vigilsec.com
Russell Housley Vigil Security、LLCメール：housley@vigilsec.com
Dave Crocker Brandenburg InternetWorking EMail: dcrocker@bbiw.net
Dave Crocker Brandenburgインターネットワーキングメール：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