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
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）IETF信托基金（2007年）。
Abstract
摘要
This document provides guidelines for applying or extending the MPLS or GMPLS ((G)MPLS) protocol suites and clarifies the IETF's (G)MPLS working groups' responsibility for the (G)MPLS protocols. This document is directed to multi-vendor fora and Standards Development Organizations (SDOs) to provide an understanding of (G)MPLS work in the IETF and documents the requisite use of IETF review procedures when considering (G)MPLS applications or protocol extensions in their work. This document does not modify IETF processes.
本文件提供了应用或扩展MPLS或GMPLS（（G）MPLS）协议套件的指南，并阐明了IETF（G）MPLS工作组对（G）MPLS协议的责任。本文件面向多供应商论坛和标准开发组织（SDO），以提供对IETF中（G）MPLS工作的理解，并记录在其工作中考虑（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
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的两条主要轨道上开发的。“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]讨论与其他SDO扩展或变更IETF协议相关的程序问题。当考虑到IETO使用的SDF和其他程序的要求时，SDF提供了指南。[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.
由其他论坛在未经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
本文件澄清了IETF的MPLS和公共控制和测量平面（CCAMP）工作组在（G）MPLS协议中的角色和职责，并记录了必要的使用以及如何使用
to apply, the [RFC4775] procedure of using the IETF review processes, [RFC2026] and [RFC2418], for fora wishing to apply or extend the (G)MPLS protocols. Use of the IETF review processes will ensure an open process for protocol development and ensure a non-harmful evolution for these IETF protocols, which will benefit the larger industry users' community. IETF itself cannot enforce a forum to use the (G)MPLS change procedure, though any forum not following it, when applying for IANA assignment or IETF publication, will be delayed until this procedure has been completed.
为了适用，对于希望应用或扩展（G）MPLS协议的论坛，使用IETF评审过程[RFC4775]程序[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。本文件中描述的任何程序均应以与这三个文件一致的方式实施。当其他SDO和论坛希望提出（G）MPLS变更时，必须使用它们。应在IETF内部使用这些标准，除非相关变更被负责区域主管认为无争议（例如，工作组章程涵盖），在这种情况下，正常IETF标准过程的其他方面包括必要的程序。
This document is the joint work of the IETF Routing Area Directors, the IETF MPLS and CCAMP Working Group Chairs, and the IETF's liaisons to the ITU-T. It had considerable review and comment from key members of the ITU-T who have given their time and opinions based on experience for which the authors are grateful. The IESG has also provided valuable input to arrive at the process documented here. The acknowledgements section lists those whose contributions have been particularly helpful.
本文件是IETF路由区域主任、IETF MPLS和CCAMP工作组主席以及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.
尽管本文件不是协议定义，但本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照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路由领域的两个工作组负责与（G）MPLS技术开发相关的工作：多协议标签交换（MPLS）工作组和公共控制和测量平面（CCAMP）工作组。
The following sections provide brief overviews of the chartered work of these two IETF working groups.
以下各节简要概述了这两个IETF工作组的特许工作。
The Multiprotocol Label Switching (MPLS) working group is responsible for standardizing the base technology that uses label switching, and for describing the implementation of Label Switched Paths (LSPs) over various packet and frame-based link level technologies. The working group charter includes procedures and protocols for the distribution of labels between routers, as well as encapsulations, operation and management, traffic engineering, and multicast considerations.
多协议标签交换（MPLS）工作组负责标准化使用标签交换的基本技术，并描述各种基于分组和帧的链路级技术上标签交换路径（LSP）的实现。工作组章程包括路由器之间标签分发的程序和协议，以及封装、操作和管理、流量工程和多播注意事项。
This document assumes that the MPLS working group remains the chartered authority on MPLS technologies, but notes that the IETF may appoint another working group (refer to [RFC2418]) to handle specific extensions or changes to the protocols. Further, in the event that the MPLS working group completes its work and is closed, the IETF will use the non-working group standards track document process (described in [RFC2026]) using designated experts from the community [RFC2434] for the MPLS protocols.
本文件假设MPLS工作组仍然是MPLS技术的特许机构，但注意到IETF可以指定另一个工作组（参考[RFC2418]）来处理协议的特定扩展或更改。此外，如果MPLS工作组完成其工作并关闭，IETF将使用非工作组标准跟踪文件过程（如[RFC2026]所述），使用来自社区[RFC2434]的MPLS协议指定专家。
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）工作组协调IETF内的工作，为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
CCAMP工作组关注的技术称为广义MPLS（GMPLS），表明CCAMP解决了一种广义技术，其中标签的定义方式如下：
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工作组的工作重点是广泛交换技术的通用方法，包括分组和帧技术。在这方面，GMPLS可以看作是MPLS的超集。
The procedures in this document assume that the CCAMP working group remains the authority on GMPLS technologies, but acknowledges that the IETF may appoint another working group (refer to [RFC2418]) to handle specific extensions or changes to the protocols. Further, in the event that the CCAMP working group completes its work and is closed, the IETF will use the non-working group standards track document process (described in [RFC2026]) using designated experts from the community [RFC2434] for the GMPLS protocols.
本文件中的程序假设CCAMP工作组仍然是GMPLS技术的权威，但承认IETF可以指定另一个工作组（参考[RFC2418]）来处理协议的特定扩展或更改。此外，如果CCAMP工作组完成其工作并关闭，IETF将使用非工作组标准跟踪文件过程（如[RFC2026]所述），使用来自社区[RFC2434]的GMPLS协议指定专家。
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 LSP，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）。但是，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.
除MPLS和CCAMP工作组外，多个工作组还编制了（G）MPLS技术的问题陈述和要求。IETF工作组的章程规定了具体任务的管理。他们的章程规定了他们的角色、与其他工作组的关系以及可能需要扩展（G）MPLS时应遵循的适用程序。本节概述了（G）MPLS相关组及其职责。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.
IP over Optical（IPO）工作组和Internet流量工程工作组（TEWG）是工作组的示例，这些工作组专注于（G）MPLS工作组将要考虑的（G）MPLS的问题陈述和要求。这些工作组没有具体规定任何协议。
The Bidirectional Forwarding Detection (BFD) working group, also may use the (G)MPLS protocols and mechanisms. The BFD working group is chartered for requirements evaluation and protocol specification related to BFD. If the working group needs to extend or change the (G)MPLS protocols, the procedures specified by its charter and the IETF's standard processes are applicable.
双向转发检测（BFD）工作组也可以使用（G）MPLS协议和机制。BFD工作组特许用于与BFD相关的需求评估和协议规范。如果工作组需要扩展或更改（G）MPLS协议，则其章程和IETF标准流程规定的程序适用。
The Layer 2 VPN (L2VPN) and Layer 3 VPN (L3VPN) working groups have been chartered to specify a limited number of solutions for Provider Provisioned VPNs. Both working groups are in the Internet Area. Much of the work of the L2VPN and L3VPN working groups does not include specifying new protocols or extensions to existing protocols. Where extensions are needed, the procedures as specified by their charters and the IETF's standard processes are applicable.
第2层VPN（L2VPN）和第3层VPN（L3VPN）工作组已获得特许，为提供商提供的VPN指定数量有限的解决方案。两个工作组都在互联网领域。L2VPN和L3VPN工作组的大部分工作不包括指定新协议或现有协议的扩展。如果需要扩展，其章程和IETF标准流程规定的程序适用。
The Layer 1 VPN (L1VPN) working group is chartered to specify mechanisms necessary for providing Layer 1 VPN services (establishment of layer 1 connections between CE devices) over a GMPLS-enabled transport service-provider network. Protocol extensions required for L1VPN will be done in cooperation with MPLS, CCAMP, OSPF, IS-IS, IDR, L3VPN, and other WGs where necessary. That is, the L1VPN working group will not develop GMPLS protocol extensions in isolation, but will develop requirements and propose extensions that will be reviewed and approved by the (G)MPLS working groups.
授权第1层VPN（L1VPN）工作组指定通过启用GMPLS的传输服务提供商网络提供第1层VPN服务（在CE设备之间建立第1层连接）所需的机制。L1VPN所需的协议扩展将在必要时与MPLS、CCAMP、OSPF、IS-IS、IDR、L3VPN和其他工作组合作完成。也就是说，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]程序的高级视图。第4节详细说明了这些程序在（G）MPLS中的应用。
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相关工作的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内部使用这些变更，除非相关变更被负责区域主管认为无争议（例如，工作组章程涵盖），在这种情况下，正常IETF标准流程的其他方面适用。不得通过任何其他机制更改或扩展（G）MPLS协议。IETF不得批准任何改变或扩展（G）MPLS协议的出版物（包括RFC，无论是在标准轨道上、信息性的还是实验性的），除非是通过正确执行本文件中的程序产生的出版物。IETF不得批准任何分配（G）MPLS协议代码点的IANA行动，除非由于正确执行本文件中的程序而导致的行动。
Figure 1 gives a visual overview to illustrate the roles of a (G)MPLS requirements evaluation working group (REWG) and (G)MPLS protocol solutions working group (PSWG). The figure presents two alternatives for a requestor: (1) contact the IETF early in the problem definition phase (preliminary investigation), or, (2) later, with a requirements statement. The figure is for illustration only; it does not contain all of the possible interactions and IETF procedure alternatives. The text in the subsequent sections describes the process.
图1给出了一个直观的概述，以说明（G）MPLS需求评估工作组（REWG）和（G）MPLS协议解决方案工作组（PSWG）的作用。该图为请求者提供了两种备选方案：（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
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，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
初步调查的一个可能结果是，需求和问题已被理解，但同意超出IETF的范围。或者，可以使用现有协议解决该问题。初步调查阶段的全部结果清单与第4.2.2节中描述的需求陈述评估阶段的结果清单类似，但是，如果IETF考虑开发协议解决方案，则要求更广泛的IETF社区参与开发完整的需求集的需求语句评估阶段必须形成过程的一部分。进程不能直接从
preliminary investigation phase to the development of solutions unless the working group agrees (e.g., the problem is minor).
初步调查阶段，除非工作组同意（例如，问题很小），否则应制定解决方案。
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协议的请求之前，必须按照[RFC2026]编写需求声明I-D。
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邮件列表、路由区域讨论邮件列表或外部SDO的正式联络向IETF介绍，这将导致IETF向REWG邮件列表介绍要求声明I-D。如果通过正式联络将需求声明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可能希望和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;
- 一份已完成的需求声明I-D，该声明已被工作组在REWG内协商一致接受，并已通过工作组最后一次呼叫；
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。ADs随后会将文件传递给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-D可在外部（如外部组织内）或IETF内编制，使用[RFC2418]的程序提交给IETF进行草案发布，并提交给PSWG考虑。此类I-D可在流程的早期阶段提交，以协助REWG制定和讨论需求，但在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必须考虑这样的i-D作为一个可能的解决方案i-D，并使用相同的开放程序（[RCF2418]）作为任何单个提交的审查和修订。IETF的程序基于公开和公平的参与，以及对技术替代方案的全面考虑。
Interested parties (both implementers and users) of the SDO originating the request are strongly encouraged to participate in the PSWG to ensure appropriate interest is shown in the solutions work and to provide timely solutions development. The IETF's work, as that of any SDO, is driven by its participants. The IETF is an open community and any SDO requesting IETF solutions work SHOULD ensure appropriate industry interest in the work, or the IETF MAY discontinue its support of the work. Appropriate communication of the discontinued work will be made to the originator of the request (if the originator is reachable).
强烈鼓励提出请求的SDO的相关方（实施者和用户）参与PSWG，以确保对解决方案工作表现出适当的兴趣，并及时提供解决方案开发。IETF的工作与任何SDO的工作一样，都是由其参与者推动的。IETF是一个开放的社区，任何请求IETF解决方案工作的SDO都应确保行业对该工作感兴趣，否则IETF可能会停止对该工作的支持。将向请求的发起人（如果可以联系到发起人）适当传达已中止的工作。
The final development of the solutions I-D is subject to the normal working group review, consensus, and last call within the PSWG.
解决方案I-D的最终开发取决于正常工作组的审查、协商一致意见以及PSWG内的最后呼吁。
Where the requirements originated from an external organization, the PSWG SHOULD regularly communicate its progress using a formal liaison process if one exists. This communication SHOULD also be used to request review input and comment on the development of the solutions I-D. The solutions I-D MUST be communicated to the originating organization during working group last call for final review against the requirements. When the solutions I-D is complete (normally upon completing working group last call and/or on entering the RFC Editor's queue) the PSWG MUST inform the originating organization of the completed solution.
如果要求来自外部组织，PSWG应定期通过正式联络流程（如果存在）传达其进度。该沟通还应用于请求审查输入和对解决方案I-D的开发发表意见。在工作组最后一次根据要求进行最终审查期间，必须将解决方案I-D传达给发起组织。解决方案识别完成后（通常在完成工作组最后一次呼叫和/或进入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.
只有在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不得限制需求声明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代码点）应提交给IETF的（G）MPLS PSWG审查，并可能作为信息性或实验性RFC发布，并且在IETF审查结果之前，IETF不得阻止向IANA申请代码点。如果需要IANA代码点分配，则必须满足相关RFC中为这些分配规定的IANA要求。强烈建议SDO鼓励其参与者参与IETF工作，以确保在工作中具有适当的行业代表性。
- Insufficient support for the work from the original requesters. If the authors of the requirements statement I-D do not make themselves available on the REWG mailing list for discussion of the requirements or do not contribute the completion of the requirements statement I-D, the chairs of the REWG MAY determine that there is insufficient support for the work and MAY reject the requirements statement I-D. In this case, the IETF MUST NOT grant permission for the work to be carried out in any other organization, and MUST NOT endorse the publication of any changes or extensions to the (G)MPLS protocols and MUST NOT instruct IANA to allocate any codepoints. The requirements may be reintroduced by starting the procedure again from the top.
- 原始请求者对工作的支持不足。如果需求声明I-D的作者未在REWG邮件列表上提供自己，以讨论需求，或未参与完成需求声明I-D，REWG主席可确定工作支持不足，并可拒绝需求声明I-D。在这种情况下，IETF不得批准在任何其他组织开展工作，也不得批准发布（G）的任何变更或扩展MPLS协议，不得指示IANA分配任何代码点。可通过从顶部再次启动程序重新引入要求。
- Satisfying the requirements would break the technology. It is possible that an assessment will be made that, although the requirements are reasonable, it is not possible to satisfy them through extensions or changes to the (G)MPLS protocols without violating the (G)MPLS architecture in such a way as would break the (G)MPLS technology. In this case, a recommendation will be made that some other technology be used to satisfy the requirements. See Section 7 for further discussions of the protection of the integrity of the (G)MPLS technology. In this case, the IETF MUST NOT grant permission for the work to be carried out in any other
- 满足这些要求将破坏这项技术。有可能进行评估，尽管需求是合理的，但不可能通过扩展或更改（G）MPLS协议来满足需求，而不违反（G）MPLS体系结构，从而破坏（G）MPLS技术。在这种情况下，将建议使用一些其他技术来满足要求。有关（G）MPLS技术完整性保护的进一步讨论，请参见第7节。在这种情况下，IETF不得批准在任何其他地方开展工作
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协议的任何更改或扩展，不得指示IANA分配任何代码点。
Upon rejection, the IETF MUST make a clear statement of why the requirements statement I-D has been rejected and what next step actions are acceptable (refer to Section 5.1).
拒绝后，IETF必须明确说明拒绝需求声明I-D的原因以及下一步可接受的行动（参考第5.1节）。
The communication of the rejection depends on the form of the original submission as follows.
拒绝通知取决于原始提交文件的形式，如下所示。
- If the requirements are brought to the IETF as a preliminary investigation (see Section 4.2.1) through an email exchange then the response MUST be made as an email response copied to an IETF mailing list so that it is automatically archived.
- 如果通过电子邮件交换将要求作为初步调查（见第4.2.1节）提交给IETF，则响应必须作为电子邮件响应复制到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.
- 如果通过正式联络将要求作为初步调查（见第4.2.1节）提交给IETF，则必须通过正式联络回复提交拒绝。
- 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、一名或多名区域主管、一名或多名工作组主席或指定专家[RFC2434]。在使用联络关系的情况下，IETF的联络经理有责任确保遵守本文件中的程序，尤其是拒绝程序。
[RFC2026] contains additional information related to procedure disagreements and appeals. The rejection of a requirements statement I-D as described in Sections 5.1 and 5.2 may be appealed in the event
[RFC2026]包含与程序分歧和上诉相关的附加信息。在下列情况下，可对第5.1节和第5.2节所述的要求声明I-D的拒绝提出上诉：
it is disputed and cannot be reversed by direct discussion between the parties. The conflict resolution and appeal mechanism is documented in [RFC2026].
这是有争议的，不能通过双方直接讨论予以撤销。冲突解决和上诉机制见[RFC2026]。
Once the solutions work has been started by the PSWG, it may be abandoned before completion. This can happen if the PSWG chairs determine that there is no longer working group support for doing the work. This could arise, for example, if no one (including the originators of the requirements statement I-D) is willing to contribute to the development of a solutions I-D.
一旦PSWG开始解决方案工作，可能会在完成之前放弃。如果PSWG主席确定不再有工作组支持开展工作，则可能发生这种情况。例如，如果没有人（包括需求声明I-D的发起人）愿意为解决方案I-D的开发做出贡献，则可能会出现这种情况。
In the event that the solutions work is abandoned by the PSWG, the Area Directors responsible for the PSWG MUST be consulted. The originators of the requirements statement I-D MUST be informed that the work has been abandoned using a mechanism dependent on how the requirements were introduced (as discussed in Section 5.2).
如果PSWG放弃解决方案工作，则必须咨询负责PSWG的区域主管。必须通知需求声明I-D的发起人，已使用取决于需求引入方式的机制放弃了工作（如第5.2节所述）。
If the solution is abandoned in this way, work on solutions for the requirements MUST NOT be started in another forum. The status of extensions and changes to the (G)MPLS protocols with regard to the specific requirements returns to how it was before the process started. Any new examination of the requirements MUST commence at the top of the process.
如果以这种方式放弃了解决方案，则不能在其他论坛上开始针对需求的解决方案的工作。（G）MPLS协议在特定需求方面的扩展和更改状态返回到流程开始前的状态。对要求的任何新检查必须从流程的顶部开始。
The abandonment of a solutions I-D may be appealed in the event it is disputed and cannot be reversed by direct discussion between the parties. The conflict resolution and appeal mechanism is documented in [RFC2026].
如果对解决方案I-D的放弃存在争议，可提出上诉，且不能通过双方直接讨论予以撤销。冲突解决和上诉机制见[RFC2026]。
The (G)MPLS working groups are REQUIRED to protect the architectural integrity of the (G)MPLS protocols and MUST NOT extend the GMPLS architecture with features that do not have general use beyond the specific case. They also MUST NOT modify the architecture just to make some function more efficient at the expense of simplicity or generality.
（G）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
对（G）MPLS协议的添加或更改的体系结构含义必须考虑与现有协议和未来版本的互操作性。添加重叠或涉及点解决方案且不通用的功能的效果很难用规则控制，并且会影响整个协议的风险。因此，将运营和技术风险降至最低
the (G)MPLS technology, IETF processes SHALL be followed for any requests on extensions to (G)MPLS protocols. With respect to (G)MPLS protocols, the (G)MPLS PSWG is the chartered "owner" of the (G)MPLS protocol, as long as the working group exists. All changes or extensions to (G)MPLS MUST first be reviewed by the (G)MPLS PSWG.
对于（G）MPLS协议扩展的任何请求，应遵循（G）MPLS技术、IETF流程。关于（G）MPLS协议，（G）MPLS PSWG是（G）MPLS协议的特许“所有者”，只要工作组存在。（G）MPLS的所有变更或扩展必须首先由（G）MPLS PSWG审查。
All requirements statement I-Ds MUST give full consideration to the security impact of the proposed additional features or functions. All solutions I-Ds MUST consider the impact on the security of the protocol extensions and to the pre-existing protocol.
所有需求声明I-Ds必须充分考虑提议的附加特性或功能的安全影响。所有解决方案i-DS必须考虑对协议扩展的安全性和预先存在的协议的影响。
This documents does not itself introduce any security issues for any (G)MPLS protocols.
本文档本身不会为任何（G）MPLS协议引入任何安全问题。
The IETF process is itself at risk from denial of service attacks. This document utilizes the IETF process and adds clarity to that process. It is possible, therefore, that this document might put the IETF process at risk.
IETF进程本身面临拒绝服务攻击的风险。本文件利用了IETF流程，并为该流程增加了清晰性。因此，本文件可能会使IETF过程处于危险之中。
Therefore, provided that the number of requirements statement I-Ds is not unreasonable, there will be no significant impact on the IETF process. The rate of arrival of requirements statement I-Ds MAY be used by the IESG to detect denial of service attacks, and the IESG SHOULD act on such an event depending on the source of the requirements statement I-D and the perceived relevance of the work. The IESG might, for example, discuss the issue with the management of external organizations.
因此，如果需求声明I-D的数量不是不合理的，则不会对IETF过程产生重大影响。IESG可使用需求声明I-D的到达率来检测拒绝服务攻击，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.
感谢对布莱恩·卡彭特、斯图尔特·布莱恩特、山姆·哈特曼、马克·汤斯利和戴夫·沃德的进一步评论。感谢Spencer Dawkins的GenArt评论。
This document makes no specific requests to IANA for action. The procedures described in this document assume that IANA will adhere to the allocation policies defined for the (G)MPLS codepoint registries and that the IETF will not endorse allocation of codepoints from those registries except where work has been carried out in accordance with the procedures described in this document.
本文件未向IANA提出具体行动要求。本文件中描述的程序假设IANA将遵守为（G）MPLS码点注册表定义的分配策略，并且IETF不会认可这些注册表中的码点分配，除非按照本文件中描述的程序进行了工作。
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[RFC2026]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月。2006
[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电子邮件：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
Scott Bradner哈佛大学电子邮件：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老狗咨询电子邮件：adrian@olddog.co.uk
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、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秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/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的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。