[要約] RFC 4929は、MPLSとGMPLSプロトコルおよび手順の変更プロセスに関するものです。その目的は、これらのプロトコルと手順の変更を効果的かつ安全に実施するためのガイドラインを提供することです。
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
マルチプロトコルラベルスイッチング（MPLS）および一般化されたMPLS（GMPLS）プロトコルと手順の変化プロセス
Status of This Memo
本文書の位置付け
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネットの最良のプラクティスを指定し、改善のための議論と提案を要求します。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（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）プロトコルスイートを適用または拡張するためのガイドラインを提供し、（g）MPLSプロトコルに対するIETF（g）MPLSワーキンググループの責任を明確にします。このドキュメントは、（g）MPLSの作業をIETFで理解するためにマルチベンダーFORAおよび標準開発組織（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の2つのメイントラックで開発されています。「MPLS」とは、パケット切り替えネットワークで行われた作業を指し、「GMPLS」とは、Packetや非パケットテクノロジーを含むあらゆる種類のネットワークに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）MPLSワーキンググループで進行中の努力と矛盾している（g）MPLSワーキンググループに相談することなく、特に拡張の開発が拡張の開発であり、その後（g）MPLSワーキンググループに 'faitとして提示されました共通 '。
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の公開プロセス以外で、他のFORAによる非標準拡張機能の定義と公開は、FORAベンダー間の使用に限定されているか、特定のアプリケーションに限定されているか、またはタイムリーなデモを許可するように合理化されているかどうかに関係なく、相互運用性を妨害し、プロトコルの複雑さを高め、業界での混乱を妨げる不幸な可能性があり、プロトコルの実装性を確保するために存在するインターネット標準プロセスを回避します。[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.
このドキュメントでは、IETFのMPLSと共通制御および測定平面（CCAMP）ワーキンググループの役割と（g）MPLSプロトコルの役割と責任を明確にし、IETFレビューを使用する[RFC4775]手順の必要な使用と適用方法を文書化します（g）MPLSプロトコルを適用または拡張したい場合、プロセス[RFC2026]および[RFC2418]。IETFレビュープロセスを使用すると、プロトコル開発のためのオープンなプロセスが確保され、これらのIETFプロトコルの非薬物進化が確保され、大規模な業界ユーザーコミュニティに利益をもたらします。IETF自体は、（g）MPLS変更手順を使用するためにフォーラムを施行することはできませんが、IANAの割り当てまたはIETFの公開を申請する際には、この手順が完了するまで延期されます。
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およびFORAが（g）MPLSの変更を提案したい場合に使用する必要があります。関係する変更が責任あるエリアディレクター（たとえば、ワーキンググループチャーターの対象）によって非操作と見なされない限り、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ワーキンググループチェア、およびIETFのITU-Tへのリエゾンの共同作業です。著者が感謝している経験に基づいて時間と意見を与えた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.
このドキュメントはプロトコルの定義ではありませんが、キーワードは「必須」、「必要はない」、「必須」、「しなければ」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、およびこのドキュメントの「オプション」は、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.
IETFのルーティングエリアの2つのワーキンググループは、（G）MPLSテクノロジーの開発に関連する作業を担当しています。マルチプロトコルラベルスイッチング（MPLS）ワーキンググループと共通制御および測定面（CCAMP）ワーキンググループ。
The following sections provide brief overviews of the chartered work of these two IETF working groups.
次のセクションでは、これら2つの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テクノロジーのチャーターされた権限のままであることを前提としていますが、IETFは特定の拡張またはプロトコルの変更を処理するために別のワーキンググループ（[RFC2418]を参照）を任命する可能性があることに注意してください。さらに、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）ワーキンググループは、ITF内のITF内の研究を調整し、ISPおよびSPコアトンネリング技術の共通制御および測定面を定義します。これには、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ワーキンググループが焦点を当てる技術は一般化されたMPLS（GMPL）と呼ばれ、CCAMPが一般化されたテクノロジーに対処していることを示しています。ここでは、ラベルがデータが輸送される技術と互換性があるように定義されています。MPLSワーキンググループはパケットとフレームのスイッチのテクノロジーに焦点を当てていますが、CCAMPワーキンググループワークは、パケットやフレームテクノロジーを含む幅広いスイッチングテクノロジーにわたって一般的な方法に焦点を当てています。この点で、GMPLは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）MPLへの拡張が必要になる場合に従うべき適用可能な手順を定義します。このセクションでは、（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.
Optical（IPO）ワーキンググループおよびインターネットトラフィックエンジニアリングワーキンググループ（TEWG）をめぐるIPは、（g）MPLSワーキンググループによって考慮される（g）MPLの問題と要件に焦点を当てたワーキンググループの例です。これらのワーキンググループは、プロトコルを指定していません。
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に必要なプロトコル拡張は、必要に応じてMPLS、CCAMP、OSPF、IS-IS、IDR、L3VPN、およびその他のWGSと協力して行われます。つまり、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]との正式または非公式の連絡関係があります。IETFは、リエゾンステートメント[RFC4053]を使用して、計画やスケジュールなど、両側で何が起こっているかについて、これらの組織と情報を交換します。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）MPLのこれらの手順の適用は、セクション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ワーキンググループ、関連するエリアディレクター、または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および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内で内部で使用する必要があります。（g）MPLSプロトコルの変更または拡張は、他のメカニズムによって作成されてはなりません。IETFは、このドキュメントの手順の正しい実行を通じて発生するものを除き（G）MPLSプロトコルを変更または拡張する出版物（RFC、標準の追跡、情報、または実験的であろうと、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に、A（g）MPLS要件評価ワーキンググループ（REWG）および（g）MPLSプロトコルソリューションワーキンググループ（PSWG）の役割を説明する視覚的な概要を示します。この図は、リクエスターの2つの代替案を示しています。（1）問題定義フェーズ（予備調査）の早い段階でIETFに連絡するか、（2）要件声明を記載しています。図はイラスト専用です。考えられるすべての相互作用と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とリエゾン関係を持っている場合、正式なリエゾンを使用してこのステップを実行する場合があります。リエゾンは、責任ある広告を割り当てる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.
要件ステートメントI-Dは、REWGメーリングリストへの電子メール、ルーティングエリアディスカッションメーリングリスト、またはIETFが要件ステートメントI-Dを導入する外部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によって正式に評価されるかどうかを決定し、PER [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が、アプリケーションステートメントインターネットドラフトの作成において、AN 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]を参照）を使用することができます。たとえば、充電、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.
ワーキンググループが作成したすべてのインターネットドラフトと同様に、ADSは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は、[RFC2418]の手順を使用してドラフトパブリケーションのためにIETFに送信され、検討のためにPSWGに導入されたIETF内で外部から（外部組織内など）またはIETF内で準備できます。このようなI-DSは、要件の開発と議論においてREWGを支援するためにプロセスの初期段階で提出される場合がありますが、PSWGが作業と作業をカバーするチャーターアイテムを持つまで、I-DはソリューションI-Dと正式に見なされません。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は、外部から生成されたソリューションI-DがPSWGソリューションI-Dの基礎を形成することを保証しませんが、PSWGは、同じオープン手順（[RFC2418]）を使用して、レビューと改訂のためにそのようなI-DをソリューションI-Dと見なす必要があります。個別の提出のため。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の利害関係者（実装者とユーザーの両方）は、Solutionsの作業に適切な関心が示され、タイムリーなソリューション開発を提供するために、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はプロトコルを要件を満たすためにどのように使用できるかを説明する必要があり、アプリケーションステートメントインターネットドラフトの生産における要件ステートメントI-Dの著者と協力することができます。既存のプロトコルを使用して要件を満たす方法を正確に説明するインターネットドラフトをプロファイルします。
- 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内でのサポートが不十分です。要件ステートメントI-D内で説明されている作業はIETFの範囲内であり、REWGメーリングリストでの要件ステートメントI-Dの元の声明のサポートにもかかわらず、REWGの椅子はREWGに不十分なサポートがあると判断しました。完全な要件ステートメントI-DとPSWGでのソリューションの開始作業。この場合、IETFは、要件ステートメントI-Dの著者にソリューションの作業を制限してはなりません。ソリューション（および/または要求されたIANAコードポイント）は、情報または実験的RFCとしてのレビューおよび可能な公開のためにIETFの（g）MPLS PSWGに提示され、IETFのレビュー結果を保留すると、IETFはコードポイントのIANAへのアプリケーションをブロックしてはなりません。IANA CodePointの割り当てが必要な場合、関連する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.
- 元の要求者からの作業に対する不十分なサポート。要件ステートメントI-Dの著者がREWGメーリングリストで要件の議論のために利用できない場合、または要件ステートメントI-Dの完了に貢献しない場合、REWGの椅子は、作業に対するサポートが不十分であると判断する場合があります。要件ステートメントI-Dを拒否する場合があります。この場合、IETFは、他の組織で実行される作業の許可を与えてはなりません。また、変更または拡張機能の公開を（g）MPLSプロトコルに承認してはなりません。要件は、手順を上から再度開始することにより再導入される場合があります。
- 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プロトコルに承認してはなりません。
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.
- 要件がEETFに予備調査としてもたらされる場合（セクション4.2.1を参照）、電子メール交換を介して、回答をIETFメーリングリストにコピーして、自動的にアーカイブされるように電子メール応答として行う必要があります。
- 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、1つ以上のエリアディレクター、1つ以上のワーキンググループチェア、または指定された専門家[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 it is disputed and cannot be reversed by direct discussion between the parties. The conflict resolution and appeal mechanism is documented in [RFC2026].
[RFC2026]には、手順の意見の不一致と控訴に関連する追加情報が含まれています。セクション5.1および5.2で説明されている要件ステートメントI-Dの拒否は、争われている場合に上訴される場合があり、当事者間の直接的な議論によって逆転することはできません。紛争解決と控訴メカニズムは[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）MPLSワーキンググループは、（g）MPLSプロトコルのアーキテクチャの完全性を保護するために必要であり、特定のケースを超えて一般的に使用されていない機能を使用してGMPLSアーキテクチャを拡張してはなりません。また、シンプルさや一般性を犠牲にして何らかの機能をより効率的にするためだけに、アーキテクチャを変更してはなりません。
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テクノロジーに対する運用および技術的リスクを最小限に抑えるには、（g）MPLSプロトコルへの拡張機能のリクエストに対してIETFプロセスに従うものとします。（g）MPLSプロトコルに関しては、（g）MPLS PSWGは、ワーキンググループが存在する限り、（g）MPLSプロトコルのチャーター「所有者」です。（g）MPLへのすべての変更または拡張機能は、最初に（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.
Bert 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の質問14のメンバー、および研究グループ15の管理管理に感謝します。ITU-Tの以下の参加者と重要な議論が行われました。ラム、ジョージ・ニューサム、イブ・ヴァルマ、リンドン・オング、スティーブン・シュー、ジョナサン・サドラー、ベン・マック・クレーン。
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.
ブライアン・カーペンター、スチュワート・ブライアント、サム・ハートマン、マーク・タウンズリー、デイブ・ワードへのさらなるレビューコメントをありがとう。GenartレビューをしてくれたSpencer Dawkinsに感謝します。
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] Bradner、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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2418] Bradner, S., "IETF Working Group Guidelines and Procedures", BCP 25, RFC 2418, September 1998.
[RFC2418] Bradner、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.、ed。、およびインターネットアーキテクチャボード、「IETFリエゾン関係の管理のためのIABプロセス」、BCP 102、RFC 4052、2005年4月。
[RFC4053] Trowbridge, S., Bradner, S., and F. Baker, "Procedures for Handling Liaison Statements to and from the IETF", BCP 103, RFC 4053, April 2005.
[RFC4053] Trowbridge、S.、Bradner、S。、およびF. Baker、「IETFとの連絡ステートメントを処理する手順」、BCP 103、RFC 4053、2005年4月。
[RFC4775] Bradner, S., Carpenter, B., Ed., and T. Narten, "Procedures for Protocol Extensions and Variations", BCP 125, RFC 4775, December 2006. 2006.
[RFC4775] Bradner、S.、Carpenter、B.、Ed。、およびT. Narten、「プロトコル拡張とバリエーションの手順」、BCP 125、RFC 4775、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] Fishman、G。およびS. Bradner、「インターネットエンジニアリングタスクフォースおよび国際電気通信連合 - 電気通信標準化セクターコラボレーションガイドライン」、RFC 3356、2002年8月。
Authors' Addresses
著者のアドレス
George Swallow Cisco Systems EMail: swallow@cisco.com
George Swallow Cisco Systems Email：swallow@cisco.com
Deborah Brungard AT&T EMail: dbrungard@att.com
Deborah Brungard AT＆Tメール：dbrungard@att.com
Bill Fenner AT&T EMail: fenner@research.att.com
Bill Fenner AT＆Tメール：fenner@research.att.com
Ross Callon Juniper Networks EMail: rcallon@juniper.net
Ross Callon Juniper Networksメール：rcallon@juniper.net
Kireeti Kompella Juniper Networks EMail: Kireeti@juniper.net
Kireeti Kompella Juniper Networksメール：kireeti@juniper.net
Alex Zinin Alcatel EMail: zinin@psg.com
Alex Zinin Alcatelメール：zinin@psg.com
Scott Bradner Harvard University EMail: sob@harvard.edu
スコット・ブラッドナー・ハーバード大学のメール：sob@harvard.edu
Editors' Addresses
編集者のアドレス
Loa Andersson Acreo AB EMail: loa@pi.se
Loa Andersson Acreo ABメール：loa@pi.se
Adrian Farrel Old Dog Consulting EMail: adrian@olddog.co.uk
Adrian Farrel Old Dog Consultingメール：adrian@olddog.co.uk
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。