[要約] RFC 4775は、プロトコルの拡張と変更の手順に関するガイドラインです。その目的は、プロトコルの拡張や変更を行う際の一貫性と互換性を確保することです。
Network Working Group S. Bradner
Request for Comments: 4775 Harvard
BCP: 125 B. Carpenter, Ed.
Category: Best Current Practice T. Narten
IBM
December 2006
Procedures for Protocol Extensions and Variations
プロトコル拡張とバリエーションの手順
Status of This Memo
本文書の位置付け
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネットの最良のプラクティスを指定し、改善のための議論と提案を要求します。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The IETF Trust (2006).
Copyright（c）The IETF Trust（2006）。
Abstract
概要
This document discusses procedural issues related to the extensibility of IETF protocols, including when it is reasonable to extend IETF protocols with little or no review, and when extensions or variations need to be reviewed by the IETF community. Experience has shown that extension of protocols without early IETF review can carry risk. The document also recommends that major extensions to or variations of IETF protocols only take place through normal IETF processes or in coordination with the IETF.
このドキュメントでは、IETFプロトコルの拡張性に関連する手続き上の問題について説明します。これには、IETFプロトコルをほとんどまたはまったくレビューなしで拡張することが合理的である場合、およびIETFコミュニティが拡張またはバリエーションをレビューする必要があります。経験によると、初期のIETFレビューなしでプロトコルの拡張がリスクを伴うことが示されています。また、このドキュメントでは、IETFプロトコルの主要な拡張またはバリエーションは、通常のIETFプロセスによってのみ、またはIETFと調整されることを推奨しています。
This document is directed principally at other Standards Development Organizations (SDOs) and vendors considering requirements for extensions to IETF protocols. It does not modify formal IETF processes.
このドキュメントは、主に他の標準開発組織（SDO）およびIETFプロトコルへの拡張の要件を考慮したベンダーに向けられています。正式なIETFプロセスを変更しません。
Table of Contents
目次
1. Introduction ....................................................2
2. Technical Risks in Extensions ...................................3
3. General Considerations ..........................................4
3.1. The Importance of Interoperability .........................4
3.2. Registered Values and the Importance of IANA Assignments ...5
3.3. Significant Extensions Require Technical Review ............5
3.4. Quality and Consistency ....................................6
3.5. The Role of Formal Liaisons ................................6
4. Procedure for Review of Extensions ..............................7
5. Some Specific Issues ...........................................10
6. Intellectual Property ..........................................10
7. Security Considerations ........................................10
8. IANA Considerations ............................................11
9. Acknowledgements ...............................................11
10. References ....................................................11
10.1. Normative References .....................................11
10.2. Informative References ...................................12
BCP 9 [RFC2026] is the current definition of the IETF standards track. This process applies not only to the initial definition of a protocol, but also to any subsequent updates, such that continued interoperability can be guaranteed. However, it is not always clear whether extensions to a protocol should be made within the IETF process, especially when they originate outside the IETF community. This document lays down guidelines and procedures for such extensions.
BCP 9 [RFC2026]は、IETF標準トラックの現在の定義です。このプロセスは、プロトコルの初期定義だけでなく、後続の更新にも適用され、継続的な相互運用性を保証できます。ただし、特にIETFコミュニティの外部から発生する場合、IETFプロセス内でプロトコルへの拡張を行う必要があるかどうかは、常に明確ではありません。このドキュメントには、このような拡張機能のガイドラインと手順が定められています。
When developing protocols, IETF Working Groups (WGs) typically include mechanisms whereby these protocols can be extended in the future. It is, of course, a good principle to design extensibility into protocols; a common definition of a successful protocol is one that becomes widely used in ways not originally anticipated. Well-designed extensibility mechanisms facilitate the evolution of protocols and help make it easier to roll out incremental changes in an interoperable fashion. At the same time, experience has shown that extensibility features should be limited to what is clearly necessary when the protocol is developed, and any later extensions should be done carefully and with a full understanding of the base protocol, existing implementations, and current operational practice. However, it is not the purpose of this document to describe the architectural principles of sound extensibility design.
プロトコルを開発する場合、IETFワーキンググループ（WGS）には通常、これらのプロトコルを将来拡張できるメカニズムが含まれます。もちろん、それはプロトコルの拡張性を設計するための良い原則です。成功したプロトコルの一般的な定義は、当初予想されていなかった方法で広く使用されるプロトコルです。適切に設計された拡張性メカニズムは、プロトコルの進化を促進し、相互運用可能な方法で増分変化を容易にするのに役立ちます。同時に、エクスペリエンスは、プロトコルが開発されたときに明らかに必要なものに拡張性機能を制限する必要があり、後の拡張機能を慎重に行い、基本プロトコル、既存の実装、および現在の運用慣行を完全に理解して行う必要があることを示しています。。ただし、このドキュメントの目的は、音の拡張性設計のアーキテクチャの原則を説明する目的ではありません。
When extensions to IETF protocols are made within the IETF, the normal IETF process is followed, including the normal processes for IETF-wide review and IESG approval. Extensions developed in this way should respect the same architectural principles and technical criteria as any other IETF work.
IETFプロトコルへの拡張がIETF内で行われると、IETF全体のレビューおよびIESGの承認のための通常のプロセスを含む、通常のIETFプロセスに従います。この方法で開発された拡張機能は、他のIETFが機能するのと同じアーキテクチャの原則と技術的基準を尊重する必要があります。
In addition to the IETF itself, other Standards Development Organizations (SDOs), vendors, and technology fora may identify a requirement for an extension to an IETF protocol. The question addressed by this document is how such bodies should proceed. There are several possible scenarios:
IETF自体に加えて、他の標準開発組織（SDO）、ベンダー、およびテクノロジーフォーラは、IETFプロトコルの拡張の要件を特定する場合があります。この文書で扱われている質問は、そのような体がどのように進むべきかです。いくつかの可能なシナリオがあります：
1. The requirement is straightforward and within the scope of whatever extension mechanism the base protocol includes.
1. 要件は簡単であり、ベースプロトコルに含まれる拡張メカニズムの範囲内です。
2. The requirement is, or may be, outside that scope, and: 1. The IETF still has an active WG in the area; 2. The IETF has no active WG, but has relevant expertise; 3. The IETF no longer has a nucleus of relevant expertise.
2. 要件は、その範囲外である、またはその範囲外である可能性があります。2. IETFにはアクティブなWGがありませんが、関連する専門知識があります。3. IETFには、関連する専門知識の核がありません。
Especially in the latter three cases, there are technical risks in extension design, described in the next section. These risks are higher when extensions to IETF protocols are made outside the IETF and without consulting the IETF.
特に後者の3つのケースでは、次のセクションで説明する拡張設計には技術的なリスクがあります。これらのリスクは、IETFプロトコルへの拡張がIETFの外側で、IETFに相談せずに行われると高くなります。
This document is focused on appropriate procedures and practices to minimize the chance that extensions developed outside the IETF will encounter these risks and, therefore, become useless or, worse, damaging to interoperability. Architectural considerations are documented elsewhere. This document is directed principally at other SDOs and vendors considering requirements for extensions to IETF protocols. It does not modify formal IETF processes.
このドキュメントは、IETFの外側で開発された拡張がこれらのリスクに遭遇する可能性を最小限に抑えるために、適切な手順と実践に焦点を当てており、したがって、役に立たない、またはさらに悪いことに相互運用性に損害を与えます。建築上の考慮事項は他の場所で文書化されています。このドキュメントは、主にIETFプロトコルへの拡張の要件を考慮した他のSDOおよびベンダーに向けられています。正式なIETFプロセスを変更しません。
The IETF claims no special position. Everything said here about IETF protocols would apply with equal force to protocols specified by any SDO. The IETF should follow whatever procedures another SDO lays down for extensions to its own protocols, if the IETF identifies a need for such an extension.
IETFは特別な位置を主張していません。ここで、IETFプロトコルについては、SDOによって指定されたプロトコルに同等の力で適用されると述べています。IETFは、IETFがそのような拡張機能の必要性を特定している場合、別のSDOが独自のプロトコルに拡張するためにレイズする手順に従う必要があります。
Extensions may be developed without full understanding of why the existing protocol was designed the way that it is -- e.g., what ideas were brought up during the original development and rejected because of some problem with them. Also, extensions could unintentionally negate some key function of the existing protocol (such as security or congestion control). Design choices can be made without analyzing their impact on the protocol as a whole, and basic underlying architectural principles of the protocol can be violated. Also, there is a risk that mutually incompatible extensions may be developed independently.
拡張は、既存のプロトコルがそのように設計された理由を完全に理解せずに開発することができます。また、拡張は意図せずに既存のプロトコル（セキュリティや輻輳制御など）のいくつかの重要な機能を無効にする可能性があります。設計の選択は、プロトコル全体への影響を分析せずに行うことができ、プロトコルの基本的な基礎となるアーキテクチャの原則に違反する可能性があります。また、相互に互換性のない拡張機能を個別に開発できるリスクがあります。
Of course, the IETF itself is not immune to such mistakes, suggesting a need for WGs to document their design decisions (including paths rejected) and some rationale for those decisions, for the benefit of both those within the IETF and those outside the IETF, perhaps years later.
もちろん、IETF自体はそのような間違いの免疫がなく、IETF内のIETF内の人々の両方の利益のために、設計上の決定（拒否されたパスを含む）とそれらの決定のいくつかの理論的根拠を文書化する必要があることを示唆しています。おそらく数年後。
Documentation of non-IETF extensions can sometimes be hard to obtain, so assessing the quality of the specification, verifying interoperability, and verifying compatibility with other extensions (including past and future extensions) can be hard or impossible.
非ITF拡張機能のドキュメントを取得するのが難しい場合があるため、仕様の品質を評価し、相互運用性を検証し、他の拡張機能（過去および将来の拡張機能を含む）との互換性を検証することは困難または不可能です。
A set of interrelated extensions to multiple protocols typically carries a greater danger of interoperability issues or incompatibilities than a simple extension. Consequently, it is important that such proposals receive earlier and more in-depth review than unitary extensions.
複数のプロトコルへの相互に関連する拡張セットは、通常、単純な拡張よりも相互運用性の問題または非互換性のより大きな危険をもたらします。その結果、そのような提案は、単一の拡張よりも早く、より詳細なレビューを受けることが重要です。
All that can be said about extensions applies with equal or greater force to variations -- in fact, by definition, protocol variations damage interoperability. They must, therefore, be intensely scrutinized. An extension adds features and, if well designed, allows interoperability between old and new implementations. A variation modifies features in such a way that old and new implementations may not interoperate. Throughout this document, what is said about extensions also applies to variations.
拡張機能について言えることはすべて、バリエーションに等しいまたはより大きな力で適用されます - 実際、定義上、プロトコルの変動は相互運用性を損傷します。したがって、それらは激しく精査されなければなりません。拡張機能は機能を追加し、適切に設計されている場合は、古い実装と新しい実装間の相互運用性を可能にします。バリエーションは、古い実装と新しい実装が相互運用しないように機能を変更します。このドキュメント全体で、拡張機能について言われていることは、バリエーションにも適用されます。
According to its Mission Statement [RFC3935], the IETF produces high quality, relevant technical and engineering documents, including protocol standards. The mission statement goes on to say that the benefit of these standards to the Internet "is in interoperability - that multiple products implementing a standard are able to work together in order to deliver valuable functions to the Internet's users".
そのミッションステートメント[RFC3935]によると、IETFは、プロトコル標準を含む高品質で関連する技術的およびエンジニアリング文書を作成しています。ミッションステートメントは、インターネットに対するこれらの基準の利点は「相互運用性である - 標準を実装する複数の製品が、インターネットのユーザーに貴重な機能を提供するために協力できる」と述べています。
One consequence of this mission is that the IETF designs protocols for the single Internet. The IETF expects its protocols to work the same everywhere. Protocol extensions designed for limited environments may be reasonable provided that products with these extensions interoperate with products without the extensions. Extensions that break interoperability are unacceptable when products with and without the extension are mixed. It is the IETF's experience that this tends to happen on the Internet even when the original designers of the extension did not expect this to happen.
このミッションの結果の1つは、IETFが単一のインターネットのプロトコルを設計することです。IETFは、そのプロトコルがどこでも同じ動作することを期待しています。限られた環境向けに設計されたプロトコル拡張機能は、これらの拡張機能を備えた製品が拡張機能のない製品と相互運用することを条件に合理的です。拡張機能の有無にかかわらず製品が混合されている場合、相互運用性を破壊する拡張は受け入れられません。IETFの経験は、これが拡張機能の元の設計者がこれが起こるとは思わなかったときでさえ、インターネット上で起こる傾向があるということです。
Another consequence of this definition of interoperability is that the IETF values the ability to exchange one product implementing a protocol with another. The IETF often specifies mandatory-to-implement functionality as part of its protocols so that there is a core set of functionality sufficient for interoperability that all products implement. The IETF tries to avoid situations where protocols need to be profiled to specify which optional features are required for a given environment, because doing so harms interoperability on the Internet as a whole.
相互運用性のこの定義のもう1つの結果は、IETFがプロトコルを別の製品と実装する1つの製品を交換する機能を評価することです。IETFは、多くの場合、すべての製品が実装する相互運用性に十分な機能セットがあるように、そのプロトコルの一部として必須の機能性を指定します。IETFは、特定の環境に必要なオプション機能を指定するためにプロトコルをプロファイルする必要がある状況を避けようとします。
The IETF, and in particular the IESG, will apply these considerations when evaluating protocol extensions proposed inside or outside the IETF.
IETF、特にIESGは、IETFの内側または外側で提案されているプロトコル拡張を評価するときに、これらの考慮事項を適用します。
An extension is often likely to make use of additional values added to an existing IANA registry (in many cases, simply by adding a new "TLV" (type-length-value) field). It is essential that such new values are properly registered by the applicable procedures, including expert review where applicable (see BCP 26, [RFC2434]). Extensions may even need to create new IANA registries in some cases.
拡張機能は、既存のIANAレジストリに追加された追加の値を使用する可能性が高いことがよくあります（多くの場合、新しい「TLV」（タイプ長価値）フィールドを追加するだけで）。このような新しい値は、該当する場合は専門家のレビューを含む、該当する手順によって適切に登録されることが不可欠です（BCP 26、[RFC2434]を参照）。拡張機能は、場合によっては新しいIANAレジストリを作成する必要がある場合があります。
Experience shows that the importance of this is often underestimated during extension design; designers sometimes assume that a new codepoint is theirs for the asking, or even simply for the taking. This is hazardous; it is far too likely that someone just taking a protocol value will find that the same value will later be formally assigned to another function, thus guaranteeing an interoperability problem.
経験は、これの重要性が拡張設計中にしばしば過小評価されることを示しています。デザイナーは、新しいCodePointが質問のために、または単に撮影のためのものであると仮定することがあります。これは危険です。プロトコル値をとるだけで、同じ値が後で正式に別の関数に割り当てられているため、相互運用性の問題が保証されることがわかります。
In many cases, IANA assignment requests trigger a thorough technical review of the proposal by a designated IETF expert reviewer. Requests are sometimes refused after such a review. Thus, extension designers must pay particular attention to any needed IANA assignments and to the applicable criteria.
多くの場合、IANAの割り当てリクエストは、指定されたIETFエキスパートレビューアによる提案の徹底的な技術レビューをトリガーします。そのようなレビューの後、リクエストは時々拒否されます。したがって、拡張設計者は、必要なIANAの割り当てと該当する基準に特に注意を払う必要があります。
Some extensions may be considered minor (e.g., adding a straightforward new TLV to an application protocol, which will only impact a subset of hosts) and some may be considered major (e.g., adding a new IP option type, which will potentially impact every node on the Internet). This is essentially a matter of judgment. It could be argued that anything requiring at most Expert Review in [RFC2434] is probably minor, and anything beyond that is major. However, even an apparently minor extension may have unforeseen consequences on interoperability. Thus, the distinction between major and minor is less important than ensuring that the right amount of technical review takes place in either case. In general, the expertise for such review lies within the same SDO that developed the original protocol. Therefore, the expertise for such review for IETF protocols lies within the IETF.
一部の拡張機能はマイナーと見なされる場合があります（たとえば、アプリケーションプロトコルに簡単な新しいTLVを追加します。これはホストのサブセットにのみ影響を与えます）、一部は主要なものと見なされる場合があります（たとえば、すべてのノードに影響を与える可能性のある新しいIPオプションタイプを追加します。インターネット上で）。これは本質的に判断の問題です。[RFC2434]で最も専門家のレビューを必要とするものはすべてマイナーであり、それ以上のものは主要なものであると主張することができます。ただし、明らかにマイナーな拡張でさえ、相互運用性に予期せぬ結果をもたらす可能性があります。したがって、メジャーとマイナーの区別は、どちらの場合でも適切な量の技術的レビューが行われることを保証するよりも重要ではありません。一般に、そのようなレビューの専門知識は、元のプロトコルを開発した同じSDO内にあります。したがって、IETFプロトコルのこのようなレビューの専門知識はIETF内にあります。
There may sometimes be doubt whether a particular proposal is or is not truly a protocol extension. When in doubt, it is preferable to err on the side of additional review. However, it should be noted that if an 'extension' only consists of registering a new value with IANA in a First Come First Served registry [RFC2434], this document is not intended to require formal IETF review. Informal review by experts may, nevertheless, be valuable. In other cases (Section 5), there is a well-specified procedure for extensions that should be followed.
特定の提案が実際にプロトコル拡張であるかどうか疑問がある場合があります。疑わしい場合は、追加のレビューの側で誤りを犯すことが望ましいです。ただし、「拡張機能」が最初に提供された最初のレジストリ[RFC2434]でIANAに新しい値を登録することでのみ構成されている場合、このドキュメントは正式なIETFレビューを必要とすることを意図していないことに注意する必要があります。それにもかかわらず、専門家による非公式のレビューは価値があるかもしれません。他のケース（セクション5）では、拡張に適合した手順があります。
The only safe rule is that, even if an extension appears minor to the person proposing it, early review by subject matter experts is advisable. For protocols that have been developed in the IETF, the appropriate forum for such review is the IETF, either in the relevant WG or Area, or by individual IETF experts if no such WG exists.
唯一の安全なルールは、たとえ拡張機能がそれを提案している人にマイナーに見えたとしても、主題の専門家による早期レビューが推奨されることです。IETFで開発されたプロトコルの場合、そのようなレビューのための適切なフォーラムは、関連するWGまたはエリアのいずれか、またはそのようなWGが存在しない場合は個々のIETF専門家によってIETFです。
In order to be adequately reviewed by relevant experts, a proposed extension must be documented in a clear and well-written specification that IETF subject matter experts have access to and can review. Ideally, such a document would be published as an Internet Draft, using terminology and content that is sufficiently consistent with the unextended specification that these experts can readily identify the technical changes proposed at an early stage.
関連する専門家によって適切にレビューされるためには、提案された拡張機能を、IETFの主題専門家がアクセスし、レビューできる明確でよく書かれた仕様に文書化する必要があります。理想的には、このようなドキュメントは、これらの専門家が初期段階で提案されている技術的な変更を容易に特定できるという非拡張仕様と十分に一致する用語とコンテンツを使用して、インターネットドラフトとして公開されます。
The IETF has formal liaisons in place with a number of SDOs; documentation of the liaison process is in [RFC4052], [RFC4053], and [RFC4691]. These liaison channels should be used as relevant for discussing and reviewing extensions, as should informal communication at the engineering level (for example, experts from other SDOs are welcome to participate in IETF meetings and mailing lists). Where formal liaison does not exist, the point of contact in the IETF should be the Chairs of relevant WGs, the most appropriate Area Director, or, in case of doubt, the IESG as a whole.
IETFには、多くのSDOが施された正式なリエゾンがあります。リエゾンプロセスの文書化は、[RFC4052]、[RFC4053]、および[RFC4691]にあります。これらの連絡チャネルは、エンジニアリングレベルでの非公式のコミュニケーションと同様に、拡張機能の議論とレビューに関連するものとして使用する必要があります（たとえば、他のSDOの専門家はIETF会議やメーリングリストに参加することを歓迎します）。正式な連絡が存在しない場合、IETFの接触点は、関連するWGSの椅子、最も適切なエリアディレクター、または疑いのある場合、IESG全体である必要があります。
In some cases, explicit provision is made in the relevant RFCs for extending individual IETF protocols. Nothing in this document overrides such procedures. Some such cases are mentioned in Section 5.
場合によっては、個々のIETFプロトコルを拡張するための関連するRFCで明示的な規定が作成されます。このドキュメントには、そのような手順を無効にするものはありません。そのようなケースのいくつかは、セクション5に記載されています。
There are several ways in which an extension to an IETF protocol can be considered for publication as an RFC:
IETFプロトコルの拡張をRFCとして公開するために考慮する方法はいくつかあります。
1. Extensions to IETF protocols developed within the IETF will be subject to the normal IETF process, exactly like new designs. It is not suggested that this is a panacea; appropriate cross-working-group and cross-area review is needed within the IETF to avoid oversights and mistakes.
1. IETF内で開発されたIETFプロトコルへの拡張は、新しいデザインとまったく同じように、通常のIETFプロセスの対象となります。これが万能薬であることは示唆されていません。監視や間違いを避けるために、IETF内で適切なクロスワーキンググループとクロスエリアのレビューが必要です。
2. Extensions to IETF protocols discussed in an IRTF Research Group may well be the prelude to regular IETF discussion. However, a Research Group may desire to specify an experimental extension before the work is mature enough for IETF processing. In this case, the Research Group is required to involve appropriate IETF or IANA experts in their process to avoid oversights.
2. IRTF研究グループで議論されたIETFプロトコルへの拡張は、定期的なIETFディスカッションの前奏曲である可能性があります。ただし、研究グループは、IETF処理に十分に成熟する前に、実験的拡張を指定することを望んでいる場合があります。この場合、研究グループは、監視を避けるために、適切なIETFまたはIANAの専門家をプロセスに関与させる必要があります。
3. Extensions to IETF protocols described in Independent Submissions to the RFC Editor are subject to IESG review, currently described in BCP 92 [RFC3932]. If appropriate, the IESG advises the RFC Editor that full IETF processing is needed, or that relevant IANA procedures need to be followed before publication can proceed. Note that Independent Submissions cannot be placed on the IETF Standards Track; they would need to enter full IETF processing.
3. RFCエディターへの独立した提出で説明されているIETFプロトコルへの拡張は、現在BCP 92 [RFC3932]で説明されているIESGレビューの対象となります。必要に応じて、IESGはRFCエディターに、完全なIETF処理が必要であること、または公開が進む前に関連するIANA手順に従う必要があることをアドバイスします。IETF標準トラックには、独立した提出物を配置できないことに注意してください。完全なIETF処理を入力する必要があります。
Where vendors or other SDOs identify a requirement for extending an IETF protocol, their first step should be to consider the scenarios listed in Section 1. If the requirement is straightforward and within the scope of a documented extension mechanism, the way is clear, and the documented mechanism must be followed. If these two conditions are not met, the next step should be to contact the relevant IETF Area Director to check whether there is an active WG in the area or, at least, relevant expertise available in the IETF. At this point, it will be possible to select the most appropriate of the above three routes. Regular IETF process is most likely to be suitable, assuming sufficient interest can be found in the IETF community. IRTF process is unlikely to be suitable unless there is a genuine research context for the proposed extension.
ベンダーまたは他のSDOがIETFプロトコルを拡張するための要件を特定している場合、最初のステップはセクション1にリストされているシナリオを考慮することです。文書化されたメカニズムに従う必要があります。これらの2つの条件が満たされていない場合、次のステップは、関連するIETFエリアディレクターに連絡して、この地域にアクティブなWGがあるか、少なくともIETFで利用可能な関連する専門知識があるかを確認することです。この時点で、上記の3つのルートの中で最も適切なものを選択することが可能です。IETFコミュニティで十分な関心が見られると仮定すると、通常のIETFプロセスが適切である可能性が最も高くなります。IRTFプロセスは、提案された拡張のための真の研究コンテキストがない限り、適切ではない可能性がありません。
In the event that the IETF no longer has relevant expertise, there are still two choices to discuss with the Area Director: bring the work to the IETF (i.e., the IETF imports expertise) or reach mutual agreement to do the work elsewhere (i.e., the IETF explicitly exports change control).
IETFに関連する専門知識がなくなった場合、エリアディレクターと話し合うための2つの選択肢がまだあります。IETF（つまり、IETFの専門知識）に作業を持ち込むか、他の場所で作業を行うための相互合意に達します（つまり、IETFは、変更制御を明示的にエクスポートします）。
In the case of an SDO that identifies a requirement for a standardized extension, a standards development process within the IETF (while maintaining appropriate liaison) is strongly recommended in preference to publishing a non-IETF standard. Otherwise, the implementor community will be faced with a standard split into two or more parts in different styles, obtained from different sources, with no unitary control over quality, compatibility, interoperability, and intellectual property conditions. Note that, since participation in the IETF is open, there is no formality or restriction for participants in other SDOs choosing to work in the IETF as well. In some cases (see Section 5), the IETF has well-defined procedures for this in place.
標準化された拡張機能の要件を識別するSDOの場合、IETF内の標準開発プロセス（適切なリエゾンを維持しながら）は、非IITF標準を公開することを好むために強く推奨されます。それ以外の場合、実装者コミュニティは、異なるスタイルの2つ以上のパートに分割され、異なるソースから得られ、品質、互換性、相互運用性、知的財産条件を単一の制御せずに取得します。IETFへの参加は開かれているため、IETFでの作業を選択する他のSDOの参加者には形式や制限はないことに注意してください。場合によっては（セクション5を参照）、IETFには、これについて明確に定義された手順があります。
Naturally, SDOs can and do develop scenarios, requirements, and architectures based on IETF specifications. It is only actual protocol extensions and changes that need to go through the IETF process. However, there is large risk of wasted effort if significant investment is made in planning stages for use of IETF technology without early review and feedback from the IETF. Other SDOs are encouraged to communicate informally or formally with the IETF as early as possible, to avoid false starts. Early technical review in a collaborative spirit is of great value. Each SDO can "own" its ideas and discuss them in its own fora, but should start talking to the IETF experts about those ideas the moment the idea is well formulated. It is understood that close collaboration may be needed in order that the IETF experts correctly understand the systems architecture envisaged by the other SDO. This is much preferable to a situation where another SDO presents the IANA and the IETF with a 'fait accompli.'
当然のことながら、SDOはIETF仕様に基づいてシナリオ、要件、およびアーキテクチャを開発できます。IETFプロセスを通過する必要があるのは、実際のプロトコル拡張と変更のみです。ただし、IETFからの早期レビューとフィードバックなしにIETFテクノロジーを使用するための計画段階に多大な投資が行われた場合、無駄な努力の大きなリスクがあります。他のSDOは、誤った開始を避けるために、できるだけ早くIETFと非公式にまたは正式に通信することをお勧めします。共同精神での初期の技術レビューは非常に価値があります。それぞれのSDOは、そのアイデアを「所有」し、独自のフォーラで議論することができますが、アイデアが十分に定式化されている瞬間に、それらのアイデアについてIETFの専門家と話し始めるはずです。IETFの専門家が他のSDOが想定しているシステムアーキテクチャを正しく理解するために、緊密なコラボレーションが必要になる場合があると理解されています。これは、別のSDOがIANAとIETFに「fait compri」を提示する状況よりもはるかに好ましいです。
Vendors that identify a requirement for an extension are strongly recommended to start informal discussion in the IETF and to publish a preliminary Internet Draft describing the requirements. This will allow the vendor, and the community, to evaluate whether there is community interest and whether there are any major or fundamental issues. However, in the case of a vendor that identifies a requirement for a proprietary extension that does not generate interest in the IETF (or IRTF) communities, an Independent Submission to the RFC Editor is strongly recommended in preference to publishing a proprietary document. Not only does this bring the draft to the attention of the community, but it also ensures a minimum of review [RFC3932], and (if published as an RFC) makes the proprietary extension available to the whole community.
拡張機能の要件を特定するベンダーは、IETFで非公式の議論を開始し、要件を説明する予備的なインターネットドラフトを公開するために強くお勧めします。これにより、ベンダーとコミュニティは、コミュニティの関心があるかどうか、および主要な問題または基本的な問題があるかどうかを評価することができます。ただし、IETF（またはIRTF）コミュニティに関心を生み出さない独自の拡張の要件を特定するベンダーの場合、RFCエディターへの独立した提出は、独自のドキュメントを公開することを好むために強く推奨されます。これにより、ドラフトがコミュニティの注意を引くだけでなく、最小限のレビュー[RFC3932]を保証し、（RFCとして公開されている場合）コミュニティ全体が独自の拡張を利用できるようにします。
If, despite these recommendations, a vendor or SDO does choose to publish its own specification for an extension to an IETF protocol, the following guidance applies:
これらの推奨事項にもかかわらず、ベンダーまたはSDOがIETFプロトコルの拡張のために独自の仕様を公開することを選択した場合、次のガイダンスが適用されます。
o Extensions to IETF protocols should be well, and publicly, documented, and reviewed at an early stage by the IETF community to be sure that the extension does not undermine basic assumptions and safeguards designed into the protocol (such as security functions) or its architectural integrity.
o IETFプロトコルへの拡張機能は、IETFコミュニティによって初期段階で拡張が順調かつ公開され、文書化され、レビューされている必要があります。。
o Vendors and other SDOs are formally requested to submit any such proposed publications for IETF review, and are invited to actively participate in the IETF process. Submission may be by an established liaison channel if it exists, or by direct communication with the relevant WG or the IESG. This should be done at an early stage, before a large investment of effort has taken place, in case basic problems are revealed. When there is a formal liaison in place between the other SDO and the IETF, the liaison channel should be used to ensure that review takes place, both by relevant experts and by established review teams or Directorates within the IETF. If there is no formal liaison, the other SDO or vendor should ask the IESG (or a relevant Area Director) to obtain such reviews. Note that general aspects such as security, internationalization, and management may need review, as well as the protocol as such.
o ベンダーおよびその他のSDOは、IETFレビューのためにそのような提案された出版物を提出するように正式に要求され、IETFプロセスに積極的に参加するよう招待されています。提出は、それが存在する場合、確立されたリエゾンチャネルによって、または関連するWGまたはIESGとの直接的な通信によるものです。これは、基本的な問題が明らかになった場合に備えて、多大な努力が行われる前に、初期段階で行う必要があります。他のSDOとIETFの間に正式なリエゾンが設置されている場合、リエゾンチャネルを使用して、関連する専門家とIETF内の確立されたレビューチームまたは局長によってレビューが行われるようにする必要があります。正式なリエゾンがない場合、他のSDOまたはベンダーは、IESG（または関連するエリアディレクター）にそのようなレビューを取得するように依頼する必要があります。セキュリティ、国際化、管理などの一般的な側面と、そのようなプロトコルだけでなく、レビューが必要になる場合があることに注意してください。
o In the case of extensions involving only routine IANA parameter assignments, for which there is an underlying IETF specification containing clear IANA Considerations, this request is satisfied as long as those considerations are satisfied (see [RFC2434]). Anything beyond this requires an explicit protocol review by experts within the IETF.
o 明確なIANAの考慮事項を含む基礎となるIETF仕様がある日常のIANAパラメーター割り当てのみを含む拡張機能の場合、これらの考慮事項が満たされている限り、この要求は満たされます（[RFC2434]を参照）。これ以上のものは、IETF内の専門家による明示的なプロトコルレビューが必要です。
o Note that, like IETF specifications, such proposed publications must include an IANA Considerations section to ensure that protocol parameter assignments that are needed to deploy extensions are not made until after a proposed extension has received adequate review, and then to ensure that IANA has precise guidance on how to make those assignments.
o IETF仕様と同様に、このような提案された出版物には、拡張機能が適切なレビューを受け取った後、IANAに正確なガイダンスがあることを確認するまで、拡張機能を展開するために必要なプロトコルパラメーター割り当てが作成されないことを確認するために、IANAの考慮事項セクションを含める必要があることに注意してください。それらの割り当ての作成方法について。
It is relatively common for MIB modules, which are all, in effect, extensions of the SMI data model, to be defined or extended outside the IETF. BCP 111 [RFC4181] offers detailed guidance for authors and reviewers.
MIBモジュールでは比較的一般的です。MIBモジュールは、すべてのSMIデータモデルの拡張機能であり、IETFの外側で定義または拡張されます。BCP 111 [RFC4181]は、著者とレビュアーに詳細なガイダンスを提供しています。
A number of protocols have foreseen experimental values for certain IANA parameters, so that experimental usages and extensions may be tested without need for a special parameter assignment. It must be stressed that such values are not intended for production use or as a way to evade the type of technical review described in this document. See [RFC3692] and [RFC4727].
多くのプロトコルが特定のIANAパラメーターの実験値を予見しているため、特別なパラメーターの割り当てを必要とせずに実験的使用と拡張機能をテストすることができます。そのような価値は、生産の使用を目的としていないか、このドキュメントに記載されている技術的なレビューの種類を回避する方法として強調する必要があります。[RFC3692]および[RFC4727]を参照してください。
RADIUS [RFC2865] is designed to carry attributes and allow definition of new attributes. But it is important that discussion of new attributes involve the IETF community of experts knowledgeable about the protocol's architecture and existing usage in order to fully understand the implications of a proposed extension. Adding new attributes without such discussion creates a high risk of interoperability or functionality failure. For this reason among others, the IETF has an active RADIUS Extensions WG at the time of writing.
RADIUS [RFC2865]は、属性を運ぶように設計され、新しい属性の定義を許可するように設計されています。しかし、新しい属性の議論には、提案された拡張の意味を完全に理解するために、プロトコルのアーキテクチャと既存の使用に関する知識豊富な専門家のIETFコミュニティが関係することが重要です。このような議論なしで新しい属性を追加すると、相互運用性または機能障害のリスクが高くなります。このため、IETFには、執筆時点でアクティブな半径拡張wgがあります。
There are certain documents that specify a change process for specific IETF protocols, such as: The SIP change process [RFC3427] The (G)MPLS change process [CHANGEPROC]
以下など、特定のIETFプロトコルの変更プロセスを指定する特定のドキュメントがあります。SIP変更プロセス[RFC3427]（g）MPLS変更プロセス[ChangeProc]
This document does not override such specific change processes.
このドキュメントは、このような特定の変更プロセスをオーバーライドしません。
All IETF documents fall under the IETF's intellectual property rules, BCP 78 [RFC3978] and BCP 79 [RFC3979], as amended. In particular, there are restrictions on the production of derivative works, and there are rights that remain with the original authors. Anybody outside the IETF considering an extension based on an IETF document must bear these legal restrictions and rights in mind.
すべてのIETF文書は、修正されたとおり、IETFの知的財産規則であるBCP 78 [RFC3978]およびBCP 79 [RFC3979]に該当します。特に、デリバティブ作品の生産には制限があり、元の著者に残っている権利があります。IETFドキュメントに基づいた拡張機能を考慮して、IETFの外側の誰でも、これらの法的制限と権利を念頭に置いている必要があります。
An extension must not introduce new security risks without also providing an adequate counter-measure, and in particular it must not inadvertently defeat security measures in the unextended protocol. This aspect must always be considered during IETF review.
拡張機能は、適切な対策も提供せずに新しいセキュリティリスクを導入してはなりません。特に、拡張されたプロトコルのセキュリティ対策を不注意に打ち負かしてはなりません。この側面は、IETFレビュー中に常に考慮する必要があります。
The IETF requests IANA to pay attention to the requirements of this document when requested to make protocol parameter assignments for vendors or other SDOs, i.e., to respect the IANA Considerations of all RFCs that contain them, and the general considerations of BCP 26 [RFC2434].
IETFは、ベンダーまたは他のSDOのプロトコルパラメーター割り当てを作成するように要求されたときにこのドキュメントの要件に注意を払うようにIANAに要求します。。
This document is heavily based on an earlier draft under a different title by Scott Bradner and Thomas Narten.
この文書は、スコット・ブラッドナーとトーマス・ナルテンによる別のタイトルの下での以前のドラフトに大きく基づいています。
That earlier draft stated: The initial version of this document was put together by the IESG in 2002. Since then, it has been reworked in response to feedback from John Loughney, Henrik Levkowetz, Mark Townsley, Randy Bush, Bernard Aboba, and others.
以前のドラフトは、このドキュメントの初期バージョンは2002年にIESGによってまとめられました。それ以来、ジョン・ラフニー、ヘンリック・レヴコウェッツ、マーク・タウンズリー、ランディ・ブッシュ、バーナード・アボバなどからのフィードバックに応じて作り直されました。
Ted Hardie, Scott Brim, Dan Romascanu, Jari Arkko, Loa Andersson, Adrian Farrel, Roy Fielding, Keith Moore, Bernard Aboba, Elwyn Davies, Stephen Trowbridge, and Ted Ts'o also made valuable comments on this document.
テッド・ハーディ、スコット・ブリム、ダン・ロマスカヌ、ジャリ・アークコ、ロア・アンダーソン、エイドリアン・ファレル、ロイ・フィールディング、キース・ムーア、バーナード・アボバ、エルウィン・デイヴィス、スティーブン・トローブリッジ、テッド・ツェは、この文書についても貴重なコメントをしました。
Sam Hartman contributed the section on interoperability.
サム・ハートマンは、相互運用性に関するセクションに貢献しました。
This document was produced using the xml2rfc tool [RFC2629].
このドキュメントは、XML2RFCツール[RFC2629]を使用して作成されました。
[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月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC2434] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 2434、1998年10月。
[RFC3427] Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, J., and B. Rosen, "Change Process for the Session Initiation Protocol (SIP)", BCP 67, RFC 3427, December 2002.
[RFC3427] Mankin、A.、Bradner、S.、Mahy、R.、Willis、D.、Ott、J.、およびB. Rosen、「セッション開始プロトコルの変更プロセス（SIP）」、BCP 67、RFC3427、2002年12月。
[RFC3692] Narten, T., "Assigning Experimental and Testing Numbers Considered Useful", BCP 82, RFC 3692, January 2004.
[RFC3692] Narten、T。、「有用と見なされる実験数とテスト数の割り当て」、BCP 82、RFC 3692、2004年1月。
[RFC3932] Alvestrand, H., "The IESG and RFC Editor Documents: Procedures", BCP 92, RFC 3932, October 2004.
[RFC3932] Alvestrand、H。、「IESGおよびRFCエディタードキュメント：手順」、BCP 92、RFC 3932、2004年10月。
[RFC3935] Alvestrand, H., "A Mission Statement for the IETF", BCP 95, RFC 3935, October 2004.
[RFC3935] Alvestrand、H。、「IETFのミッションステートメント」、BCP 95、RFC 3935、2004年10月。
[RFC3978] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC 3978, March 2005.
[RFC3978] Bradner、S。、「貢献におけるIETFの権利」、BCP 78、RFC 3978、2005年3月。
[RFC3979] Bradner, S., "Intellectual Property Rights in IETF Technology", BCP 79, RFC 3979, March 2005.
[RFC3979] Bradner、S。、「IETFテクノロジーの知的財産権」、BCP 79、RFC 3979、2005年3月。
[RFC4052] Daigle, L. and Internet Architecture Board, "IAB Processes for Management of IETF Liaison Relationships", BCP 102, RFC 4052, April 2005.
[RFC4052] Daigle、L。およびInternet Architecture Board、「IETFリエゾン関係の管理のためのIABプロセス」、BCP 102、RFC 4052、2005年4月。
[RFC4053] Trowbridge, S., Bradner, S., and F. Baker, "Procedures for Handling Liaison Statements to and from the IETF", BCP 103, RFC 4053, April 2005.
[RFC4053] Trowbridge、S.、Bradner、S。、およびF. Baker、「IETFとの＆from the IETFとの操作手順」、BCP 103、RFC 4053、2005年4月。
[RFC4181] Heard, C., "Guidelines for Authors and Reviewers of MIB Documents", BCP 111, RFC 4181, September 2005.
[RFC4181] Heard、C。、「MIB文書の著者およびレビュアーのガイドライン」、BCP 111、RFC 4181、2005年9月。
[RFC4727] Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4, ICMPv6, UDP, and TCP Headers", RFC 4727, November 2006.
[RFC4727] Fenner、B。、「IPv4、IPv6、ICMPV4、ICMPV6、UDP、およびTCPヘッダーの実験値」、RFC 4727、2006年11月。
[CHANGEPROC] Andersson, L. and A. Farrel, "Change Process for Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Protocols and Procedures", Work in Progress, October 2006.
[ChangeProc] Andersson、L。およびA. Farrel、「マルチプロトコルラベルスイッチング（MPLS）および一般化されたMPLS（GMPLS）プロトコルと手順の変更プロセス」、2006年10月の進行中。
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June 1999.
[RFC2629] Rose、M。、「XMLを使用したI-DSおよびRFCの書き込み」、RFC 2629、1999年6月。
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
[RFC2865] Rigney、C.、Willens、S.、Rubens、A。、およびW. Simpson、「リモート認証ダイヤルインユーザーサービス（RADIUS）」、RFC 2865、2000年6月。
[RFC4691] Andersson, L., "Guidelines for Acting as an IETF Liaison to Another Organization", RFC 4691, October 2006.
[RFC4691] Andersson、L。、「別の組織へのIETF連絡役として行動するためのガイドライン」、RFC 4691、2006年10月。
Authors' Addresses
著者のアドレス
Scott Bradner Harvard University 29 Oxford St. Cambridge, MA 02138 US
スコットブラッドナーハーバード大学29オックスフォードセントケンブリッジ、マサチューセッツ州02138 US
EMail: sob@harvard.edu
Brian Carpenter, Ed. IBM 8 Chemin de Blandonnet 1214 Vernier Switzerland
ブライアン・カーペンター、編IBM 8 Chemin de Blandonnet 1214 Vernier Switzerland
EMail: brc@zurich.ibm.com
Thomas Narten IBM 3039 Cornwallis Ave. PO Box 12195 - BRQA/502 Research Triangle Park, NC 27709-2195 US
Thomas Narten IBM 3039 Cornwallis Ave. PO Box 12195 -BRQA/502 Research Triangle Park、NC 27709-2195 US
EMail: narten@us.ibm.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2006).
Copyright（c）The IETF Trust（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST, AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースは免責明示的または暗示されたすべての保証。ここでの情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。