Network Working Group L. Andersson, Ed.
Request for Comments: 4929 Acreo AB
BCP: 129 A. Farrel, Ed.
Category: Best Current Practice Old Dog Consulting
June 2007
Change Process for Multiprotocol Label Switching (MPLS) and
Generalized MPLS (GMPLS) Protocols and Procedures
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 (2007).
著作権（C）IETFトラスト（2007）。
Abstract
抽象
This document provides guidelines for applying or extending the MPLS or GMPLS ((G)MPLS) protocol suites and clarifies the IETF's (G)MPLS working groups' responsibility for the (G)MPLS protocols. This document is directed to multi-vendor fora and Standards Development Organizations (SDOs) to provide an understanding of (G)MPLS work in the IETF and documents the requisite use of IETF review procedures when considering (G)MPLS applications or protocol extensions in their work. This document does not modify IETF processes.
この文書では、MPLSやGMPLS（（G）MPLS）プロトコルスイートを適用するか、拡張するためのガイドラインを提供し、IETFの（G）は（G）MPLSプロトコルのためのワーキンググループの責任を明確にMPLS。この文書は、IETFで（G）MPLS作業の理解を提供するために、マルチベンダーフォーラムおよび標準開発機関（SDOの）に向け、その中に（G）MPLSアプリケーションやプロトコルの拡張を検討する際にIETFレビュー手続の必要な使用を文書化しています作業。このドキュメントは、IETFのプロセスを変更しません。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Document Source ............................................4
1.2. Conventions Used in This Document ..........................4
2. Overview of (G)MPLS within the IETF .............................4
2.1. IETF Working Groups Developing (G)MPLS Technology ..........5
2.1.1. Multiprotocol Label Switching Working Group .........5
2.1.2. Common Control & Measurement Plane Working Group ....5
2.1.3. MPLS and CCAMP Division of Work .....................6
2.2. Other (G)MPLS Technology-Related Working Groups ............6
2.3. Organizations Outside the IETF .............................7
3. Overview of (G)MPLS Change Process ..............................8
4. MPLS and GMPLS Change Process ...................................9
4.1. Flow Diagram ..............................................10
4.2. Description of Process Stages .............................11
4.2.1. Preliminary Investigation ..........................12
4.2.2. Requirements Statement Evaluation ..................13
4.2.3. Working Group Procedures ...........................14
4.2.4. REWG Evaluation of the Requirements Statement I-D ..14
4.2.5. AD Evaluation of Completed Requirements
Statement I-D ......................................14
4.2.6. IESG review of Requirements Statement I-D
and PSWG Charter ...................................15
4.2.7. Solutions Work .....................................15
5. Rejecting the Requirements Statements I-D ......................16
5.1. Reasons for Rejection .....................................16
5.2. Actions Required When Rejecting Requirements
Statement I-Ds ............................................18
5.3. Appeals ...................................................18
6. Abandonment of the Solutions I-D ...............................19
6.1. Appeals ...................................................19
7. (G)MPLS Integrity and Ownership ................................19
8. Security Considerations ........................................20
9. Acknowledgements ...............................................20
10. IANA Considerations ...........................................21
11. References ....................................................21
11.1. Normative References .....................................21
11.2. Informative References ...................................21
The MPLS and GMPLS technology is developed in two main tracks in the IETF. "MPLS" refers to the work done for packet switched networks, while "GMPLS" refers to the efforts to apply the MPLS protocols to all types of networks including packet and non-packet technologies.
MPLSとGMPLS技術は、IETFにおける二つの主要なトラックに開発されています。 「GMPLS」は、パケットと非パケット技術を含むネットワークのすべてのタイプにMPLSプロトコルを適用するための努力を指しながら「MPLS」は、パケット交換ネットワークのために行った作業を指します。
Though GMPLS by definition is a superset of MPLS, the term "(G)MPLS" is used in this document to indicate both of these tracks. A terminology section that covers the use of terms and concepts used in this document is found in Section 2.6.
定義によるGMPLSは、MPLSのスーパーセットであるが、用語「（G）MPLS」は、これらのトラックの両方を示すために、本書で使用されています。この文書で使用される用語と概念の使用をカバーする用語のセクションは、セクション2.6で発見されました。
[RFC4775] discusses procedural issues related to the extension or variation of IETF protocols by other SDOs. It provides the guidelines and procedures to be used by other SDOs when considering the requirements for extensions to IETF protocols. [RFC4775] recommends that major extensions to, or variations of, IETF protocols only take place through normal IETF processes or in coordination with the IETF.
[RFC4775]は、他のSDOによる伸長またはIETFプロトコルの変化に関連した手続き上の問題を論じています。これは、IETFプロトコルへの拡張のための要件を検討する際のガイドラインと手順は、他のSDOによって使用されるように用意されています。 [RFC4775]は、主要なへの拡張、またはのバリエーションは、IETFプロトコルが唯一の通常のIETFプロセスを介して、またはIETFと連携して行わことをお勧めします。
The (G)MPLS protocol families were developed within the IETF and constitute significant protocol suites within the Internet standards. The (G)MPLS suites of protocols have become popular for a number of new applications and deployment scenarios. There have been concerns with regards to other technology fora developing, using, and publishing non-standard protocol extensions as a standard not only for use within their community, also for wider use by the industry. Especially concerning is the development of extensions, without consulting the (G)MPLS working groups, which are in conflict with efforts on-going in the (G)MPLS working groups, and then presented to the (G)MPLS working group as 'fait accompli'.
（G）MPLSプロトコルファミリは、IETFの中で開発し、インターネット標準内の重要なプロトコルスイートを構成しました。プロトコルの（G）MPLSスイートは、新しいアプリケーションや展開シナリオの数のために人気となっています。他の技術フォーラムに関しては、開発使用して、また、産業による利用拡大のために、彼らのコミュニティ内だけでなく、使用するための標準として非標準プロトコルの拡張機能を公開して関心がありました。特にに関する（G）を相談することなく、機能拡張の開発である上、行く（G）での取り組みと競合しているワーキンググループを、MPLSワーキンググループをMPLS、その後、（G）に提示faitが「としてワーキンググループMPLS accompli」。
The definition and publishing of non-standard extensions by other fora, without IETF review, and outside of the IETF publication process, regardless if rationalized as limited to use among fora vendors, or limited to a particular application, or rationalized as allowing timely demos, has the unfortunate potential to hinder interoperability and increase complexity of the protocol, sows confusion in the industry, and circumvents the Internet standards process that exists to ensure protocol implementability. As described in [RFC4775], non-standard extensions, including experimental values, are not to be portrayed as industrial standards whether by an individual vendor, an industry forum, or a standards body.
合理化に関係なくあれば他のフォーラムによって、IETFレビューせず、及びIETF発行プロセスの外部非標準拡張の定義および公開は、フォーラム・ベンダー間の使用に限定され、又は特定の用途に限定されず、又は適時デモを可能にするように合理化として、相互運用性を妨げ、プロトコルの複雑さを高めるために不幸な可能性を秘めている、業界の混乱をまく、およびプロトコルの実現可能性を確保するために存在しているインターネット標準化プロセスを回避します。 [RFC4775]で説明したように、実験値を含む非標準の拡張機能は、かどうか、個々のベンダー、業界のフォーラム、または標準化団体によって工業規格として描かれるべきではありません。
This document clarifies the IETF's MPLS and Common Control and Measurement Plane (CCAMP) working groups' roles and responsibilities for the (G)MPLS protocols and documents the requisite use of, and how to apply, the [RFC4775] procedure of using the IETF review processes, [RFC2026] and [RFC2418], for fora wishing to apply or extend the (G)MPLS protocols. Use of the IETF review processes will ensure an open process for protocol development and ensure a non-harmful evolution for these IETF protocols, which will benefit the larger industry users' community. IETF itself cannot enforce a forum to use the (G)MPLS change procedure, though any forum not following it, when applying for IANA assignment or IETF publication, will be delayed until this procedure has been completed.
この文書は、（G）MPLSプロトコルのIETFのMPLSおよび共通コントロールおよび測定プレーン（CCAMP）ワーキンググループの役割と責任を明確にし、必要なの使用、そしてどのように適用するには、IETFのレビューを使用しての[RFC4775]の手順を文書化プロセス、適用又は（G）MPLSプロトコルを拡張することを望むフォーラムのために[RFC2026]及び[RFC2418]。 IETFレビュープロセスの使用は、プロトコルの開発のためのオープンなプロセスを確保し、より大きな業界のユーザーのコミュニティに恩恵をもたらすこれらのIETFプロトコル、のための非有害な進化を保証します。 IANA割り当てまたはIETF出版のために適用する場合、この手順が完了するまで、任意のフォーラムは、遅延され、それを以下ではないがIETF自体は、（G）MPLS変更手順を使用するフォーラムを強制することができません。
This document does not change the formal IETF standards process as defined in [RFC2026] and [RFC2418]. It is consistent with the general procedures for protocol extensions defined in [RFC4775] and shows how they are applied in the case of (G)MPLS. Any procedures described in this document are to be implemented in a way consistent with these three documents. They MUST be used when other SDOs and fora wish to propose (G)MPLS changes. They SHOULD be used internally within the IETF unless the changes concerned are considered non-controversial by the responsible Area Director(s) (e.g., covered by the working group charter), in which case other aspects of the normal IETF standards process cover the necessary procedures.
[RFC2026]と[RFC2418]で定義されている。この文書では、正式なIETF標準化プロセスを変更しません。これは[RFC4775]で定義されたプロトコルの拡張のための一般的な手順と一致して、それらが（G）MPLSの場合に適用される方法を示しています。本資料に記載された手順では、これら3つの文書と一致した方法で実装されることになります。他のSDOとフォーラムは、（G）MPLSの変更を提案したい場合、それらを使用しなければなりません。関係の変更は、通常のIETF標準化プロセスの場合、他の側面が必要をカバーする、責任あるエリアディレクター（複数可）（例えば、ワーキンググループ憲章でカバー）による非物議を考慮されない限り、彼らは、IETF内で内部的に使用されるべきです手順。
This document is the joint work of the IETF Routing Area Directors, the IETF MPLS and CCAMP Working Group Chairs, and the IETF's liaisons to the ITU-T. It had considerable review and comment from key members of the ITU-T who have given their time and opinions based on experience for which the authors are grateful. The IESG has also provided valuable input to arrive at the process documented here. The acknowledgements section lists those whose contributions have been particularly helpful.
この文書は、IETFルーティングエリアディレクター、IETF MPLSおよびCCAMP作業部会の議長、およびITU-TへのIETFのリエゾンの共同作業です。これは、著者が感謝している経験に基づいて、自分の時間と意見を与えているITU-Tの主要メンバーからかなりのレビューとコメントしていました。 IESGはまた、ここに文書化されたプロセスに到着する貴重な入力を提供してきました。謝辞セクションは、その貢献に特に役立っているこれらを一覧表示します。
Although this document is not a protocol definition, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. This usage is chosen to make the steps and procedures completely clear.
この文書では、 "MAY"、プロトコルの定義はありませんが、キーワード "MUST"、 "MUST NOT"、 "REQUIRED"、 "NOT SHALL"、 "推奨"、 "すべきではない" "べきである" "ないものと" が、この文書に記載されている、及び「OPTIONAL」は、RFC 2119 [RFC2119]に記載されているように解釈されるべきです。この用法は、手順や手続きを完全に明確にするために選択されています。
This section describes the key IETF working groups developing the (G)MPLS technology and provides information on IETF working groups using the (G)MPLS technology.
このセクションでは、（G）MPLS技術を開発し、キーIETFワーキンググループを記述し、（G）MPLS技術を使用してIETFワーキンググループに関する情報を提供します。
It should be remembered that the IETF environment is highly dynamic. Working groups and whole areas come and go. The overview of the relevant working groups within the IETF is only a snapshot in time.
IETF環境は非常に動的であることを忘れてはなりません。ワーキンググループ全体の領域が行ったり来たり。 IETF内の関連ワーキンググループの概要については、時間の唯一のスナップショットです。
Two working groups in the IETF's Routing Area are responsible for work related to developing the (G)MPLS technologies: Multiprotocol Label Switching (MPLS) working group and the Common Control and Measurement Plane (CCAMP) working group.
ワーキンググループと共通制御・計測プレーン（CCAMP）ワーキンググループマルチプロトコルラベルスイッチング（MPLS）：IETFのルーティングエリアにおける二つのワーキンググループは、（G）MPLS技術の開発に関連する仕事を担当しています。
The following sections provide brief overviews of the chartered work of these two IETF working groups.
次のセクションでは、これら二つのIETFワーキンググループのチャーター作業の簡単な概要を提供しています。
The Multiprotocol Label Switching (MPLS) working group is responsible for standardizing the base technology that uses label switching, and for describing the implementation of Label Switched Paths (LSPs) over various packet and frame-based link level technologies. The working group charter includes procedures and protocols for the distribution of labels between routers, as well as encapsulations, operation and management, traffic engineering, and multicast considerations.
マルチプロトコルラベルスイッチング（MPLS）ワーキンググループラベルスイッチングを使用する基盤技術の標準化を担当し、ラベルの実装を記述するための各種のパケットやフレームベースのリンクレベルの技術上（LSPを）パスを交換。ワーキンググループ憲章は、手続きやプロトコルルータ間のラベルの配布のためだけでなく、カプセル化、運用管理、トラフィックエンジニアリング、およびマルチキャストの考慮が含まれます。
This document assumes that the MPLS working group remains the chartered authority on MPLS technologies, but notes that the IETF may appoint another working group (refer to [RFC2418]) to handle specific extensions or changes to the protocols. Further, in the event that the MPLS working group completes its work and is closed, the IETF will use the non-working group standards track document process (described in [RFC2026]) using designated experts from the community [RFC2434] for the MPLS protocols.
この文書では、MPLSワーキンググループは、MPLS技術上のチャーター権限を残っていることを前提としていますが、処理するために、特定の拡張子やプロトコルへの変更（[RFC2418]を参照してください）IETFは、別のワーキンググループを任命することができると述べています。さらに、MPLSワーキンググループが作業を完了し、閉じられた場合に、IETFは、非ワーキンググループの基準は、ドキュメントプロセスを追跡使用するMPLSプロトコルのコミュニティから指定された専門家を使用して、[RFC2434]（[RFC2026]で説明） 。
The IETF Common Control and Measurement Plane (CCAMP) working group coordinates the work within the IETF defining common control and measurement planes for ISP and SP core tunneling technologies. This includes, but is not limited to, defining signaling protocols and measurement protocols such that they support multiple physical path and tunnel technologies using input from technology-specific working groups such as the MPLS working group. It also includes the development of protocol-independent metrics and parameters for describing links and paths that can be carried in protocols.
IETF共通制御及び測定プレーン（CCAMP）ワーキンググループは、ISPとSPコアトンネリング技術のための共通の制御と測定面を規定するIETF内で動作を調整します。これは、シグナリングプロトコルと、彼らはそのようなMPLSワーキンググループとして技術固有ワーキンググループからの入力を使用して、複数の物理パスとトンネル技術をサポートするような測定プロトコルを定義する、含むが、これらに限定されません。それはまた、リンクおよびプロトコルで実施することができる経路を説明するためのプロトコル独立型メトリックおよびパラメータの開発を含みます。
The technology that the CCAMP working group focuses on is called Generalized MPLS (GMPLS), indicating that CCAMP addresses a generalized technology, where labels are defined in such a way that they will be compatible with the technology over which the data is transported. While the MPLS working group focuses on packet- and frame-switched technologies, the CCAMP working group work focuses on common methods across a broad spectrum of switching technologies including packet and frame technologies. In this respect, GMPLS can be viewed as a superset of MPLS.
CCAMPワーキンググループは、焦点を当て技術はCCAMPラベルは、それらが、データが搬送されるにわたって技術と互換性があるように定義される一般的な技術を、アドレスことを示す、一般化されたMPLS（GMPLS）と呼ばれています。 MPLSワーキンググループは、パケット交換とフレーム交換技術に焦点を当てているが、グループ作業を作業CCAMPパケット及びフレーム技術を含む技術を切り替えるの広いスペクトルにわたって一般的な方法に焦点を当てます。この点で、GMPLSは、MPLSのスーパーセットとして見ることができます。
The procedures in this document assume that the CCAMP working group remains the authority on GMPLS technologies, but acknowledges that the IETF may appoint another working group (refer to [RFC2418]) to handle specific extensions or changes to the protocols. Further, in the event that the CCAMP working group completes its work and is closed, the IETF will use the non-working group standards track document process (described in [RFC2026]) using designated experts from the community [RFC2434] for the GMPLS protocols.
このマニュアルの手順は、CCAMPワーキンググループは、GMPLS技術の権威をままですが、IETFは、別のワーキンググループを任命することができることを認めることを前提とし、特定の拡張子やプロトコルへの変更を処理するために（[RFC2418]を参照してください）。さらに、CCAMPワーキンググループが作業を完了し、閉じられた場合に、IETFは、非ワーキンググループ基準はGMPLSプロトコルのために[RFC2434]コミュニティから指定された専門家を使用して（[RFC2026]で説明）文書のプロセスを追跡する使用します。
From time to time, the MPLS and CCAMP working groups decide to divide work between themselves in a way that does not strictly follow the split between the working groups as defined in the working group charters. This is the case, e.g., for P2MP TE LSPs, where the MPLS working group is specifying requirements and base technology for all of the (G)MPLS technologies.
時々、MPLSおよびCCAMPワーキンググループは、ワーキンググループのチャーターで定義されている厳密にワーキンググループ間の分割に従わない方法で自分自身との間に作業を分割することを決定します。これは、MPLSワーキンググループは、（G）MPLS技術の全ての要件と基盤技術を指定されたP2MP TE LSPを、のために、例えば、ケースです。
An entity or individual that wishes to propose extensions or changes to (G)MPLS should first decide to which working group (MPLS or CCAMP) it will bring the proposal. However, the MPLS and CCAMP working group chairs, in conjunction with their Area Directors, may redirect the proposal to another working group.
（G）への拡張や変更を提案することを希望するエンティティまたは個々のMPLSは、まず、それは提案をもたらすワーキンググループ（MPLSまたはCCAMP）これに決定する必要があります。しかし、MPLSおよびCCAMPワーキンググループの議長は、そのエリアの取締役と連携して、別のワーキンググループへの提案をリダイレクトすることがあります。
Problem statements and requirements for (G)MPLS technology have been produced by several working groups in addition to the MPLS and CCAMP working groups. IETF working groups are defined for the management of specific tasks by their charter. Their charter defines their role, relationship with other working groups, and the applicable procedures to follow when extensions to (G)MPLS may be needed. This section provides an overview of the (G)MPLS-related groups and their responsibilities. Additional information describing the working groups and their charters is available on the IETF web pages.
（G）MPLS技術の問題文と要件は、MPLSとCCAMPワーキンググループに加えて、いくつかのワーキンググループによって製造されてきました。 IETFワーキンググループは、その憲章によって特定のタスクの管理のために定義されています。彼らのチャーターは、彼らの役割、他のワーキンググループとの関係を定義し、（G）MPLSへの拡張が必要になることが該当する場合の手順は、従うこと。このセクションでは、（G）MPLS関連グループとその責任の概要を提供します。ワーキンググループとその憲章を記述する追加情報は、IETFのWebページ上で使用可能です。
The IP over Optical (IPO) working group and the Internet Traffic Engineering working group (TEWG) are examples of working groups which focus on problem statements and requirements for (G)MPLS to be considered by the (G)MPLS working groups. These working groups have not specified any protocols.
光オーバーIP（IPO）ワーキンググループとインターネットトラフィックエンジニアリングワーキンググループ（TEWG）（G）によって考慮されるべき問題文と（G）MPLSのための要件に焦点を当てて取り組ん基の例では、ワーキンググループをMPLS。これらのワーキンググループには、任意のプロトコルを指定していません。
The Bidirectional Forwarding Detection (BFD) working group, also may use the (G)MPLS protocols and mechanisms. The BFD working group is chartered for requirements evaluation and protocol specification related to BFD. If the working group needs to extend or change the (G)MPLS protocols, the procedures specified by its charter and the IETF's standard processes are applicable.
双方向フォワーディング検出（BFD）ワーキンググループは、また、（G）MPLSプロトコルおよびメカニズムを使用してもよいです。 BFDワーキンググループは、要件の評価やBFDに関連するプロトコル仕様のためにチャーターされます。ワーキンググループは、（G）MPLSプロトコルを拡張または変更する必要がある場合、そのチャーター及びIETFの標準的な方法によって指定された手順が適用可能です。
The Layer 2 VPN (L2VPN) and Layer 3 VPN (L3VPN) working groups have been chartered to specify a limited number of solutions for Provider Provisioned VPNs. Both working groups are in the Internet Area. Much of the work of the L2VPN and L3VPN working groups does not include specifying new protocols or extensions to existing protocols. Where extensions are needed, the procedures as specified by their charters and the IETF's standard processes are applicable.
レイヤ2 VPN（L2VPN）、レイヤ3 VPN（L3VPN）ワーキンググループは、プロバイダープロビジョニングVPN用のソリューションの限られた数を指定するためにチャーターされました。どちらのワーキンググループは、インターネットエリアです。 L2VPNとL3VPNワーキンググループの作業の多くは、既存のプロトコルに新しいプロトコルや拡張子を指定して含まれていません。拡張が必要とされている場合は、その憲章とIETFの標準プロセスで指定された手順が適用されます。
The Layer 1 VPN (L1VPN) working group is chartered to specify mechanisms necessary for providing Layer 1 VPN services (establishment of layer 1 connections between CE devices) over a GMPLS-enabled transport service-provider network. Protocol extensions required for L1VPN will be done in cooperation with MPLS, CCAMP, OSPF, IS-IS, IDR, L3VPN, and other WGs where necessary. That is, the L1VPN working group will not develop GMPLS protocol extensions in isolation, but will develop requirements and propose extensions that will be reviewed and approved by the (G)MPLS working groups.
レイヤ1 VPN（L1VPN）ワーキンググループは、GMPLS対応のトランスポート・サービス・プロバイダのネットワークを介してレイヤ1 VPNサービス（CEデバイス間のレイヤ1接続の確立）を提供するために必要なメカニズムを指定するためにチャーターされています。 L1VPNのために必要なプロトコル拡張は、IDR、L3VPN、および他のWG必要IS-IS、MPLS、CCAMP、OSPFと協力して行われます。つまり、L1VPNワーキンググループが単独でGMPLSプロトコル拡張機能を開発しませんが、要件を開発し、レビューし、（G）MPLSワーキンググループによって承認される拡張を提案します。
The Pseudo Wire Emulation End to End (PWE3) working group is a working group that may use the (G)MPLS protocols in its specifications. Should the PWE3 specifications require extension or changes to the (G)MPLS protocols, the procedures as specified by its charter and the IETF's standard processes are applicable.
擬似ワイヤエミュレーションエンドワーキンググループ（PWE3）を終了するために、その仕様に（G）MPLSプロトコルを使用してもよいワーキンググループです。 PWE3仕様（G）MPLSプロトコルに拡張や変更が必要な場合は、その憲章とIETFの標準プロセスで指定された手順が適用されます。
A number of standards development organizations (SDOs) and industrial forums use or reference the (G)MPLS protocols in their specifications. Some of these organizations have formal or informal liaison relationships with the IETF [RFC4052]. The IETF exchanges information with these organizations about what is happening on both sides, including plans and schedules, using liaison statements [RFC4053]. More details about the cooperation relationship between the IETF and the ITU-T can be found in [RFC3356].
標準開発機関（SDOの）と産業フォーラムの数は、その仕様に（G）MPLSプロトコルを使用するか、または参照します。これらの組織の一部は、IETF [RFC4052]で公式または非公式のリエゾン関係を持っています。リエゾン文[RFC4053]を使用して、計画やスケジュールを含め、両側に何が起こっているかについて、これらの団体とIETF情報を交換します。 IETFとITU-Tとの間の協力関係についての詳細は、[RFC3356]に見出すことができます。
The procedures in this document are applicable to all organizations outside the IETF whether or not they have formal liaison relationships with the IETF. If any organization outside the IETF has a requirement for extensions or modifications to the (G)MPLS protocols then the procedures in this document apply.
このマニュアルの手順は、彼らがIETFとの正式なリエゾン関係を持っているかどうかIETF外のすべての組織に適用されます。 IETF外の組織は、（G）MPLSプロトコルへの拡張または修正の必要がある場合、この文書の手順が適用されます。
This is a non-normative section, as it is intended to provide a high-level view of [RFC4775] procedures for protocol extensions. Application of these procedures for (G)MPLS are defined in detail in Section 4.
プロトコルの拡張のために[RFC4775]の手順の高レベルのビューを提供するように意図され、これは、非規範的部分です。 （G）MPLSのためのこれらの方法の適用は、セクション4で詳細に定義されています。
Whenever there is reason to believe that a particular problem may be solved by use of or extensions to the (G)MPLS protocols, a communication using the formal liaison process, or, for a forum without a formal relationship, an informal communication, may be used to discuss the problem with the IETF ([RFC4052] and [RFC4053]). Collaboration with the IETF in the early discussion phase will facilitate a timely understanding of whether the problem has already been solved, may be outside the scope of the (G)MPLS protocols, or may require more investigation.
特定の問題は、（G）MPLSプロトコルへの使用または拡張することによって解決することができると信じるに足る理由があるときはいつでも、通信正式な関係、非公式の通信なしフォーラムのために、正式なリエゾン・プロセスを使用して、またはであってもよく、 IETF（[RFC4052]及び[RFC4053]）の問題を議論するために使用されます。問題はすでに解決されたか否かのタイムリーな理解を容易にする初期議論相中IETFとのコラボレーションは、（G）MPLSプロトコルの範囲外であってもよいし、またはそれ以上の調査を必要とするかもしれません。
Whenever any extension or change to the (G)MPLS protocols is desired, a problem statement and/or requirements statement must be produced and must be submitted to IETF as an Internet-Draft. When the requirements come from an external organization, informal communications, such as e-mail to working group mailing lists, is strongly encouraged as it facilitates timely and cooperative work. However, if desired, the Internet-Draft, containing the requirement(s), may be submitted to the working group using a formal liaison statement. IETF's response to the request will be given as a reply to the liaison. This use of formal communication reduces the risk of confusing an individual participant's opinion for that of the group as can happen on mailing lists, though it does introduce a more lengthy communication cycle. If there is no formal liaison relationship, a communication may be sent directly to the (G)MPLS working group, a relevant Area Director, or the IESG.
（G）MPLSプロトコルに対する任意の拡張や変更が所望されるときはいつでも、問題文及び/又は必要条件文が生成されなければならず、インターネットドラフトとしてIETFに提出しなければなりません。要件は、外部組織から来るとき、それはタイムリーと共同作業を容易にするので、このようなグループのメーリングリストを作業に電子メールなどの非公式の通信は、強く推奨されます。しかし、必要に応じて、要件（複数可）を含むインターネットドラフトは、正式なリエゾンステートメントを使用して、ワーキンググループに提出することができます。リクエストにIETFの応答がリエゾンへの応答として与えられます。それは、より長い通信サイクルを導入しても、正式なコミュニケーションのこの使用は、メーリングリスト上で起こることができるように、グループのための個々の参加者の意見を混乱のリスクを低減します。正式な連絡関係が存在しない場合、通信は、（G）MPLSワーキンググループ、関連Areaディレクター、またはIESGに直接送信してもよいです。
The IETF, through the appropriate Area Director, and the chairs of the MPLS and CCAMP working groups for (G)MPLS related work, will direct the requirements draft to an appropriate working group for assessment and comment. This process may require communication and discussion for clarification, but the IETF undertakes to perform the assessment in a timely manner.
IETFは、適切な地域ディレクター、および（G）MPLS関連研究のためのMPLSとCCAMPワーキンググループの議長を通じて、評価とコメントを適切なワーキンググループに要件案を指示します。このプロセスは、明確化のためのコミュニケーションや議論を必要とするかもしれないが、IETFは、タイムリーに評価を行うことを約束します。
In assessing the requirements statement I-D, the IETF may determine:
要件書I-Dの評価では、IETFが決定することができます。
- that the requirements can be satisfied without modifications to the (G)MPLS protocols
- 要求は、（G）MPLSプロトコルに変更せずに満たすことができること
- that the requirements are not sufficiently general or there is not sufficient interest to do a standards-track solution to warrant a Standards-track change to the (G)MPLS protocols
- 要件は十分に一般的ではありませんか（G）MPLSプロトコルに標準トラックの変更を正当化するために標準化過程のソリューションを行うのに十分な関心がないこと
- that the requirements justify a standards-track change to the (G)MPLS protocols
- 要件は、（G）MPLSプロトコルに標準トラックの変更を正当化すること
- that the requirements might not be possible to satisfy without violating the (G)MPLS architecture in a way that would harm the (G)MPLS technology
- 要件は、（G）MPLS技術を害するような方法で（G）MPLSアーキテクチャに違反することなく満足させることが可能ではないかもしれないということ
- that the requirements should be combined with other requirements to solve a more general problem or solve the same problem in a more flexible way.
- 要件は、より一般的な問題を解決するか、より柔軟な方法で、同じ問題を解決するための他の要件と組み合わせなければならないこと。
In the event that the IETF agrees to develop a solution, the IETF will set milestones that would result in timely delivery of the solution in a timely manner. If the IETF rejects the requirements, this will only be done with clear explanation and full discussion with the source of the requirements.
IETFは、ソリューションを開発することに同意する場合には、IETFは、タイムリーにソリューションのタイムリーな配信につながるマイルストーンを設定します。 IETFが要件を拒否した場合、これが唯一の明確な説明と要件のソースとの完全な議論を行うことになります。
The solutions that are developed within the IETF may be sourced from external organizations and presented for review, discussion, modification, and adoption as Internet-Drafts. Such solutions drafts may be presented to the IETF in advance of the completion of the requirements work, but all solutions will be processed through the normal IETF process with other proposed solutions. Solution drafts are adopted as an IETF working group draft when the requirements are stable, and not before the protocol-responsible working group has a charter item to cover the solutions work. It is strongly recommended for interested parties to start informal discussion in the IETF, as early as possible, and to co-author in the IETF's work. It is not recommended for the source forum to continue to work on solutions in parallel with on-going work in the IETF. If the protocol-responsible working group is unable to accept the work (e.g., due to current work load), the IETF processes ([RFC2418]) provide alternate options for ensuring the work is completed.
IETF内で開発されているソリューションは、外部機関から調達し、見直し、議論、修正、およびインターネットドラフトとして採択のために提示することができます。このような溶液のドラフトは、要件作業の完了に先立ってIETFに提示されてもよいが、すべての解決策は、他の提案された解決策と通常IETFプロセスを通じて処理されます。プロトコル責任ワーキンググループは、ソリューションの作業をカバーするためにチャーターアイテムを持って前に、ソリューションのドラフトはない要件が安定しているとき、IETFワーキンググループ案として採用されており、。利害関係者が可能な限り早期に、IETFで非公式協議を開始すること、およびIETFの仕事に著者を共同することを強くお勧めします。それは、IETFで、進行中の作業と並行して解決に取り組み続けるために、ソースのフォーラムにはお勧めできません。プロトコル責任ワーキンググループは、（これは現在の作業負荷に、例えば）作業を受け入れることができない場合、IETFプロセスは、（[RFC2418]）が完了した仕事を確保するための代替オプションを提供します。
This section defines the (G)MPLS change process and the rules that must be followed in order to make extensions or changes to the (G)MPLS protocols. The language of [RFC2119] is used in order to clarify the required behavior of the IETF and the originator of the change request. It is consistent with the general procedures for protocol extensions defined in [RFC4775]. Any interpretation of procedures described in this document and their implementation are to be in a way consistent with [RFC4775].
このセクションでは、（G）MPLS変更処理と、（G）MPLSプロトコルの拡張または変更を行うために従わなければならない規則を定義します。 [RFC2119]の言語は、IETFおよび変更要求の発信元の必要な動作を明確にするために使用されます。これは[RFC4775]で定義されたプロトコルの拡張のための一般的な手順と一致しています。本文書及びその実施に記載された手順のいずれかの解釈は[RFC4775]と一致するようにしなければなりません。
Anyone who intends to use one of the existing (G)MPLS protocols, but thinks that it will not satisfy their needs MUST use the procedures described in this document. They SHOULD be used internally within the IETF unless the changes concerned are considered non-controversial by the responsible Area Director(s) (e.g., covered by the working group charter), in which case other aspects of the normal IETF standards process apply. Changes or extensions to the (G)MPLS protocols MUST NOT be made by any other mechanism. The IETF MUST NOT endorse any publications (including RFCs, whether on the Standards Track, Informational, or Experimental) that change or extend the (G)MPLS protocols except for those that arise through the correct execution of the procedures in this document. The IETF MUST NOT endorse any IANA action that allocates (G)MPLS protocol codepoints, except as a result of actions arising from the correct execution of the procedures in this document.
既存の（G）MPLSプロトコルのいずれかを使用しようとするが、それは彼らのニーズを満たしていないだろうと考えている誰もが、この文書に記載されている手順を使用しなければなりません。関係の変更は、通常のIETF標準化プロセスの他の側面が適用される場合には責任エリアディレクター（S）（例えば、ワーキンググループ憲章によってカバーさ）、により非物議を考慮されない限り、彼らは、IETF内で内部的に使用されるべきです。 （G）MPLSプロトコルの変更や拡張は、他のメカニズムによって行われてはなりません。 IETFは、このマニュアルの手順を正しく実行することによって生じたものを除く（G）MPLSプロトコルを拡張し、その変更または（標準化過程、情報、または実験的にかどうか、のRFCを含む）あらゆる出版物を支持してはなりません。 IETFは、この文書に記載されている手順の正しい実行に起因する行動の結果として以外（G）MPLSプロトコルコードポイントを割り当てる任意のIANAのアクションを承認してはいけません。
Figure 1 gives a visual overview to illustrate the roles of a (G)MPLS requirements evaluation working group (REWG) and (G)MPLS protocol solutions working group (PSWG). The figure presents two alternatives for a requestor: (1) contact the IETF early in the problem definition phase (preliminary investigation), or, (2) later, with a requirements statement. The figure is for illustration only; it does not contain all of the possible interactions and IETF procedure alternatives. The text in the subsequent sections describes the process.
図1（G）MPLS要件評価ワーキンググループ（REWG）及び（G）MPLSプロトコルソリューションワーキンググループ（PSWG）の役割を説明するための視覚的な概観を与えます。図では、要求者のための2つの選択肢を提示：（1）の要件のステートメントを使用して、（2）以降では、早期の問題定義段階（予備調査）でのIETFに連絡、または。図は、単に例示のためのものです。それが可能な相互作用とIETF手続きの選択肢のすべてが含まれていません。以降のセクション内のテキストは、プロセスを説明します。
Start +-------------+
| |optional |
+--<--------------------|preliminary |<-------Start
| |investigation|
V +-------------+
+------------+ +---------+ +---------+
|requirements| discussion |review by| YES | IESG | YES
|statement |----------->|WG chairs|------------->|decision |------+
|I-D | on mailing |and ADs | request to | | |
+------------+ list +---------+ IESG to +---------+ |
| appoint REWG | |
|NO and charter |NO REWG|
V req eval | chartered|
+-------------+ | to work on|
|response | | requirements|
|to the | | statement|
|requirements |<-----------------+ |
+->|statement |<----------------+ |
| +-------------+ | |
| ^ | |
NO| | NO | |
| +-----------------+ | V
| | | NO +------+
+--------+ +-------+ +--------| REWG |
| IESG/ | YES | AD | | req |
+-----------|decision|<---------------|review |<------------| eval |
|PSWG | | request to | | YES | |
|chartered +--------+ IESG to +-------+ +------+
|to work approve I-D
| and charter
| PSWG (if needed)
| +---------+
| | IETF | +-----+
+--------->| PSWG |-----/ /---->| RFC |
+---->| process | +-----+
| +---------+
solutions
I-D
Figure 1: Change Process Overview
This section describes how the (G)MPLS change process works, what is expected from individuals or organizations that want to extend or change the (G)MPLS protocols, and the responsibilities of the IETF.
このセクションでは、（G）MPLS変更処理は、（G）MPLSプロトコル、およびIETFの責任を拡張または変更したい個人または組織から期待されているものを、どのように動作するかを説明します。
This step is OPTIONAL, and is intended to provide a lightweight way to "feel out" the IETF's position on a proposal without going to the effort of writing an Internet-Draft. The intention is to determine whether the problem has been examined already, whether the problem is in scope for the IETF, and whether solutions are already known.
このステップはオプションであり、インターネットドラフトを書くの努力に行かなくても提案についてIETFの立場を「アウト感じる」ための軽量な方法を提供することを意図しています。意図は、問題がIETFのスコープ内にあるかどうかの問題は、既に検討されているかどうかを決定することである、そして溶液は既に知られているかどうか。
Although the preliminary investigation phase is optional it is RECOMMENDED that the originator of any requirements consult and discuss the issues concerned as early as possible to avoid any wasted effort, and the preliminary investigation phase provides a mechanism to do this.
予備調査の段階はオプションですが、任意の要件の発信者が協議し、任意の無駄な努力を避けるために、可能な限り早期に関係する問題を議論することを推奨し、予備調査の段階では、これを行うためのメカニズムを提供しています。
Useful discussions may be held at this stage in order to ensure that the problem statement and requirements statement Internet-Drafts contain the right material. This step is described as lightweight because no Internet-Draft is required and because the step largely involves offline discussions. However, it may be the case that this step involves considerable technical discussions and may, in fact, involve an extensive, substantive exchange of ideas and opinions.
有益な議論は、問題文の要件と文のインターネットドラフトは、右の材料が含まれていることを確実にするために、この段階で保持することができます。何のインターネットドラフトが必要とされないため、この手順は、軽量として記述されており、ステップは、主にオフラインでの議論を伴うため。しかし、それはこのステップはかなりの技術的な議論を必要とすると、実際には、アイデアや意見の豊富な、実質的な交換を含み得る場合があります。
This step SHOULD be carried out informally on the mailing list of the REWG or on the Routing Area discussion mailing list, and MAY be initiated by any individual, group of individuals, external organization, or IETF working group.
このステップはREWGのメーリングリスト上またはルーティングエリア議論メーリングリストで非公式に行われるべきであり、いかなる個人、個人のグループ、外部の組織、またはIETFワーキンググループによって開始することができます。
When an external SDO has a liaison relationship with the IETF, it MAY carry out this step using a formal liaison. The liaison SHOULD be sent to the designated liaison manager who is responsible for forwarding them to the IESG who will assign a Responsible AD. The initiators of the liaison SHOULD make themselves available for discussion on the selected mailing list. If a formal liaison is used, the IETF will respond using the procedures of [RFC4053].
外部SDOは、IETFとの連絡関係を持っている場合は、正式なリエゾンを使用して、この手順を実行することができます。リエゾンは責任ADを割り当てますIESGに転送するための責任がある指定されたリエゾンマネージャに送信する必要があります。リエゾンの開始剤は、選択されたメーリングリストでの議論のために自身が利用できるようにすべきです。正式なリエゾンを使用する場合は、IETFは、[RFC4053]の手順を使用して応答します。
At this stage, a problem statement I-D MAY be produced to help further the discussions and to clarify the issues being addressed.
この段階では、問題文のI-Dは、さらに議論を支援すると問題が解決されている明確にするために製造することができます。
A possible outcome of this preliminary investigation is that the requirements and problem are understood, but agreed to be out of scope for the IETF. Alternatively, it may be that the problem can be solved with existing protocols. The full list of outcomes from the preliminary investigation phase are similar to those for the requirements statement evaluation phase described in Section 4.2.2, but the requirements statement evaluation phase that allows wider IETF community participation in developing a complete requirement set MUST form part of the process if the IETF is to consider to develop protocol solutions. The process cannot move direct from the preliminary investigation phase to the development of solutions unless the working group agrees (e.g., the problem is minor).
この予備調査の可能な結果が要件と問題が理解されているということですが、IETFの範囲外であることを合意しました。また、それは問題が既存のプロトコルで解決できることもあります。予備調査段階から成果の完全なリストは、4.2.2項で説明した要件のステートメント評価フェーズのためのものと同様であるが、完全な要件のセットを開発する上で、より広いIETFコミュニティの参加を可能にする要件文評価フェーズは、その一部を形成しなければなりませんIETFであれば、プロセスは、プロトコル・ソリューションを開発することを検討することです。ワーキンググループが同意しない限り、プロセスはソリューションの開発に予備調査相から直接移動できない（例えば、問題は軽微です）。
Before the IETF can formally pronounce on requests to change or extend the (G)MPLS protocols, a requirements statement I-D MUST be written per [RFC2026].
IETFが正式に（G）MPLSプロトコルを変更したり、拡張する要求に発音できるようにするには、要件のステートメントのI-Dは、[RFC2026]あたりに書かなければなりません。
The requirements statement I-D MUST be introduced by the authors to the IETF through an email to the REWG mailing list, to the Routing Area discussion mailing list, or by a formal liaison from an external SDO which will result in the IETF introducing the requirements statement I-D to the REWG mailing list. If the requirements statement I-D is brought to the IETF through a formal liaison, the initiators of the liaison SHOULD make themselves available for discussion on the designated IETF mailing lists.
要件のステートメントIDはREWGメーリングリストへの電子メールで、ルーティングエリア議論のメーリングリストに、またはIETFは、要件のステートメントIDを導入することになる外部SDOからの正式なリエゾンによってIETFに著者によって導入されなければなりませんREWGメーリングリストへ。要件書I-Dは、正式なリエゾンを通じてIETFにもたらされている場合は、リエゾンの開始剤は、指定されたIETFメーリングリストでの議論のために自身が利用できるようにすべきです。
After discussion on the IETF mailing lists, the responsible Area Director MUST decide whether the requirements will be formally evaluated by the IETF, and MUST deliver a response to the per [RFC4053] and [RFC4775]. If a formal liaison was not used, the response SHOULD be delivered to the appropriate contact as listed on the communication.
IETFメーリングリスト上の議論の後、責任あるエリアディレクターは、要件が正式にIETFによって評価されるかどうかを決定しなければならない、とあたり[RFC4053]と[RFC4775]への応答を提供しなければなりません。正式なリエゾンを使用しない場合は、応答が通信に記載されているように、適切な連絡先に配信される必要があります。
The IETF response MUST be sufficiently explanatory to inform the requesting organization of what, if anything, the IETF has decided to do in response to the request. The following list is provided to illustrate possible responses:
IETF応答はどちらかといえば、IETFは要求に応じて行うことを決めたもの、の要求する組織に通知するために十分な説明でなければなりません。以下のリストは、可能な応答を説明するために提供されています。
a. Requirements not understood. Further discussion is required.
A。要件が理解されていません。さらなる議論が必要です。
b. Requirements understood, but judged to be out of scope for the IETF. In this case, the originator of the requirements can work on requirements and solutions and will not be impeded by the IETF. The IETF may request to be kept informed of progress.
B。要件は理解するが、IETFの範囲外であると判断します。この場合、要件の創始者は、要件やソリューションに取り組むことができ、IETFによって妨害されることはありません。 IETFは、進捗状況の通知を保持することが要求することができます。
c. Requirements understood, but no protocol extensions are needed. It may be desirable for the external SDO to cooperate with the an IETF working group in the production of an Applicability Statement Internet-Draft.
C。要件は理解したが、何のプロトコル拡張は必要ありません。外部SDOは、適用性に関する声明のインターネットドラフトの生産にIETFワーキンググループと協力することが望ましい場合があります。
d. Requirements understood, and the IETF would like to develop protocol extensions. This results in execution of the rest of the procedure, described below. The requirements raised in the requirements statement I-D may be combined with other requirements to produce more general extensions or changes to the (G)MPLS protocols.
D。要件を理解し、そしてIETFプロトコルの拡張機能を開発したいと思います。これは、以下の手順の残りの部分の実行につながります。必要条件文I-Dに上昇要件は、（G）MPLSプロトコルに、より一般的な拡張や変更を生成する他の要件と組み合わせることができます。
In many cases, the problem covered by the requirements statement I-D will fall within the scope of the existing charter of a working group. In this case, the responsible Area Directors will designate the working group as the REWG and pass the requirements statement I-D to the working group for evaluation. If the problem is not covered by an existing charter, other alternatives (refer to [RFC2418]) may be used, e.g., rechartering, BOF, chartering a new working group.
多くの場合、要件書I-Dでカバー問題は、ワーキンググループの既存の憲章の範囲内に含まれます。この場合、責任エリアの取締役はREWGとしてワーキンググループを指定し、評価のためのワーキンググループに要件書I-Dを渡します。問題は、既存のチャーターによって覆われていない場合、他の選択肢は、（[RFC2418]参照）を使用することができる、例えば、rechartering、BOF、新しいワーキンググループをチャーター。
If the IETF modifies its prior decision to accept the work, the IETF MUST communicate this to the requestor in a timely manner.
IETFは、仕事を受け入れるその前に決定を変更する場合は、IETFは、タイムリーに要求者にこれを通信する必要があります。
The objective of the REWG evaluation process is to determine a clear and complete statement of the requirements for changes or extensions to the (G)MPLS protocols. This will necessitate normal IETF working group procedures in the REWG and MAY include the generation of revisions of the requirements statement I-D in cooperation between the members of the REWG and the original authors of the requirements statement I-D.
REWG評価プロセスの目的は、（G）MPLSプロトコルの変更や拡張のための要件の明確かつ完全なステートメントを決定することです。これはREWGで、通常のIETFワーキンググループの手続きが必要となるとREWGのメンバーと要件文のI-Dの原作者間の協力の要求文のI-Dのリビジョンの世代を含むかもしれません。
The originators of the requirements statement I-D MUST make themselves available to discuss the work on the REWG mailing list. If this does not happen, the chairs of the REWG MAY determine that there is insufficient support for the work and MAY reject the requirements statement I-D.
要件書I-DのオリジネーターはREWGメーリングリストの仕事を議論する自身が利用できるようにしなければなりません。これが起こらない場合は、REWGの椅子は仕事のための十分なサポートがあることを決定することができると要求文のI-Dを拒否することがあります。
The output of the REWG will be either:
REWGの出力のいずれかになります。
- a completed requirements statement I-D that has been accepted by working group consensus within the REWG and has passed through working group last call;
- ワーキンググループの最後の呼び出しを通過したREWG内のワーキンググループの総意によって受け入れられてきた完成要件文のI-D;
or
または
- a rejection of the requirements using the response procedure as described in Section 5.
- 第5節で説明したように応答手順を使用して要求の拒絶。
As with all Internet-Drafts produced by a working group, the ADs will review the completed requirements statement I-D produced by the REWG. The ADs will then pass the document to the IESG for review. If charter changes are needed or a new PSWG needed, the appropriate process will be followed.
ワーキンググループによって生成されたすべてのインターネットドラフトと同じように、広告はREWGによって生成完成要件文のI-Dを検討します。広告はその後、レビューのためにIESGに文書を渡します。チャーターの変更が必要とされたり、新しいPSWGが必要な場合は、適切なプロセスが続きます。
As with all Internet-Drafts, the IESG will review and make a decision on the progression of the requirements statement I-D.
すべてのインターネットドラフトと同様に、IESGは見直し、必要条件文のI-Dの進行上の意思決定を行います。
If the IESG rejects the requirements statement I-D, it will generate an appropriate response to the working group (and, if needed, to the originator of the request).
IESGが要件文のI-Dを拒否した場合、それは（および、必要に応じて、要求の発信元に）ワーキンググループへの適切な応答を生成します。
The IESG will review any proposed charter changes for the PSWG or, if needed, consider alternatives. This might include the formation of a new working group specifically to work on the solutions.
IESGはPSWGのための任意の提案チャーター変更を確認するか、必要であれば、代替案を検討します。これは、新しいワーキンググループの形成は、具体的解決策に取り組むことなどがあります。
The appropriate PSWG will start work on solutions following the normal IETF process.
適切なPSWGは、通常のIETFプロセスを次のソリューションに関する作業を開始します。
Solutions I-Ds MAY be prepared externally (such as within an external organization) or within the IETF, submitted to the IETF for draft publication using the procedures of [RFC2418], and introduced to the PSWG for consideration. Such I-Ds MAY be submitted at earlier stages in the process to assist the REWG in its development and discussion of the requirements, but no I-D will be formally considered as a solutions I-D until the PSWG has a charter item that covers the work and the REWG chairs are confident that the requirements are stable.
溶液I-DSは、（例えば、外部組織内のように）外部から調製またはIETF内、[RFC2418]の手順を使用してドラフト公開ためIETFに提出され、検討のためPSWGに導入することができます。 PSWGが仕事とカバーチャーターアイテムを持ってまで、このようなI-DSは、ソリューションのIDとしてその開発と要件の議論でREWGを支援するために、プロセスに早い段階で提出することができるが、ないIDが正式に考慮されませんREWGの椅子は、要件が安定していることを確信しています。
The IETF makes no guarantees that an externally produced solutions I-D will form the basis of the PSWG solutions I-D, but the PSWG MUST consider such an I-D for review and revision as a possible solution I-D, using the same open procedures ([RFC2418]) as for any individual submission. The IETF's procedures are based on open and fair participation, and thorough consideration of technical alternatives.
IETFは、外部生成ソリューションIDがPSWGソリューションIDの基礎を形成することになるが、PSWGは（[RFC2418]）と同じオープン手順を使用して、可能な解決策IDとしてレビューと改訂のためにそのようなIDを考慮しなければならないことを保証しません個々の提出。 IETFの手順は、技術的な代替案のオープンでフェア参加、徹底的な考察に基づいています。
Interested parties (both implementers and users) of the SDO originating the request are strongly encouraged to participate in the PSWG to ensure appropriate interest is shown in the solutions work and to provide timely solutions development. The IETF's work, as that of any SDO, is driven by its participants. The IETF is an open community and any SDO requesting IETF solutions work SHOULD ensure appropriate industry interest in the work, or the IETF MAY discontinue its support of the work. Appropriate communication of the discontinued work will be made to the originator of the request (if the originator is reachable).
要求を発信するSDOの利害関係者（実装者とユーザーの両方）が強く、適切な関心がソリューションの作業に示されていることを確認し、タイムリーなソリューションの開発を提供するために、PSWGに参加することが奨励されています。 IETFの仕事は、任意のSDOのものとして、その参加者によって駆動されます。 IETFは、オープンコミュニティで、IETFソリューションの仕事を要求する任意のSDOは仕事で適切な業界の関心を確実にしなければならない、またはIETFは仕事のサポートを中止することがあります。 （発信者が到達可能である場合）廃止作業の適切な通信は、要求の発信元について説明します。
The final development of the solutions I-D is subject to the normal working group review, consensus, and last call within the PSWG.
ソリューションI-Dの最終開発は、通常のワーキンググループの検討、合意、およびPSWG内の最後の呼び出しの対象となります。
Where the requirements originated from an external organization, the PSWG SHOULD regularly communicate its progress using a formal liaison process if one exists. This communication SHOULD also be used to request review input and comment on the development of the solutions I-D. The solutions I-D MUST be communicated to the originating organization during working group last call for final review against the requirements. When the solutions I-D is complete (normally upon completing working group last call and/or on entering the RFC Editor's queue) the PSWG MUST inform the originating organization of the completed solution.
要件は、外部組織から元の場所が存在する場合、PSWGは定期的に、正式なリエゾン・プロセスを使用して、その進捗状況を伝えるべきです。この通信はまた、ソリューションI-Dの開発のレビューを入力してコメントを要求するために使用されるべきです。ソリューションI-Dは、要件に対する最終審査のためのグループの最後の呼び出しを作業中に元の組織に伝達されなければなりません。ソリューションI-D（通常は最後の呼び出しおよび/またはRFC編集者のキューに入るにワーキンググループを完了すると）完了するとPSWGが完了ソリューションの起源組織に通知しなければなりません。
Rejection of the requirements statements is a sensitive matter for the authors of the requirements and MUST be handled with full disclosure and explanation by the IETF. All working group actions are taken in a public forum ([RFC2418]).
要件のステートメントの拒絶は、要件の作成者のための敏感な問題であり、IETFによって完全な開示および説明を処理する必要があります。すべてのワーキンググループのアクションが公開フォーラム（[RFC2418]）で撮影されています。
The requirements can be rejected at various stages of the process as described in the previous sections. The person or group that makes the rejection is responsible for generating an explanation of the rejection and MUST follow the [RFC4775] process. Possible reasons for rejection are described in this section.
前のセクションで説明したような要件は、プロセスの種々の段階で拒否することができます。拒絶反応を作る人やグループは、拒絶反応の説明を生成するための責任があると[RFC4775]のプロセスに従わなければなりません。拒否の考えられる理由は、このセクションで説明されています。
The requirements statement I-D can only be rejected with full disclosure by the IETF. Possible reasons for rejection and possible next steps as described here.
要件書I-DはIETFによって完全な開示を拒否することができます。拒否の考えられる理由と、ここで説明したように可能な次のステップ。
- Requirements not understood. Either during preliminary investigation or during evaluation of the requirements statement I-D, it was not clear what the requirements are, or what the problem being addressed is.
- 要件理解されていません。予備調査の際や要件のステートメントのI-Dの評価の際にどちらか、要件が何であるか明確ではなかった、または何の問題が対処されていることです。
This rejection forms part of an on-going communication and it is expected that the process will continue with further iterations.
この拒否は、進行中のコミュニケーションの一部を形成し、プロセスがさらなる反復を継続することが予想されます。
- Out of scope for the IETF. Many stages of this process may determine that the requirements are out of scope for the IETF. In this case, the IETF MUST NOT constrain the authors of the requirements statement I-D from working on a solution. If any (G)MPLS changes are later identified, the requestor MUST reinitiate the (G)MPLS change procedure.
- IETFの範囲外。このプロセスの多くの段階では、要件がIETFの範囲外であると判断することができます。この場合、IETFは、解決策に取り組んでからの要求文のI-Dの著者を拘束してはなりません。任意の（G）MPLS変更が後で確認された場合、リクエスタは、（G）MPLS変更手順を再開しなければなりません。
- No protocols extensions or changes are needed. At some stage in the evaluation of the requirements it may become clear that they can all be met through appropriate use of existing protocols. In this case, no further evaluation of the requirements is required, but the REWG MUST explain how the protocols can be used to meet the requirements and MAY cooperate with the authors of the requirements statement I-D in the production of an Applicability Statement Internet-Draft or a Profiles Internet-Draft that explains precisely how the existing protocols can be used to meet the requirements.
- いいえ、プロトコルの拡張や変更が必要とされています。要件の評価では、いくつかの段階では、それは彼らがすべての既存のプロトコルの適切な使用によって満たすことができることが明らかになることがあります。この場合、要件のさらなる評価が必要とされないが、REWGはプロトコルが要件を満たすために使用することができると適用ステートメントインターネットドラフトの生産に必要条件文IDの作成者と協働することができるか、どのように説明しなければなりません正確には、既存のプロトコルが要件を満たすために使用することができる方法を説明プロファイルのインターネットドラフト。
- Insufficient support within the IETF. Although the work described within the requirements statement I-D is within scope for the IETF, and despite the support of the originators of the requirements statement I-D on the REWG mailing list, the chairs of the REWG have determined that there is insufficient support in the REWG to complete requirements statement I-D and initiate solutions work in the PSWG. In this case, the IETF MUST NOT restrict the authors of the requirements statement I-D from working on a solution. The solution (and/or IANA codepoints requested) SHALL be presented to the IETF's (G)MPLS PSWG for review and possible publication as an Informational or Experimental RFC, and, pending IETF review results, the IETF SHALL NOT block applications to IANA for codepoints. If IANA codepoint assignments are required, the IANA Requirements prescribed for those assignments in the relevant RFCs MUST be satisfied. It is highly recommended for the SDO to encourage its participants to participate in the IETF work to ensure appropriate industry representation in the work.
- IETF内の不十分なサポート。要件のステートメントID内に記述作業がIETFのための範囲内である、とREWGメーリングリスト上の要件のステートメントIDの創始者の支援にもかかわらず、REWGの椅子はにREWGで不十分なサポートがあると判断しています完全な要件のステートメントIDとソリューションがPSWGで作業を開始。この場合、IETFは、解決策に取り組んでからの要求文のI-Dの作者を制限してはいけません。溶液を（及び/又はIANAコードポイントが要求）情報または実験RFCとして検討および可能出版のためにIETFの（G）MPLS PSWGに提示、および、IETFレビュー結果をペンディングされるべきであり、IETFは、コードポイントのためのIANAにアプリケーションをブロックしないもの。 IANAコードポイントの割り当てが必要な場合は、関連するRFCでそれらの割り当てのために処方さIANAの要件を満たす必要があります。 SDOは仕事に適切な業界の表現を確保するために、IETFの作業に参加するためにその参加を奨励することを強くお勧めします。
- Insufficient support for the work from the original requesters. If the authors of the requirements statement I-D do not make themselves available on the REWG mailing list for discussion of the requirements or do not contribute the completion of the requirements statement I-D, the chairs of the REWG MAY determine that there is insufficient support for the work and MAY reject the requirements statement I-D. In this case, the IETF MUST NOT grant permission for the work to be carried out in any other organization, and MUST NOT endorse the publication of any changes or extensions to the (G)MPLS protocols and MUST NOT instruct IANA to allocate any codepoints. The requirements may be reintroduced by starting the procedure again from the top.
- オリジナルのリクエスタからの仕事のための不十分なサポート。要件のステートメントIDの作成者が要件の議論のためのREWGメーリングリストに自身が利用できるようにしていないか、要件のステートメントIDの完成に貢献していない場合は、REWGの椅子は仕事のための十分なサポートがあることを決定することができますそして、要件のステートメントIDを拒否することがあります。この場合には、IETFは、仕事は、他の組織で行うことが許可を与えてはいけません、及び（G）MPLSプロトコルの変更や拡張の発行を承認してはいけませんし、任意のコードポイントを割り当てるIANAに指示してはいけません。要件は、上からもう一度手順を開始することにより、再導入することができます。
- Satisfying the requirements would break the technology. It is possible that an assessment will be made that, although the requirements are reasonable, it is not possible to satisfy them through extensions or changes to the (G)MPLS protocols without violating the (G)MPLS architecture in such a way as would break the (G)MPLS technology. In this case, a recommendation will be made that some other technology be used to satisfy the requirements. See Section 7 for further discussions of the protection of the integrity of the (G)MPLS technology. In this case, the IETF MUST NOT grant permission for the work to be carried out in any other organization, and MUST NOT endorse the publication of any changes or extensions to the (G)MPLS protocols and MUST NOT instruct IANA to allocate any codepoints.
- 要件を満たすことは技術を破ります。要件が合理的であるものの、壊れるような方法で（G）MPLSアーキテクチャに違反することなく（G）MPLSプロトコルの拡張や変更を介してそれらを満足させることは不可能である、という評価がなされることがあります（G）MPLS技術。この場合、勧告は、他のいくつかの技術要件を満たすために使用されていることが行われます。 （G）MPLS技術の整合性の保護のさらなる議論については、セクション7を参照してください。この場合には、IETFは、仕事は、他の組織で行うことが許可を与えてはいけません、及び（G）MPLSプロトコルの変更や拡張の発行を承認してはいけませんし、任意のコードポイントを割り当てるIANAに指示してはいけません。
Upon rejection, the IETF MUST make a clear statement of why the requirements statement I-D has been rejected and what next step actions are acceptable (refer to Section 5.1).
拒否されると、IETFは、要件のステートメントは、I-Dは拒否され、どのような次のステップのアクションは（5.1節参照）許容されてきた理由の明確な声明をしなければなりません。
The communication of the rejection depends on the form of the original submission as follows.
次のように拒絶反応の通信は、元の提出の形式に依存します。
- If the requirements are brought to the IETF as a preliminary investigation (see Section 4.2.1) through an email exchange then the response MUST be made as an email response copied to an IETF mailing list so that it is automatically archived.
- 要件は予備調査としてIETFにもたらされた場合、応答は、それが自動的にアーカイブされるようにIETFメーリングリストにコピーされた電子メールの応答として行われなければならないメール交換を通じて（セクション4.2.1を参照してください）。
- If the requirements are brought to the IETF as a preliminary investigation (see Section 4.2.1) through a formal liaison, the rejection MUST be delivered through a formal liaison response.
- 要件は予備調査としてIETFにされる場合は、正式なリエゾンを通じて（セクション4.2.1を参照）、拒否は正式なリエゾン応答を介して配信されなければなりません。
- If a requirements statement I-D has been produced and discussed on an IETF email list, the response MUST be made as an email response and copied to the email list.
- 要件のステートメントのI-Dを作製し、IETFのメールリストに議論されている場合は、応答は電子メールの応答として行われ、電子メールリストにコピーする必要があります。
- If a requirements statement I-D has been produced and brought to the IETF through a formal liaison, the rejection MUST be delivered through a formal liaison response.
- I-Dを作製し、正式なリエゾンを通じてIETFにもたらされた要件のステートメントの場合、拒否は、正式なリエゾン応答を介して配信されなければなりません。
- If an IETF working group has been involved in the review or production of any Internet-Drafts for the requirements or for the solutions, the working group MUST be notified of the rejection and the reasons.
- IETFワーキンググループが要件またはソリューションのための任意のインターネットドラフトの見直しや生産に携わってきた場合は、ワーキンググループは拒否と理由を通知しなければなりません。
The responsibility for the generation of the response lies with the person, people, or group that instigates the rejection. This may be the IESG, one or more Area Directors, one or more working group chairs, or a designated expert [RFC2434]. In the case of the use of a liaison relationship, the IETF's liaison manager has responsibility for ensuring that the procedures in this document, and particularly the rejection procedures, are followed.
応答の生成のための責任は、拒絶反応を扇動人、人、またはグループです。これはIESG、一つ以上のエリアディレクター、一つ以上のワーキンググループチェア、または指定された専門家[RFC2434]かもしれません。連絡関係を利用する場合には、IETFの連絡マネージャは、この文書に記載されている手順、特に拒否手順は、従っていることを保証する責任を負っています。
[RFC2026] contains additional information related to procedure disagreements and appeals. The rejection of a requirements statement I-D as described in Sections 5.1 and 5.2 may be appealed in the event
[RFC2026]は、プロシージャ不一致とアピールに関連する追加情報を含みます。セクション5.1および5.2に記載されるように要求文I-Dの拒絶は、イベントにアピールすることができます
it is disputed and cannot be reversed by direct discussion between the parties. The conflict resolution and appeal mechanism is documented in [RFC2026].
それが争われ、当事者間の直接の話し合いによって逆転することはできません。紛争解決及びアピール機構は、[RFC2026]に記載されています。
Once the solutions work has been started by the PSWG, it may be abandoned before completion. This can happen if the PSWG chairs determine that there is no longer working group support for doing the work. This could arise, for example, if no one (including the originators of the requirements statement I-D) is willing to contribute to the development of a solutions I-D.
ソリューションの作業がPSWGによって開始された後、それが完了する前に放棄することができます。 PSWGの椅子が作業を行うためのワーキンググループのサポートがなくなったと判断していない場合に発生します。 （要件文のI-Dのオリジネーター含む）誰がI-Dソリューションの発展に貢献して喜んでない場合、これは、例えば、発生する可能性があります。
In the event that the solutions work is abandoned by the PSWG, the Area Directors responsible for the PSWG MUST be consulted. The originators of the requirements statement I-D MUST be informed that the work has been abandoned using a mechanism dependent on how the requirements were introduced (as discussed in Section 5.2).
ソリューションの作業がPSWGにより放棄された場合には、PSWGを担当するエリアの取締役は相談しなければなりません。要件書I-Dのオリジネーターは仕事が（5.2節で述べたように）の要件が導入されたかに依存メカニズムを使用して放棄されたことが通知されなければなりません。
If the solution is abandoned in this way, work on solutions for the requirements MUST NOT be started in another forum. The status of extensions and changes to the (G)MPLS protocols with regard to the specific requirements returns to how it was before the process started. Any new examination of the requirements MUST commence at the top of the process.
溶液はこのように放棄された場合は、別のフォーラムで起動してはならない要件のためのソリューションに取り組んでいます。特定の要件に関して（G）MPLSプロトコルの拡張や変更の状況は、プロセスが開始する前にそれがあったかに戻ります。要件のいずれかの新しい検査は、プロセスの先頭に開始しなければなりません。
The abandonment of a solutions I-D may be appealed in the event it is disputed and cannot be reversed by direct discussion between the parties. The conflict resolution and appeal mechanism is documented in [RFC2026].
ソリューションI-Dの放棄は、それが争われ、当事者間の直接の話し合いによって逆転することができない場合に上訴することができます。紛争解決及びアピール機構は、[RFC2026]に記載されています。
The (G)MPLS working groups are REQUIRED to protect the architectural integrity of the (G)MPLS protocols and MUST NOT extend the GMPLS architecture with features that do not have general use beyond the specific case. They also MUST NOT modify the architecture just to make some function more efficient at the expense of simplicity or generality.
（G）は、ワーキンググループは、（G）MPLSプロトコルのアーキテクチャの整合性を保護するために必要とされており、具体的なケースを超えた一般的な使用を持っていない機能を備えたGMPLSのアーキテクチャを拡張してはならないMPLS。彼らはまた、ただ単純さや汎用性を犠牲にしていくつかの機能をより効率的にするためにアーキテクチャを変更してはいけません。
The architectural implications of additions or changes to the (G)MPLS protocols MUST consider interoperability with existing and future versions of the protocols. The effects of adding features that overlap, or that deal with a point solution and are not general, are much harder to control with rules and risk impacting the protocol as a whole. Therefore, to minimize operational and technical risks to the (G)MPLS technology, IETF processes SHALL be followed for any requests on extensions to (G)MPLS protocols. With respect to (G)MPLS protocols, the (G)MPLS PSWG is the chartered "owner" of the (G)MPLS protocol, as long as the working group exists. All changes or extensions to (G)MPLS MUST first be reviewed by the (G)MPLS PSWG.
（G）への追加や変更の建築含意はMPLSプロトコルは、プロトコルの既存および将来のバージョンとの相互運用性を考慮しなければなりません。重複、またはポイント溶液でその取引および一般的ではない機能を、追加の効果は、全体としてのプロトコルに影響を与える規則およびリスクに制御することがはるかに困難です。したがって、（G）MPLS技術を運用し、技術的なリスクを最小限に抑えるために、IETFのプロセスは、（G）MPLSプロトコルの拡張機能上の任意の要求のために従わなければなりません。 （G）MPLSプロトコルに対して、（G）MPLS PSWGであればワーキンググループが存在するように、（G）MPLSプロトコルのチャーター「所有者」です。 （G）MPLSに対するすべての変更や拡張は、最初の（G）MPLS PSWGによって審査されなければなりません。
All requirements statement I-Ds MUST give full consideration to the security impact of the proposed additional features or functions. All solutions I-Ds MUST consider the impact on the security of the protocol extensions and to the pre-existing protocol.
すべての要件文のI-Dsが提案されている追加の特徴または機能のセキュリティへの影響に十分配慮しなければなりません。すべてのソリューションI-DSは、プロトコルの拡張機能のセキュリティ上および既存のプロトコルへの影響を考慮しなければなりません。
This documents does not itself introduce any security issues for any (G)MPLS protocols.
この文書は、それ自体は、任意の（G）MPLSプロトコルのいずれかのセキュリティ問題を紹介しません。
The IETF process is itself at risk from denial of service attacks. This document utilizes the IETF process and adds clarity to that process. It is possible, therefore, that this document might put the IETF process at risk.
IETFプロセスは、サービス拒否攻撃の危険にさらさそのものです。このドキュメントは、IETFプロセスを利用し、そのプロセスに明確さを追加します。これは、この文書が危険にIETFプロセスを置くかもしれないこと、そのため、可能です。
Therefore, provided that the number of requirements statement I-Ds is not unreasonable, there will be no significant impact on the IETF process. The rate of arrival of requirements statement I-Ds MAY be used by the IESG to detect denial of service attacks, and the IESG SHOULD act on such an event depending on the source of the requirements statement I-D and the perceived relevance of the work. The IESG might, for example, discuss the issue with the management of external organizations.
したがって、要件書I-DSの数は不合理ではないことを提供し、IETFプロセスに重大な影響が生じることはありません。要件書I-DSの到着率は、サービス拒否攻撃を検出するために、IESGによって使用することができ、IESGは必要条件文のI-Dのソースと仕事の知覚関連性に応じて、このようなイベントに行動しなければなりません。 IESGは、例えば、外部組織の管理に問題を議論することがあります。
The input given by Bert Wijnen has been useful and detailed.
バートWijnenによって与えられた入力が便利で詳述されています。
Review feedback and discussions with various members of the ITU-T has been helpful in refining the process described in this document. Thanks in particular to the members of Question 14 of Study Group 15, and to the management of Study Group 15. Important discussions were held with the following participants in the ITU-T: Yoichi Maeda, Greg Jones, Stephen Trowbridge, Malcolm Betts, Kam Lam, George Newsome, Eve Varma, Lyndon Ong, Stephen Shew, Jonathan Sadler, and Ben Mack-Crane.
レビューのフィードバックとITU-Tの様々なメンバーとの議論は、この文書に記載されたプロセスの微細化に役立っています。洋一前田、グレッグ・ジョーンズ、スティーブン・トローブリッジ、マルコムベッツ、カム：研究グループ15の、および15の重要な議論がITU-Tで、次の参加者で開催された研究グループの経営者への質問14のメンバーに特に感謝ラム、ジョージ・ニューサム、イブヴァルマ、リンドンオング、スティーブン供え、ジョナサン・サドラー、そしてベン・マッククレーン。
Thanks for further review comments to Brian Carpenter, Stewart Bryant, Sam Hartman, Mark Townsley, and Dave Ward. Thanks to Spencer Dawkins for the GenArt review.
さらに検討のためのおかげでブライアン・カーペンター、スチュワートブライアント、サム・ハートマン、マークTownsley、とデイブ・ワードにコメントしています。 GenArtレビューのためスペンサードーキンスに感謝します。
This document makes no specific requests to IANA for action. The procedures described in this document assume that IANA will adhere to the allocation policies defined for the (G)MPLS codepoint registries and that the IETF will not endorse allocation of codepoints from those registries except where work has been carried out in accordance with the procedures described in this document.
この文書では、アクションのためのIANAへの具体的な要求を行うものではありません。この文書に記載されている手順は、IANAは、（G）用に定義された割り当てポリシーに準拠すると仮定コードポイントレジストリをMPLSおよびIETFは、作業が記載された手順に従って行われている場合を除き、これらのレジストリからのコードポイントの割り当てを承認しないことこのドキュメントインチ
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[RFC2026]ブラドナーの、S.、 "インターネット標準化プロセス - リビジョン3"、BCP 9、RFC 2026、1996年10月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2418] Bradner, S., "IETF Working Group Guidelines and Procedures", BCP 25, RFC 2418, September 1998.
[RFC2418]ブラドナーの、S.、 "IETFワーキンググループガイドラインと手順"、BCP 25、RFC 2418、1998年9月。
[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月。
[RFC4052] Daigle, L., Ed., 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から連絡文を処理するための手順"。
[RFC4775] Bradner, S., Carpenter, B., Ed., and T. Narten, "Procedures for Protocol Extensions and Variations", BCP 125, RFC 4775, December 2006. 2006.
[RFC4775]ブラドナーの、S.、大工、B.、エド。、およびT. Narten氏、BCP 125、RFC 4775、2006、2006年12月 "プロトコル拡張機能やバリエーションのための手順"。
[RFC3356] Fishman, G. and S. Bradner, "Internet Engineering Task Force and International Telecommunication Union - Telecommunications Standardization Sector Collaboration Guidelines", RFC 3356, August 2002.
[RFC3356]フィッシュマン、G.とS.ブラドナーの、「インターネットエンジニアリングタスクフォースおよび国際電気通信連合 - 電気通信標準化部門の連携ガイドライン」、RFC 3356、2002年8月。
Authors' Addresses
著者のアドレス
George Swallow Cisco Systems EMail: swallow@cisco.com
ジョージツバメシスコシステムズ電子メール：swallow@cisco.com
Deborah Brungard AT&T EMail: dbrungard@att.com
デボラBrungard AT＆T Eメール：dbrungard@att.com
Bill Fenner AT&T EMail: fenner@research.att.com
ビルフェナーAT＆T Eメール：fenner@research.att.com
Ross Callon Juniper Networks EMail: rcallon@juniper.net
ロスCallonジュニパーネットワークスのEメール：rcallon@juniper.net
Kireeti Kompella Juniper Networks EMail: Kireeti@juniper.net
Kireeti KompellaジュニパーネットワークスのEメール：Kireeti@juniper.net
Alex Zinin Alcatel EMail: zinin@psg.com
アレックスジニンアルカテルEメール：zinin@psg.com
Scott Bradner Harvard University EMail: sob@harvard.edu
スコット・ブラッドナーハーバード大学Eメール：sob@harvard.edu
Editors' Addresses
エディタのアドレス
Loa Andersson Acreo AB EMail: loa@pi.se
ロア・アンダーソンAcreo ABメール：loa@pi.se
Adrian Farrel Old Dog Consulting EMail: adrian@olddog.co.uk
エードリアンファレル老犬のコンサルティングメール：adrian@olddog.co.uk
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（2007）。
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 HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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機能のための基金は現在、インターネット協会によって提供されます。