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.

このドキュメントはインターネットコミュニティのためのインターネットBest Current Practicesを指定し、改善のための議論と提案を要求します。このメモの配布は無制限です。

Copyright Notice

著作権表示

Copyright (C) The IETF Trust (2006).

著作権(C)IETFトラスト(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.

この文書は、IETFプロトコルへの拡張のための要件を考慮し、他の標準開発機関(SDOの)およびベンダーで主に向けられています。これは、正式な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
        
1. Introduction
1. はじめに

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ワーキンググループ(のWG)は、典型的には、これらのプロトコルは、将来的に拡張することができるメカニズムを含みます。もちろん、プロトコルへの拡張を設計するための良い原則です。成功したプロトコルの一般的な定義は広く当初の予想ではない方法で使用される状態になるものです。うまく設計された拡張メカニズムは、プロトコルの進化を促進し、それが簡単に相互運用可能な方法で増分変更をロールアウトするのに役立ちます。同時に、経験は、プロトコルが開発され、それ以降の拡張機能は、慎重かつ基本プロトコル、既存の実装、および現在の動作の練習を完全に理解した上で行わなければならないとき、拡張機能は明らかに必要なものに限定されるべきであることが示されています。しかし、健全な拡張性設計の建築原則を説明するために、この文書の目的ではありません。

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プロセスは、IETF全体のレビューとIESG承認のための通常のプロセスを含め、続いています。このように開発された拡張機能は、他の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.
        

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は、独自のプロトコルへの拡張のために産むどんな手順に従う必要があります。

2. Technical Risks in Extensions
Extensionsの2.技術リスク

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自体は、各WGは、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.

非IETFの拡張機能のドキュメントは時々ので、仕様の品質を評価する相互運用性を検証し、(過去および将来の拡張を含む)他の拡張機能との互換性を検証することは困難または不可能であることができ、入手が難しいことができます。

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.

拡張子について言うことができるすべてのことは、変化に同等以上の力で適用されます - 実際には、定義により、プロトコルのバリエーションは、相互運用性を損傷します。彼らは、それゆえ、強烈に精査する必要があります。拡張子は、機能を追加し、うまく設計された場合は、古いものと新しい実装間の相互運用性を可能にします。バリエーションは古いものと新しい実装を相互運用しないことがあり、このような方法で機能を変更します。このドキュメントでは、どのような機能拡張について言われることもバリエーションに適用されます。

3. General Considerations
3.一般的な考慮事項
3.1. The Importance of Interoperability
3.1. 相互運用性の重要性

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.

この相互運用性の定義の他の結果は、IETFが他とのプロトコルを実装する一つの製品を交換する能力値ということです。すべての製品は、実装の相互運用性のための十分な機能のコアセットがあるように、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内部または外部に提案されたプロトコル拡張を評価する際に、これらの考慮事項を適用します。

3.2. Registered Values and the Importance of IANA Assignments
3.2. 登録された値とIANAの割り当ての重要性

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.

拡張子は、多くの場合、追加の値を利用する可能性がある(多くの場合、単に新しい「TLV」(タイプ - 長さ - 値)フィールドを追加することで)既存のIANAレジストリに追加。このような新しい値が適切(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.

経験は、このことの重要性は、多くの場合、拡張設計時に過小評価されていることを示しています。設計者は、時には新しいコードポイントを尋ねる彼らである、あるいは単に撮影のためにあることを前提としています。これは危険です。同じ値が、後に正式ので、相互運用性の問題を保証し、別の機能に割り当てられることばかりプロトコル値を取る誰かが見つけることはあまりにも可能性があります。

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の割り当てにし、該当する基準に特に注意を払う必要があります。

3.3. Significant Extensions Require Technical Review
3.3. 大幅な機能拡張は、技術的な審査が必要

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です。

3.4. Quality and Consistency
3.4. 品質と一貫性

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の主題の専門家は、にアクセスして確認することができ、明確でよく書かれた仕様に文書化されなければなりません。理想的には、このような文書では、用語使用して、これらの専門家が容易に早い段階で提案された技術的な変更内容を識別することができます拡張されていない仕様と十分に一致しているコンテンツ、インターネットドラフトとして公開されます。

3.5. The Role of Formal Liaisons
3.5. 正式なリエゾンの役割

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の数と場所での正式なリエゾンを持っています。連絡プロセスのドキュメントは[RFC4053]及び[RFC4691]、[RFC4052]です。エンジニアリングレベルでの非公式の通信は(例えば、他のSDOからの専門家がIETF会議やメーリングリストに参加することを歓迎している)必要があるとして、これらのリエゾンチャンネルは、議論や拡張を検討するための関連として使用する必要があります。正式なリエゾンが存在しない場合は、IETFでの接点は、関連のWGの議長、最も適切なエリアディレクター、または、疑わしい場合には、全体としてIESGにする必要があります。

4. Procedure for Review of Extensions
拡張機能の見直し4.手順

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.

IETF内で開発IETFプロトコルへ1.拡張は、まさに新しいデザインのように、通常の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.

IRTF研究グループで議論IETFプロトコルへ2.拡張機能は十分に通常の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.

RFC編集者に提出独立で説明IETFプロトコルへ3.拡張機能は、現在、BCP 92 [RFC3932]で説明され、IESGレビューの対象となっています。適切な場合には、IESGは、完全なIETF処理が必要であることをRFC編集者に助言する、またはパブリケーションを続行する前に、関連する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つの条件が満たされていない場合は、次のステップは、地域で活躍WGや、IETFで利用可能な、少なくとも、関連する専門知識があるかどうかを確認するために、関連する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.

IETF内で、標準化された拡張のための標準開発プロセスの要件を特定するSDOの場合には(適切な連絡を維持しながら)、強く、非IETF規格を公開に優先して推奨されます。それ以外の場合は、実装者のコミュニティは、品質、互換性、相互運用性、および知的財産の条件を超えるなし一元管理して、さまざまなソースから入手した、様々なスタイルに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提示の状況に非常に好適である「既成事実を。」

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が正確持っていることを確認するために、なおそれらの割り当てを作成する方法についてのガイダンス。

5. Some Specific Issues
5.いくつかの固有の問題

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モジュールのための比較的一般的であり、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は、執筆時点でアクティブなRADIUS拡張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.

この文書では、このような特定の変更プロセスを無効にすることはありません。

6. Intellectual Property
6.知的財産

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外の誰もが心の中でこれらの法的規制や権利を負担しなければなりません。

7. Security Considerations
7.セキュリティの考慮事項

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レビュー中に考慮されなければなりません。

8. IANA Considerations
8. IANAの考慮事項

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は、[RFC2434]ベンダーや他のSDOのためのプロトコルパラメータの割り当てを行うことが要求されたときにそれらを含むすべてのRFCのIANAの考慮事項、およびBCP 26の一般的な考慮事項を尊重すること、すなわち、この文書の要求事項に注意を払うようにIANAを要請します。

9. Acknowledgements
9.謝辞

This document is heavily based on an earlier draft under a different title by Scott Bradner and Thomas Narten.

この文書は重くスコット・ブラッドナーとトーマス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によって一緒に置かれた、それはジョンLoughney、ヘンリクLevkowetz、マークTownsley、ランディブッシュ、バーナードAboba、他からのフィードバックに応じて改訂されました。

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.

テッドハーディー、スコット・ブリム、ダンRomascanu、ヤリArkko、ロア・アンダーソン、エードリアンファレル、ロイ・フィールディング、キースムーア、バーナードAboba、エルウィン・デイヴィス、スティーブン・トローブリッジ、およびテッドTs'oさんも、この文書に貴重なコメントをしました。

Sam Hartman contributed the section on interoperability.

サム・ハートマンは、相互運用性に関するセクションを貢献しました。

This document was produced using the xml2rfc tool [RFC2629].

この文書は、xml2rfcツール[RFC2629]を使用して製造しました。

10. References
10.参考文献
10.1. Normative References
10.1. 引用規格

[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.

[RFC2026]ブラドナーの、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]マンキン、A.、ブラドナー、S.、マーイ、R.、ウィリス、D.、オット、J.、およびB.ローゼン、 "セッション開始プロトコル(SIP)のための変更処理"、BCP 67、RFC 3427、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 Editorのドキュメント:プロシージャ"、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]ブラドナーの、S.、 "質問の投稿IETF権"、BCP 78、RFC 3978、2005年3月。

[RFC3979] Bradner, S., "Intellectual Property Rights in IETF Technology", BCP 79, RFC 3979, March 2005.

[RFC3979]ブラドナーの、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.およびインターネットアーキテクチャ委員会、BCP 102、RFC 4052、2005年4月 "IETFリエゾン関係の管理のためのIABのプロセス"。

[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]トローブリッジ、S.、ブラ​​ドナー、S.、およびF.ベイカー、BCP 103、RFC 4053、2005年4月 "およびIETFから連絡文を処理するための手順"。

[RFC4181] Heard, C., "Guidelines for Authors and Reviewers of MIB Documents", BCP 111, RFC 4181, September 2005.

[RFC4181]聞いた、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]フェナー、B.、RFC 4727、2006年11月 "のIPv4、IPv6の、ICMPv4の、ICMPv6の、UDP、およびTCPヘッダには実験値"。

10.2. Informative References
10.2. 参考文献

[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]アンデション、L.とA.ファレル、「(MPLS)をマルチプロトコルラベルスイッチングのための変更処理と一般化MPLS(GMPLS)プロトコルおよび手順」、進歩、2006年10月に作業。

[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June 1999.

[RFC2629]ローズ、M.、 "ライティングI-DSおよびXMLを使用している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.、ウィレンス、S.、ルーベン、A.、およびW.シンプソン、RFC 2865、2000年6月 "ユーザーサービス(RADIUS)でリモート認証ダイヤル"。

[RFC4691] Andersson, L., "Guidelines for Acting as an IETF Liaison to Another Organization", RFC 4691, October 2006.

[RFC4691]アンデション、L.、RFC 4691、2006年10月 "別の組織にIETFリエゾンとして機能するためのガイドライン"。

Authors' Addresses

著者のアドレス

Scott Bradner Harvard University 29 Oxford St. Cambridge, MA 02138 US

スコット・ブラッドナーハーバード大学29オックスフォードセントケンブリッジ、MA 02138米国

EMail: sob@harvard.edu

メールアドレス:sob@harvard.edu

Brian Carpenter, Ed. IBM 8 Chemin de Blandonnet 1214 Vernier Switzerland

ブライアン・カーペンター、エド。 IBM 8シュマン・デ・Blandonnet 1214バーニアスイス

EMail: brc@zurich.ibm.com

メールアドレス:brc@zurich.ibm.com

Thomas Narten IBM 3039 Cornwallis Ave. PO Box 12195 - BRQA/502 Research Triangle Park, NC 27709-2195 US

トーマスNarten氏IBM 3039コーンウォリスアベニュー。私書箱12195 - BRQA / 502リサーチトライアングルパーク、ノースカロライナ州27709から2195米

EMail: narten@us.ibm.com

メールアドレス:narten@us.ibm.com

Full Copyright Statement

完全な著作権声明

Copyright (C) The IETF Trust (2006).

著作権(C)IETFトラスト(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.

この文書およびここに含まれる情報は、上に提供される基礎とCONTRIBUTOR、ORGANIZATION彼/彼女が表すOR(もしあれば)後援が「そのまま」、インターネット学会、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.

IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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 Editor機能のための基金は現在、インターネット協会によって提供されます。