Internet Engineering Task Force (IETF) A. Farrel
Request for Comments: 6123 Old Dog Consulting
Category: Historic February 2011
ISSN: 2070-1721
Internet Engineering Task Force (IETF) A. Farrel
Request for Comments: 6123 Old Dog Consulting
Category: Historic February 2011
ISSN: 2070-1721
Inclusion of Manageability Sections in Path Computation Element (PCE) Working Group Drafts
在路径计算元素（PCE）工作组草稿中包含可管理性部分
Abstract
摘要
It has often been the case that manageability considerations have been retrofitted to protocols after they have been specified, standardized, implemented, or deployed. This is sub-optimal. Similarly, new protocols or protocol extensions are frequently designed without due consideration of manageability requirements.
在协议被指定、标准化、实现或部署之后，可管理性考虑因素常常被改进为协议。这是次优的。类似地，新协议或协议扩展经常在设计时没有适当考虑可管理性需求。
The Operations Area has developed "Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions" (RFC 5706), and those guidelines have been adopted by the Path Computation Element (PCE) Working Group.
运营部门制定了“考虑新协议和协议扩展的运营和管理指南”（RFC 5706），这些指南已被路径计算元素（PCE）工作组采用。
Previously, the PCE Working Group used the recommendations contained in this document to guide authors of Internet-Drafts on the contents of "Manageability Considerations" sections in their work. This document is retained for historic reference.
此前，PCE工作组使用本文件中包含的建议，指导互联网草案作者在其工作中“可管理性考虑”部分的内容。本文件保留供历史参考。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for the historical record.
本文件不是互联网标准跟踪规范；它是为了历史记录而出版的。
This document defines a Historic Document for the Internet community. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文档定义了互联网社区的历史文档。本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6123.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6123.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
This document is produced for historic reference.
本文件仅供历史参考。
When new protocols or protocol extensions are developed, it is often the case that not enough consideration is given to the manageability of the protocols or to the way in which they will be operated in the network. The result is that manageability considerations are only understood once the protocols have been implemented and sometimes not until after they have been deployed.
当开发新的协议或协议扩展时，通常没有充分考虑协议的可管理性或协议在网络中的操作方式。结果是，只有在实现了协议之后，才理解可管理性考虑因素，有时直到部署协议之后才理解。
The resultant attempts to retrofit manageability mechanisms are not always easy or architecturally pleasant. Furthermore, it is possible that certain protocol designs make manageability particularly hard to achieve.
因此，改进可管理性机制的尝试并不总是容易的，也不总是架构上令人愉快的。此外，某些协议设计可能使可管理性特别难以实现。
Recognizing that manageability is fundamental to the utility and success of protocols designed within the IETF, and that simply defining a MIB module does not necessarily provide adequate manageability, this document was developed to define recommendations for the inclusion of Manageability Considerations sections in all Internet-Drafts produced within the PCE Working Group. It was the intention that meeting these recommendations would ensure that proper consideration was given to the support of manageability at all stages of the protocol development process from Requirements and Architecture through Specification and Applicability.
认识到可管理性是IETF内设计的协议的实用性和成功的基础，简单定义MIB模块并不一定能提供足够的可管理性，本文件旨在定义在PCE工作组内编制的所有互联网草案中纳入可管理性考虑部分的建议。其目的是，满足这些建议将确保在协议开发过程的各个阶段（从需求和体系结构到规范和适用性）适当考虑对可管理性的支持。
It is clear that the presence of such a section in an Internet-Draft does not guarantee that the protocol will be well-designed or manageable. However, the inclusion of this section will ensure that the authors have the opportunity to consider the issues, and, by reading the material in this document, they will gain some guidance.
很明显，互联网草案中存在这样一个章节并不保证协议设计良好或易于管理。然而，这一部分的纳入将确保作者有机会考虑这些问题，并且通过阅读本文件中的材料，他们将得到一些指导。
This document was developed within the PCE Working Group and was used to help guide the authors and editors within the working group to produce Manageability Considerations sections in the Internet-Drafts and RFCs produced by the working group.
本文件由PCE工作组编制，用于帮助指导工作组内的作者和编辑在工作组编制的互联网草稿和RFC中编制可管理性注意事项部分。
[RFC5706] presents general guidance from the IETF's Operations Area for considering Operations and Management of new protocols and protocol extensions. It has been adopted by the PCE Working Group to provide guidance to editors and authors within the working group, so this document is no longer required. However, the working group considers that it will be useful to archive this document as Historic for future reference.
[RFC5706]提供了IETF操作领域的一般指南，用于考虑新协议和协议扩展的操作和管理。PCE工作组已通过该文件，为工作组内的编辑和作者提供指导，因此不再需要该文件。然而，工作组认为，将本文件作为历史性文件存档以备将来参考是有益的。
This document is not a protocol specification. 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 [RFC2119] in order that the contents of a Manageability Considerations section can be clearly understood.
本文件不是协议规范。本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中的描述进行解释，以便清楚理解可管理性考虑部分的内容。
In this context, "manageability" is used to refer to the interactions between a network operator (a human or an application) and the network components (hosts, routers, switches, applications, and protocols) performed to ensure the correct operation of the network.
在此上下文中，“可管理性”用于指网络运营商（人员或应用程序）与网络组件（主机、路由器、交换机、应用程序和协议）之间的交互，以确保网络的正确运行。
Manageability issues are often referred to under the collective acronym, FCAPS [X.700], which stands for the following:
可管理性问题通常在集体首字母缩写词FCAPS[X.700]下提及，代表以下内容：
- Fault management - Configuration - Accounting - Performance - Security
- 故障管理-配置-记帐-性能-安全
Conventionally, Security is already covered an Internet-Draft in its own Security Considerations section, and this document does not in any way diminish the need for that section. Indeed, as pointed out in Section 6, a full consideration of other aspects of manageability may increase the text that should be supplied in the Security Considerations section.
按照惯例，安全性已经包含在其自身的安全考虑部分的互联网草案中，并且本文件不会以任何方式减少对该部分的需要。事实上，正如第6节所指出的，充分考虑可管理性的其他方面可能会增加安全考虑部分中应提供的文本。
The author of a Manageability Considerations section should certainly consider all aspects of FCAPS. The author should reflect on how the manageability of a new protocol impacts the manageability and operation of the entire network. Specific optional subsections (see
可管理性考虑部分的作者当然应该考虑FCAPS的所有方面。作者应该思考新协议的可管理性如何影响整个网络的可管理性和操作。特定可选小节（参见
Section 2.3) should be added as necessary to describe features of FCAPS that are pertinent but are not covered by the recommended subsections. More discussion of what manageability is and what may be included in a Manageability Considerations section can be found in [RFC5706].
应根据需要添加第2.3）节，以描述相关但未包含在推荐小节中的FCAP特征。关于什么是可管理性以及可管理性注意事项部分可能包含的内容的更多讨论，请参见[RFC5706]。
As part of documenting the manageability considerations for a new protocol or for protocol extensions, authors should consider that one of the objectives of specifying protocols within the IETF is to ensure interoperability of implementations. This interoperability extends to the manageability function so that it is an ideal that there should be implementation independence between management applications and managed entities. This may be promoted by the use of standardized management protocols and by the specification of standard information models.
作为记录新协议或可扩展协议的可管理性考虑的一部分，作者应考虑在IETF内指定协议的目标之一是确保实现的互操作性。这种互操作性扩展到可管理性功能，因此理想情况是管理应用程序和被管理实体之间应该实现独立性。这可以通过标准化管理协议的使用和标准信息模型的规范来促进。
Note that, in some contexts, reference is made to the term "management plane". This is used to describe the exchange of management messages through management protocols (often transported by IP and by IP transport protocols) between management applications and the managed entities such as network nodes. The management plane may use distinct addressing schemes, virtual links or tunnels, or a physically separate management control network. The management plane should be seen as separate from, but possibly overlapping with, the control plane, in which signaling and routing messages are exchanged, and the forwarding plane (sometimes called the data plane or user plane), in which user traffic is transported.
注意，在某些情况下，提及术语“管理平面”。这用于描述管理应用程序和被管理实体（如网络节点）之间通过管理协议（通常通过IP和IP传输协议传输）交换管理消息。管理平面可以使用不同的寻址方案、虚拟链路或隧道，或者物理上独立的管理控制网络。管理平面应被视为独立于控制平面（在其中交换信令和路由消息）和转发平面（有时称为数据平面或用户平面）（在其中传输用户业务）但可能重叠。
Note that examples of the sections described here can be found in the documents listed in Appendix A.
请注意，附录A中列出的文件中可以找到此处所述章节的示例。
In the event that there are no manageability requirements for an Internet-Draft, the draft SHOULD still contain a Manageability Considerations section. The presence of this section indicates to the reader that due consideration has been given to manageability and that there are no (or no new) requirements.
如果互联网草案没有可管理性要求，草案仍应包含可管理性注意事项部分。本节的出现向读者表明，适当考虑了可管理性，并且没有（或没有新的）要求。
In this case, the section SHOULD contain a simple statement such as "There are no new manageability requirements introduced by this document" and SHOULD briefly explain why that is the case with a summary of manageability mechanisms that already exist.
在这种情况下，本节应包含一个简单的陈述，如“本文件没有引入新的可管理性要求”，并应简要解释为什么会出现这种情况，并总结现有的可管理性机制。
Note that a null Manageability Considerations section may take some effort to compose. It is important to demonstrate to the reader that no additional manageability mechanisms are required, and it is often hard to prove that something is not needed. A null Manageability Considerations section SHOULD NOT consist only of the simple statement that there are no new manageability requirements.
请注意，空可管理性注意事项部分可能需要一些努力来编写。向读者证明不需要额外的可管理性机制是很重要的，而且通常很难证明不需要什么。空的可管理性注意事项部分不应该只包含没有新的可管理性要求的简单语句。
If an Internet-Draft genuinely has no manageability impact, it should be possible to construct a simple null Manageability Considerations section that explains why this is the case.
如果互联网草案确实没有可管理性影响，那么应该可以构建一个简单的空可管理性注意事项部分来解释为什么会出现这种情况。
If the Manageability Considerations section is not null, it SHOULD contain at least the following subsections. Guidance on the content of these subsections can be found in Section 3 of this document.
如果“可管理性注意事项”部分不为空，则至少应包含以下子部分。本文件第3节提供了关于这些小节内容的指导。
- Control of Function through Configuration and Policy - Information and Data Models, e.g., MIB modules - Liveness Detection and Monitoring - Verifying Correct Operation - Requirements on Other Protocols and Functional Components - Impact on Network Operation
- 通过配置和策略控制功能-信息和数据模型，例如MIB模块-活跃度检测和监控-验证正确操作-对其他协议和功能组件的要求-对网络操作的影响
In the event that one or more of these subsections is not relevant, it SHOULD still be present and SHOULD contain a simple statement explaining why the subsection is not relevant. That is, null subsections are allowed, and each should be formed following the advice in Section 2.1.
如果其中一个或多个小节不相关，则该小节仍应存在，并应包含解释该小节不相关原因的简单陈述。也就是说，允许空白子节，每个子节应按照第2.1节中的建议形成。
The list of subsections above is not intended to be prescriptively limiting. Other subsections can and SHOULD be added according to the requirements of each individual Internet-Draft. If a topic does not fit comfortably into any of the subsections listed, the authors should be relaxed about adding new subsections as necessary.
上述各小节的列表并非旨在规定性限制。根据每个互联网草案的要求，可以也应该添加其他小节。如果某个主题不适合列出的任何小节，那么作者应该放松，在必要时添加新的小节。
The Manageability Considerations section SHOULD be placed immediately before the Security Considerations section in any Internet-Draft.
在任何Internet草稿中，可管理性注意事项部分应放在安全注意事项部分之前。
This section gives guidance on the information to be included in each of the recommended subsections listed above. Note that, just as other subsections may be included, so additional information MAY also be included in these subsections.
本节给出了上述各推荐小节中应包含的信息指南。注意，正如可能包括其他小节一样，这些小节也可能包括其他信息。
This subsection describes the functional elements that may be controlled through configuration and/or policy.
本小节描述了可通过配置和/或策略控制的功能元素。
For example, many protocol specifications include timers that are used as part of the operation of the protocol. These timers often have default values suggested in the protocol specification and do not need to be configurable. However, it is often the case that the protocol requires that the timers can be configured by the operator to ensure specific behavior by the implementation.
例如，许多协议规范包括作为协议操作一部分使用的计时器。这些定时器通常具有协议规范中建议的默认值，不需要配置。然而，协议通常要求操作员配置计时器，以确保实现的特定行为。
Even if all configurable items have been described within the body of the document, they SHOULD be identified in this subsection, but a reference to another section of the document is sufficient if there is a full description elsewhere.
即使文件正文中描述了所有可配置项，也应在本小节中对其进行标识，但如果其他地方有完整的描述，则参考文件的另一部分就足够了。
Other protocol elements are amenable to control through the application of local or network-wide policy. It is not the intention that this subsection should give details of policy implementation since that is covered by more general policy framework specifications such as [RFC3060] and [RFC3460]. Additionally, specific frameworks for policy as applicable within protocol or functional architectures are also normally covered in separate documents, for example, [RFC5394].
其他协议元素可以通过应用本地或网络范围的策略进行控制。本小节不打算给出政策实施的细节，因为更一般的政策框架规范（如[RFC3060]和[RFC3460]）涵盖了政策实施的细节。此外，协议或功能架构中适用的特定策略框架通常也包含在单独的文档中，例如，[RFC5394]。
However, this section SHOULD identify which protocol elements are potentially subject to policy and should give guidance on the application of policy for successful operation of the protocol. Where this material is already described within the body of the document, this subsection SHOULD still identify the issues and reference the other sections of the document.
但是，本节应确定哪些协议要素可能受政策约束，并应就协议成功运行的政策应用提供指导。如果本材料已在文件正文中描述，本小节仍应确定问题并参考文件的其他章节。
This subsection SHOULD describe the information and data models necessary for the protocol or the protocol extensions. This includes, but is not necessarily limited to, the MIB modules developed specifically for the protocol functions specified in the document.
本小节应描述协议或协议扩展所需的信息和数据模型。这包括但不一定限于专门为文件中指定的协议功能开发的MIB模块。
Where new or extended MIB modules are recommended, it is helpful if this section can give an overview of the items to be modeled by the MIB modules. This does not require an object-by-object description of all of the information that needs to be modeled, but it could explain the high-level "object groupings" (perhaps to the level of suggesting the MIB tables) and certainly should explain the major manageable entities. For example, a protocol specification might include separate roles for "sender" and "receiver" and might be broken into a "session" and individual "transactions"; if so, this section could list these functionalities as separate manageable entities.
如果建议使用新的或扩展的MIB模块，如果本节可以概述MIB模块要建模的项，则会很有帮助。这并不需要对需要建模的所有信息进行逐个对象的描述，但它可以解释高级“对象分组”（可能达到建议MIB表的级别），并且肯定应该解释主要的可管理实体。例如，协议规范可能包括“发送方”和“接收方”的单独角色，并且可能被分解为“会话”和单个“事务”；如果是这样，本节可以将这些功能列为单独的可管理实体。
[RFC3444] may be useful in determining what information to include in this section.
[RFC3444]可能有助于确定本节中包含的信息。
The description in this section can be by reference where other documents already exist.
本节中的说明可供其他文件参考。
It should be noted that the significance of MIB modules may be decreasing, but there is still a requirement to consider the managed objects necessary for successful operation of the protocol or protocol extensions. This means that due consideration should be given not only to what objects need to be managed but also to what management model should be used. There are now several options, including the MIB/SNMP (Simple Network Management Protocol) model and the Network Configuration Protocol (NETCONF) model, being developed by the NETCONF Data Modeling Language (NETMOD) Working Group [YANG].
应该注意的是，MIB模块的重要性可能会降低，但是仍然需要考虑成功地运行协议或协议扩展所必需的被管理对象。这意味着，不仅要适当考虑需要管理哪些对象，还要考虑应该使用什么管理模型。现在有几个选项，包括MIB/SNMP（简单网络管理协议）模型和网络配置协议（NETCONF）模型，由NETCONF数据建模语言（NETMOD）工作组[YANG]开发。
Liveness detection and monitoring apply both to the control plane and the data plane.
活跃度检测和监视同时应用于控制平面和数据平面。
Mechanisms for detecting faults in the control plane or for monitoring its liveness are usually built into the control plane protocols or inherited from underlying data plane or forwarding plane protocols. These mechanisms do not typically require additional management capabilities but are essential features for the protocol to be usable and manageable. Therefore, this section SHOULD highlight the mechanisms in the new protocol or protocol extensions that are required in order to ensure liveness detection and monitoring within the protocol.
用于检测控制平面中的故障或监视其活动性的机制通常内置于控制平面协议中，或从底层数据平面或转发平面协议继承。这些机制通常不需要额外的管理功能，而是协议可用和可管理的基本功能。因此，本节应强调新协议或协议扩展中所需的机制，以确保协议内的活动性检测和监视。
Further, when a control plane fault is detected, there is often a requirement to coordinate recovery action through management applications or at least to record the fact in an event log. This section SHOULD identify the management actions expected when the protocol detects a control plane fault.
此外，当检测到控制平面故障时，通常需要通过管理应用程序协调恢复操作，或者至少在事件日志中记录事实。本节应确定协议检测到控制平面故障时预期的管理措施。
Where the protocol is responsible for establishing data or user plane connectivity, liveness detection and monitoring usually need to be achieved through other mechanisms. In some cases, these mechanisms already exist within other protocols responsible for maintaining lower layer connectivity, but it will often be the case that new procedures are required so that failures in the data path can be detected and reported rapidly, allowing remedial action to be taken. This section SHOULD refer to other mechanisms that are assumed to provide monitoring of data plane liveness and SHOULD identify requirements for new mechanisms as appropriate.
当协议负责建立数据或用户平面连接时，通常需要通过其他机制实现活跃度检测和监视。在某些情况下，这些机制已经存在于负责维护较低层连接的其他协议中，但通常需要新的程序，以便能够快速检测和报告数据路径中的故障，从而采取补救措施。本节应参考其他假设用于提供数据平面活动性监控的机制，并应根据需要确定新机制的要求。
This section SHOULD describe the need for liveness and detection monitoring, SHOULD highlight existing tools, SHOULD identify requirements and specifications for new tools (as appropriate for the level of the document being written), and SHOULD describe the coordination of tools with each other, with management applications, and with the base protocol being specified.
本节应描述对活性和检测监控的需求，应突出现有工具，应确定新工具的要求和规范（根据所编写文件的级别而定），并应描述工具之间的协调，以及管理应用程序，并且指定了基本协议。
An important function that Operations and Management (OAM) can provide is a toolset for verifying the correct operation of a protocol. To some extent, this may be achieved through access to information and data models that report the status of the protocol and the state installed on network devices. However, it may also be valuable to provide techniques for testing the effect that the protocol has had on the network by sending data through the network and observing its behavior.
操作和管理（OAM）可以提供的一个重要功能是用于验证协议正确操作的工具集。在某种程度上，这可以通过访问报告协议状态和网络设备上安装的状态的信息和数据模型来实现。然而，通过网络发送数据并观察其行为，为测试协议对网络的影响提供技术也是有价值的。
Thus, this section SHOULD include details of how the correct operation of the protocols described by the Internet-Draft can be tested, and, in as far as the Internet-Draft impacts on the operation of the network, this section SHOULD include a discussion about how the correct end-to-end operation of the network can be tested and how the correct data or forwarding plane function of each network element can be verified.
因此，本节应包括如何测试互联网草案所述协议的正确运行的细节，以及互联网草案对网络运行的影响，本节应讨论如何测试网络的正确端到端操作，以及如何验证每个网元的正确数据或转发平面功能。
There may be some overlap between this section and that describing liveness detection and monitoring since the same tools may be used in some cases.
由于在某些情况下可能会使用相同的工具，因此本节与描述活性检测和监控的部分之间可能存在一些重叠。
The text in this section SHOULD describe the requirements that the new protocol puts on other protocols and functional components as well as requirements from other protocols that have been considered
本节中的文本应描述新协议对其他协议和功能组件的要求，以及已考虑的其他协议的要求
in designing the new protocol. This is pertinent to manageability because those other protocols may already be deployed and operational and because those other protocols also need to be managed.
在设计新协议时。这与可管理性相关，因为这些其他协议可能已经部署并可操作，而且这些其他协议也需要管理。
It is not appropriate to consider the interaction between the new protocol and all other protocols in this section, but it is important to identify the specific interactions that are assumed for the correct functioning of the new protocol or protocol extensions.
在本节中考虑新协议与所有其他协议之间的交互是不合适的，但重要的是识别为新协议或协议扩展正确运行所假定的特定交互。
The introduction of a new protocol or extensions to an existing protocol may have an impact on the operation of existing networks. This section SHOULD outline such impacts (which may be positive), including scaling concerns and interactions with other protocols.
引入新协议或对现有协议的扩展可能会对现有网络的运行产生影响。本节应概述此类影响（可能是积极的），包括扩展关注点和与其他协议的交互。
For example, a new protocol that doubles the number of active, reachable addresses in use within a network might need to be considered in the light of the impact on the scalability of the IGPs operating within the network.
例如，考虑到对网络内运行的IGP的可伸缩性的影响，可能需要考虑将网络内使用的活动、可到达地址的数量增加一倍的新协议。
A very important feature that SHOULD be addressed in this section is backward compatibility. If protocol extensions are being introduced, what impact will this have on a network that has an earlier version of the protocol deployed? Will it be necessary to upgrade all nodes in the network? Can the protocol versions operate side by side? Can the new version of the protocol be tunneled through the old version? Can existing services be migrated without causing a traffic hit or is a "maintenance period" required to perform the upgrade? What are the configuration implications for the new and old protocol variants?
本节中应该讨论的一个非常重要的特性是向后兼容性。如果引入协议扩展，这将对部署了早期版本协议的网络产生什么影响？是否需要升级网络中的所有节点？协议版本能否同时运行？新版本的协议可以通过旧版本进行隧道传输吗？是否可以迁移现有服务而不造成流量损失，或者执行升级是否需要“维护期”？新旧协议变体的配置含义是什么？
Where a new protocol is introduced, issues similar to backward compatibility may exist and SHOULD be described. How is migration from an old protocol to the new protocol achieved? Do existing protocols need to be interfaced to the new protocol?
在引入新协议的情况下，可能存在类似于向后兼容性的问题，应予以说明。如何实现从旧协议到新协议的迁移？现有协议是否需要与新协议连接？
Anything that is not covered in one of the recommended subsections described above but is needed to understand the manageability situation SHOULD be covered in an additional section. This may be a catch-all section named "Other Considerations" or may be one or more additional optional sections as described in Section 2.3.
任何未在上述推荐小节中介绍但需要了解可管理性情况的内容都应在附加章节中介绍。这可能是一个名为“其他注意事项”的全面章节，也可能是第2.3节所述的一个或多个附加可选章节。
This document does not introduce any new codepoints or name spaces for registration with IANA. It makes no request to IANA for action.
本文件不引入任何新的代码点或名称空间，以便在IANA注册。它没有要求IANA采取行动。
Internet-Drafts SHOULD NOT introduce new codepoints, name spaces, or requests for IANA action within the Manageability Considerations section.
Internet草案不应在“可管理性注意事项”部分中引入新的代码点、名称空间或IANA操作请求。
This document defines Manageability Considerations sections recommended for inclusion in all PCE Working Group Internet-Drafts. As such, the whole document is relevant to manageability.
本文件定义了建议纳入所有PCE工作组互联网草案的可管理性注意事项部分。因此，整个文档与可管理性相关。
Note that the impact of the application of this document to Internet-Drafts produced within the PCE Working Group should be that PCE protocols and associated protocols are designed and extended with manageability in mind. This should result in more robust and more easily deployed protocols.
请注意，将本文件应用于PCE工作组内编制的互联网草案的影响应该是，PCE协议和相关协议的设计和扩展应考虑可管理性。这将产生更健壮、更易于部署的协议。
However, since this document does not describe any specific protocol, protocol extensions, or protocol usage, no manageability considerations need to be discussed here.
但是，由于本文档未描述任何特定的协议、协议扩展或协议使用，因此无需在此讨论可管理性考虑事项。
(This is an example of a null Manageability Considerations section).
（这是空可管理性注意事项部分的一个示例）。
This document is Historic and describes the format and content of Internet-Drafts. As such, it introduces no new security concerns.
本文件具有历史意义，描述了互联网草稿的格式和内容。因此，它不会带来新的安全问题。
However, there is a clear overlap between security, operations, and management. The manageability aspects of security SHOULD be covered within the mandatory Security Considerations of each Internet-Draft. New security considerations introduced by the Manageability Considerations section MUST be covered in the Security Considerations section.
然而，安全、运营和管理之间存在明显的重叠。安全性的可管理性方面应包含在每个互联网草案的强制性安全注意事项中。“可管理性注意事项”部分引入的新安全注意事项必须包含在“安全注意事项”部分中。
Note that fully designing a protocol before it is implemented (including designing the manageability aspects) is likely to result in a more robust protocol. That is a benefit to network security. Retrofitting manageability to a protocol can make the protocol more vulnerable to security attacks, including attacks through the new manageability facilities. Therefore, the use of this document is RECOMMENDED in order to help ensure the security of all protocols to which it is applied.
请注意，在实现协议之前完全设计协议（包括设计可管理性方面）可能会产生更健壮的协议。这对网络安全有好处。改进协议的可管理性可以使协议更容易受到安全攻击，包括通过新的可管理性设施进行的攻击。因此，建议使用本文档，以帮助确保应用本文档的所有协议的安全性。
This document is based on earlier work exploring the need for Manageability Considerations sections in all Internet-Drafts produced within the Routing Area of the IETF. That document was produced by Avri Doria and Loa Andersson working with the current author. Their input was both sensible and constructive.
本文件基于先前的工作，探索IETF路由区域内产生的所有互联网草案中对可管理性考虑部分的需求。该文件由Avri Doria和Loa Andersson与现任作者合作制作。他们的意见既明智又有建设性。
Peka Savola provided valuable feedback on an early versions of the original document. Thanks to Bert Wijnen, Dan Romascanu, David Harrington, Lou Berger, Spender Dawkins, Tom Petch, Matthew Meyer, Dimitri Papdimitriou, Stewart Bryant, and Jamal Hadi Salim for their comments.
佩卡·萨沃拉就原始文件的早期版本提供了宝贵的反馈。感谢伯特·维恩、丹·罗马斯坎努、大卫·哈林顿、卢·伯杰、斯潘德·道金斯、汤姆·佩奇、马修·迈耶、迪米特里·帕迪米特里欧、斯图尔特·布莱恩特和贾马尔·哈迪·萨利姆的评论。
Thanks to the PCE Working Group for adopting the ideas contained in this document and for including Manageability Considerations sections in their Internet-Drafts and RFCs.
感谢PCE工作组采纳了本文件中包含的理念，并在其互联网草案和RFC中纳入了可管理性考虑部分。
[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月。
[RFC3060] Moore, B., Ellesson, E., Strassner, J., and A. Westerinen, "Policy Core Information Model -- Version 1 Specification", RFC 3060, February 2001.
[RFC3060]Moore，B.，Ellesson，E.，Strassner，J.，和A.Westerinen，“政策核心信息模型——版本1规范”，RFC 3060，2001年2月。
[RFC3460] Moore, B., Ed., "Policy Core Information Model (PCIM) Extensions", RFC 3460, January 2003.
[RFC3460]Moore，B.，Ed.，“政策核心信息模型（PCIM）扩展”，RFC 3460，2003年1月。
[RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between Information Models and Data Models", RFC 3444, January 2003.
[RFC3444]Pras，A.和J.Schoenwaeld，“关于信息模型和数据模型之间的差异”，RFC 3444，2003年1月。
[RFC5394] Bryskin, I., Papadimitriou, D., Berger, L., and J. Ash, "Policy-Enabled Path Computation Framework", RFC 5394, December 2008.
[RFC5394]Bryskin，I.，Papadimitriou，D.，Berger，L.，和J.Ash，“策略启用路径计算框架”，RFC 53942008年12月。
[RFC5706] Harrington, D., "Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions", RFC 5706, November 2009.
[RFC5706]Harrington，D.，“考虑新协议和协议扩展的操作和管理指南”，RFC 5706，2009年11月。
[X.700] CCITT Recommendation X.700 (1992), Management framework for Open Systems Interconnection (OSI) for CCITT applications.
[X.700]CCITT建议X.700（1992），CCITT应用的开放系统互连（OSI）管理框架。
[YANG] Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, October 2010.
[YANG]Bjorklund，M.，Ed.“YANG-网络配置协议（NETCONF）的数据建模语言”，RFC 6020，2010年10月。
Readers are referred to the following documents for example Manageability Considerations sections that received positive comments during IESG review:
读者可参考以下文件，例如IESG审查期间收到积极评论的可管理性注意事项部分：
Farrel, A., Vasseur, J.-P., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006.
Farrel，A.，Vasseur，J.-P.，和J.Ash，“基于路径计算元素（PCE）的体系结构”，RFC 46552006年8月。
Le Roux, J., Ed., "Requirements for Path Computation Element (PCE) Discovery", RFC 4674, October 2006.
Le Roux，J.，编辑，“路径计算元素（PCE）发现的要求”，RFC 4674，2006年10月。
Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. Zhang, "OSPF Protocol Extensions for Path Computation Element (PCE) Discovery", RFC 5088, January 2008.
Le Roux，JL.，Ed.，Vasseur，JP.，Ed.，Ikejiri，Y.，和R.Zhang，“路径计算元素（PCE）发现的OSPF协议扩展”，RFC 5088，2008年1月。
Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, March 2009.
Vasseur，JP.，Ed.，和JL。Le Roux，Ed.“路径计算元素（PCE）通信协议（PCEP）”，RFC 54402009年3月。
Bradford, R., Ed., Vasseur, JP., and A. Farrel, "Preserving Topology Confidentiality in Inter-Domain Path Computation Using a Path-Key-Based Mechanism", RFC 5520, April 2009.
Bradford，R.，Ed.，Vasseur，JP.，和A.Farrel，“使用基于路径密钥的机制在域间路径计算中保持拓扑机密性”，RFC 5520，2009年4月。
Oki, E., Takeda, T., Le Roux, JL., and A. Farrel, "Framework for PCE-Based Inter-Layer MPLS and GMPLS Traffic Engineering", RFC 5623, September 2009.
Oki，E.，Takeda，T.，Le Roux，JL.，和A.Farrel，“基于PCE的层间MPLS和GMPLS流量工程框架”，RFC 56232009年9月。
Author's Address
作者地址
Adrian Farrel Old Dog Consulting EMail: adrian@olddog.co.uk
Adrian Farrel老狗咨询电子邮件：adrian@olddog.co.uk