RFC4775 日本語訳
4775 Procedures for Protocol Extensions and Variations. S. Bradner, B.Carpenter, Ed., T. Narten. December 2006. (Format: TXT=32797 bytes) (Also BCP0125) (Status: BEST CURRENT PRACTICE)
プログラムでの自動翻訳です。
英語原文
Network Working Group S. Bradner
Request for Comments: 4775 Harvard
BCP: 125 B. Carpenter, Ed.
Category: Best Current Practice T. Narten
IBM
December 2006
コメントを求めるワーキンググループS.ブラドナーの要求をネットワークでつないでください: 4775ハーバードBCP: エド125B.大工、カテゴリ: 最も良い現在の練習T.Narten IBM2006年12月
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).
IETFが信じる著作権(C)(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.
このドキュメントは主に他のStandards Development Organizations(SDOs)とIETFプロトコルと拡大のための要件を考える業者で指示されます。 それは正式なIETFの過程を変更しません。
Bradner, et al. Best Current Practice [Page 1] RFC 4775 Procedures for Protocol Extensions December 2006
ブラドナー、他 プロトコル拡大2006年12月のための最も良い現在の習慣[1ページ]RFC4775手順
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. 序論…2 2. 拡大における技術的なリスク…3 3. 一般問題…4 3.1. 相互運用性の重要性…4 3.2. 値とIANA課題の重要性を示します…5 3.3. 重要な拡張子は技術審査を必要とします…5 3.4. 品質と一貫性…6 3.5. 正式な連絡の役割…6 4. 拡大のレビューのための手順…7 5. いくつかの特定の問題…10 6. 知的所有権…10 7. セキュリティ問題…10 8. IANA問題…11 9. 承認…11 10. 参照…11 10.1. 標準の参照…11 10.2. 有益な参照…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.
BCP9[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 Working Groups(WGs)は将来これらのプロトコルを広げることができるメカニズムを通常含んでいます。 もちろん、プロトコルに伸展性を設計するのは、良い原則です。 うまくいっているプロトコルの一般的な定義は広く元々予期されなかった方法で使用されるようになるものです。 よく設計された伸展性メカニズムは、共同利用できるファッションでプロトコルの発展を容易にして、漸進的変化を押して伸ばすのをより簡単にするのを助けます。 同時に、経験はプロトコルが開発しているとき、伸展性機能を明確に必要なことに制限するべきであり、慎重とベースプロトコル、既存の実現、および現在の操作上の習慣の十分な理解でどんな後の拡大もするべきであるのを示しました。 しかしながら、音の伸展性デザインの建築原則について説明するのは、このドキュメントの目的ではありません。
Bradner, et al. Best Current Practice [Page 2] RFC 4775 Procedures for Protocol Extensions December 2006
ブラドナー、他 プロトコル拡大2006年12月のための最も良い現在の習慣[2ページ]RFC4775手順
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自身に加えて、他のStandards Development Organizations(SDOs)、業者、および技術フォーラムは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. そして、要件はあるか、またはその範囲の外にあるかもしれない、: 1. IETFはその領域にまだアクティブなWGを持っています。 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プロトコルと拡大のための要件を考える他のSDOsと業者で指示されます。 それは正式な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は別のSDOが拡大のためにそれ自身のプロトコルに定めるどんな手順にも従うはずです、IETFがそのような拡大のために必要なものを見分けるなら。
2. Technical Risks in 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
拡大はそれが道ですが、既存のプロトコルが設計された理由に関する十分な理解なしで発生するかもしれません--例えばどんな考えが、オリジナルの開発の間、持って来られて、それらに関する何らかの問題で拒絶されましたか? また、拡大は既存のプロトコル(セキュリティか輻輳制御などの)の何らかの主要な機能を何気なく否定するかもしれません。 それらの衝撃を分析しないで、全体でプロトコル、および基本的な基本的にデザイン選択をすることができます。
Bradner, et al. Best Current Practice [Page 3] RFC 4775 Procedures for Protocol Extensions December 2006
ブラドナー、他 プロトコル拡大2006年12月のための最も良い現在の習慣[3ページ]RFC4775手順
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自身はそのような誤りに免疫がありません、WGsがそれらの決定のために彼らのデザイン決定(経路が拒絶した包含)と何らかの原理を記録する必要性を示して、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.
複数のプロトコルへの1セットの相関的な拡大は相互運用性問題か両立し難いことという単純拡大より重大な危険を通常運びます。 その結果、そのような提案が単一の拡大よりさらに早くて徹底的なレビューを受け取るのは、重要です。
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".
Mission Statement[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
この任務の1つの結果はIETFがただ一つのインターネットにプロトコルを設計するということです。 IETFは、プロトコルがいたる所で同じように働くと予想します。 これらの拡大を伴う製品が製品で拡大なしで共同利用すれば、限られた環境のために設計されたプロトコル拡大は合理的であるかもしれません。 製品であるときに、相互運用性を壊す拡大は容認できません。
Bradner, et al. Best Current Practice [Page 4] RFC 4775 Procedures for Protocol Extensions December 2006
ブラドナー、他 プロトコル拡大2006年12月のための最も良い現在の習慣[4ページ]RFC4775手順
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.
複雑であった拡大のあるなしにかかわらず。 これが、拡大のオリジナルのデザイナーが、これが起こると予想さえしなかったとき、インターネットで起こる傾向があるのは、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がプロトコルを実行する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の中、または、IETFの外で提案されたプロトコル拡大を評価するとき、IETF、および特にIESGはこれらの問題を適用するでしょう。
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.
拡大はしばしば既存のIANA登録(多くのケースと、単に新しい"TLV"(長さの値をタイプする)分野を加えるのによる)に加えられた加算値を利用しそうです。 そのような新しい値が適切な手順で適切に示されるのは、不可欠です、適切であるところに専門のレビューを含んでいて(BCP26を見てください、[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課題と適用基準に関する特別の注意も向けなければなりません。
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
いくつかの拡大が小さい方であると(例えば、ホストの部分集合に影響を与えるだけであるアプリケーション・プロトコルに簡単な新しいTLVを追加します)考えられるかもしれません、そして、或るものは主要であると(例えば、新しいIPオプションタイプを加えます)考えられるかもしれません。潜在的に、タイプはインターネットのあらゆるノードに影響を与えるでしょう。 これは本質的には判断の問題です。 それ
Bradner, et al. Best Current Practice [Page 5] RFC 4775 Procedures for Protocol Extensions December 2006
ブラドナー、他 プロトコル拡大2006年12月のための最も良い現在の習慣[5ページ]RFC4775手順
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.
論争されて、[RFC2434]でExpert Reviewを高々必要とするその何でもたぶん小さい方であり、それを超えたものが何か主要であるということであるかもしれません。 しかしながら、明らかに小さい方の拡大さえ相互運用性に予期しない結果を持っているかもしれません。 したがって、技術審査の正しい量がどちらの場合でも行われるのを確実にするほど少佐と未成年者の区別は重要ではありません。 一般に、そのようなレビューのための専門的技術はオリジナルのプロトコルを開発したのと同じ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.
疑問が特定の提案があるか、本当に、プロトコル拡大でないことにかかわらず時々あるかもしれません。 追加レビューの側で間違えるのが疑問で望ましいときに。 しかしながら、'拡大'がFirst Come First Served登録[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かAreaのIETFであるか個々のIETF専門家で、そのようなWGがいいえなら存在します。
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内容の専門家が近づく手段を持っている明確で上手に書かれた仕様に記録しなければならなくて、論評できます。 理想的に、そのようなドキュメントはインターネットDraftとして発表されて、これらの専門家が容易に特定できる「非-広げ」られた仕様と十分一致した用語と内容を使用して、技術変化は初期のときに提案しました。
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は多くのSDOsと共に適所に正式な連絡を持っています。 連絡の過程のドキュメンテーションが[RFC4052]、[RFC4053]、および[RFC4691]にあります。 これらの連絡チャンネルは拡大について議論して、見直すのにおいて関連するとして使用されるべきです、工学レベルにおける非公式のコミュニケーションであるべきであることのように(例えば、IETFミーティングとメーリングリストに参加するのにおいて他のSDOsからの専門家を歓迎します)。 正式な連絡が存在しないところでは、IETFの連絡先は全体で関連WGs、最も適切なAreaディレクター、または疑わしい場合はIESGのChairsであるべきです。
Bradner, et al. Best Current Practice [Page 6] RFC 4775 Procedures for Protocol Extensions December 2006
ブラドナー、他 プロトコル拡大2006年12月のための最も良い現在の習慣[6ページ]RFC4775手順
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プロトコルを広げるために関連RFCsで明白な設備をします。 何も本書ではそのような手順をくつがえしません。 そのようないくつかの場合がセクション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 Research Groupで議論したIETFプロトコルへの拡大はたぶん定期的なIETF議論へのプレリュードでしょう。 しかしながら、Research Groupは、IETF処理において、仕事が十分熟している前に実験的な拡大を指定することを望むかもしれません。 この場合、Research Groupは、見落としを避けるために彼らの過程の適切な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 Editorへの無党派Submissionsで説明されたIETFプロトコルへの拡大は、IESGレビューを受けることがあって、現在、BCP92[RFC3932]で説明されています。 適切であるなら、IESGは、完全なIETF処理が必要である、または関連IANA手順が、公表が続くことができる前に続かれる必要であるとRFC Editorに忠告します。 無党派SubmissionsをIETF Standards Trackに置くことができないことに注意してください。 彼らは、完全な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.
業者か他のSDOsがIETFプロトコルを広げるための要件を特定するところでは、彼らの第一歩はセクション1に記載されたシナリオを考えることであるべきです。 要件が簡単であり、記録された拡大メカニズムの範囲の中では、道が明確であり、記録されたメカニズムに従わなければならないなら。 これらの2つの条件が満たされないなら、次のステップは領域かIETFで利用可能な少なくとも関連専門的技術にはアクティブなWGがあるかをチェックするために関連IETF Areaディレクターに連絡することであるべきです。 ここに、上の3つのルートにおける最も好個を選択するのは可能でしょう。 IETF共同体で十分な関心を見つけることができると仮定して、通常のIETFの過程は適当である最も傾向があります。 提案された拡大のための本物の研究関係がない場合、IRTFの過程は適当でありそうにはありません。
Bradner, et al. Best Current Practice [Page 7] RFC 4775 Procedures for Protocol Extensions December 2006
ブラドナー、他 プロトコル拡大2006年12月のための最も良い現在の習慣[7ページ]RFC4775手順
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に関連専門的技術がもうない場合、Areaディレクターと議論する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規格を発行することに優先してIETF(適切な連絡を維持している間)の中の規格開発の過程は強く推薦されます。 さもなければ、得られたさまざまな原因と異なったスタイルで作成者社会は品質、互換性、相互運用性、および知的所有権条件の単一の規制なしで2つ以上の部品への標準の分裂に直面するでしょう。 IETFへの参加が開いているので関係者のためのどんな堅苦しさも制限もまた、IETFで働くのを選ぶ他のSDOsにないことに注意してください。 いくつかの場合(セクション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.'
当然、SDOsは開発して、IETF仕様に基づくシナリオ、要件、および構造を開発できます。 それは、実際のプロトコル拡張子とIETFの過程に直面する必要がある変化にすぎません。 しかしながら、IETF技術の使用のためにIETFから早めのレビューとフィードバックなしで計画段階で重要な投資をするなら、無駄な努力の大きいリスクがあります。 他のSDOsは非公式か正式にできるだけ早く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
拡大のための要件を特定する業者は、IETFで四角ばらない意見の交換を始めて、要件について説明する予備のインターネットDraftを発行するのが強く推薦されます。 これは業者、および共同体を許容するために共同体関心があるかどうかと、何か主要であるか基本的な問題があるかどうか評価することを望んでいます。 しかしながら、IETF(または、IRTF)共同体への関心を呼ばない独占拡大のための要件を特定する業者の場合では、独占ドキュメントを発表することに優先してRFC Editorへの無党派Submissionは強く推薦されます。 唯一でない、これは草稿を持って来ます。
Bradner, et al. Best Current Practice [Page 8] RFC 4775 Procedures for Protocol Extensions December 2006
ブラドナー、他 プロトコル拡大2006年12月のための最も良い現在の習慣[8ページ]RFC4775手順
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.
共同体の注意、それだけで、また、最小レビュー[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 業者と他のSDOsはIETFレビューのためにそのようなあらゆる提案された刊行物を提出するよう正式に要求されていて、活発にIETFの過程に参加するよう誘われています。 それが存在しているか、または関連WGかIESGとのダイレクトコミュニケーションであるなら、服従が確立した連絡チャンネルであるかもしれません。 初期のときにこれをするべきです、努力の多額の投資が行われる前に、基本的問題が明らかにされるといけないので。 他のSDOとIETFの間に正式な連絡係が適所にいるとき、連絡チャンネルはレビューが行われるのを保証するのに使用されるべきです、IETFの中の確立したレビューの関連専門家とチームかDirectoratesによる両方。 どんな正式な連絡もいなければ、もう片方のSDOか業者が、そのようなレビューを得るようにIESG(または、関連Areaディレクター)に頼むべきです。 セキュリティや、国際化や、管理などの一般的な局面がそういうもののレビュー、およびプロトコルを必要とするかもしれないことに注意してください。
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 Considerationsを含む基本的な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 Considerations部を含まなければなりません。
Bradner, et al. Best Current Practice [Page 9] RFC 4775 Procedures for Protocol Extensions December 2006
ブラドナー、他 プロトコル拡大2006年12月のための最も良い現在の習慣[9ページ]RFC4775手順
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の外で定義されるか、または広げられるためにモデル化されます。(モジュールはすべてです)。 BCP111[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 Extensions 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の知的所有権規則、BCP78[RFC3978]、およびBCP79[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レビューの間、いつもこの局面を考えなければなりません。
Bradner, et al. Best Current Practice [Page 10] RFC 4775 Procedures for Protocol Extensions December 2006
ブラドナー、他 プロトコル拡大2006年12月のための最も良い現在の習慣[10ページ]RFC4775手順
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は、彼らを含むすべてのRFCsのIANA Considerations、およびBCP26[RFC2434]の一般的な問題を尊敬するためにすなわち、業者か他のSDOsのためのプロトコルパラメタ課題をするよう要求されているときにはこのドキュメントの要件に注意を向けるよう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、Henrik 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.
また、テッド・ハーディー、スコットBrim、ダンRomascanu、ヤリArkko、Loaアンデション、エードリアン・ファレル、ロイFielding、キース・ムーア、バーナードAboba、Elwynデイヴィース、スティーブン・トローブリッジ、およびテッド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インチ、BCP9、RFC2026、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問題部に書くためのガイドライン」BCP26、RFC2434(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.ローゼンは「セッション開始プロトコル(一口)のために過程を変えます」、BCP67、RFC3427、2002年12月。
[RFC3692] Narten, T., "Assigning Experimental and Testing Numbers
Considered Useful", BCP 82, RFC 3692, January 2004.
[RFC3692] Narten、T.、「役に立つと考えられた実験的でテストしている数を割り当てます」、BCP82、RFC3692、2004年1月。
[RFC3932] Alvestrand, H., "The IESG and RFC Editor Documents:
Procedures", BCP 92, RFC 3932, October 2004.
[RFC3932] Alvestrand、H.、「IESGとRFCエディタは以下を記録します」。 「手順」、BCP92、RFC3932、2004年10月。
Bradner, et al. Best Current Practice [Page 11] RFC 4775 Procedures for Protocol Extensions December 2006
ブラドナー、他 プロトコル拡大2006年12月のための最も良い現在の習慣[11ページ]RFC4775手順
[RFC3935] Alvestrand, H., "A Mission Statement for the IETF",
BCP 95, RFC 3935, October 2004.
[RFC3935] Alvestrand、H.、「IETFのための使命記述書」、BCP95、RFC3935、2004年10月。
[RFC3978] Bradner, S., "IETF Rights in Contributions", BCP 78,
RFC 3978, March 2005.
[RFC3978] ブラドナー、S.、「貢献におけるIETF権利」、BCP78、RFC3978、2005年3月。
[RFC3979] Bradner, S., "Intellectual Property Rights in IETF
Technology", BCP 79, RFC 3979, March 2005.
[RFC3979] ブラドナー、S.、「IETF技術による知的所有権」、BCP79、RFC3979、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.、およびインターネット・アーキテクチャ委員会、「IABはIETF連絡関係の管理のために処理します」、BCP102、RFC4052、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] トローブリッジ、S.、ブラドナー、S.、およびF.ベイカー、「IETFとIETFからの取り扱い連絡声明のための手順」、BCP103、RFC4053(2005年4月)。
[RFC4181] Heard, C., "Guidelines for Authors and Reviewers of MIB
Documents", BCP 111, RFC 4181, September 2005.
BCP111、C.、「MIBドキュメントの作者と評論家へのガイドライン」と[RFC4181]が聞いて、RFCが4181であり、9月は2005です。
[RFC4727] Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4,
ICMPv6, UDP, and TCP Headers", RFC 4727, November 2006.
[RFC4727]フェナー、B.、「IPv4、IPv6、ICMPv4、ICMPv6、UDP、およびTCPヘッダーの実験値」、RFC4727、2006年11月。
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.ファレルは「Multiprotocolラベルの切り換え(MPLS)、一般化されたMPLS(GMPLS)プロトコル、および手順のために過程を変えます」、処理中の作業、2006年10月。
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
June 1999.
M. [RFC2629]ローズ、RFC2629、「XMLを使用することでI-DsとRFCsに書く」6月1999日
[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.シンプソン、「ユーザサービス(半径)におけるリモート認証ダイヤル」、RFC2865(2000年6月)。
[RFC4691] Andersson, L., "Guidelines for Acting as an IETF Liaison
to Another Organization", RFC 4691, October 2006.
[RFC4691] アンデション、L.、「IETF連絡係として別の組織に機能するためのガイドライン」、RFC4691、2006年10月。
Bradner, et al. Best Current Practice [Page 12] RFC 4775 Procedures for Protocol Extensions December 2006
ブラドナー、他 プロトコル拡大2006年12月のための最も良い現在の習慣[12ページ]RFC4775手順
Authors' Addresses
作者のアドレス
Scott Bradner Harvard University 29 Oxford St. Cambridge, MA 02138 US
スコットブラドナーハーバード大学29オックスフォード聖MA02138ケンブリッジ(米国)
EMail: sob@harvard.edu
メール: sob@harvard.edu
Brian Carpenter, Ed. IBM 8 Chemin de Blandonnet 1214 Vernier Switzerland
エドブライアンCarpenter、IBM8Chemin de Blandonnet1214Vernierスイス
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 IBM3039コーンウォリスAve。 私書箱12195--BRQA/502リサーチトライアングル公園、NC27709-2195米国
EMail: narten@us.ibm.com
メール: narten@us.ibm.com
Bradner, et al. Best Current Practice [Page 13] RFC 4775 Procedures for Protocol Extensions December 2006
ブラドナー、他 プロトコル拡大2006年12月のための最も良い現在の習慣[13ページ]RFC4775手順
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2006).
IETFが信じる著作権(C)(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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機能のための基金は現在、インターネット協会によって提供されます。
Bradner, et al. Best Current Practice [Page 14]
ブラドナー、他 最も良い現在の習慣[14ページ]
一覧
スポンサーリンク
