RFC4929 日本語訳
4929 Change Process for Multiprotocol Label Switching (MPLS) andGeneralized MPLS (GMPLS) Protocols and Procedures. L. Andersson, Ed.,A. Farrel, Ed.. June 2007. (Format: TXT=56742 bytes) (Also BCP0129) (Status: BEST CURRENT PRACTICE)
プログラムでの自動翻訳です。
英語原文
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
ワーキンググループのL.アンデション、エドをネットワークでつないでください。コメントのために以下を要求してください。 4929Acreo AB BCP: 129 エドA.ファレル、カテゴリ: 犬のコンサルティング2007年6月に古い最も良い現在の習慣
Change Process for Multiprotocol Label Switching (MPLS) and
Generalized MPLS (GMPLS) Protocols and Procedures
Multiprotocolラベルの切り換え(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.
このドキュメントはインターネット共同体、要求議論、および提案のためのインターネットBest Current Practicesを改良に指定します。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(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とドキュメントにおける、(G) MPLS仕事の理解にIETFレビュー手順の必要な使用を提供するようマルチベンダフォーラムとStandards Development Organizations(SDOs)に指示されます。 このドキュメントはIETFの過程を変更しません。
Andersson & Farrel Best Current Practice [Page 1] RFC 4929 MPLS and GMPLS Change Process June 2007
アンデションとファレル最も良い現在の習慣[1ページ]RFC4929MPLSとGMPLSは過程2007年6月に変化します。
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
1. 序論…3 1.1. ソースを記録してください…4 1.2. このドキュメントで中古のコンベンション…4 2. (G) IETFの中のMPLSの概観…4 2.1. (G) MPLS技術を開発するIETFワーキンググループ…5 2.1.1. Multiprotocolは切り換え作業部会をラベルします…5 2.1.2. 共通制御機構と測定飛行機作業部会…5 2.1.3. 仕事のMPLSとCCAMP事業部…6 2.2. 他の(G)のMPLSの技術関連のワーキンググループ…6 2.3. IETFの外での組織…7 3. (G) MPLS変化の過程の概観…8 4. MPLSとGMPLSは過程を変えます…9 4.1. フローチャート…10 4.2. 過程ステージの記述…11 4.2.1. 下調べ…12 4.2.2. 要件声明評価…13 4.2.3. ワーキンググループ手順…14 4.2.4. 要件声明I-DのREWG評価。14 4.2.5. 完成した要件声明I-DのAD評価…14 4.2.6. Requirements Statement I-DとPSWG憲章のIESGレビュー…15 4.2.7. ソリューションは働いています…15 5. 要件声明I-Dを拒絶します…16 5.1. 拒絶の理由…16 5.2. 要件声明I-Dsを拒絶するとき、動作が必要です…18 5.3. 上告します…18 6. ソリューションI-Dの放棄…19 6.1. 上告します…19 7. (G)MPLS保全と所有権…19 8. セキュリティ問題…20 9. 承認…20 10. IANA問題…21 11. 参照…21 11.1. 標準の参照…21 11.2. 有益な参照…21
Andersson & Farrel Best Current Practice [Page 2] RFC 4929 MPLS and GMPLS Change Process June 2007
アンデションとファレル最も良い現在の習慣[2ページ]RFC4929MPLSとGMPLSは過程2007年6月に変化します。
1. Introduction
1. 序論
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」はパケットと非パケット技術を含むすべてのタイプのネットワークに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]は他のSDOsでIETFプロトコルの拡大か変化に関連する手続き上の問題について議論します。 IETFプロトコルと拡大のための要件を考えるとき、他のSDOsによって使用されるように、それはガイドラインと手順を提供します。 [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ワーキンググループに提示されています)。
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.
他のフォーラムのそばでの標準的でない拡大の定義と出版は、プロトコルimplementabilityを確実にするために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
このドキュメントが(G)MPLSプロトコルへのIETFのMPLS、Common Control、およびMeasurement Plane(CCAMP)ワーキンググループの役割と責任をはっきりさせて、必要な使用を記録する、どのように
Andersson & Farrel Best Current Practice [Page 3] RFC 4929 MPLS and GMPLS Change Process June 2007
アンデションとファレル最も良い現在の習慣[3ページ]RFC4929MPLSとGMPLSは過程2007年6月に変化します。
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.
[RFC2026]と[RFC2418]、適用するために、IETFレビューを使用する[RFC4775]手順は処理されます、(G)MPLSプロトコルを適用したいか、または広げたがっているフォーラムに。 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通のドキュメントと一致した方法で実行されることです。 他のSDOsと(G) MPLS変化を提案するというフォーラム願望であるときに、それらを使用しなければなりません。 それら、関する変化が非論議を呼ぶのは責任があるAreaディレクター(例えば、ワーキンググループ特許で、覆われる)によって考えられない場合SHOULDがIETFの中で内部的に使用されて、その場合、正常なIETF標準化過程の他の局面が必要な手順をカバーしています。
1.1. Document Source
1.1. ドキュメントソース
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ルート設定のAreaディレクター、IETF MPLS、およびCCAMP作業部会Chairsの共同作業と、ITU-TへのIETFの連絡です。 それには、作者が感謝している経験に基づく彼らの時間と意見を教えたITU-Tの主要なメンバーからのかなりのレビューとコメントがありました。 また、IESGは、ここに記録された過程に到着するように貴重な入力を提供しました。 承認部は貢献が特に役立っているそれらを記載します。
1.2. Conventions Used in This Document
1.2. 本書では使用されるコンベンション
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.
このドキュメントはプロトコル定義ではありませんが、キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[RFC2119]で説明されるように本書では解釈されることであるべきですか? この用法はステップをするように選ばれています、そして、手順は完全にクリアされます。
2. Overview of (G)MPLS within the IETF
2. (G) IETFの中のMPLSの概観
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ワーキンググループの情報を提供します。
Andersson & Farrel Best Current Practice [Page 4] RFC 4929 MPLS and GMPLS Change Process June 2007
アンデションとファレル最も良い現在の習慣[4ページ]RFC4929MPLSとGMPLSは過程2007年6月に変化します。
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の中の関連ワーキンググループの概観はスナップにすぎません。
2.1. IETF Working Groups Developing (G)MPLS Technology
2.1. (G) MPLS技術を開発する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のルート設定Areaの2つのワーキンググループが(G)MPLS技術を開発すると関連する仕事に責任があります: Multiprotocol Label Switching(MPLS)ワーキンググループとCommon ControlとMeasurement Plane(CCAMP)ワーキンググループ。
The following sections provide brief overviews of the chartered work of these two IETF working groups.
以下のセクションはこれらの2つのIETFワーキンググループの貸し切りの仕事の簡潔な概観を提供します。
2.1.1. Multiprotocol Label Switching Working Group
2.1.1. Multiprotocolラベル切り換え作業部会
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.
Multiprotocol Label Switching(MPLS)ワーキンググループはラベルの切り換えを使用するベース技術を標準化して、様々なパケットとフレームベースのリンク・レベル技術の上でLabel Switched Paths(LSPs)の実現について説明するのに責任があります。 ワーキンググループ特許はルータの間のラベルの分配のための手順とプロトコルを含んでいます、カプセル化、操作、管理、交通工学、およびマルチキャスト問題と同様に。
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]では、説明される)使用を使用するでしょう。
2.1.2. Common Control & Measurement Plane Working Group
2.1.2. 共通制御機構と測定飛行機作業部会
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 Common ControlとMeasurement Plane(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
CCAMPワーキンググループが焦点を合わせる技術はGeneralized MPLS(GMPLS)と呼ばれます、CCAMPが一般化された技術を記述するのを示してそれ。そこでは、ラベルがそのような方法で定義されます。
Andersson & Farrel Best Current Practice [Page 5] RFC 4929 MPLS and GMPLS Change Process June 2007
アンデションとファレル最も良い現在の習慣[5ページ]RFC4929MPLSとGMPLSは過程2007年6月に変化します。
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.
それらはデータが輸送される技術と互換性があるでしょう。 MPLSワーキンググループはパケットとフレームで切り換えられた技術に焦点を合わせますが、パケットとフレーム技術を含んでいて、CCAMPワーキンググループ仕事は切り換え技術の広いスペクトルの向こう側に共通方法に焦点を合わせます。 この点で、MPLSのスーパーセットとしてGMPLSを見なすことができます。
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]では、説明される)使用を使用するでしょう。
2.1.3. MPLS and CCAMP Division of Work
2.1.3. 仕事のMPLSとCCAMP事業部
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ワーキンググループは、ワーキンググループ特許で定義されるように厳密にワーキンググループの間の分裂に続かない方法で自分たちの間の仕事を分割すると決めます。 これはそうです、例えば、P2MP TE LSPsのために。そこでは、MPLSワーキンググループが(G)MPLS技術のすべてに要件とベース技術を指定しています。
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)に提案をもたらすかを決めるべきです。 しかしながら、彼らのAreaディレクターに関連して、MPLSとCCAMPワーキンググループいすは別のワーキンググループに提案を向け直すかもしれません。
2.2. Other (G)MPLS Technology-Related Working Groups
2.2. 他の(G)のMPLSの技術関連のワーキンググループ
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への拡大が必要であるときに、続くようにそれらの役割、他のワーキンググループとの関係、および適切な手順を定義します。 このセクションはMPLS関連のグループとそれらの責任を(G)の概観に提供します。 ワーキンググループと彼らの特許について説明する追加情報はIETFウェブページで利用可能です。
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)ワーキンググループの上のIPとインターネットTraffic Engineeringワーキンググループ(TEWG)は問題声明に焦点を合わせるワーキンググループと(G) MPLSが(G)MPLSワーキンググループによって考えられるという要件に関する例です。 これらのワーキンググループはどんなプロトコルも指定していません。
Andersson & Farrel Best Current Practice [Page 6] RFC 4929 MPLS and GMPLS Change Process June 2007
アンデションとファレル最も良い現在の習慣[6ページ]RFC4929MPLSとGMPLSは過程2007年6月に変化します。
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.
Bidirectional Forwarding Detection(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.
Layer2VPN(L2VPN)とLayer3VPN(L3VPN)ワーキンググループは、Provider Provisioned VPNsの限られた数の解決策を指定するためにチャーターされました。 両方のワーキンググループがインターネットAreaにあります。 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.
Layer1VPN(L1VPN)ワーキンググループは、VPNサービスをLayer1に供給するのに必要なメカニズムを指定するためにチャーターされます。(CE装置の間の1つの接続) aの上でGMPLSによって可能にされた輸送サービスプロバイダーがネットワークでつなぐ層の設立。 MPLSと提携してL1VPNに必要であるプロトコル拡大をするでしょう、CCAMP、OSPF、-、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.
End(PWE3)ワーキンググループへのPseudo Wire Emulation Endは仕様で(G)MPLSプロトコルを使用するかもしれないワーキンググループです。 PWE3仕様が拡大を必要とするべきですか、または(G)MPLSプロトコルへの変化、指定されるとしての特許による手順、およびIETFの標準の過程は適切です。
2.3. Organizations Outside the IETF
2.3. 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].
多くの規格開発組織(SDOs)と産業フォーラムが、それらの仕様で(G)MPLSプロトコルに使用するか、または参照をつけます。 これらの組織の中には、IETF[RFC4052]との正式であるか非公式の連絡関係を持っているものもあります。 何が両側で起こるかに関してIETFはこれらの組織と共に情報交換します、プランとスケジュールを含んでいて、連絡声明[RFC4053]を使用して。 [RFC3356]でIETFとITU-Tとの協力関係に関するその他の詳細を見つけることができます。
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プロトコルに拡大か変更のための要件を持っているなら、手順は本書では適用されます。
Andersson & Farrel Best Current Practice [Page 7] RFC 4929 MPLS and GMPLS Change Process June 2007
アンデションとファレル最も良い現在の習慣[7ページ]RFC4929MPLSとGMPLSは過程2007年6月に変化します。
3. Overview of (G)MPLS Change Process
3. (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.
適切なAreaディレクター、およびMPLSのいすを通した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プロトコルへの変更なしで要件を満たすことができます。
Andersson & Farrel Best Current Practice [Page 8] RFC 4929 MPLS and GMPLS Change Process June 2007
アンデションとファレル最も良い現在の習慣[8ページ]RFC4929MPLSとGMPLSは過程2007年6月に変化します。
- 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プロトコルへのStandards-道の変化を保証するために標準化過程解決策ができるくらいの関心がありません。
- 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])は仕事が終了しているのを確実にするための交互のオプションを提供します。
4. MPLS and GMPLS Change Process
4. MPLSとGMPLSは過程を変えます。
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]と一致していることです。
Andersson & Farrel Best Current Practice [Page 9] RFC 4929 MPLS and GMPLS Change Process June 2007
アンデションとファレル最も良い現在の習慣[9ページ]RFC4929MPLSとGMPLSは過程2007年6月に変化します。
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プロトコルの1つを使用するつもりですが、本書では説明されて、それが手順を用いなければならないと考えるのを彼らの需要を満たさない人はだれも。 それら、関する変化が非論議を呼ぶのは責任があるAreaディレクター(例えば、ワーキンググループ特許で、覆われる)によって考えられない場合SHOULDがIETFの中で内部的に使用されて、その場合、正常なIETF標準化過程の他の局面が適用されます。 (G)MPLSプロトコルへの変更か拡大がいかなる他のメカニズムによっても行われてはいけません。 IETF MUST NOTは手順の正しい実行で本書では起こるもの以外の(G)MPLSプロトコルを変えるか、または広げるどんな刊行物(Standards Track、Informational、またはExperimentalにかかわらずRFCsを含んでいる)にも裏書きします。 IETF MUST NOTは(G) MPLSプロトコルcodepointsを割り当てるどんなIANA動作も是認します、手順の正しい実行から本書では起こる動作を除いて。
4.1. Flow Diagram
4.1. フローチャート
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手順代替手段のすべてを含んでいません。 その後のセクションのテキストは過程について説明します。
Andersson & Farrel Best Current Practice [Page 10] RFC 4929 MPLS and GMPLS Change Process June 2007
アンデションとファレル最も良い現在の習慣[10ページ]RFC4929MPLSとGMPLSは過程2007年6月に変化します。
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
始め+-------------+ | |任意| +--<。--------------------|準備段階| <、-、-、-、-、-、--始め| |調査| +に対して-------------+ +------------+ +---------+ +---------+ |要件| 議論|論評してください。| はい| IESG| はい|声明|、-、-、-、-、-、-、-、-、-、--、>|WGいす|、-、-、-、-、-、-、-、-、-、-、-、--、>|決定|------+ |I-D| 郵送に関して|そして、広告| 要求| | | +------------+ リスト+---------+ +へのIESG---------+ | | REWGを任命してください。| | |ノー、と特許|REWGがありません。| V req eval| チャーターされます。| +-------------+ | 仕事に、オンです。| |応答| | 要件| |the| | 声明| |要件| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--+ | +->|声明| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--+ | | +-------------+ | | | ^ | | いいえ| | いいえ| | | +-----------------+ | V| | | +がありません。------+ +--------+ +-------+ +--------| REWG| | IESG/| はい| 西暦| | req| +-----------|決定| <、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|レビュー| <、-、-、-、-、-、-、-、-、-、-、--、| eval| |PSWG| | 要求| | はい| | |貸し切りの+--------+ +へのIESG-------+ +------+ |働くには、I-Dを承認してください。| そして、特許| PSWG(必要であるなら)| +---------+ | | IETF| +-----+ +--------->| PSWG|-----/ /---->| RFC| +---->| 過程| +-----+ | +---------+ ソリューションI-D図1: 変化過程概観
4.2. Description of Process Stages
4.2. 過程ステージの記述
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の責任を広げたいか、または変えたがっている組織について、説明します。
Andersson & Farrel Best Current Practice [Page 11] RFC 4929 MPLS and GMPLS Change Process June 2007
アンデションとファレル最も良い現在の習慣[11ページ]RFC4929MPLSとGMPLSは過程2007年6月に変化します。
4.2.1. Preliminary Investigation
4.2.1. 下調べ
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.
このステップは、OPTIONALであり、提案のときにインターネット草稿を書く努力に行かないで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.
下調べフェーズが任意ですが、どんな要件の創始者もどんな無駄な努力も避けることをできるだけ早く心配している問題を参照して、議論するのが、RECOMMENDEDであり、下調べフェーズは、これをするためにメカニズムを提供します。
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.
このステップSHOULDはREWGに関するメーリングリストの上、または、ルート設定Area議論メーリングリストの上で非公式に行われて、どんな個人、個体群、外部の組織、または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との連絡関係があるとき、正式な連絡係を使用して、それはこのステップを行うかもしれません。 連絡SHOULD、Responsible ADを割り当てるIESGにそれらを送るのに責任がある指定された連絡のマネージャに送ってください。 連絡SHOULDの創始者は自分たちを選択されたメーリングリストについての議論に利用可能にします。 正式な連絡係が使用されていると、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 MAY、生産されて、さらに議論を助けて、記述される問題をはっきりさせてください。
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
この下調べの可能な結果は要件と問題が、理解されていましたが、IETFのための範囲の外にあるのに同意したということです。 代わりに、そして、多分、既存のプロトコルで問題を解決できます。 セクション4.2.2で説明された要件声明評価段階に、下調べフェーズからの結果の完全リストはそれらと同様ですが、IETFが、プロトコル解決策を見いだすと考えるつもりであるなら、完全な要件セットを発展させることへの、より広いIETF住民参加を許容する要件声明評価段階は過程の一部を形成しなければなりません。 過程はダイレクトに動くことができません。
Andersson & Farrel Best Current Practice [Page 12] RFC 4929 MPLS and GMPLS Change Process June 2007
アンデションとファレル最も良い現在の習慣[12ページ]RFC4929MPLSとGMPLSは過程2007年6月に変化します。
preliminary investigation phase to the development of solutions unless the working group agrees (e.g., the problem is minor).
ワーキンググループが同意しない場合(例えば、問題は小さい方です)調査が解決策の開発に位相を合わせる準備段階。
4.2.2. Requirements Statement Evaluation
4.2.2. 要件声明評価
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 MUSTが[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 MUSTが作者によってREWGメーリングリストへのメールでIETFに紹介されて、ルート設定Area議論メーリングリスト、または正式な外部のSDOからの連絡係で要件声明I-DをREWGメーリングリストに取り入れるIETFをもたらしてください。 要件声明I-Dが正式な連絡係でIETFに持って来られるなら、連絡SHOULDの創始者は自分たちを指定された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によって正式に評価されるか否かに関係なく、決めなければならなくて、応答を渡さなければならない責任があるAreaについての議論の後、[RFC4053]と[RFC4775]単位で。 正式な連絡係は使用されませんでした、応答SHOULD。コミュニケーションに記載されているように適切な接触に渡してください。
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ワーキンググループ、Applicability Statementインターネット草稿の生産で。
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プロトコルへの変化を起こすという他の要件に結合されるかもしれません。
Andersson & Farrel Best Current Practice [Page 13] RFC 4929 MPLS and GMPLS Change Process June 2007
アンデションとファレル最も良い現在の習慣[13ページ]RFC4929MPLSとGMPLSは過程2007年6月に変化します。
4.2.3. Working Group Procedures
4.2.3. ワーキンググループ手順
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でカバーされた問題はワーキンググループの既存の特許の範囲の中に下がるでしょう。 この場合、責任があるAreaディレクターは評価のためにワーキンググループへの要件声明I-DにREWGとパスとしてのワーキンググループを指定するでしょう。 問題が既存の特許でカバーされていないなら、他の代替手段(言及します[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 MUSTは直ちにこれを要請者に伝えます。
4.2.4. REWG Evaluation of the Requirements Statement I-D
4.2.4. 要件声明I-DのREWG評価
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 MUSTの創始者は自分たちをREWGメーリングリストに対する仕事について議論するために利用可能にします。 これが起こらないなら、REWG MAYのいすは、仕事の不十分なサポートがあると決心して、要件声明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で説明されるように応答手順を用いる要件の拒絶。
4.2.5. AD Evaluation of Completed Requirements Statement I-D
4.2.5. 完成した要件声明I-DのAD評価
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を見直すでしょう。 そして、ADsはレビューのためにドキュメントをIESGに渡すでしょう。 特許変化が必要であるか、そして、新しいPSWGが必要であることで、適切な過程は従われるでしょう。
Andersson & Farrel Best Current Practice [Page 14] RFC 4929 MPLS and GMPLS Change Process June 2007
アンデションとファレル最も良い現在の習慣[14ページ]RFC4929MPLSとGMPLSは過程2007年6月に変化します。
4.2.6. IESG review of Requirements Statement I-D and PSWG Charter
4.2.6. Requirements Statement I-DとPSWG憲章のIESGレビュー
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のためにどんな提案された特許変化も見直すか、または必要であるなら、代替手段を考えるでしょう。 これは、特に解決策に取り組むために新しいワーキンググループの構成を含むかもしれません。
4.2.7. Solutions Work
4.2.7. ソリューション仕事
The appropriate PSWG will start work on solutions following the normal IETF process.
正常なIETFの過程に従って、適切なPSWGは解決策で就業するでしょう。
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に紹介するかもしれません。 開発にREWGを助けるために過程による早期のステージでそのようなI-Dsを提出するかもしれません、そして、要件の議論をみなしますが、PSWGには仕事をカバーする特許項目があって、REWGいすが要件が安定していると確信するまで、解決策I-Dであると正式にどんなI-Dもみなさないでしょう。
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 MUSTがレビューと改正のための可能な解決策I-DのようなI-Dを考えるという保証を全くしません、どんな個々の服従のようにも同じ公開手順([RFC2418])を使用して。 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の利害関係者(implementersとユーザの両方)が適切な関心が解決策仕事で示されるのを保証して、タイムリーな解決策開発を前提とするためにPSWGに参加するよう強く奨励されます。 どんなSDOのものとしても、IETFの仕事は関係者によって追い立てられます。 IETFはIETF解決策仕事SHOULDが仕事への適切な産業関心を確実にするよう要求する疎生群落とあらゆるSDOであるかIETF MAYは仕事のサポートを中止します。 中止された仕事の適切なコミュニケーションは要求の創始者に作られるでしょう(創始者が届くなら)。
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の中の通常のワーキンググループレビュー、コンセンサス、および最後の呼び出しを必要としています。
Andersson & Farrel Best Current Practice [Page 15] RFC 4929 MPLS and GMPLS Change Process June 2007
アンデションとファレル最も良い現在の習慣[15ページ]RFC4929MPLSとGMPLSは過程2007年6月に変化します。
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 SHOULDは、1つが存在しているなら正式な連絡の過程を使用することで進歩を定期的に伝えます。 このコミュニケーションSHOULDはまた、レビュー入力を要求するのに使用されて、コメントします。解決策I-Dの開発に関して。 ソリューションI-D MUST、ワーキンググループの間の組織が最後に最終審査のために要件に対して呼ぶ由来とコミュニケートしてください。 解決策I-Dが完全であるときに(通常、最後の呼び出しRFC Editorの待ち行列に入るときワーキンググループを完成するときの)、PSWG MUSTは完成した解決策について由来している組織に知らせます。
5. Rejecting the Requirements Statements I-D
5. 要件声明I-Dを拒絶します。
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]の過程に従わなければなりません。 拒絶の可能な理由はこのセクションで説明されます。
5.1. Reasons for Rejection
5.1. 拒絶の理由
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.
IETFは完全な開示で要件声明I-Dを拒絶できるだけです。 拒絶の可能な理由とここで説明される次の可能なステップ。
- 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 MUST NOTは解決策に取り組むのからの要件声明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
- どんなプロトコル拡大も変化も必要ではありません。 要件の評価における何らかの段階では、既存のプロトコルの適切な使用でそれらにすべて会うことができるのは明確になるかもしれません。 コネ
Andersson & Farrel Best Current Practice [Page 16] RFC 4929 MPLS and GMPLS Change Process June 2007
アンデションとファレル最も良い現在の習慣[16ページ]RFC4929MPLSとGMPLSは過程2007年6月に変化します。
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 MUSTは条件を満たすのに正確にどう既存のプロトコルを使用できるかがわかるApplicability Statementインターネット草稿かProfilesインターネット草稿の生産でプロトコルがどう条件を満たすのに使用できて、要件声明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の中の不十分なサポート。 IETF、およびREWGメーリングリストにおける要件声明I-Dの創始者のサポートにもかかわらず、範囲の中に要件声明I-Dの中で説明された仕事がありますが、REWGのいすは、要件声明I-Dを完成して、PSWGで解決策仕事を開始するために不十分なサポートがREWGにあると決心していました。 この場合、IETF MUST NOTは解決策に取り組むのからの要件声明I-Dの作者を制限します。 そして、IETFレビュー結果までレビューと可能な公表のためにInformationalかExperimental RFCとして解決策(そして/または、要求されたIANA codepoints)SHALLをIETF(G)のMPLS PSWGに寄贈して、IETF SHALL NOTはcodepointsのためにIANAにアプリケーションを妨げます。 IANA codepoint課題が必要であるなら、関連RFCsのそれらの課題に処方されたIANA Requirementsを満たさなければなりません。 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 MAYのいすは、仕事の不十分なサポートがあると決心して、要件声明I-Dを拒絶するかもしれません。 この場合、IETF MUST NOTは、仕事がいかなる他の組織でも行われる許可を与えて、どんな変化や拡大の公表も(G)MPLSプロトコルに是認してはいけなくて、あらゆるcodepointsを割り当てるよう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
- 要件を満たすと、技術は破られるでしょう。 要件が妥当ですが、拡大か(G)MPLSプロトコルへの変化で(G)MPLS技術を破るような方法で(G)MPLS構造に違反しないでそれらを満たすのが可能でないという査定をするのは可能です。 この場合、ある他の技術が要件を満たすのに使用されるという推薦状をするでしょう。 (G)MPLS技術の保全の保護のさらなる議論に関してセクション7を見てください。 この場合、IETF MUST NOTは仕事がいかなる他のも行われる許可を与えます。
Andersson & Farrel Best Current Practice [Page 17] RFC 4929 MPLS and GMPLS Change Process June 2007
アンデションとファレル最も良い現在の習慣[17ページ]RFC4929MPLSとGMPLSは過程2007年6月に変化します。
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プロトコルに是認してはいけなくて、あらゆるcodepointsを割り当てるようIANAに命令してはいけません。
5.2. Actions Required When Rejecting Requirements Statement I-Ds
5.2. 要件声明I-Dsを拒絶するとき、動作が必要です。
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 MUSTは要件声明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にもたらすなら(セクション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.
- IETFメールでI-Dについて生産されて、議論したという要件声明が記載するなら、応答をメール応答として作られていて、メールリストにコピーしなければなりません。
- 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人以上のAreaディレクター、1脚以上のワーキンググループいす、または指定された専門家であるかもしれません[RFC2434]。 連絡関係の使用の場合では、IETFの連絡のマネージャはこのドキュメントの手順、および特に拒絶手順が従われているのを確実にすることへの責任を持っています。
5.3. Appeals
5.3. 上告
[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が出来事で上告されるかもしれないという要件声明の拒絶
Andersson & Farrel Best Current Practice [Page 18] RFC 4929 MPLS and GMPLS Change Process June 2007
アンデションとファレル最も良い現在の習慣[18ページ]RFC4929MPLSとGMPLSは過程2007年6月に変化します。
it is disputed and cannot be reversed by direct discussion between the parties. The conflict resolution and appeal mechanism is documented in [RFC2026].
それについて議論して、パーティーの間のダイレクト議論で逆にすることができません。 紛争解決と上告メカニズムは[RFC2026]に記録されます。
6. Abandonment of the Solutions I-D
6. ソリューションI-Dの放棄
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 MUSTに責任があるAreaディレクター。相談されます。 創始者、要件声明I-D MUSTでは、仕事がどう要件を導入したかの(セクション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プロトコルへの拡大と変化の状態はそれがどう過程が始めた前であったかに戻ります。 要件のどんな新しい調査も過程の先端で始まらなければなりません。
6.1. Appeals
6.1. 上告
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]に記録されます。
7. (G)MPLS Integrity and Ownership
7. (G)MPLS保全と所有権
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プロトコルの建築保全を保護するREQUIREDであり、特定のケースに一般的使用を持っていない特徴で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
(G)MPLSプロトコルへの追加か変化の建築含意は存在とプロトコルの将来のバージョンがある相互運用性を考えなければなりません。 規則とリスクが全体でプロトコルに影響を与えていて、重なっているか、ポイント解決に対処している、または一般的でない特徴を加えるという効果ははるかに制御しにくいです。 したがって、操作上的、そして、技術的な危険を最小にします。
Andersson & Farrel Best Current Practice [Page 19] RFC 4929 MPLS and GMPLS Change Process June 2007
アンデションとファレル最も良い現在の習慣[19ページ]RFC4929MPLSとGMPLSは過程2007年6月に変化します。
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技術、IETFはSHALLを処理します。拡大に関するあらゆる要求には、(G) MPLSプロトコルに続かれてください。 (G) MPLSプロトコルに関して、(G)MPLS PSWGは(G)MPLSプロトコルの貸し切りの「所有者」です、ワーキンググループが存在する限り。 すべての変化か拡大、(G) MPLS MUSTに、最初に、(G)MPLS PSWGによって見直されてください。
8. Security Considerations
8. セキュリティ問題
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 SHOULD条例が要件声明I-Dの源と仕事の知覚された関連性によるのを検出するのにIESGによって使用されるかもしれません。 例えば、IESGは外部の組織の経営で問題に取り組むかもしれません。
9. Acknowledgements
9. 承認
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の様々なメンバーとのレビューフィードバックと議論は本書では説明された過程を洗練する際に役立っています。 Study Group15のQuestion14のメンバーと、そして、Study Group15の管理を特にありがとうございます。 重要な議論がITU-Tの以下の関係者と共に行われました: 余市マエダ、グレッグ・ジョーンズ、スティーブン・トローブリッジ、マルコム・ベッツ、カム・ラム、ジョージNewsome、イブ・バルマー、リンドン・オング、スティーブン・シュー、ジョナサン・サドラー、およびベン・マックはためらいます。
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.
さらなるレビューコメントをブライアンCarpenter、スチュワートブライアント、サム・ハートマン、マークTownsley、およびデーヴ・ウォードをありがとうございます。 GenArtのためのスペンサー・ダウキンズへの感謝は論評します。
Andersson & Farrel Best Current Practice [Page 20] RFC 4929 MPLS and GMPLS Change Process June 2007
アンデションとファレル最も良い現在の習慣[20ページ]RFC4929MPLSとGMPLSは過程2007年6月に変化します。
10. IANA Considerations
10. IANA問題
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 codepoint登録と定義された配分方針を固く守って、本書では説明された手順によると、仕事が行われたところ以外に、IETFがそれらの登録からcodepointsの配分を是認しないと仮定します。
11. References
11. 参照
11.1. Normative References
11.1. 引用規格
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996.
[RFC2026] ブラドナー、S.、「改正3インチ、BCP9、RFC2026、1996年インターネット標準化過程--10月。」
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC2418] Bradner, S., "IETF Working Group Guidelines and
Procedures", BCP 25, RFC 2418, September 1998.
[RFC2418] ブラドナーと、S.と、「IETFワーキンググループガイドラインと手順」、BCP25、RFC2418、9月1998日
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[RFC2434]Narten、T.とH.Alvestrand、「RFCsにIANA問題部に書くためのガイドライン」BCP26、RFC2434(1998年10月)。
[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.、エドインターネット・アーキテクチャ委員会、「IABはIETF連絡関係の管理のために処理します」、BCP102、RFC4052、2005年4月。
[RFC4053] Trowbridge, S., Bradner, S., and F. Baker, "Procedures for
Handling Liaison Statements to and from the IETF", BCP
103, RFC 4053, April 2005.
[RFC4053] トローブリッジ、S.、ブラドナー、S.、およびF.ベイカー、「IETFとIETFからの取り扱い連絡声明のための手順」、BCP103、RFC4053(2005年4月)。
[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、「プロトコル拡大と変化のための手順」BCP125、RFC4775(2006年12月)。 2006.
11.2. Informative References
11.2. 有益な参照
[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.ブラドナー、「インターネット・エンジニアリング・タスク・フォースと国際電気通信連合--、テレコミュニケーション標準化セクター共同ガイドライン、」、RFC3356(2002年8月)
Andersson & Farrel Best Current Practice [Page 21] RFC 4929 MPLS and GMPLS Change Process June 2007
アンデションとファレル最も良い現在の習慣[21ページ]RFC4929MPLSとGMPLSは過程2007年6月に変化します。
Authors' Addresses
作者のアドレス
George Swallow Cisco Systems EMail: swallow@cisco.com
ジョージツバメシスコシステムズメール: swallow@cisco.com
Deborah Brungard AT&T EMail: dbrungard@att.com
デボラBrungard AT&T EMail: dbrungard@att.com
Bill Fenner AT&T EMail: fenner@research.att.com
ビルフェナーAT&T EMail: fenner@research.att.com
Ross Callon Juniper Networks EMail: rcallon@juniper.net
ロスCallon杜松ネットワークはメールされます: rcallon@juniper.net
Kireeti Kompella Juniper Networks EMail: Kireeti@juniper.net
Kireeti Kompella杜松ネットワークはメールされます: Kireeti@juniper.net
Alex Zinin Alcatel EMail: zinin@psg.com
アレックスジニンアルカテルEMail: zinin@psg.com
Scott Bradner Harvard University EMail: sob@harvard.edu
スコットブラドナーハーバード大学EMail: sob@harvard.edu
Editors' Addresses
エディタのアドレス
Loa Andersson Acreo AB EMail: loa@pi.se
LoaアンデションAcreo ABはメールします: loa@pi.se
Adrian Farrel Old Dog Consulting EMail: adrian@olddog.co.uk
エードリアンのファレルの古い犬のコンサルティングメール: adrian@olddog.co.uk
Andersson & Farrel Best Current Practice [Page 22] RFC 4929 MPLS and GMPLS Change Process June 2007
アンデションとファレル最も良い現在の習慣[22ページ]RFC4929MPLSとGMPLSは過程2007年6月に変化します。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Andersson & Farrel Best Current Practice [Page 23]
アンデションとファレルBest現在の習慣[23ページ]
一覧
スポンサーリンク
