Network Working Group                                         S. Bradner
Request for Comments: 4775                                       Harvard
BCP: 125                                               B. Carpenter, Ed.
Category: Best Current Practice                                T. Narten
                                                           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).




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.


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.


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.


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.


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:


1. The requirement is straightforward and within the scope of whatever extension mechanism the base protocol includes.


   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.


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 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.


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.


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.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.


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.


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.


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.


4. Procedure for Review of Extensions

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.


There are several ways in which an extension to an IETF protocol can be considered for publication as an 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.


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.


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.


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).


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.'


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.


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:


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 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 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

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]


This document does not override such specific change processes.


6. Intellectual Property

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

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.


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

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.


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].


10. References
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.


[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米国



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

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



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米



Full Copyright Statement


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に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。



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


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は、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。



Funding for the RFC Editor function is currently provided by the Internet Society.

RFC Editor機能のための基金は現在、インターネット協会によって提供されます。