Network Working Group D. Harrington
Request for Comments: 5706 HuaweiSymantec USA
Category: Informational November 2009
Network Working Group D. Harrington
Request for Comments: 5706 HuaweiSymantec USA
Category: Informational November 2009
Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions
考虑新协议和协议扩展的操作和管理的指南
Abstract
摘要
New protocols or protocol extensions are best designed with due consideration of the functionality needed to operate and manage the protocols. Retrofitting operations and management is sub-optimal. The purpose of this document is to provide guidance to authors and reviewers of documents that define new protocols or protocol extensions regarding aspects of operations and management that should be considered.
新协议或协议扩展的设计最好充分考虑到操作和管理协议所需的功能。改造操作和管理是次优的。本文件的目的是为定义新协议或协议扩展的文件的作者和审阅者提供指南，这些协议涉及应考虑的运营和管理方面。
Status of This Memo
关于下段备忘
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2009 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 BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括《信托法律条款》第4.e节中所述的简化BSD许可文本，并且提供BSD许可中所述的代码组件时不提供任何担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，其衍生作品可能会
not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
不得在IETF标准流程之外创建，除非将其格式化以RFC形式发布，或将其翻译成英语以外的语言。
Table of Contents
目录
1. Introduction ....................................................4
1.1. Designing for Operations and Management ....................4
1.2. This Document ..............................................5
1.3. Motivation .................................................5
1.4. Background .................................................6
1.5. Available Management Technologies ..........................7
1.6. Terminology ................................................8
2. Operational Considerations - How Will the New Protocol
Fit into the Current Environment? ...............................8
2.1. Operations .................................................9
2.2. Installation and Initial Setup .............................9
2.3. Migration Path ............................................10
2.4. Requirements on Other Protocols and Functional
Components ................................................11
2.5. Impact on Network Operation ...............................11
2.6. Verifying Correct Operation ...............................12
3. Management Considerations - How Will the Protocol Be Managed? ..12
3.1. Interoperability ..........................................14
3.2. Management Information ....................................17
3.2.1. Information Model Design ...........................18
3.3. Fault Management ..........................................18
3.3.1. Liveness Detection and Monitoring ..................19
3.3.2. Fault Determination ................................19
3.3.3. Root Cause Analysis ................................20
3.3.4. Fault Isolation ....................................20
3.4. Configuration Management ..................................20
3.4.1. Verifying Correct Operation ........................22
3.5. Accounting Management .....................................22
3.6. Performance Management ....................................22
3.6.1. Monitoring the Protocol ............................23
3.6.2. Monitoring the Device ..............................24
3.6.3. Monitoring the Network .............................24
3.6.4. Monitoring the Service .............................25
3.7. Security Management .......................................25
4. Documentation Guidelines .......................................26
4.1. Recommended Discussions ...................................27
4.2. Null Manageability Considerations Sections ................27
4.3. Placement of Operations and Manageability
Considerations Sections ...................................28
5. Security Considerations ........................................28
6. Acknowledgements ...............................................28
7. Informative References .........................................29
Appendix A. Operations and Management Review Checklist ..........32
A.1. Operational Considerations ................................32
A.2. Management Considerations ................................34
A.3. Documentation .............................................35
1. Introduction ....................................................4
1.1. Designing for Operations and Management ....................4
1.2. This Document ..............................................5
1.3. Motivation .................................................5
1.4. Background .................................................6
1.5. Available Management Technologies ..........................7
1.6. Terminology ................................................8
2. Operational Considerations - How Will the New Protocol
Fit into the Current Environment? ...............................8
2.1. Operations .................................................9
2.2. Installation and Initial Setup .............................9
2.3. Migration Path ............................................10
2.4. Requirements on Other Protocols and Functional
Components ................................................11
2.5. Impact on Network Operation ...............................11
2.6. Verifying Correct Operation ...............................12
3. Management Considerations - How Will the Protocol Be Managed? ..12
3.1. Interoperability ..........................................14
3.2. Management Information ....................................17
3.2.1. Information Model Design ...........................18
3.3. Fault Management ..........................................18
3.3.1. Liveness Detection and Monitoring ..................19
3.3.2. Fault Determination ................................19
3.3.3. Root Cause Analysis ................................20
3.3.4. Fault Isolation ....................................20
3.4. Configuration Management ..................................20
3.4.1. Verifying Correct Operation ........................22
3.5. Accounting Management .....................................22
3.6. Performance Management ....................................22
3.6.1. Monitoring the Protocol ............................23
3.6.2. Monitoring the Device ..............................24
3.6.3. Monitoring the Network .............................24
3.6.4. Monitoring the Service .............................25
3.7. Security Management .......................................25
4. Documentation Guidelines .......................................26
4.1. Recommended Discussions ...................................27
4.2. Null Manageability Considerations Sections ................27
4.3. Placement of Operations and Manageability
Considerations Sections ...................................28
5. Security Considerations ........................................28
6. Acknowledgements ...............................................28
7. Informative References .........................................29
Appendix A. Operations and Management Review Checklist ..........32
A.1. Operational Considerations ................................32
A.2. Management Considerations ................................34
A.3. Documentation .............................................35
Often when new protocols or protocol extensions are developed, not enough consideration is given to how the protocol will be deployed, operated, and managed. Retrofitting operations and management mechanisms is often hard and architecturally unpleasant, and certain protocol design choices may make deployment, operations, and management particularly hard. This document provides guidelines to help protocol designers and working groups consider the operations and management functionality for their new IETF protocol or protocol extension at an earlier phase.
通常在开发新协议或协议扩展时，没有充分考虑如何部署、操作和管理协议。改进操作和管理机制通常很困难，而且在体系结构上也令人不快，某些协议设计选择可能使部署、操作和管理变得特别困难。该文档提供了帮助协议设计者和工作组在早期阶段考虑其新IETF协议或协议扩展的操作和管理功能的指导方针。
The operational environment and manageability of the protocol should be considered from the start when new protocols are designed.
在设计新协议时，应从一开始就应考虑协议的操作环境和可管理性。
Most of the existing IETF management standards are focused on using Structure of Management Information (SMI)-based data models (MIB modules) to monitor and manage networking devices. As the Internet has grown, IETF protocols have addressed a constantly growing set of needs, such as web servers, collaboration services, and applications. The number of IETF management technologies has been expanding and the IETF management strategy has been changing to address the emerging management requirements. The discussion of emerging sets of management requirements has a long history in the IETF. The set of management protocols you should use depends on what you are managing.
大多数现有的IETF管理标准侧重于使用基于管理信息结构（SMI）的数据模型（MIB模块）来监视和管理网络设备。随着互联网的发展，IETF协议满足了不断增长的需求，如web服务器、协作服务和应用程序。IETF管理技术的数量在不断扩大，IETF管理策略也在不断变化，以满足新出现的管理需求。在IETF中，对新兴管理需求集的讨论由来已久。您应该使用的管理协议集取决于您正在管理的内容。
Protocol designers should consider which operations and management needs are relevant to their protocol, document how those needs could be addressed, and suggest (preferably standard) management protocols and data models that could be used to address those needs. This is similar to a working group (WG) that considers which security threats are relevant to their protocol, documents how threats should be mitigated, and then suggests appropriate standard protocols that could mitigate the threats.
协议设计者应该考虑哪些操作和管理需求与它们的协议相关，记录这些需求是如何解决的，以及建议（最好是标准的）管理协议和数据模型，这些协议和数据模型可以用来解决这些需求。这类似于一个工作组（WG），该工作组考虑哪些安全威胁与其协议相关，记录应如何减轻威胁，然后建议可以减轻威胁的适当标准协议。
When a WG considers operation and management functionality for a protocol, the document should contain enough information for readers to understand how the protocol will be deployed and managed. The WG should expect that considerations for operations and management may need to be updated in the future, after further operational experience has been gained.
当工作组考虑协议的操作和管理功能时，文档应包含足够的信息，以便读者了解如何部署和管理协议。工作组应预计，在获得进一步的运营经验后，未来可能需要更新运营和管理方面的考虑因素。
This document makes a distinction between "Operational Considerations" and "Management Considerations", although the two are closely related. The section on manageability is focused on management technology, such as how to utilize management protocols and how to design management data models. The operational considerations apply to operating the protocol within a network, even if there were no management protocol actively being used.
本文件区分了“业务考虑”和“管理考虑”，尽管两者密切相关。关于可管理性的部分主要关注管理技术，例如如何利用管理协议以及如何设计管理数据模型。操作注意事项适用于在网络内操作协议，即使没有正在使用的管理协议。
The purpose of this document is to provide guidance about what to consider when thinking about the management and deployment of a new protocol, and to provide guidance about documenting the considerations. The following guidelines are designed to help writers provide a reasonably consistent format for such documentation. Separate manageability and operational considerations sections are desirable in many cases, but their structure and location is a decision that can be made from case to case.
本文件的目的是提供指导，当考虑新协议的管理和部署时要考虑什么，并提供关于记录考虑事项的指导。以下指南旨在帮助作者为此类文档提供合理一致的格式。在许多情况下，单独的可管理性和操作注意事项部分是可取的，但它们的结构和位置是可以根据具体情况作出决定的。
This document does not impose a solution, imply that a formal data model is needed, or imply that using a specific management protocol is mandatory. If protocol designers conclude that the technology can be managed solely by using proprietary command line interfaces (CLIs) and that no structured or standardized data model needs to be in place, this might be fine, but it is a decision that should be explicit in a manageability discussion -- that this is how the protocol will need to be operated and managed. Protocol designers should avoid having manageability pushed for a later phase of the development of the standard.
本文档没有强制实施解决方案，也没有暗示需要正式的数据模型，或者暗示必须使用特定的管理协议。如果协议设计者得出结论，认为该技术可以仅通过使用专有命令行接口（CLI）进行管理，并且不需要建立结构化或标准化的数据模型，那么这可能是好的，但这是一个在可管理性讨论中应该明确的决定——协议需要如何操作和管理。协议设计者应该避免将可管理性推到标准开发的后期。
In discussing the importance of considering operations and management, this document sets forth a list of guidelines and a checklist of questions to consider (see Appendix A), which a protocol designer or reviewer can use to evaluate whether the protocol and documentation address common operations and management needs. Operations and management are highly dependent on their environment, so most guidelines are subjective rather than objective.
在讨论考虑操作和管理的重要性时，该文件列出了一系列指南和要考虑的问题的清单（见附录A），协议设计者或审计员可以用来评估协议和文档是否涉及共同的操作和管理需求。运营和管理高度依赖于环境，因此大多数指南是主观的，而不是客观的。
For years the IETF community has used the IETF Standard Management Framework, including the Simple Network Management Protocol [RFC3410], the Structure of Management Information [RFC2578], and MIB data models for managing new protocols. As the Internet has evolved, operators have found the reliance on one protocol and one schema language for managing all aspects of the Internet inadequate. The IESG policy to require working groups to write a MIB module to
多年来，IETF社区一直使用IETF标准管理框架，包括简单网络管理协议[RFC3410]、管理信息结构[RFC2578]和用于管理新协议的MIB数据模型。随着互联网的发展，运营商发现依靠一种协议和一种模式语言来管理互联网的各个方面是不够的。IESG策略要求工作组将MIB模块写入
provide manageability for new protocols is being replaced by a policy that is more open to using a variety of management protocols and data models designed to achieve different goals.
为新协议提供可管理性正在被一项政策所取代，该政策更开放，可以使用各种管理协议和数据模型来实现不同的目标。
This document provides some initial guidelines for considering operations and management in an IETF Management Framework that consists of multiple protocols and multiple data-modeling languages, with an eye toward being flexible while also striving for interoperability.
本文件为考虑IETF管理框架中的操作和管理提供了一些初步指南，IETF管理框架由多个协议和多个数据建模语言组成，着眼于灵活性，同时努力实现互操作性。
Fully new protocols may require significant consideration of expected operations and management, while extensions to existing, widely deployed protocols may have established de facto operations and management practices that are already well understood.
全新的协议可能需要大量考虑预期的操作和管理，而对广泛部署的现有协议的扩展可能已经建立了已经很好理解的事实上的操作和管理实践。
Suitable management approaches may vary for different areas, working groups, and protocols in the IETF. This document does not prescribe a fixed solution or format in dealing with operational and management aspects of IETF protocols. However, these aspects should be considered for any IETF protocol because we develop technologies and protocols to be deployed and operated in the real-world Internet. It is fine if a WG decides that its protocol does not need interoperable management or no standardized data model, but this should be a deliberate decision, not the result of omission. This document provides some guidelines for those considerations.
对于IETF中的不同区域、工作组和协议，合适的管理方法可能会有所不同。本文件未规定处理IETF协议操作和管理方面的固定解决方案或格式。然而，任何IETF协议都应该考虑这些方面，因为我们开发了在真实互联网中部署和操作的技术和协议。如果工作组决定其协议不需要可互操作的管理或没有标准化的数据模型，这是可以的，但这应该是一个深思熟虑的决定，而不是遗漏的结果。本文件为这些考虑提供了一些指导原则。
There have been a significant number of efforts, meetings, and documents that are related to Internet operations and management. Some of them are mentioned here to help protocol designers find documentation of previous efforts. Hopefully, providing these references will help the IETF avoid rehashing old discussions and reinventing old solutions.
已经有大量与互联网运营和管理相关的工作、会议和文件。这里提到其中一些是为了帮助协议设计者找到以前工作的文档。希望，提供这些参考资料将有助于IETF避免重复旧的讨论和重新发明旧的解决方案。
In 1988, the IAB published "IAB Recommendations for the Development of Internet Network Management Standards" [RFC1052], which recommended a solution that, where possible, deliberately separates modeling languages, data models, and the protocols that carry data. The goal is to allow standardized information and data models to be used by different protocols.
1988年，IAB发布了“IAB关于制定互联网网络管理标准的建议”[RFC1052]，其中推荐了一种解决方案，该解决方案在可能的情况下有意分离建模语言、数据模型和承载数据的协议。目标是允许不同协议使用标准化的信息和数据模型。
In 2001, Operations and Management Area design teams were created to document requirements related to the configuration of IP-based networks. One output was "Requirements for Configuration Management of IP-based Networks" [RFC3139].
2001年，成立了运营和管理区设计小组，以记录与基于IP的网络配置有关的要求。一个输出是“基于IP的网络的配置管理要求”[RFC3139]。
In 2003, the Internet Architecture Board (IAB) held a workshop on Network Management [RFC3535] that discussed the strengths and weaknesses of some IETF network management protocols and compared them to operational needs, especially configuration.
2003年，互联网体系结构委员会（IAB）举办了一次网络管理研讨会[RFC3535]，讨论了一些IETF网络管理协议的优缺点，并将其与操作需求，特别是配置进行了比较。
One issue discussed was the user-unfriendliness of the binary format of SNMP [RFC3410] and Common Open Policy Service (COPS) Usage for Policy Provisioning (COPS-PR) [RFC3084], and it was recommended that the IETF explore an XML-based Structure of Management Information and an XML-based protocol for configuration.
讨论的一个问题是SNMP二进制格式[RFC3410]和用于策略提供（COPS-PR）[RFC3084]的通用开放策略服务（COPS）使用对用户不友好，建议IETF探索基于XML的管理信息结构和基于XML的配置协议。
Another conclusion was that the tools for event/alarm correlation and for root cause analysis and logging are not sufficient and that there is a need to support a human interface and a programmatic interface. The IETF decided to standardize aspects of the de facto standard for system-logging security and programmatic support.
另一个结论是，事件/警报关联以及根本原因分析和记录的工具不够，需要支持人机界面和编程界面。IETF决定对系统日志安全和编程支持的事实标准的各个方面进行标准化。
In 2006, the IETF discussed whether the Management Framework should be updated to accommodate multiple IETF schema languages for describing the structure of management information and multiple IETF standard protocols for performing management tasks. The IESG asked that a document be written to discuss how protocol designers and working groups should address management in this emerging multi-protocol environment. This document and some planned companion documents attempt to provide some guidelines for navigating the rapidly shifting operating and management environments.
2006年，IETF讨论了是否应更新管理框架，以适应用于描述管理信息结构的多种IETF模式语言和用于执行管理任务的多种IETF标准协议。IESG要求编写一份文件，讨论协议设计者和工作组应如何在这种新兴的多协议环境中解决管理问题。本文件和一些计划中的配套文件试图为快速变化的运营和管理环境提供一些指导。
The IETF has a number of standard management protocols available that are suitable for different purposes. These include:
IETF有许多适用于不同用途的标准管理协议。这些措施包括：
Simple Network Management Protocol - SNMP [RFC3410]
简单网络管理协议-SNMP[RFC3410]
Syslog [RFC5424]
系统日志[RFC5424]
Remote Authentication Dial-In User Service - RADIUS [RFC2865]
远程身份验证拨入用户服务-RADIUS[RFC2865]
DIAMETER [RFC3588]
直径[RFC3588]
Network Configuration Protocol - NETCONF [RFC4741]
网络配置协议-NETCONF[RFC4741]
IP Flow Information Export - IPFIX [RFC5101]
IP流信息导出-IPFIX[RFC5101]
A planned supplement to this document will discuss these protocol standards, discuss some standard information and data models for specific functionality, and provide pointers to the documents that define them.
本文档的计划补充将讨论这些协议标准，讨论特定功能的一些标准信息和数据模型，并提供指向定义这些标准的文档的指针。
This document deliberately does not use the (capitalized) keywords described in RFC 2119 [RFC2119]. RFC 2119 states the keywords must only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmissions). For example, they must not be used to try to impose a particular method on implementers where the method is not required for interoperability. This informational document is a set of guidelines based on current practices of **some** protocol designers and operators. This document is biased toward router operations and management and some advice may not be directly applicable to protocols with a different purpose, such as application server protocols. This document **does not** describe interoperability requirements, so the capitalized keywords from RFC 2119 do not apply here.
本文档故意不使用RFC 2119[RFC2119]中描述的（大写）关键字。RFC 2119规定，关键字只能在互操作或限制可能造成伤害的行为（例如，限制重传）实际需要时使用。例如，如果互操作性不需要某个方法，则不能使用它们试图将该方法强加给实现者。本信息性文档是一套基于**一些**协议设计者和运营商当前实践的指南。本文档偏向于路由器操作和管理，一些建议可能不直接适用于具有不同用途的协议，例如应用服务器协议。本文件**未**描述互操作性要求，因此RFC 2119中大写的关键字在此不适用。
o CLI: Command Line Interface
o CLI：命令行界面
o Data model: a mapping of the contents of an information model into a form that is specific to a particular type of data store or repository [RFC3444].
o 数据模型：将信息模型的内容映射为特定于特定类型数据存储或存储库的表单[RFC3444]。
o Information model: an abstraction and representation of the entities in a managed environment, their properties, attributes and operations, and the way that they relate to each other. It is independent of any specific repository, software usage, protocol, or platform [RFC3444].
o 信息模型：管理环境中实体的抽象和表示，它们的属性、属性和操作，以及它们之间的关系。它独立于任何特定的存储库、软件使用、协议或平台[RFC3444]。
o New protocol: includes new protocols, protocol extensions, data models, or other functionality being designed.
o 新协议：包括新协议、协议扩展、数据模型或正在设计的其他功能。
o Protocol designer: represents individuals and working groups involved in the development of new protocols or extensions.
o 协议设计者：代表参与新协议或扩展开发的个人和工作组。
2. Operational Considerations - How Will the New Protocol Fit into the Current Environment?
2. 操作注意事项-新协议如何适应当前环境？
Designers of a new protocol should carefully consider the operational aspects. To ensure that a protocol will be practical to deploy in the real world, it is not enough to merely define it very precisely in a well-written document. Operational aspects will have a serious impact on the actual success of a protocol. Such aspects include bad interactions with existing solutions, a difficult upgrade path, difficulty of debugging problems, difficulty configuring from a central database, or a complicated state diagram that operations staff will find difficult to understand.
新协议的设计者应该仔细考虑操作方面。为了确保在现实世界中部署一个协议是切实可行的，仅仅在一个编写良好的文档中非常精确地定义它是不够的。操作方面将对协议的实际成功产生严重影响。这些方面包括与现有解决方案的不良交互、困难的升级路径、调试问题的困难、从中央数据库进行配置的困难，或者操作人员难以理解的复杂状态图。
BGP flap damping [RFC2439] is an example. It was designed to block high-frequency route flaps; however, the design did not consider the existence of BGP path exploration / slow convergence. In real operations, path exploration caused false flap damping, resulting in loss of reachability. As a result, many networks turned flap damping off.
BGP襟翼阻尼[RFC2439]就是一个例子。设计用于阻挡高频路径襟翼；然而，设计没有考虑BGP路径探索/慢收敛的存在。在实际操作中，路径探索会导致伪襟翼阻尼，导致可达性丧失。因此，许多网络关闭了襟翼阻尼。
Protocol designers can analyze the operational environment and mode of work in which the new protocol or extension will work. Such an exercise need not be reflected directly by text in their document, but could help in visualizing how to apply the protocol in the Internet environments where it will be deployed.
协议设计者可以分析新协议或扩展将在其中工作的操作环境和工作模式。这种做法不需要直接通过文件中的文本反映出来，但可以帮助可视化如何在部署协议的互联网环境中应用协议。
A key question is how the protocol can operate "out of the box". If implementers are free to select their own defaults, the protocol needs to operate well with any choice of values. If there are sensible defaults, these need to be stated.
一个关键问题是协议如何“开箱即用”地运行。如果实现者可以自由选择自己的默认值，那么协议需要在任何值的选择下都能很好地运行。如果存在合理的违约，则需要说明。
There may be a need to support a human interface, e.g., for troubleshooting, and a programmatic interface, e.g., for automated monitoring and root cause analysis. The application programming interfaces and the human interfaces might benefit from being similar to ensure that the information exposed by these two interfaces is consistent when presented to an operator. Identifying consistent methods of determining information, such as what gets counted in a specific counter, is relevant.
可能需要支持人机界面（例如用于故障排除）和编程界面（例如用于自动监控和根本原因分析）。应用程序编程接口和人员接口可能会从相似性中获益，以确保这两个接口公开的信息在呈现给操作员时是一致的。确定确定信息的一致方法，例如在特定计数器中计算的内容，是相关的。
Protocol designers should consider what management operations are expected to be performed as a result of the deployment of the protocol -- such as whether write operations will be allowed on routers and on hosts, or whether notifications for alarms or other events will be expected.
协议设计者应该考虑由于协议的部署而执行的管理操作，例如是否允许在路由器和主机上进行写操作，或者是否期望警报或其他事件的通知。
Anything that can be configured can be misconfigured. "Architectural Principles of the Internet" [RFC1958], Section 3.8, states: "Avoid options and parameters whenever possible. Any options and parameters should be configured or negotiated dynamically rather than manually."
任何可以配置的东西都可能配置错误。“互联网架构原则”[RFC1958]第3.8节规定：“尽可能避免选项和参数。任何选项和参数都应动态配置或协商，而不是手动配置。”
To simplify configuration, protocol designers should consider specifying reasonable defaults, including default modes and parameters. For example, it could be helpful or necessary to specify default values for modes, timers, default state of logical control
为了简化配置，协议设计者应该考虑指定合理的默认值，包括默认模式和参数。例如，为模式、计时器、逻辑控制的默认状态指定默认值可能会有帮助或必要
variables, default transports, and so on. Even if default values are used, it must be possible to retrieve all the actual values or at least an indication that known default values are being used.
变量、默认传输等。即使使用默认值，也必须能够检索所有实际值，或者至少能够检索到使用已知默认值的指示。
Protocol designers should consider how to enable operators to concentrate on the configuration of the network as a whole rather than on individual devices. Of course, how one accomplishes this is the hard part.
协议设计者应该考虑如何使运营商集中于整个网络的配置，而不是单个设备上。当然，如何做到这一点是很难的。
It is desirable to discuss the background of chosen default values, or perhaps why a range of values makes sense. In many cases, as technology changes, the values in an RFC might make less and less sense. It is very useful to understand whether defaults are based on best current practice and are expected to change as technologies advance or whether they have a more universal value that should not be changed lightly. For example, the default interface speed might be expected to change over time due to increased speeds in the network, and cryptographical algorithms might be expected to change over time as older algorithms are "broken".
最好讨论所选默认值的背景，或者讨论为什么一系列值是有意义的。在许多情况下，随着技术的变化，RFC中的值可能变得越来越没有意义。了解默认值是否基于当前最佳实践并随着技术的进步而改变，或者它们是否具有不应轻易改变的更普遍的价值，这是非常有用的。例如，由于网络速度的提高，默认接口速度可能会随着时间的推移而改变，而密码算法可能会随着时间的推移而改变，因为较旧的算法会被“破坏”。
It is extremely important to set a sensible default value for all parameters.
为所有参数设置合理的默认值非常重要。
The default value should stay on the conservative side rather than on the "optimizing performance" side (example: the initial RTT and RTTvar values of a TCP connection).
默认值应保持在保守端，而不是“优化性能”端（例如：TCP连接的初始RTT和RTTvar值）。
For those parameters that are speed-dependent, instead of using a constant, try to set the default value as a function of the link speed or some other relevant factors. This would help reduce the chance of problems caused by technology advancement.
对于那些与速度相关的参数，不要使用常数，而是尝试将默认值设置为链接速度或其他相关因素的函数。这将有助于减少因技术进步而出现问题的机会。
If the new protocol is a new version of an existing one, or if it is replacing another technology, the protocol designer should consider how deployments should transition to the new protocol. This should include coexistence with previously deployed protocols and/or previous versions of the same protocol, incompatibilities between versions, translation between versions, and side effects that might occur. Are older protocols or versions disabled or do they coexist in the network with the new protocol?
如果新协议是现有协议的一个新版本，或者如果它正在替换另一个技术，则协议设计者应该考虑部署应该如何过渡到新协议。这应包括与以前部署的协议和/或同一协议的以前版本共存、版本之间的不兼容、版本之间的转换以及可能发生的副作用。旧协议或版本是否已禁用，或者它们是否与新协议在网络中共存？
Many protocols benefit from being incrementally deployable -- operators may deploy aspects of a protocol before deploying the protocol fully.
许多协议都受益于增量部署——操作员可以在完全部署协议之前部署协议的各个方面。
Protocol designers should consider the requirements that the new protocol might put on other protocols and functional components and should also document the requirements from other protocols and functional elements that have been considered in designing the new protocol.
协议设计者应该考虑新协议可能会对其他协议和功能组件提出的要求，并且还应该记录在设计新协议时已经考虑过的其他协议和功能元素的要求。
These considerations should generally remain illustrative to avoid creating restrictions or dependencies, or potentially impacting the behavior of existing protocols, or restricting the extensibility of other protocols, or assuming other protocols will not be extended in certain ways. If restrictions or dependencies exist, they should be stated.
这些注意事项通常应保持说明性，以避免产生限制或依赖，或可能影响现有协议的行为，或限制其他协议的可扩展性，或假设其他协议不会以某些方式扩展。如果存在限制或依赖关系，则应予以说明。
For example, the design of the Resource ReSerVation Protocol (RSVP) [RFC2205] required each router to look at the RSVP PATH message and, if the router understood RSVP, add its own address to the message to enable automatic tunneling through non-RSVP routers. But in reality, routers cannot look at an otherwise normal IP packet and potentially take it off the fast path! The initial designers overlooked that a new "deep packet inspection" requirement was being put on the functional components of a router. The "router alert" option ([RFC2113], [RFC2711]) was finally developed to solve this problem for RSVP and other protocols that require the router to take some packets off the fast-forwarding path. Yet, router alert has its own problems in impacting router performance.
例如，资源预留协议（RSVP）[RFC2205]的设计要求每个路由器查看RSVP路径消息，如果路由器理解RSVP，则将其自己的地址添加到消息中，以启用通过非RSVP路由器的自动隧道。但在现实中，路由器无法看到一个正常的IP数据包，并有可能使它脱离快速路径！最初的设计人员忽略了一个新的“深度数据包检查”要求被放在路由器的功能组件上。“路由器警报”选项（[RFC2113]、[RFC2711]）最终被开发出来，以解决RSVP和其他协议的这个问题，这些协议要求路由器从快进路径上取下一些数据包。然而，路由器警报在影响路由器性能方面有其自身的问题。
The introduction of a new protocol or extensions to an existing protocol may have an impact on the operation of existing networks. Protocol designers 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 interior gateway protocols operating within the network.
引入新协议或对现有协议的扩展可能会对现有网络的运行产生影响。协议设计者应概述此类影响（可能是积极的），包括扩展关注点和与其他协议的交互。例如，考虑到对网络内运行的内部网关协议的可伸缩性的影响，可能需要考虑将网络内使用的活动、可到达地址的数量增加一倍的新协议。
A protocol could send active monitoring packets on the wire. If we don't pay attention, we might get very good accuracy, but could send too many active monitoring packets.
协议可以在线路上发送活动监视数据包。如果我们不注意，我们可能会得到很好的准确性，但可能会发送太多的活动监视数据包。
The protocol designer should consider the potential impact on the behavior of other protocols in the network and on the traffic levels and traffic patterns that might change, including specific types of traffic, such as multicast. Also, consider the need to install new
协议设计者应该考虑对网络中其他协议的行为和可能改变的流量级别和业务模式的潜在影响，包括特定类型的流量，例如多播。此外，考虑安装新设备的必要性。
components that are added to the network as a result of changes in the configuration, such as servers performing auto-configuration operations.
由于配置更改而添加到网络的组件，例如执行自动配置操作的服务器。
The protocol designer should consider also the impact on infrastructure applications like DNS [RFC1034], the registries, or the size of routing tables. For example, Simple Mail Transfer Protocol (SMTP) [RFC5321] servers use a reverse DNS lookup to filter out incoming connection requests. When Berkeley installed a new spam filter, their mail server stopped functioning because of overload of the DNS cache resolver.
协议设计者还应该考虑对基础设施应用的影响，如DNS[RCF1034 ]、注册中心或路由表的大小。例如，简单邮件传输协议（SMTP）[RFC5321]服务器使用反向DNS查找来过滤传入的连接请求。当Berkeley安装一个新的垃圾邮件过滤器时，他们的邮件服务器因为DNS缓存解析程序过载而停止工作。
The impact on performance may also be noted -- increased delay or jitter in real-time traffic applications, or increased response time in client-server applications when encryption or filtering are applied.
还可能注意到对性能的影响——实时流量应用程序中的延迟或抖动增加，或者在应用加密或过滤时客户端服务器应用程序中的响应时间增加。
It is important to minimize the impact caused by configuration changes. Given configuration A and configuration B, it should be possible to generate the operations necessary to get from A to B with minimal state changes and effects on network and systems.
将配置更改造成的影响降至最低非常重要。给定配置A和配置B，应该能够生成从A到B所需的操作，并且状态变化和对网络和系统的影响最小。
The protocol designer should consider techniques for testing the effect that the protocol has had on the network by sending data through the network and observing its behavior (aka active monitoring). Protocol designers should consider how the correct end-to-end operation of the new protocol in the network can be tested actively and passively, and how the correct data or forwarding plane function of each network element can be verified to be working properly with the new protocol. Which metrics are of interest?
协议设计者应该考虑通过网络发送数据并观察其行为（AKA主动监视）来测试协议对网络的影响的技术。协议设计者应该考虑网络中新协议的正确端到端操作如何主动和被动地测试，以及如何验证每个网络单元的正确数据或转发平面功能如何正确地与新协议一起工作。哪些指标值得关注？
Having simple protocol status and health indicators on network devices is a recommended means to check correct operation.
建议在网络设备上设置简单的协议状态和运行状况指示器，以检查操作是否正确。
The considerations of manageability should start from identifying the entities to be managed, as well as how the managed protocol is supposed to be installed, configured, and monitored.
可管理性的考虑应该从确定要管理的实体以及如何安装、配置和监视托管协议开始。
Considerations for management should include a discussion of what needs to be managed, and how to achieve various management tasks. Where are the managers and what type of management interfaces and protocols will they need? The "write a MIB module" approach to considering management often focuses on monitoring a protocol endpoint on a single device. A MIB module document typically only
管理方面的考虑应包括讨论需要管理什么，以及如何实现各种管理任务。经理在哪里？他们需要什么类型的管理接口和协议？考虑管理的“编写MIB模块”方法通常侧重于监视单个设备上的协议端点。MIB模块文档通常仅限于
considers monitoring properties observable at one end, while the document does not really cover managing the *protocol* (the coordination of multiple ends), and does not even come near managing the *service* (which includes a lot of stuff that is very far away from the box). This is exactly what operators hate -- you need to be able to manage both ends. As [RFC3535] says, "MIB modules can often be characterized as a list of ingredients without a recipe".
考虑在一端可以观察到的监视属性，而文档实际上没有涉及管理*protocol*（多个端的协调），甚至没有接近管理*service*（其中包括许多离盒子很远的东西）。这正是运营商所讨厌的——您需要能够管理两端。正如[RFC3535]所说，“MIB模块通常可以描述为没有配方的成分列表”。
The management model should take into account factors such as:
管理模式应考虑以下因素：
o What type of management entities will be involved (agents, network management systems)?
o 将涉及何种类型的管理实体（代理、网络管理系统）？
o What is the possible architecture (client-server, manager-agent, poll-driven or event-driven, auto-configuration, two levels or hierarchical)?
o 可能的体系结构是什么（客户机-服务器、管理器-代理、轮询驱动或事件驱动、自动配置、两级或分层）？
o What are the management operations (initial configuration, dynamic configuration, alarm and exception reporting, logging, performance monitoring, performance reporting, debugging)?
o 管理操作是什么（初始配置、动态配置、报警和异常报告、日志记录、性能监控、性能报告、调试）？
o How are these operations performed (locally, remotely, atomic operation, scripts)? Are they performed immediately or are they time scheduled or event triggered?
o 这些操作是如何执行的（本地、远程、原子操作、脚本）？它们是立即执行还是按时间安排或事件触发？
Protocol designers should consider how the new protocol will be managed in different deployment scales. It might be sensible to use a local management interface to manage the new protocol on a single device, but in a large network, remote management using a centralized server and/or using distributed management functionality might make more sense. Auto-configuration and default parameters might be possible for some new protocols.
协议设计者应该考虑如何在不同的部署规模下管理新协议。使用本地管理接口在单个设备上管理新协议可能是明智的，但在大型网络中，使用集中式服务器和/或使用分布式管理功能进行远程管理可能更有意义。自动配置和默认参数可能适用于某些新协议。
Management needs to be considered not only from the perspective of a device, but also from the perspective of network and service management. A service might be network and operational functionality derived from the implementation and deployment of a new protocol. Often an individual network element is not aware of the service being delivered.
管理不仅需要从设备的角度考虑，还需要从网络和服务管理的角度考虑。服务可能是从新协议的实现和部署中派生的网络和操作功能。通常，单个网元不知道正在交付的服务。
WGs should consider how to configure multiple related/co-operating devices and how to back off if one of those configurations fails or causes trouble. NETCONF [RFC4741] addresses this in a generic manner by allowing an operator to lock the configuration on multiple devices, perform the configuration settings/changes, check that they are OK (undo if not), and then unlock the devices.
WGS应考虑如何配置多个相关/合作设备，以及如果这些配置中的一个失效或造成故障，如何退避。NETCONF[RFC4741]通过允许操作员锁定多个设备上的配置，执行配置设置/更改，检查它们是否正常（如果没有，则撤消），然后解锁设备，以通用方式解决此问题。
Techniques for debugging protocol interactions in a network must be part of the network-management discussion. Implementation source code should be debugged before ever being added to a network, so asserts and memory dumps do not normally belong in management data models. However, debugging on-the-wire interactions is a protocol issue: while the messages can be seen by sniffing, it is enormously helpful if a protocol specification supports features that make debugging of network interactions and behaviors easier. There could be alerts issued when messages are received or when there are state transitions in the protocol state machine. However, the state machine is often not part of the on-the-wire protocol; the state machine explains how the protocol works so that an implementer can decide, in an implementation-specific manner, how to react to a received event.
调试网络中协议交互的技术必须是网络管理讨论的一部分。实现源代码应该在添加到网络之前进行调试，因此断言和内存转储通常不属于管理数据模型。然而，在线交互的调试是一个协议问题：虽然可以通过嗅探来查看消息，但是如果协议规范支持使网络交互和行为的调试更容易的功能，这将非常有帮助。当收到消息或协议状态机中存在状态转换时，可能会发出警报。然而，状态机通常不是在线协议的一部分；状态机解释协议如何工作，以便实现者能够以特定于实现的方式决定如何对接收到的事件做出反应。
In a client/server protocol, it may be more important to instrument the server end of a protocol than the client end, since the performance of the server might impact more nodes than the performance of a specific client.
In a client/server protocol, it may be more important to instrument the server end of a protocol than the client end, since the performance of the server might impact more nodes than the performance of a specific client.translate error, please retry
Just as when deploying protocols that will inter-connect devices, management interoperability should be considered -- whether across devices from different vendors, across models from the same vendor, or across different releases of the same product. Management interoperability refers to allowing information sharing and operations between multiple devices and multiple management applications, often from different vendors. Interoperability allows for the use of third-party applications and the outsourcing of management services.
正如部署将设备相互连接的协议时一样，应该考虑管理互操作性——无论是来自不同供应商的设备之间、来自同一供应商的模型之间，还是同一产品的不同版本之间。管理互操作性是指允许多个设备和多个管理应用程序（通常来自不同的供应商）之间共享信息和进行操作。互操作性允许使用第三方应用程序和外包管理服务。
Some product designers and protocol designers assume that if a device can be managed individually using a command line interface or a web page interface, that such a solution is enough. But when equipment from multiple vendors is combined into a large network, scalability of management may become a problem. It may be important to have consistency in the management interfaces so network-wide operational processes can be automated. For example, a single switch might be easily managed using an interactive web interface when installed in a single-office small business, but when, say, a fast-food company installs similar switches from multiple vendors in hundreds or thousands of individual branches and wants to automate monitoring them from a central location, monitoring vendor- and model-specific web pages would be difficult to automate.
一些产品设计师和协议设计师认为，如果可以使用命令行界面或网页界面单独管理设备，那么这样的解决方案就足够了。但是，当来自多个供应商的设备组合到一个大型网络中时，管理的可扩展性可能会成为一个问题。管理接口的一致性可能很重要，这样网络范围的操作过程就可以自动化。例如，当单个交换机安装在单个办公室的小型企业中时，可以使用交互式web界面轻松管理单个交换机，但如果一家快餐公司在数百或数千家分支机构中安装了来自多个供应商的类似交换机，并希望从一个中心位置对其进行自动化监控，监控特定于供应商和模型的网页将很难实现自动化。
The primary goal is the ability to roll out new useful functions and services in a way in which they can be managed in a scalable manner, where one understands the network impact (as part of the total cost of operations) of that service.
主要目标是能够以一种可扩展的方式管理新的有用功能和服务，并了解该服务对网络的影响（作为运营总成本的一部分）。
Getting everybody to agree on a single syntax and an associated protocol to do all management has proven to be difficult. So management systems tend to speak whatever the boxes support, whether or not the IETF likes this. The IETF is moving from support for one schema language for modeling the structure of management information (Structure of Management Information Version 2 (SMIv2) [RFC2578]) and one simple network management protocol (Simple Network Management Protocol (SNMP) [RFC3410]) towards support for additional schema languages and additional management protocols suited to different purposes. Other Standard Development Organizations (e.g., the Distributed Management Task Force - DMTF, the Tele-Management Forum - TMF) also define schemas and protocols for management and these may be more suitable than IETF schemas and protocols in some cases. Some of the alternatives being considered include:
事实证明，要让每个人都同意一个语法和一个相关的协议来进行所有管理是很困难的。因此，无论IETF是否喜欢，管理系统都倾向于说出方框支持的任何内容。IETF正在从支持一种用于建模管理信息结构的模式语言（管理信息结构版本2（SMIv2）[RFC2578]）和一种简单网络管理协议（简单网络管理协议（SNMP）[RFC3410]）支持适用于不同用途的其他模式语言和其他管理协议。其他标准开发组织（如分布式管理工作队-DMTF、远程管理论坛-TMF）也定义了管理模式和协议，在某些情况下，这些模式和协议可能比IETF模式和协议更合适。正在考虑的一些备选方案包括：
o XML Schema Definition [W3C.REC-xmlschema-0-20010502]
o XML模式定义[W3C.REC-xmlschema-0-20010502]
and
和
o NETCONF Configuration Protocol [RFC4741]
o NETCONF配置协议[RFC4741]
o the IP Flow Information Export (IPFIX) Protocol [RFC5101]) for usage accounting
o 用于使用计费的IP流信息导出（IPFIX）协议[RFC5101]）
o the syslog protocol [RFC5424] for logging
o 用于日志记录的系统日志协议[RFC5424]
Interoperability needs to be considered on the syntactic level and the semantic level. While it can be irritating and time-consuming, application designers, including operators who write their own scripts, can make their processing conditional to accommodate syntactic differences across vendors, models, or releases of product.
互操作性需要在语法层面和语义层面上加以考虑。虽然这可能会令人恼火且耗时，但应用程序设计者（包括编写自己脚本的操作员）可以将其处理设置为有条件的，以适应不同供应商、模型或产品版本之间的语法差异。
Semantic differences are much harder to deal with on the manager side -- once you have the data, its meaning is a function of the managed entity.
在管理器方面，语义差异更难处理——一旦您拥有了数据，其含义就是托管实体的一个功能。
Information models are helpful to try to focus interoperability on the semantic level -- they establish standards for what information should be gathered and how gathered information might be used, regardless of which management interface carries the data or which vendor produces the product. The use of an information model might help improve the ability of operators to correlate messages in different protocols where the data overlaps, such as a syslog message
信息模型有助于将互操作性重点放在语义级别上——它们为应该收集哪些信息以及如何使用收集的信息建立了标准，而不管哪个管理界面承载数据或哪个供应商生产产品。使用信息模型可能有助于提高操作员在数据重叠的不同协议（如syslog消息）中关联消息的能力
and an SNMP notification about the same event. An information model might identify which error conditions should be counted separately and which error conditions can be counted together in a single counter. Then, whether the counter is gathered via SNMP, a CLI command, or a syslog message, the counter will have the same meaning.
以及关于同一事件的SNMP通知。信息模型可以识别哪些错误条件应该单独计数，哪些错误条件可以在单个计数器中一起计数。然后，无论计数器是通过SNMP、CLI命令还是syslog消息收集的，计数器都具有相同的含义。
Protocol designers should consider which information might be useful for managing the new protocol or protocol extensions.
协议设计者应该考虑哪些信息可能用于管理新协议或协议扩展。
IM --> conceptual/abstract model
| for designers and operators
+----------+---------+
| | |
DM DM DM --> concrete/detailed model
for implementers
IM --> conceptual/abstract model
| for designers and operators
+----------+---------+
| | |
DM DM DM --> concrete/detailed model
for implementers
Information Models and Data Models
信息模型和数据模型
Figure 1
图1
Protocol designers may decide an information model or data model would be appropriate for managing the new protocol or protocol extensions.
协议设计者可以决定信息模型或数据模型是否适合管理新协议或协议扩展。
"On the Difference between Information Models and Data Models" [RFC3444] can be helpful in determining what information to consider regarding information models (IMs), as compared to data models (DMs).
“关于信息模型和数据模型之间的差异”[RCFC444 ]有助于确定与信息模型（IMS）有关的信息，与数据模型（DMS）相比。
Information models should come from the protocol WGs and include lists of events, counters, and configuration parameters that are relevant. There are a number of information models contained in protocol WG RFCs. Some examples:
信息模型应来自协议WGs，并包括相关事件、计数器和配置参数的列表。协议工作组RFC中包含许多信息模型。一些例子：
o [RFC3060] - Policy Core Information Model version 1
o [RFC3060]-策略核心信息模型版本1
o [RFC3290] - An Informal Management Model for Diffserv Routers
o [RFC3290]-区分服务路由器的非正式管理模型
o [RFC3460] - Policy Core Information Model Extensions
o [RFC3460]-策略核心信息模型扩展
o [RFC3585] - IPsec Configuration Policy Information Model
o [RFC3585]-IPsec配置策略信息模型
o [RFC3644] - Policy Quality of Service Information Model
o [RFC3644]-策略服务质量信息模型
o [RFC3670] - Information Model for Describing Network Device QoS Datapath Mechanisms
o [RFC3670]-用于描述网络设备QoS数据路径机制的信息模型
o [RFC3805] - Printer MIB v2 (contains both an IM and a DM)
o [RFC3805]-打印机MIB v2（包含IM和DM）
Management protocol standards and management data model standards often contain compliance clauses to ensure interoperability. Manageability considerations should include discussion of which level of compliance is expected to be supported for interoperability.
管理协议标准和管理数据模型标准通常包含符合性条款，以确保互操作性。可管理性考虑因素应包括讨论互操作性预期支持的法规遵从性级别。
Languages used to describe an information model can influence the nature of the model. Using a particular data-modeling language, such as the SMIv2, influences the model to use certain types of structures, such as two-dimensional tables. This document recommends using English text (the official language for IETF specifications) to describe an information model. A sample data model could be developed to demonstrate the information model.
用于描述信息模型的语言会影响模型的性质。使用特定的数据建模语言（如SMIv2）会影响模型使用某些类型的结构，如二维表。本文件建议使用英文文本（IETF规范的官方语言）来描述信息模型。可以开发一个样本数据模型来演示信息模型。
A management information model should include a discussion of what is manageable, which aspects of the protocol need to be configured, what types of operations are allowed, what protocol-specific events might occur, which events can be counted, and for which events an operator should be notified.
管理信息模型应包括以下内容的讨论：什么是可管理的，需要配置协议的哪些方面，允许哪些类型的操作，可能发生哪些协议特定事件，哪些事件可以计数，以及应该通知操作员哪些事件。
Operators find it important to be able to make a clear distinction between configuration data, operational state, and statistics. They need to determine which parameters were administratively configured and which parameters have changed since configuration as the result of mechanisms such as routing protocols or network management protocols. It is important to be able to separately fetch current configuration information, initial configuration information, operational state information, and statistics from devices; to be able to compare current state to initial state; and to compare information between devices. So when deciding what information should exist, do not conflate multiple information elements into a single element.
操作员发现能够明确区分配置数据、操作状态和统计信息非常重要。他们需要确定哪些参数是通过管理方式配置的，哪些参数在配置后由于路由协议或网络管理协议等机制而发生了更改。重要的是能够分别从设备获取当前配置信息、初始配置信息、操作状态信息和统计信息；能够比较当前状态和初始状态；以及比较设备之间的信息。因此，在决定应该存在哪些信息时，不要将多个信息元素合并为单个元素。
What is typically difficult to work through are relationships between abstract objects. Ideally, an information model would describe the relationships between the objects and concepts in the information model.
通常很难处理的是抽象对象之间的关系。理想情况下，信息模型将描述信息模型中对象和概念之间的关系。
Is there always just one instance of this object or can there be multiple instances? Does this object relate to exactly one other object or may it relate to multiple? When is it possible to change a relationship?
这个对象总是只有一个实例，还是可以有多个实例？该对象是否仅与一个其他对象相关，或者可能与多个对象相关？什么时候可以改变一段关系？
Do objects (such as rows in tables) share fate? For example, if a row in table A must exist before a related row in table B can be created, what happens to the row in table B if the related row in table A is deleted? Does the existence of relationships between objects have an impact on fate sharing?
对象（如表中的行）是否共享命运？例如，如果必须先存在表a中的一行，然后才能创建表B中的相关行，那么如果删除表a中的相关行，表B中的行会发生什么情况？物体之间关系的存在对命运分享有影响吗？
This document recommends keeping the information model as simple as possible by applying the following criteria:
本文档建议通过应用以下标准使信息模型尽可能简单：
1. Start with a small set of essential objects and add only as further objects are needed.
1. 从一小组基本对象开始，仅在需要其他对象时添加。
2. Require that objects be essential for management.
2. 要求对象对管理至关重要。
3. Consider evidence of current use and/or utility.
3. 考虑当前使用和/或实用工具的证据。
4. Limit the total number of objects.
4. 限制对象的总数。
5. Exclude objects that are simply derivable from others in this or other information models.
5. 排除在此信息模型或其他信息模型中仅可从其他模型派生的对象。
6. Avoid causing critical sections to be heavily instrumented. A guideline is one counter per critical section per layer.
6. 避免对关键部分进行大量检测。一个准则是每层每一个临界截面有一个计数器。
The protocol designer should document the basic faults and health indicators that need to be instrumented for the new protocol, as well as the alarms and events that must be propagated to management applications or exposed through a data model.
协议设计者应记录新协议需要检测的基本故障和运行状况指标，以及必须传播到管理应用程序或通过数据模型公开的警报和事件。
The protocol designer should consider how fault information will be propagated. Will it be done using asynchronous notifications or polling of health indicators?
协议设计者应该考虑如何传播故障信息。是否使用异步通知或运行状况指示器轮询来完成？
If notifications are used to alert operators to certain conditions, then the protocol designer should discuss mechanisms to throttle notifications to prevent congestion and duplications of event notifications. Will there be a hierarchy of faults, and will the fault reporting be done by each fault in the hierarchy, or will only the lowest fault be reported and the higher levels be suppressed? Should there be aggregated status indicators based on concatenation of propagated faults from a given domain or device?
如果通知用于提醒操作员某些情况，则协议设计者应讨论限制通知的机制，以防止拥塞和事件通知的重复。是否存在故障的层次结构，是否由层次结构中的每个故障进行故障报告，还是只报告最低级别的故障并抑制较高级别的故障？是否应该有基于给定域或设备传播的故障串联的聚合状态指示器？
SNMP notifications and syslog messages can alert an operator when an aspect of the new protocol fails or encounters an error or failure condition, and SNMP is frequently used as a heartbeat monitor. Should the event reporting provide guaranteed accurate delivery of the event information within a given (high) margin of confidence? Can we poll the latest events in the box?
当新协议的某个方面出现故障或遇到错误或故障情况时，SNMP通知和系统日志消息可以向操作员发出警报，并且SNMP经常用作心跳监视器。事件报告是否应在给定（高）置信区间内保证事件信息的准确传递？我们可以在盒子里投票选出最新的事件吗？
Protocol designers should always build in basic testing features (e.g., ICMP echo, UDP/TCP echo service, NULL RPCs (remote procedure calls)) that can be used to test for liveness, with an option to enable and disable them.
协议设计者应始终内置基本测试功能（例如，ICMP echo、UDP/TCP echo服务、空RPC（远程过程调用）），这些功能可用于测试活动性，并提供启用和禁用它们的选项。
Mechanisms for monitoring the liveness of the protocol and for detecting faults in protocol connectivity are usually built into protocols. In some cases, mechanisms already exist within other protocols responsible for maintaining lower-layer connectivity (e.g., ICMP echo), but often new procedures are required to detect failures and to report rapidly, allowing remedial action to be taken.
协议中通常内置用于监控协议活动性和检测协议连接中的故障的机制。在某些情况下，负责维护低层连接的其他协议（如ICMP echo）中已经存在机制，但通常需要新的程序来检测故障并快速报告，以便采取补救措施。
These liveness monitoring mechanisms do not typically require additional management capabilities. However, when a system detects a fault, there is often a requirement to coordinate recovery action through management applications or at least to record the fact in an event log.
这些活动性监视机制通常不需要额外的管理功能。但是，当系统检测到故障时，通常需要通过管理应用程序协调恢复操作，或者至少在事件日志中记录事实。
It can be helpful to describe how faults can be pinpointed using management information. For example, counters might record instances of error conditions. Some faults might be able to be pinpointed by comparing the outputs of one device and the inputs of another device, looking for anomalies. Protocol designers should consider what counters should count. If a single counter provided by vendor A counts three types of error conditions, while the corresponding counter provided by vendor B counts seven types of error conditions, these counters cannot be compared effectively -- they are not interoperable counters.
描述如何使用管理信息查明故障可能会有所帮助。例如，计数器可能会记录错误条件的实例。通过比较一台设备的输出和另一台设备的输入，查找异常情况，可以查明某些故障。协议设计者应该考虑计数器应该计数。如果供应商a提供的单个计数器统计三种类型的错误条件，而供应商B提供的相应计数器统计七种类型的错误条件，则无法有效比较这些计数器——它们不是可互操作的计数器。
How do you distinguish between faulty messages and good messages?
如何区分错误消息和良好消息？
Would some threshold-based mechanisms, such as Remote Monitoring (RMON) events/alarms or the EVENT-MIB, be usable to help determine error conditions? Are SNMP notifications for all events needed, or are there some "standard" notifications that could be used? Or can relevant counters be polled as needed?
一些基于阈值的机制，如远程监控（RMON）事件/报警或事件MIB，是否可用于帮助确定错误条件？是否需要所有事件的SNMP通知，或者是否可以使用一些“标准”通知？或者可以根据需要轮询相关计数器？
Root cause analysis is about working out where in the network the fault is. For example, if end-to-end data delivery is failing (reported by a notification), root cause analysis can help find the failed link or node in the end-to-end path.
根本原因分析是关于找出故障在网络中的位置。例如，如果端到端数据传递失败（通过通知报告），则根本原因分析可以帮助在端到端路径中查找失败的链接或节点。
It might be useful to isolate or quarantine faults, such as isolating a device that emits malformed messages that are necessary to coordinate connections properly. This might be able to be done by configuring next-hop devices to drop the faulty messages to prevent them from entering the rest of the network.
隔离或隔离故障可能很有用，例如隔离发出错误消息的设备，这些错误消息是正确协调连接所必需的。这可以通过配置下一跳设备来删除错误消息，以防止它们进入网络的其余部分来实现。
A protocol designer should document the basic configuration parameters that need to be instrumented for a new protocol, as well as default values and modes of operation.
协议设计者应记录新协议需要检测的基本配置参数，以及默认值和操作模式。
What information should be maintained across reboots of the device, or restarts of the management system?
在设备重新启动或管理系统重新启动期间，应维护哪些信息？
"Requirements for Configuration Management of IP-based Networks" [RFC3139] discusses requirements for configuration management, including discussion of different levels of management, high-level policies, network-wide configuration data, and device-local configuration. Network configuration is not just multi-device push or pull. It is knowing that the configurations being pushed are semantically compatible. Is the circuit between them configured compatibly on both ends? Is the IS-IS metric the same? ... Now answer those questions for 1,000 devices.
“基于IP的网络的配置管理要求”[RFC3139]讨论了配置管理的要求，包括对不同管理级别、高级策略、网络范围的配置数据和设备本地配置的讨论。网络配置不仅仅是多设备推拉。它知道被推送的配置在语义上是兼容的。它们之间的电路在两端配置是否兼容？Is-Is度量是相同的吗。。。现在为1000台设备回答这些问题。
A number of efforts have existed in the IETF to develop policy-based configuration management. "Terminology for Policy-Based Management" [RFC3198] was written to standardize the terminology across these efforts.
IETF已经做出了许多努力来开发基于策略的配置管理。编写“基于策略的管理术语”[RFC3198]是为了使这些工作中的术语标准化。
Implementations should not arbitrarily modify configuration data. In some cases (such as access control lists (ACLs)), the order of data items is significant and comprises part of the configured data. If a protocol designer defines mechanisms for configuration, it would be desirable to standardize the order of elements for consistency of configuration and of reporting across vendors and across releases from vendors.
实现不应随意修改配置数据。在某些情况下（例如访问控制列表（ACL）），数据项的顺序是重要的，并且包含部分配置数据。如果协议设计人员定义了配置机制，则需要标准化元素的顺序，以确保跨供应商和跨供应商发布的配置和报告的一致性。
There are two parts to this:
这有两个部分：
1. A Network Management System (NMS) could optimize ACLs for performance reasons.
1. 出于性能原因，网络管理系统（NMS）可以优化ACL。
2. Unless the device/NMS systems has correct rules / a lot of experience, reordering ACLs can lead to a huge security issue.
2. 除非设备/NMS系统具有正确的规则/丰富的经验，否则重新排序ACL可能会导致巨大的安全问题。
Network-wide configurations may be stored in central master databases and transformed into formats that can be pushed to devices, either by generating sequences of CLI commands or complete configuration files that are pushed to devices. There is no common database schema for network configuration, although the models used by various operators are probably very similar. Many operators consider it desirable to extract, document, and standardize the common parts of these network-wide configuration database schemas. A protocol designer should consider how to standardize the common parts of configuring the new protocol, while recognizing that vendors may also have proprietary aspects of their configurations.
网络范围的配置可以存储在中央主数据库中，并转换为可以推送到设备的格式，方法是生成CLI命令序列或推送到设备的完整配置文件。网络配置没有通用的数据库模式，尽管不同运营商使用的模型可能非常相似。许多运营商认为，提取、文档化和规范这些网络范围的配置数据库模式的公共部分是可取的。协议设计者应该考虑如何规范配置新协议的公共部分，同时认识到供应商也可能具有其配置的专有方面。
It is important to enable operators to concentrate on the configuration of the network as a whole, rather than individual devices. Support for configuration transactions across a number of devices could significantly simplify network configuration management. The ability to distribute configurations to multiple devices, or to modify candidate configurations on multiple devices, and then activate them in a near-simultaneous manner might help. Protocol designers can consider how it would make sense for their protocol to be configured across multiple devices. Configuration templates might also be helpful.
使运营商能够将注意力集中在整个网络的配置上，而不是单个设备上，这一点很重要。支持跨多个设备的配置事务可以显著简化网络配置管理。能够将配置分发到多个设备，或者修改多个设备上的候选配置，然后以几乎同时的方式激活它们可能会有所帮助。协议设计者可以考虑在多个设备上配置协议的意义。配置模板也可能有帮助。
Consensus of the 2002 IAB Workshop [RFC3535] was that textual configuration files should be able to contain international characters. Human-readable strings should utilize UTF-8, and protocol elements should be in case-insensitive ASCII.
2002年IAB研讨会[RFC3535]的共识是，文本配置文件应该能够包含国际字符。人类可读的字符串应该使用UTF-8，协议元素应该是不区分大小写的ASCII。
A mechanism to dump and restore configurations is a primitive operation needed by operators. Standards for pulling and pushing configurations from/to devices are desirable.
转储和恢复配置的机制是操作员需要的基本操作。从/到设备的拉和推配置标准是可取的。
Given configuration A and configuration B, it should be possible to generate the operations necessary to get from A to B with minimal state changes and effects on network and systems. It is important to minimize the impact caused by configuration changes.
给定配置A和配置B，应该能够生成从A到B所需的操作，并且状态变化和对网络和系统的影响最小。将配置更改造成的影响降至最低非常重要。
A protocol designer should consider the configurable items that exist for the control of function via the protocol elements described in the protocol specification. For example, sometimes the protocol
协议设计者应该考虑通过协议规范中描述的协议元素来控制功能的可配置项。例如，有时协议
requires that timers can be configured by the operator to ensure specific policy-based behavior by the implementation. These timers should have default values suggested in the protocol specification and may not need to be otherwise configurable.
要求操作员可以配置计时器，以确保实现基于策略的特定行为。这些定时器应具有协议规范中建议的默认值，并且可能不需要以其他方式进行配置。
An important function that should be provided is guidance on how to verify the correct operation of a protocol. A protocol designer could suggest techniques for testing the impact of the protocol on the network before it is deployed as well as techniques for testing the effect that the protocol has had on the network after being deployed.
应提供的一个重要功能是指导如何验证协议的正确操作。协议设计者可以建议在部署协议之前测试协议对网络的影响的技术，以及在部署协议之后测试协议对网络的影响的技术。
Protocol designers should consider how to test the correct end-to-end operation of the service or network, how to verify the correct functioning of the protocol, and whether that is verified by testing the service function and/or by testing the forwarding function of each network element. This may be achieved through status and statistical information gathered from devices.
协议设计者应该考虑如何测试服务或网络的正确的端到端操作，如何验证协议的正确运行，以及是否通过测试服务功能和/或通过测试每个网络元件的转发功能来验证该协议是否正确。这可以通过从设备收集的状态和统计信息来实现。
A protocol designer should consider whether it would be appropriate to collect usage information related to this protocol and, if so, what usage information would be appropriate to collect.
协议设计者应该考虑收集与此协议相关的使用信息是否合适，如果有的话，什么样的使用信息将适合收集。
"Introduction to Accounting Management" [RFC2975] discusses a number of factors relevant to monitoring usage of protocols for purposes of capacity and trend analysis, cost allocation, auditing, and billing. The document also discusses how some existing protocols can be used for these purposes. These factors should be considered when designing a protocol whose usage might need to be monitored or when recommending a protocol to do usage accounting.
“会计管理简介”[RFC2975]讨论了与监控协议使用相关的一些因素，以进行容量和趋势分析、成本分配、审计和计费。本文件还讨论了如何将一些现有协议用于这些目的。在设计可能需要监控其使用情况的协议时，或在建议协议进行使用情况核算时，应考虑这些因素。
From a manageability point of view, it is important to determine how well a network deploying the protocol or technology defined in the document is doing. In order to do this, the network operators need to consider information that would be useful to determine the performance characteristics of a deployed system using the target protocol.
从可管理性的角度来看，确定部署文档中定义的协议或技术的网络的性能是很重要的。为了做到这一点，网络运营商需要考虑有用的信息，以确定使用目标协议的部署系统的性能特征。
The IETF, via the Benchmarking Methodology WG (BMWG), has defined recommendations for the measurement of the performance characteristics of various internetworking technologies in a laboratory environment, including the systems or services that are
IETF通过标杆管理方法工作组（BMWG）定义了实验室环境中各种互联网技术性能特征测量的建议，包括
built from these technologies. Each benchmarking recommendation describes the class of equipment, system, or service being addressed; discusses the performance characteristics that are pertinent to that class; clearly identifies a set of metrics that aid in the description of those characteristics; specifies the methodologies required to collect said metrics; and lastly, presents the requirements for the common, unambiguous reporting of benchmarking results. Search for "benchmark" in the RFC search tool.
基于这些技术构建。每个基准测试建议都描述了所涉及的设备、系统或服务的类别；讨论与该类相关的性能特征；明确确定一组有助于描述这些特征的指标；指定收集所述指标所需的方法；最后，提出了通用、明确的基准测试结果报告要求。在RFC搜索工具中搜索“基准”。
Performance metrics may be useful in multiple environments and for different protocols. The IETF, via the IP Performance Monitoring (IPPM) WG, has developed a set of standard metrics that can be applied to the quality, performance, and reliability of Internet data delivery services. These metrics are designed such that they can be performed by network operators, end users, or independent testing groups. The existing metrics might be applicable to the new protocol. Search for "metric" in the RFC search tool. In some cases, new metrics need to be defined. It would be useful if the protocol documentation identified the need for such new metrics. For performance monitoring, it is often important to report the time spent in a state, rather than reporting the current state. Snapshots are of less value for performance monitoring.
性能指标在多个环境和不同协议中可能很有用。IETF通过IP性能监控（IPPM）工作组开发了一套标准度量标准，可应用于互联网数据交付服务的质量、性能和可靠性。这些指标的设计使得网络运营商、最终用户或独立测试组可以执行这些指标。现有指标可能适用于新协议。在RFC搜索工具中搜索“度量”。在某些情况下，需要定义新的指标。如果协议文件确定了对此类新指标的需求，这将非常有用。对于性能监视，报告在某个状态下花费的时间通常比报告当前状态更重要。快照对于性能监视的价值较小。
There are several parts to performance management to be considered: protocol monitoring, device monitoring (the impact of the new protocol / service activation on the device), network monitoring, and service monitoring (the impact of service activation on the network).
性能管理有几个部分需要考虑：协议监控、设备监控（新协议/服务激活对设备的影响）、网络监控和服务监控（服务激活对网络的影响）。
Certain properties of protocols are useful to monitor. The number of protocol packets received, the number of packets sent, and the number of packets dropped are usually very helpful to operators.
协议的某些属性可用于监视。接收的协议数据包数量、发送的数据包数量和丢弃的数据包数量通常对运营商非常有用。
Packet drops should be reflected in counter variable(s) somewhere that can be inspected -- both from the security point of view and from the troubleshooting point of view.
数据包丢失应该反映在可以检查的某个计数器变量中——无论是从安全角度还是从故障排除角度。
Counter definitions should be unambiguous about what is included in the count and what is not included in the count.
计数器定义应明确计数中包含的内容和计数中未包含的内容。
Consider the expected behaviors for counters -- what is a reasonable maximum value for expected usage? Should they stop counting at the maximum value and retain the maximum value, or should they rollover? How can users determine if a rollover has occurred, and how can users determine if more than one rollover has occurred?
考虑计数器的预期行为——期望使用的合理最大值是什么？它们应该停止在最大值处计数并保留最大值，还是应该滚动？用户如何确定是否发生了滚动，以及用户如何确定是否发生了多个滚动？
Consider whether multiple management applications will share a counter; if so, then no one management application should be allowed to reset the value to zero since this will impact other applications.
考虑多个管理应用程序是否共享一个计数器；如果是，则不允许任何一个管理应用程序将该值重置为零，因为这将影响其他应用程序。
Could events, such as hot-swapping a blade in a chassis, cause discontinuities in counter? Does this make any difference in evaluating the performance of a protocol?
机箱中的刀片热插拔等事件是否会导致计数器中断？这对评估协议的性能有什么影响吗？
The protocol document should make clear the limitations implicit within the protocol and the behavior when limits are exceeded. This should be considered in a data-modeling-independent manner -- what makes managed-protocol sense, not what makes management-protocol-sense. If constraints are not managed-protocol-dependent, then it should be left for the management-protocol data modelers to decide. For example, VLAN identifiers have a range of 1..4095 because of the VLAN standards. A MIB implementing a VLAN table should be able to support 4096 entries because the content being modeled requires it.
协议文件应明确协议中隐含的限制以及超出限制时的行为。这应该以独立于数据建模的方式来考虑——是什么让托管协议有意义，而不是什么让管理协议有意义。如果约束不依赖于管理协议，则应由管理协议数据建模人员决定。例如，由于VLAN标准，VLAN标识符的范围为1..4095。实现VLAN表的MIB应该能够支持4096个条目，因为建模的内容需要它。
Consider whether device performance will be affected by the number of protocol entities being instantiated on the device. Designers of an information model should include information, accessible at runtime, about the maximum number of instances an implementation can support, the current number of instances, and the expected behavior when the current instances exceed the capacity of the implementation or the capacity of the device.
考虑设备性能是否会受到在设备上实例化的协议实体数量的影响。信息模型的设计者应包括在运行时可访问的信息，包括实现可支持的最大实例数、当前实例数以及当前实例超过实现容量或设备容量时的预期行为。
Designers of an information model should model information, accessible at runtime, about the maximum number of protocol entity instances an implementation can support on a device, the current number of instances, and the expected behavior when the current instances exceed the capacity of the device.
信息模型的设计者应该对运行时可访问的信息进行建模，包括实现在设备上可支持的最大协议实体实例数、当前实例数以及当前实例超过设备容量时的预期行为。
Consider whether network performance will be affected by the number of protocol entities being deployed.
考虑网络性能是否会受到部署的协议实体数量的影响。
Consider the capability of determining the operational activity, such as the number of messages in and the messages out, the number of received messages rejected due to format problems, and the expected behaviors when a malformed message is received.
考虑确定操作活动的能力，例如消息中的消息数量和消息输出，由于格式问题而拒绝的接收消息的数量，以及接收到错误消息时的预期行为。
What are the principal performance factors that need to be looked at when measuring the operational performance of the network built using the protocol? Is it important to measure setup times? End-to-end connectivity? Hop-to-hop connectivity? Network throughput?
在测量使用该协议构建的网络的运行性能时，需要考虑哪些主要性能因素？测量设置时间是否重要？端到端连接？跳到跳的连接？网络吞吐量？
What are the principal performance factors that need to be looked at when measuring the performance of a service using the protocol? Is it important to measure application-specific throughput? Client-server associations? End-to-end application quality? Service interruptions? User experience?
在使用协议测量服务性能时，需要考虑哪些主要性能因素？测量特定于应用程序的吞吐量是否重要？客户机-服务器关联？端到端应用程序质量？服务中断？用户体验？
Protocol designers should consider how to monitor and manage security aspects and vulnerabilities of the new protocol.
协议设计者应该考虑如何监控和管理新协议的安全性和脆弱性。
There will be security considerations related to the new protocol. To make it possible for operators to be aware of security-related events, it is recommended that system logs should record events, such as failed logins, but the logs must be secured.
将有与新协议相关的安全考虑。为了使操作员能够了解与安全相关的事件，建议系统日志应记录事件，例如登录失败，但必须对日志进行保护。
Should a system automatically notify operators of every event occurrence, or should an operator-defined threshold control when a notification is sent to an operator?
系统是否应在每次事件发生时自动通知操作员，还是应在向操作员发送通知时由操作员定义阈值控制？
Should certain statistics be collected about the operation of the new protocol that might be useful for detecting attacks, such as the receipt of malformed messages, messages out of order, or messages with invalid timestamps? If such statistics are collected, is it important to count them separately for each sender to help identify the source of attacks?
是否应收集有关新协议操作的某些统计信息，这些信息可能有助于检测攻击，例如接收格式错误的消息、顺序错误的消息或具有无效时间戳的消息？如果收集了此类统计数据，是否有必要对每个发件人分别进行统计，以帮助识别攻击源？
Manageability considerations that are security-oriented might include discussion of the security implications when no monitoring is in place, the regulatory implications of absence of audit-trail or logs in enterprises, exceeding the capacity of logs, and security exposures present in chosen/recommended management mechanisms.
以安全为导向的可管理性考虑因素可能包括讨论未实施监控时的安全影响、企业中缺少审计跟踪或日志的监管影响、超过日志容量以及所选/推荐的管理机制中存在的安全风险。
Consider security threats that may be introduced by management operations. For example, Control and Provisioning of Wireless Access Points (CAPWAP) breaks the structure of monolithic Access Points (APs) into Access Controllers and Wireless Termination Points (WTPs). By using a management interface, internal information that was previously not accessible is now exposed over the network and to management applications and may become a source of potential security threats.
考虑管理操作可能引入的安全威胁。例如，无线接入点（CAPWAP）的控制和配置将单片接入点（AP）的结构分为接入控制器和无线终端点（WTP）。通过使用管理界面，以前无法访问的内部信息现在通过网络和管理应用程序公开，并可能成为潜在安全威胁的来源。
The granularity of access control needed on management interfaces needs to match operational needs. Typical requirements are a role-based access control model and the principle of least privilege, where a user can be given only the minimum access necessary to perform a required task.
管理接口所需的访问控制粒度需要与操作需求相匹配。典型的需求是基于角色的访问控制模型和最小权限原则，其中用户只能获得执行所需任务所需的最小访问权限。
Some operators wish to do consistency checks of access control lists across devices. Protocol designers should consider information models to promote comparisons across devices and across vendors to permit checking the consistency of security configurations.
一些运营商希望跨设备对访问控制列表进行一致性检查。协议设计者应该考虑信息模型，以促进跨设备和跨供应商的比较，以检查安全配置的一致性。
Protocol designers should consider how to provide a secure transport, authentication, identity, and access control that integrates well with existing key and credential management infrastructure. It is a good idea to start with defining the threat model for the protocol, and from that deducing what is required.
协议设计者应该考虑如何提供与现有密钥和证书管理基础设施良好结合的安全传输、认证、身份和访问控制。从定义协议的威胁模型开始是一个好主意，并从中推断需要什么。
Protocol designers should consider how access control lists are maintained and updated.
协议设计者应该考虑如何维护和更新访问控制列表。
Standard SNMP notifications or syslog messages [RFC5424] might already exist, or can be defined, to alert operators to the conditions identified in the security considerations for the new protocol. For example, you can log all the commands entered by the operator using syslog (giving you some degree of audit trail), or you can see who has logged on/off using the Secure SHell Protocol (SSH) and from where; failed SSH logins can be logged using syslog, etc.
标准SNMP通知或系统日志消息[RFC5424]可能已经存在，或者可以定义，以提醒操作员注意新协议的安全注意事项中确定的条件。例如，您可以使用syslog记录操作员输入的所有命令（为您提供一定程度的审核跟踪），或者您可以查看谁使用安全SHell协议（SSH）登录/注销，以及从何处登录；可以使用syslog等记录失败的SSH登录。
An analysis of existing counters might help operators recognize the conditions identified in the security considerations for the new protocol before they can impact the network.
对现有计数器的分析可能有助于操作员在新协议的安全注意事项中确定的条件影响网络之前识别这些条件。
Different management protocols use different assumptions about message security and data-access controls. A protocol designer that recommends using different protocols should consider how security will be applied in a balanced manner across multiple management interfaces. SNMP authority levels and policy are data-oriented, while CLI authority levels and policy are usually command-oriented (i.e., task-oriented). Depending on the management function, sometimes data-oriented or task-oriented approaches make more sense. Protocol designers should consider both data-oriented and task-oriented authority levels and policy.
不同的管理协议对消息安全性和数据访问控制使用不同的假设。建议使用不同协议的协议设计者应该考虑如何安全地跨多个管理接口以安全的方式应用安全性。SNMP权限级别和策略面向数据，而CLI权限级别和策略通常面向命令（即面向任务）。根据管理功能，有时面向数据或面向任务的方法更有意义。协议设计者应该考虑面向数据和面向任务的权限级别和策略。
This document is focused on what a protocol designer should think about and how those considerations might be documented.
本文档主要关注协议设计者应该考虑什么以及如何记录这些注意事项。
This document does not describe interoperability requirements but rather describes practices that are useful to follow when dealing with manageability aspects in IETF documents, so the capitalized keywords from [RFC2119] do not apply here. Any occurrence of words like 'must' or 'should' needs to be interpreted only in the context of their natural, English-language meaning.
本文档不描述互操作性要求，而是描述了在处理IETF文档中的可管理性方面时需要遵循的实践，因此[RFC2119]中大写的关键字在此不适用。出现“必须”或“应该”等词时，仅需根据其自然英语意义进行解释。
A Manageability Considerations section should include discussion of the management and operations topics raised in this document, and when one or more of these topics is not relevant, it would be useful to contain a simple statement explaining why the topic is not relevant for the new protocol. Of course, additional relevant topics should be included as well.
可管理性注意事项部分应包括对本文件中提出的管理和操作主题的讨论，当其中一个或多个主题不相关时，最好包含一个简单的说明，解释该主题与新协议不相关的原因。当然，还应包括其他相关主题。
Existing protocols and data models can provide the management functions identified in the previous section. Protocol designers should consider how using existing protocols and data models might impact network operations.
现有协议和数据模型可以提供上一节中确定的管理功能。协议设计者应该考虑如何使用现有协议和数据模型可能影响网络操作。
A protocol designer may seriously consider the manageability requirements of a new protocol and determine that no management functionality is needed by the new protocol. It would be helpful to those who may update or write extensions to the protocol in the future or to those deploying the new protocol to know the thinking of the working group regarding the manageability of the protocol at the time of its design.
协议设计者可以认真考虑新协议的可管理性要求，并确定新协议不需要管理功能。了解工作组在设计协议时对协议的可管理性的想法，对于那些将来可能更新或编写协议扩展的人，或者部署新协议的人，都是有帮助的。
If there are no new manageability or deployment considerations, it is recommended that a Manageability Considerations section contain a simple statement such as, "There are no new manageability requirements introduced by this document," and a brief explanation of why that is the case. The presence of such a Manageability Considerations section would indicate to the reader that due consideration has been given to manageability and operations.
如果没有新的可管理性或部署注意事项，建议在可管理性注意事项部分包含一条简单的语句，如“本文档没有引入新的可管理性要求”，并简要解释为什么会出现这种情况。这样一个可管理性注意事项部分的存在将向读者表明，已经对可管理性和操作给予了适当的考虑。
In the case where the new protocol is an extension and the base protocol discusses all the relevant operational and manageability considerations, it would be helpful to point out the considerations section in the base document.
如果新协议是一个扩展，而基础协议讨论了所有相关的操作和可管理性注意事项，那么在基础文档中指出注意事项部分会有所帮助。
If a protocol designer develops a Manageability Considerations section for a new protocol, it is recommended that the section be placed immediately before the Security Considerations section. Reviewers interested in such sections could find it easily, and this placement could simplify the development of tools to detect the presence of such a section.
如果协议设计者为新协议开发了可管理性注意事项部分，建议将该部分放在安全注意事项部分之前。对这类章节感兴趣的评审员可以很容易地找到它，这种布局可以简化检测这类章节存在的工具的开发。
This document is informational and provides guidelines for considering manageability and operations. It introduces no new security concerns.
本文档仅供参考，并提供了考虑可管理性和操作的指南。它没有引入新的安全问题。
The provision of a management portal to a network device provides a doorway through which an attack on the device may be launched. Making the protocol under development be manageable through a management protocol creates a vulnerability to a new source of attacks. Only management protocols with adequate security apparatus, such as authentication, message integrity checking, and authorization, should be used.
向网络设备提供管理门户提供了一个入口，通过该入口可以发起对该设备的攻击。通过管理协议使正在开发的协议易于管理会造成新攻击源的漏洞。只应使用具有足够安全设备的管理协议，如身份验证、消息完整性检查和授权。
A standard description of the manageable knobs and whistles on a protocol makes it easier for an attacker to understand what they may try to control and how to tweak it.
协议上可管理旋钮和口哨的标准描述使攻击者更容易理解他们可能试图控制的内容以及如何调整。
A well-designed protocol is usually more stable and secure. A protocol that can be managed and inspected offers the operator a better chance of spotting and quarantining any attacks. Conversely, making a protocol easy to inspect is a risk if the wrong person inspects it.
设计良好的协议通常更稳定、更安全。可以管理和检查的协议为操作员提供了更好的发现和隔离任何攻击的机会。相反，如果错误的人检查协议，则使其易于检查是一种风险。
If security events cause logs and/or notifications/alerts, a concerted attack might be able to be mounted by causing an excess of these events. In other words, the security-management mechanisms could constitute a security vulnerability. The management of security aspects is important (see Section 3.7).
如果安全事件导致日志和/或通知/警报，则可能会通过导致这些事件过多而引发协同攻击。换句话说，安全管理机制可能构成安全漏洞。安全方面的管理很重要（见第3.7节）。
This document started from an earlier document edited by Adrian Farrel, which itself was based on work exploring the need for Manageability Considerations sections in all Internet-Drafts produced within the Routing Area of the IETF. That earlier work was produced by Avri Doria, Loa Andersson, and Adrian Farrel, with valuable feedback provided by Pekka Savola and Bert Wijnen.
本文件始于阿德里安·法雷尔（Adrian Farrel）编辑的早期文件，该文件本身基于在IETF路由区域内产生的所有互联网草案中探索可管理性考虑部分的需要的工作。早期的作品由Avri Doria、Loa Andersson和Adrian Farrel制作，Pekka Savola和Bert Wijnen提供了宝贵的反馈。
Some of the discussion about designing for manageability came from private discussions between Dan Romascanu, Bert Wijnen, Juergen Schoenwaelder, Andy Bierman, and David Harrington.
关于可管理性设计的一些讨论来自Dan Romascanu、Bert Wijnen、Juergen Schoenwaeld、Andy Bierman和David Harrington之间的私人讨论。
Thanks to reviewers who helped fashion this document, including Harald Alvestrand, Ron Bonica, Brian Carpenter, Benoit Claise, Adrian Farrel, David Kessens, Dan Romascanu, Pekka Savola, Juergen Schoenwaelder, Bert Wijnen, Ralf Wolter, and Lixia Zhang.
感谢帮助制作本文件的评论家，包括哈拉尔·阿尔维斯特朗、罗恩·博尼卡、布赖恩·卡彭特、贝诺特·克莱斯、阿德里安·法雷尔、大卫·凯森斯、丹·罗马斯坎努、佩卡·萨沃拉、尤尔根·斯肯瓦埃尔德、伯特·维恩、拉尔夫·沃尔特和张丽霞。
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[RFC1034]Mockapetris，P.，“域名-概念和设施”，STD 13，RFC 1034，1987年11月。
[RFC1052] Cerf, V., "IAB recommendations for the development of Internet network management standards", RFC 1052, April 1988.
[RFC1052]Cerf，V.，“IAB关于制定互联网网络管理标准的建议”，RFC1052，1988年4月。
[RFC1958] Carpenter, B., "Architectural Principles of the Internet", RFC 1958, June 1996.
[RFC1958]Carpenter，B.，“互联网的建筑原理”，RFC19581996年6月。
[RFC2113] Katz, D., "IP Router Alert Option", RFC 2113, February 1997.
[RFC2113]Katz，D.，“IP路由器警报选项”，RFC 21131997年2月。
[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月。
[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[RFC2205]Braden，B.，Zhang，L.，Berson，S.，Herzog，S.，和S.Jamin，“资源预留协议（RSVP）——第1版功能规范”，RFC 22052997年9月。
[RFC2439] Villamizar, C., Chandra, R., and R. Govindan, "BGP Route Flap Damping", RFC 2439, November 1998.
[RFC2439]Villamizar，C.，Chandra，R.，和R.Govindan，“BGP路线襟翼阻尼”，RFC 2439，1998年11月。
[RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
[RFC2578]McCloghrie，K.，Ed.，Perkins，D.，Ed.，和J.Schoenwaeld，Ed.“管理信息的结构版本2（SMIv2）”，STD 58，RFC 2578，1999年4月。
[RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", RFC 2711, October 1999.
[RFC2711]帕特里奇，C.和A.杰克逊，“IPv6路由器警报选项”，RFC27111999年10月。
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
[RFC2865]Rigney，C.，Willens，S.，Rubens，A.，和W.Simpson，“远程认证拨入用户服务（RADIUS）”，RFC 28652000年6月。
[RFC2975] Aboba, B., Arkko, J., and D. Harrington, "Introduction to Accounting Management", RFC 2975, October 2000.
[RFC2975]Aboba，B.，Arkko，J.，和D.Harrington，“会计管理导论”，RFC 29752000年10月。
[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月。
[RFC3084] Chan, K., Seligson, J., Durham, D., Gai, S., McCloghrie, K., Herzog, S., Reichmeyer, F., Yavatkar, R., and A. Smith, "COPS Usage for Policy Provisioning (COPS-PR)", RFC 3084, March 2001.
[RFC3084]Chan，K.，Seligson，J.，Durham，D.，Gai，S.，McCloghrie，K.，Herzog，S.，Reichmeyer，F.，Yavatkar，R.，和A.Smith，“策略供应的COPS使用（COPS-PR）”，RFC 30842001年3月。
[RFC3139] Sanchez, L., McCloghrie, K., and J. Saperia, "Requirements for Configuration Management of IP-based Networks", RFC 3139, June 2001.
[RFC3139]Sanchez，L.，McCloghrie，K.，和J.Saperia，“基于IP网络的配置管理要求”，RFC 3139，2001年6月。
[RFC3198] Westerinen, A., Schnizlein, J., Strassner, J., Scherling, M., Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry, J., and S. Waldbusser, "Terminology for Policy-Based Management", RFC 3198, November 2001.
[RFC3198]威斯特林，A.，施尼兹莱因，J.，斯特拉斯纳，J.，舍林，M.，奎因，B.，赫尔佐格，S.，休恩，A.，卡尔森，M.，佩里，J.，和S.瓦尔德布瑟，“基于政策的管理术语”，RFC 3198，2001年11月。
[RFC3290] Bernet, Y., Blake, S., Grossman, D., and A. Smith, "An Informal Management Model for Diffserv Routers", RFC 3290, May 2002.
[RFC3290]Bernet，Y.，Blake，S.，Grossman，D.，和A.Smith，“区分服务路由器的非正式管理模型”，RFC 32902002年5月。
[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002.
[RFC3410]Case，J.，Mundy，R.，Partain，D.，和B.Stewart，“互联网标准管理框架的介绍和适用性声明”，RFC 34102002年12月。
[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月。
[RFC3460] Moore, B., "Policy Core Information Model (PCIM) Extensions", RFC 3460, January 2003.
[RFC3460]Moore，B.，“政策核心信息模型（PCIM）扩展”，RFC 3460，2003年1月。
[RFC3535] Schoenwaelder, J., "Overview of the 2002 IAB Network Management Workshop", RFC 3535, May 2003.
[RFC3535]Schoenwaeld，J.，“2002年IAB网络管理研讨会概述”，RFC 3535，2003年5月。
[RFC3585] Jason, J., Rafalow, L., and E. Vyncke, "IPsec Configuration Policy Information Model", RFC 3585, August 2003.
[RFC3585]Jason，J.，Rafalow，L.，和E.Vyncke，“IPsec配置策略信息模型”，RFC 3585，2003年8月。
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[RFC3588]Calhoun，P.，Loughney，J.，Guttman，E.，Zorn，G.，和J.Arkko，“直径基础协议”，RFC 3588，2003年9月。
[RFC3644] Snir, Y., Ramberg, Y., Strassner, J., Cohen, R., and B. Moore, "Policy Quality of Service (QoS) Information Model", RFC 3644, November 2003.
[RFC3644]Snir，Y.，Ramberg，Y.，Strassner，J.，Cohen，R.，和B.Moore，“政策服务质量（QoS）信息模型”，RFC 36442003年11月。
[RFC3670] Moore, B., Durham, D., Strassner, J., Westerinen, A., and W. Weiss, "Information Model for Describing Network Device QoS Datapath Mechanisms", RFC 3670, January 2004.
[RFC3670]Moore，B.，Durham，D.，Strassner，J.，Westerinen，A.，和W.Weiss，“描述网络设备QoS数据路径机制的信息模型”，RFC 3670，2004年1月。
[RFC3805] Bergman, R., Lewis, H., and I. McDonald, "Printer MIB v2", RFC 3805, June 2004.
[RFC3805]伯格曼，R.，刘易斯，H.，和I.麦克唐纳，“打印机MIB v2”，RFC 3805，2004年6月。
[RFC4741] Enns, R., "NETCONF Configuration Protocol", RFC 4741, December 2006.
[RFC4741]Enns，R.，“网络配置协议”，RFC 47412006年12月。
[RFC5101] Claise, B., "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information", RFC 5101, January 2008.
[RFC5101]Claise，B.，“用于交换IP流量信息的IP流量信息导出（IPFIX）协议规范”，RFC 5101，2008年1月。
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008.
[RFC5321]Klensin，J.，“简单邮件传输协议”，RFC 53212008年10月。
[RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009.
[RFC5424]Gerhards，R.，“系统日志协议”，RFC 54242009年3月。
[W3C.REC-xmlschema-0-20010502] Fallside, D., "XML Schema Part 0: Primer", World Wide Web Consortium FirstEdition REC-xmlschema-0-20010502, May 2001, <http://www.w3.org/TR/2001/REC-xmlschema-0-20010502>.
[W3C.REC-xmlschema-0-20010502]Fallside，D.，“XML模式第0部分：入门”，万维网联盟第一版REC-xmlschema-0-20010502，2001年5月<http://www.w3.org/TR/2001/REC-xmlschema-0-20010502>.
This appendix provides a quick checklist of issues that protocol designers should expect operations and management expert reviewers to look for when reviewing a document being proposed for consideration as a protocol standard.
本附录提供了一份快速检查表，列出了协议设计人员在审查拟作为协议标准考虑的文件时，应期望运营和管理专家审查人员查找的问题。
1. Has deployment been discussed? See Section 2.1.
1. 是否讨论了部署？见第2.1节。
* Does the document include a description of how this protocol or technology is going to be deployed and managed?
* 该文档是否包括如何部署和管理该协议或技术的描述？
* Is the proposed specification deployable? If not, how could it be improved?
* 建议的规范是否可部署？如果没有，如何改进？
* Does the solution scale well from the operational and management perspective? Does the proposed approach have any scaling issues that could affect usability for large-scale operation?
* 从运营和管理角度来看，该解决方案是否具有良好的可扩展性？提议的方法是否存在任何可能影响大规模操作可用性的扩展问题？
* Are there any coexistence issues?
* 是否存在共存问题？
2. Has installation and initial setup been discussed? See Section 2.2.
2. 是否讨论了安装和初始设置？见第2.2节。
* Is the solution sufficiently configurable?
* 解决方案是否足够可配置？
* Are configuration parameters clearly identified?
* 配置参数是否明确标识？
* Are configuration parameters normalized?
* 配置参数是否规范化？
* Does each configuration parameter have a reasonable default value?
* 每个配置参数是否都有合理的默认值？
* Will configuration be pushed to a device by a configuration manager, or pulled by a device from a configuration server?
* 配置是由配置管理器推送到设备上，还是由设备从配置服务器拉到设备上？
* How will the devices and managers find and authenticate each other?
* 设备和管理器将如何相互查找和验证？
3. Has the migration path been discussed? See Section 2.3.
3. 是否讨论了迁移路径？见第2.3节。
* Are there any backward compatibility issues?
* 是否存在任何向后兼容性问题？
4. Have the Requirements on other protocols and functional components been discussed? See Section 2.4.
4. 是否讨论了其他协议和功能组件的要求？见第2.4节。
* What protocol operations are expected to be performed relative to the new protocol or technology, and what protocols and data models are expected to be in place or recommended to ensure for interoperable management?
* 相对于新协议或技术，预计将执行哪些协议操作，以及预计将实施或建议哪些协议和数据模型以确保互操作管理？
5. Has the impact on network operation been discussed? See Section 2.5.
5. 是否讨论了对网络运营的影响？见第2.5节。
* Will the new protocol significantly increase traffic load on existing networks?
* 新协议会显著增加现有网络上的流量负载吗？
* Will the proposed management for the new protocol significantly increase traffic load on existing networks?
* 新协议的拟议管理是否会显著增加现有网络上的流量负载？
* How will the new protocol impact the behavior of other protocols in the network? Will it impact performance (e.g., jitter) of certain types of applications running in the same network?
* 新协议将如何影响网络中其他协议的行为？它是否会影响在同一网络中运行的某些类型的应用程序的性能（例如抖动）？
* Does the new protocol need supporting services (e.g., DNS or Authentication, Authorization, and Accounting - AAA) added to an existing network?
* 新协议是否需要向现有网络添加支持服务（例如DNS或身份验证、授权和记帐-AAA）？
6. Have suggestions for verifying correct operation been discussed? See Section 2.6.
6. 是否讨论了验证正确操作的建议？见第2.6节。
* How can one test end-to-end connectivity and throughput?
* 如何测试端到端连接和吞吐量？
* Which metrics are of interest?
* 哪些指标值得关注？
* Will testing have an impact on the protocol or the network?
* 测试会对协议或网络产生影响吗？
7. Has management interoperability been discussed? See Section 3.1.
7. 是否讨论了管理互操作性？见第3.1节。
* Is a standard protocol needed for interoperable management?
* 互操作管理是否需要标准协议？
* Is a standard information or data model needed to make properties comparable across devices from different vendors?
* 是否需要标准信息或数据模型来使不同供应商的设备的属性具有可比性？
8. Are there fault or threshold conditions that should be reported? See Section 3.3.
8. 是否存在应报告的故障或阈值条件？见第3.3节。
* Does specific management information have time utility?
* 具体的管理信息是否具有时间效用？
* Should the information be reported by notifications? Polling? Event-driven polling?
* 是否应通过通知报告信息？投票事件驱动轮询？
* Is notification throttling discussed?
* 是否讨论了通知限制？
* Is there support for saving state that could be used for root cause analysis?
* 是否支持保存可用于根本原因分析的状态？
9. Is configuration discussed? See Section 3.4.
9. 是否讨论了配置？见第3.4节。
* Are configuration defaults and default modes of operation considered?
* 是否考虑了配置默认值和默认操作模式？
* Is there discussion of what information should be preserved across reboots of the device or the management system? Can devices realistically preserve this information through hard reboots where physical configuration might change (e.g., cards might be swapped while a chassis is powered down)?
* 是否讨论了在重新启动设备或管理系统时应保留哪些信息？在物理配置可能发生更改的情况下（例如，在机箱断电时可能交换卡），设备是否可以通过硬重启来实际保留此信息？
Do you anticipate any manageability issues with the specification?
您是否预计该规范会出现任何可管理性问题？
1. Is management interoperability discussed? See Section 3.1.
1. 是否讨论了管理互操作性？见第3.1节。
* Will it use centralized or distributed management?
* 它将使用集中式管理还是分布式管理？
* Will it require remote and/or local management applications?
* 它是否需要远程和/或本地管理应用程序？
* Are textual or graphical user interfaces required?
* 是否需要文本或图形用户界面？
* Is textual or binary format for management information preferred?
* 管理信息首选文本格式还是二进制格式？
2. Is management information discussed? See Section 3.2.
2. 是否讨论了管理信息？见第3.2节。
* What is the minimal set of management (configuration, faults, performance monitoring) objects that need to be instrumented in order to manage the new protocol?
* 管理新协议所需的最小管理（配置、故障、性能监视）对象集是什么？
3. Is fault management discussed? See Section 3.3.
3. 是否讨论了故障管理？见第3.3节。
* Is Liveness Detection and Monitoring discussed?
* 是否讨论了活性检测和监控？
* Does the solution have failure modes that are difficult to diagnose or correct? Are faults and alarms reported and logged?
* 解决方案是否存在难以诊断或纠正的故障模式？是否报告并记录了故障和警报？
4. Is configuration management discussed? See Section 3.4.
4. 是否讨论了配置管理？见第3.4节。
* Is protocol state information exposed to the user? How? Are significant state transitions logged?
* 协议状态信息是否向用户公开？怎样是否记录了重要的状态转换？
5. Is accounting management discussed? See Section 3.5.
5. 是否讨论了会计管理？见第3.5节。
6. Is performance management discussed? See Section 3.6.
6. 是否讨论了绩效管理？见第3.6节。
* Does the protocol have an impact on network traffic and network devices? Can performance be measured?
* 协议是否对网络流量和网络设备有影响？绩效可以衡量吗？
* Is protocol performance information exposed to the user?
* 协议性能信息是否向用户公开？
7. Is security management discussed? See Section 3.7.
7. 是否讨论了安全管理？见第3.7节。
* Does the specification discuss how to manage aspects of security, such as access controls, managing key distribution, etc.
* 规范是否讨论了如何管理安全方面，如访问控制、管理密钥分发等。
Is an operational considerations and/or manageability section part of the document?
操作注意事项和/或可管理性部分是否为文件的一部分？
Does the proposed protocol have a significant operational impact on the Internet?
提议的协议是否对互联网的运营有重大影响？
Is there proof of implementation and/or operational experience?
是否有实施和/或运营经验的证明？
Author's Address
作者地址
David Harrington HuaweiSymantec USA 20245 Stevens Creek Blvd Cupertino, CA 95014 USA
David Harrington HuaweiSymantec USA 20245美国加利福尼亚州库比蒂诺史蒂文斯溪大道95014号
Phone: +1 603 436 8634
EMail: ietfdbh@comcast.net
Phone: +1 603 436 8634
EMail: ietfdbh@comcast.net