[要約] RFC 7127は、提案された標準の特性を評価するためのガイドラインです。その目的は、標準化プロセスの透明性と品質を向上させることです。
Internet Engineering Task Force (IETF) O. Kolkman Request for Comments: 7127 NLnet Labs BCP: 9 S. Bradner Updates: 2026 Harvard University Category: Best Current Practice S. Turner ISSN: 2070-1721 IECA, Inc. January 2014
Characterization of Proposed Standards
提案された規格の特徴
Abstract
概要
RFC 2026 describes the review performed by the Internet Engineering Steering Group (IESG) on IETF Proposed Standard RFCs and characterizes the maturity level of those documents. This document updates RFC 2026 by providing a current and more accurate characterization of Proposed Standards.
RFC 2026は、IETF Proposed Standard RFCsについてInternet Engineering Steering Group(IESG)が実施したレビューについて説明し、それらのドキュメントの成熟度を特徴付けています。このドキュメントは、提案された標準の最新かつより正確な特性を提供することによってRFC 2026を更新します。
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 5741.
このドキュメントは、IETF(Internet Engineering Task Force)の製品です。 Internet Engineering Steering Group(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/rfc7127.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http://www.rfc-editor.org/info/rfc7127で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright(c)2014 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. IETF Review of Proposed Standards . . . . . . . . . . . . . . 2 3. Characterization of Specifications . . . . . . . . . . . . . 3 3.1. Characterization of IETF Proposed Standard Specifications 3 3.2. Characteristics of Internet Standards . . . . . . . . . . 4 4. Further Considerations . . . . . . . . . . . . . . . . . . . 4 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 6. Normative References . . . . . . . . . . . . . . . . . . . . 4 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 5
In the two decades after publication of RFC 2026 [RFC2026], the IETF has evolved its review processes of Proposed Standard RFCs, and thus Section 4.1.1 of RFC 2026 no longer accurately describes IETF Proposed Standards.
RFC 2026 [RFC2026]の公開後20年で、IETFは提案された標準RFCのレビュープロセスを進化させたため、RFC 2026のセクション4.1.1はIETF提案された標準を正確に説明しなくなりました。
This document only updates the characterization of Proposed Standards from Section 4.1.1 of RFC 2026 and does not speak to or alter the procedures for the maintenance of Standards Track documents from RFC 2026 and RFC 6410 [RFC6410]. For complete understanding of the requirements for standardization, those documents should be read in conjunction with this document.
このドキュメントは、RFC 2026のセクション4.1.1から提案された標準の特性を更新するだけであり、RFC 2026およびRFC 6410 [RFC6410]からの標準トラックドキュメントのメンテナンス手順を説明または変更しません。標準化の要件を完全に理解するには、これらのドキュメントをこのドキュメントと併せて読む必要があります。
The entry-level maturity for the standards track is "Proposed Standard". A specific action by the IESG is required to move a specification onto the Standards Track at the "Proposed Standard" level.
標準化トラックのエントリーレベルの成熟度は「提案された標準」です。仕様を「提案された標準」レベルで標準化過程に移行するには、IESGによる特定のアクションが必要です。
Initially it was intended that most IETF technical specifications would progress through a series of maturity stages starting with Proposed Standard, then progressing to Draft Standard, then finally to Internet Standard (see Section 6 of RFC 2026). For a number of reasons this progression is not common. Many Proposed Standards are actually deployed on the Internet and used extensively, as stable protocols. This proves the point that the community often deems it unnecessary to upgrade a specification to Internet Standard. Actual practice has been that full progression through the sequence of standards levels is typically quite rare, and most popular IETF protocols remain at Proposed Standard. Over time, the IETF has developed a more extensive review process.
当初、ほとんどのIETF技術仕様は、提案された標準から始まり、ドラフト標準、最後にインターネット標準(RFC 2026のセクション6を参照)に至る一連の成熟段階を経て進行することが意図されていました。多くの理由により、この進行は一般的ではありません。多くの提案された標準は実際にインターネット上に展開され、安定したプロトコルとして広く使用されています。これは、コミュニティが仕様をインターネット標準にアップグレードする必要がないとしばしば考える点を証明しています。実際の実践では、一連の標準レベルの完全な進行は通常非常にまれであり、最も一般的なIETFプロトコルはProposed Standardのままです。時間の経過とともに、IETFはより広範なレビュープロセスを開発してきました。
IETF Proposed Standards documents have been subject to open development and review by the Internet technical community, generally including a number of formal cross-discipline reviews and, specifically, a security review. This is further strengthened in many cases by implementations and even the presence of interoperable code. Hence, IETF Proposed Standards are of such quality that they are ready for the usual market-based product development and deployment efforts into the Internet.
IETF Proposed Standardsドキュメントは、インターネット技術コミュニティによるオープンな開発とレビューの対象になっています。これには、一般に、複数の正式な分野横断的なレビュー、具体的にはセキュリティレビューが含まれます。これは、多くの場合、実装や相互運用可能なコードの存在によってさらに強化されます。したがって、IETF Proposed Standardsは、通常の市場ベースの製品開発とインターネットへの展開の取り組みに対応できる品質を備えています。
The text in the following section replaces Section 4.1.1 of RFC 2026. Section 3.2 is a verbatim copy of the characterization of Internet Standards from Section 4.1.3 of RFC 2026 and is provided for convenient reference. The text only provides the characterization; process issues for Draft and Internet Standards are described in RFC 2026 and its updates, specifically RFC 6410.
次のセクションのテキストは、RFC 2026のセクション4.1.1を置き換えます。セクション3.2は、RFC 2026のセクション4.1.3からのインターネット標準の特徴の逐語的なコピーであり、参照しやすいように提供されています。テキストは特性を提供するだけです。ドラフトおよびインターネット標準のプロセスの問題は、RFC 2026とその更新、特にRFC 6410で説明されています。
The entry-level maturity for the standards track is "Proposed Standard". A specific action by the IESG is required to move a specification onto the standards track at the "Proposed Standard" level.
標準化トラックのエントリーレベルの成熟度は「提案された標準」です。仕様を「提案された標準」レベルで標準トラックに移動するには、IESGによる特定のアクションが必要です。
A Proposed Standard specification is stable, has resolved known design choices, has received significant community review, and appears to enjoy enough community interest to be considered valuable.
提案された標準仕様は安定しており、既知の設計上の選択を解決し、重要なコミュニティレビューを受けており、価値があると見なされる十分なコミュニティの関心を楽しんでいるようです。
Usually, neither implementation nor operational experience is required for the designation of a specification as a Proposed Standard. However, such experience is highly desirable and will usually represent a strong argument in favor of a Proposed Standard designation.
通常、仕様をProposed Standardとして指定するために、実装や運用の経験は必要ありません。ただし、そのような経験は非常に望ましいものであり、通常は標準案の指定を支持する強力な論拠となります。
The IESG may require implementation and/or operational experience prior to granting Proposed Standard status to a specification that materially affects the core Internet protocols or that specifies behavior that may have significant operational impact on the Internet.
IESGは、コアインターネットプロトコルに重大な影響を与える仕様、またはインターネットに重大な運用上の影響を与える可能性のある動作を指定する仕様に標準案のステータスを付与する前に、実装または運用の経験を必要とする場合があります。
A Proposed Standard will have no known technical omissions with respect to the requirements placed upon it. Proposed Standards are of such quality that implementations can be deployed in the Internet. However, as with all technical specifications, Proposed Standards may be revised if problems are found or better solutions are identified, when experiences with deploying implementations of such technologies at scale is gathered.
提案された標準は、それに課せられた要件に関して、既知の技術的な省略はありません。提案された標準は、実装をインターネットに展開できるような品質のものです。ただし、すべての技術仕様と同様に、問題が見つかった場合、またはより優れたソリューションが特定された場合、そのようなテクノロジーの実装を大規模に展開した経験が集まったときに、標準案は改訂される場合があります。
A specification for which significant implementation and successful operational experience has been obtained may be elevated to the Internet Standard level. An Internet Standard (which may simply be referred to as a 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.
重要な実装と成功した運用経験が得られた仕様は、インターネット標準レベルに引き上げられる可能性があります。インターネット標準(単に標準と呼ばれることもあります)は、高度な技術的成熟度と、指定されたプロトコルまたはサービスがインターネットコミュニティに大きな利益をもたらすという一般に信じられている信念によって特徴付けられます。
Occasionally, the IETF may choose to publish as Proposed Standard a document that contains areas of known limitations or challenges. In such cases, any known issues with the document will be clearly and prominently communicated in the document, for example, in the abstract, the introduction, or a separate section or statement.
時折、IETFは、既知の制限または課題の領域を含むドキュメントをProposed Standardとして公開することを選択する場合があります。そのような場合、ドキュメントの既知の問題は、たとえば要約、導入、または個別のセクションやステートメントなど、ドキュメント内で明確かつ目立つように伝えられます。
This document does not directly affect the security of the Internet.
このドキュメントは、インターネットのセキュリティには直接影響しません。
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[RFC2026] Bradner、S。、「インターネット標準プロセス-リビジョン3」、BCP 9、RFC 2026、1996年10月。
[RFC6410] Housley, R., Crocker, D., and E. Burger, "Reducing the Standards Track to Two Maturity Levels", BCP 9, RFC 6410, October 2011.
[RFC6410] Housley、R.、Crocker、D。、およびE. Burger、「Reducing the Standards Track to Two Maturity Levels」、BCP 9、RFC 6410、2011年10月。
This document is inspired by a discussion at the open microphone session during the technical plenary at IETF 87. Thanks to, in alphabetical order, Jari Arkko, Carsten Bormann, Scott Brim, Randy Bush, Benoit Claise, Dave Cridland, Spencer Dawkins, Adrian Farrel, Stephen Farrell, Subramanian Moonesamy, and Pete Resnick for motivation, input, and review.
このドキュメントは、IETF 87の技術プレナリーでのオープンマイクセッションでの議論に触発されました。JariArkko、Carsten Bormann、Scott Brim、Randy Bush、Benoit Claise、Dave Cridland、Spencer Dawkins、Adrian Farrelのおかげで、 、モチベーション、インプット、レビューのためのスティーブン・ファレル、サブラマニアン・ムーネサミー、ピート・レズニック。
John Klensin and Dave Crocker have provided significant contributions.
John KlensinとDave Crockerは重要な貢献をしてくれました。
Authors' Addresses
著者のアドレス
Olaf Kolkman Stichting NLnet Labs Science Park 400 Amsterdam 1098 XH The Netherlands
Olaf Kolkman Stichting NLnet Labs Science Park 400アムステルダム1098 XHオランダ
EMail: olaf@nlnetlabs.nl URI: http://www.nlnetlabs.nl/
Scott O. Bradner Harvard University Information Technology Innovation and Architecture 8 Story St., Room 5014 Cambridge, MA 02138 United States of America
スコットO.ブラドナーハーバード大学情報技術の革新とアーキテクチャ8 Story St.、Room 5014 Cambridge、MA 02138 United States of America
Phone: +1 617 495 3864 EMail: sob@harvard.edu URI: http://www.harvard.edu/huit
Sean Turner IECA, Inc.
ショーンターナーIECA、Inc.
EMail: turners@ieca.com