Network Working Group J. Schoenwaelder
Request for Comments: 3535 International University Bremen
Category: Informational May 2003
Network Working Group J. Schoenwaelder
Request for Comments: 3535 International University Bremen
Category: Informational May 2003
Overview of the 2002 IAB Network Management Workshop
2002年IAB网络管理研讨会概述
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) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
Abstract
摘要
This document provides an overview of a workshop held by the Internet Architecture Board (IAB) on Network Management. The workshop was hosted by CNRI in Reston, VA, USA on June 4 thru June 6, 2002. The goal of the workshop was to continue the important dialog started between network operators and protocol developers, and to guide the IETFs focus on future work regarding network management. This report summarizes the discussions and lists the conclusions and recommendations to the Internet Engineering Task Force (IETF) community.
本文件概述了互联网体系结构委员会（IAB）举办的网络管理研讨会。研讨会由CNRI于2002年6月4日至6月6日在美国弗吉尼亚州雷斯顿主办。研讨会的目标是继续网络运营商和协议开发人员之间开始的重要对话，并指导IETF关注网络管理方面的未来工作。本报告总结了讨论情况，并向互联网工程任务组（IETF）社区列出了结论和建议。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Network Management Technologies . . . . . . . . . . . . . . . 3
2.1 SNMP / SMI / MIBs . . . . . . . . . . . . . . . . . . . 4
2.2 COPS-PR / SPPI / PIBs . . . . . . . . . . . . . . . . . 5
2.3 CIM / MOF / UML / PCIM . . . . . . . . . . . . . . . . . 6
2.4 CLI / TELNET / SSH . . . . . . . . . . . . . . . . . . . 7
2.5 HTTP / HTML . . . . . . . . . . . . . . . . . . . . . . 8
2.6 XML . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3. Operator Requirements . . . . . . . . . . . . . . . . . . . . 10
4. SNMP Framework Discussions . . . . . . . . . . . . . . . . . . 12
5. Consolidated Observations . . . . . . . . . . . . . . . . . . 14
6. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 16
7. Security Considerations . . . . . . . . . . . . . . . . . . . 17
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
Normative References . . . . . . . . . . . . . . . . . . . . . . 18
Informative References . . . . . . . . . . . . . . . . . . . . . 18
Appendix - Participants . . . . . . . . . . . . . . . . . . . . . 19
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 20
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Network Management Technologies . . . . . . . . . . . . . . . 3
2.1 SNMP / SMI / MIBs . . . . . . . . . . . . . . . . . . . 4
2.2 COPS-PR / SPPI / PIBs . . . . . . . . . . . . . . . . . 5
2.3 CIM / MOF / UML / PCIM . . . . . . . . . . . . . . . . . 6
2.4 CLI / TELNET / SSH . . . . . . . . . . . . . . . . . . . 7
2.5 HTTP / HTML . . . . . . . . . . . . . . . . . . . . . . 8
2.6 XML . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3. Operator Requirements . . . . . . . . . . . . . . . . . . . . 10
4. SNMP Framework Discussions . . . . . . . . . . . . . . . . . . 12
5. Consolidated Observations . . . . . . . . . . . . . . . . . . 14
6. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 16
7. Security Considerations . . . . . . . . . . . . . . . . . . . 17
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
Normative References . . . . . . . . . . . . . . . . . . . . . . 18
Informative References . . . . . . . . . . . . . . . . . . . . . 18
Appendix - Participants . . . . . . . . . . . . . . . . . . . . . 19
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 20
The IETF has started several activities in the operations and management area to develop technologies and standards that aim to help network operators manage their networks. The main network management technologies currently being developed within the IETF are:
IETF在运营和管理领域开展了多项活动，以开发旨在帮助网络运营商管理其网络的技术和标准。IETF中目前正在开发的主要网络管理技术有：
o The Simple Network Management Protocol (SNMP) [RFC3410] was created in the late 1980s. The initial version (SNMPv1) is widely deployed, while the latest version (SNMPv3), which addresses security requirements, is just beginning to gain significant deployment.
o 简单网络管理协议（SNMP）[RFC3410]创建于20世纪80年代末。最初的版本（SNMPv1）被广泛部署，而最新的版本（SNMPv3）解决了安全性需求，刚刚开始获得大量部署。
o The Common Information Model (CIM) [CIM], developed by the Distributed Management Task Force (DMTF), has been extended in cooperation with the DMTF to describe high-level policies as rule sets (PCIM) [RFC3060]. Mappings of the CIM policy extensions to LDAP schemas have been defined and work continues to define specific schema extension for QoS and security policies.
o 由分布式管理任务组（DMTF）开发的公共信息模型（CIM）[CIM]与DMTF合作进行了扩展，以将高级策略描述为规则集（PCIM）[RFC3060]。CIM策略扩展到LDAP模式的映射已经定义，并将继续为QoS和安全策略定义特定的模式扩展。
o The Common Open Policy Service (COPS) [RFC2748] protocol has been extended to provision configuration information on devices (COPS-PR) [RFC3084]. Work is underway to define data definitions for specific services such as Differentiated Services (DiffServ).
o 公共开放策略服务（COPS）[RFC2748]协议已扩展到提供设备配置信息（COPS-PR）[RFC3084]。正在为特定服务定义数据定义，如区分服务（DiffServ）。
During 2001, several meetings have been organized at various events (NANOG-22 May 2001, RIPE-40 October 2001, LISA-XV December 2001, IETF-52 December 2001) to start a direct dialog between network operators and protocol developers. During these meetings, several operators have expressed their opinion that the developments in the IETF do not really address their requirements, especially for configuration management. This naturally leads to the question of whether the IETF should refocus resources, and which strategic future activities in the operations and management area should be started.
在2001年期间，在各种活动中组织了几次会议（2001年5月22日NANOG-22、2001年10月40日RIME-40、2001年12月LISA-XV、2001年12月IETF-52），以便在网络运营商和协议开发商之间展开直接对话。在这些会议期间，一些运营商表示了他们的观点，即IETF中的开发并没有真正满足他们的需求，特别是配置管理方面的需求。这自然会导致IETF是否应该重新集中资源，以及应该在运营和管理领域启动哪些战略性未来活动的问题。
The Internet Architecture Board (IAB), on June 4 thru June 6, 2002, held an invitational workshop on network management. The goal of the workshop was to continue the important dialog started between network operators and protocol developers, and to guide the IETFs focus on future work regarding network management.
互联网架构委员会（IAB）于2002年6月4日至6月6日举办了一次网络管理邀请研讨会。研讨会的目标是继续网络运营商和协议开发人员之间开始的重要对话，并指导IETF关注网络管理方面的未来工作。
The workshop started with two breakout session to (a) identify a list of technologies relevant for network management together with their strengths and weaknesses, and to (b) identify the most important operator needs. The results of these discussions are documented in Section 2 and Section 3. During the following discussions, many more specific characteristics of the current SNMP framework were identified. These discussions are documented in Section 4. Section 5 defines a combined feature list that was developed during the discussions following the breakout sessions. Section 6 gives concrete recommendations to the IETF.
研讨会从两个分组会议开始：（a）确定与网络管理相关的技术列表及其优缺点，以及（b）确定最重要的运营商需求。这些讨论的结果记录在第2节和第3节中。在下面的讨论中，确定了当前SNMP框架的许多更具体的特征。这些讨论记录在第4节中。第5节定义了在分组会议之后的讨论中开发的组合功能列表。第6节给出了IETF的具体建议。
The following text makes no explicit distinction between different versions of SNMP. For the majority of the SNMP related statements, the protocol version is irrelevant. Nevertheless, some statements are more applicable to SNMPv1/SNMPv2c environments, while other statements (especially those concerned with security) are more applicable to SNMPv3 environments.
以下文本没有明确区分不同版本的SNMP。对于大多数与SNMP相关的语句，协议版本是不相关的。尽管如此，有些语句更适用于SNMPv1/SNMPv2c环境，而其他语句（特别是与安全相关的语句）更适用于SNMPv3环境。
During the breakout sessions, the protocol developers assembled a list of the various network management technologies that are available or under active development. For each technology, a list of strong (+) and weak (-) points were identified. There are also some characteristics which appear to be neutral (o).
在分组会议期间，协议开发人员汇总了可用或正在积极开发的各种网络管理技术的列表。对于每种技术，都确定了一系列的优点（+）和缺点（-）。还有一些特性看起来是中性的（o）。
The list does not attempt to be complete. Focus was given to IETF specific technologies (SNMP, COPS-PR, PCIM) and widely used proprietary technologies (CLI, HTTP/HTML, XML). The existence of other generic management technologies (such as TL1, CORBA, CMIP/GDMO,
该列表不会试图完成。重点关注IETF特定技术（SNMP、COPS-PR、PCIM）和广泛使用的专有技术（CLI、HTTP/HTML、XML）。其他通用管理技术（如TL1、CORBA、CMIP/GDMO、，
TMN) or specific management technologies for specific problem domains (such as RADIUS, DHCP, BGP, OSPF) were acknowledged, but were not the focus of discussion.
TMN）或特定问题域（如RADIUS、DHCP、BGP、OSPF）的特定管理技术得到了承认，但不是讨论的重点。
The SNMP management technology was created in the late 1980s and has since been widely implemented and deployed in the Internet. There is lots of implementational and operational experience, and the characteristics of the technology are thus well understood.
SNMP管理技术创建于20世纪80年代末，此后已在Internet上广泛实施和部署。有很多实现和操作经验，因此对该技术的特点有很好的理解。
+ SNMP works reasonably well for device monitoring. The stateless nature of SNMP is useful for statistical and status polling.
+ SNMP在设备监控方面运行良好。SNMP的无状态特性对于统计和状态轮询非常有用。
+ SNMP is widely deployed for basic monitoring. Some core MIB modules, such as the IF-MIB [RFC2863], are implemented on most networking devices.
+ SNMP广泛用于基本监控。一些核心MIB模块，如IF-MIB[RFC2863]，在大多数网络设备上实现。
+ There are many well defined proprietary MIB modules developed by network device vendors to support their management products.
+ 网络设备供应商开发了许多定义良好的专有MIB模块，以支持其管理产品。
+ SNMP is an important data source for systems that do event correlation, alarm detection, and root cause analysis.
+ SNMP是执行事件关联、报警检测和根本原因分析的系统的重要数据源。
o SNMP requires applications to be useful. SNMP was, from its early days, designed as a programmatic interface between management applications and devices. As such, using SNMP without management applications or smart tools appears to be more complicated.
o SNMP要求应用程序有用。从早期开始，SNMP就被设计为管理应用程序和设备之间的编程接口。因此，在没有管理应用程序或智能工具的情况下使用SNMP似乎更加复杂。
o Standardized MIB modules often lack writable MIB objects which can be used for configuration, and this leads to a situation where the interesting writable objects exist in proprietary MIB modules.
o 标准化的MIB模块通常缺少可用于配置的可写MIB对象，这导致在专有MIB模块中存在有趣的可写对象。
- There are scaling problems with regard to the number of objects in a device. While SNMP provides reasonable performance for the retrieval of a small amount of data from many devices, it becomes rather slow when retrieving large amounts of data (such as routing tables) from a few devices.
- 设备中的对象数量存在缩放问题。虽然SNMP为从许多设备检索少量数据提供了合理的性能，但在从少数设备检索大量数据（如路由表）时，它会变得相当缓慢。
- There is too little deployment of writable MIB modules. While there are some notable exceptions in areas, such as cable modems where writable MIB modules are essential, it appears that router equipment is usually not fully configurable via SNMP.
- 可写MIB模块的部署太少。虽然在某些领域存在一些明显的例外，例如电缆调制解调器，其中可写MIB模块是必不可少的，但路由器设备似乎通常不能通过SNMP完全配置。
- The SNMP transactional model and the protocol constraints make it more complex to implement MIBs, as compared to the implementation of commands of a command line interface interpreter. A logical operation on a MIB can turn into a sequence of SNMP interactions
- 与命令行接口解释器命令的实现相比，SNMP事务模型和协议约束使得实现MIB更加复杂。MIB上的逻辑操作可以转变为一系列SNMP交互
where the implementation has to maintain state until the operation is complete, or until a failure has been determined. In case of a failure, a robust implementation must be smart enough to roll the device back into a consistent state.
其中，实现必须保持状态，直到操作完成，或直到确定故障。在出现故障的情况下，健壮的实现必须足够智能，以便将设备回滚到一致的状态。
- SNMP does not support easy retrieval and playback of configurations. One part of the problem is that it is not easy to identify configuration objects. Another part of the problem is that the naming system is very specific and physical device reconfigurations can thus break the capability to play back a previous configuration.
- SNMP不支持轻松检索和回放配置。问题的一部分是，识别配置对象并不容易。问题的另一部分是命名系统非常具体，因此物理设备重新配置可能会破坏回放以前配置的能力。
- There is often a semantic mismatch between the task-oriented view of the world usually preferred by operators and the data-centric view of the world provided by SNMP. Mapping from a task-oriented view to the data-centric view often requires some non-trivial code on the management application side.
- 运营商通常喜欢的面向任务的世界视图与SNMP提供的以数据为中心的世界视图之间常常存在语义不匹配。从面向任务的视图到以数据为中心的视图的映射通常需要管理应用程序端的一些非常重要的代码。
- Several standardized MIB modules lack a description of high-level procedures. It is often not obvious from reading the MIB modules how certain high-level tasks are accomplished, which leads to several different ways to achieve the same goal, which increases costs and hinders interoperability.
- 一些标准化的MIB模块缺少对高级过程的描述。通过阅读MIB模块，通常不清楚某些高级任务是如何完成的，这会导致实现同一目标的几种不同方式，从而增加成本并阻碍互操作性。
A more detailed discussion about the SNMP management technology can be found in Section 4.
有关SNMP管理技术的更详细讨论，请参见第4节。
The COPS protocol [RFC2748] was defined in the late 1990s to support policy control over QoS signaling protocols. The COPS-PR extension allows provision policy information on devises.
COPS协议[RFC2748]定义于20世纪90年代末，以支持对QoS信令协议的策略控制。COPS-PR扩展允许提供有关设备的政策信息。
+ COPS-PR allows high-level transactions for single devices, including deleting one configuration and replacing it with another.
+ COPS-PR允许对单个设备进行高级事务处理，包括删除一个配置并替换为另一个配置。
+ COPS-PRs non-overlapping instance namespace normally ensures that no other manager can corrupt a specific configuration. All transactions for a given instance namespace are required to be executed in-order.
+ COPS PRs非重叠实例命名空间通常确保没有其他管理器会损坏特定配置。给定实例命名空间的所有事务都需要按顺序执行。
+ Both manager and device states are completely synchronized with one another at all times. If there is a failure in communication, the state is resynchronized when the network is operating properly again and the device's network configuration is valid.
+ 管理器和设备状态始终彼此完全同步。如果通信出现故障，当网络再次正常运行且设备的网络配置有效时，状态将重新同步。
+ The atomicity of transactions is well-defined. If there is any failure in a transaction, that specific failure is reported to the manager, and the local configuration is supposed to be automatically rolled-back to the state of the last "good" transaction.
+ 事务的原子性定义良好。如果事务中存在任何故障，则该特定故障将报告给管理器，并且本地配置应自动回滚到上一个“良好”事务的状态。
+ Capability reporting is part of the framework PIB which must be supported by COPS-PR implementations. This allows management applications to adapt to the capabilities present on a device.
+ 能力报告是框架PIB的一部分，必须得到COPS-PR实施的支持。这允许管理应用程序适应设备上的功能。
+ The focus of COPS-PR is configuration, and the protocol has been optimized for this purpose (by using for example TCP as a transport mechanism).
+ COPS-PR的重点是配置，并为此目的对协议进行了优化（例如使用TCP作为传输机制）。
o Only a single manager is allowed to have control, at any point in time, for a given subject category on a device. (The subject category maps to a COPS Client-Type.) This single manager assumption simplifies the protocol as it makes it easier to maintain shared state.
o 在任何时间点，只有一个管理员可以控制设备上给定的主题类别。（主题类别映射到COPS客户端类型。）此单一管理器假设简化了协议，因为它更容易维护共享状态。
o Similar to SNMP, COPS-PR requires applications to be useful since it is also designed as a programmatic interface between management applications and devices.
o 与SNMP类似，COPS-PR要求应用程序有用，因为它还被设计为管理应用程序和设备之间的编程接口。
- As of the time of the meeting, there are no standardized PIB modules.
- 截至会议召开时，还没有标准化的PIB模块。
- Compared to SNMP, there is not yet enough experience to understand the strong and weak aspects of the protocol in operational environments.
- 与SNMP相比，还没有足够的经验来理解操作环境中协议的优缺点。
- COPS-PR does not support easy retrieval and playback of configurations. The reasons are similar as for SNMP.
- COPS-PR不支持轻松检索和回放配置。原因与SNMP类似。
- The COPS-PR view of the world is data-centric, similar to SNMP's view of the world. A mapping from the data-centric view to a task-oriented view and vice versa, has similar complexities as with SNMP.
- COPS-PR的世界观是以数据为中心的，类似于SNMP的世界观。从以数据为中心的视图到面向任务的视图的映射（反之亦然）与SNMP具有类似的复杂性。
The development of the Common Information Model (CIM) [CIM] started in the DMTF in the mid 1990s. The development follows a top-down approach where core classes are defined first and later extended to model specific services. The DMTF and the IETF jointly developed policy extensions of the CIM, known as PCIM [RFC3060].
公共信息模型（CIM）[CIM]的开发始于20世纪90年代中期的DMTF。开发遵循自顶向下的方法，首先定义核心类，然后扩展到特定于模型的服务。DMTF和IETF联合开发了CIM的策略扩展，称为PCIM[RFC3060]。
+ The CIM technology generally follows principles of object-orientation with full support of methods on data objects, which is not available in SNMP or COPS-PR.
+ CIM技术通常遵循面向对象的原则，完全支持数据对象上的方法，这在SNMP或COPS-PR中是不可用的。
+ The MOF format allows representation of instances in a common format. No such common format exists for SNMP or COPS-PR. It is of course possible to store instances in the form of BER encoded ASN.1 sequences, but this is generally not suitable for human readability.
+ MOF格式允许以通用格式表示实例。SNMP或COPS-PR不存在此类通用格式。当然可以以BER编码ASN.1序列的形式存储实例，但这通常不适合人类可读性。
+ There is support for a query facility which allows the locating of CIM objects. However, the query language itself is not yet specified as part of the CIM standards. Implementations currently use proprietary query languages, such as the Windows Management Instrumentation Query Language (WQL).
+ 支持查询功能，该功能允许定位CIM对象。但是，查询语言本身尚未指定为CIM标准的一部分。实现目前使用专有的查询语言，如Windows Management Instrumentation查询语言（WQL）。
+ The information modeling work in CIM is done by using Unified Modeling Language (UML) as a graphical notation. This attracts people with a computer science background who have learned to use UML as part of their education.
+ CIM中的信息建模工作是通过使用统一建模语言（UML）作为图形符号来完成的。这吸引了具有计算机科学背景的人，他们已经学会使用UML作为他们教育的一部分。
o The main practical use of CIM schemas today seems to be the definition of data structures used internally by management systems.
o 今天，CIM模式的主要实际用途似乎是定义管理系统内部使用的数据结构。
- The CIM schemas have rather complex interrelationships that must be understood before one can reasonably extend the set of existing schemas.
- CIM模式具有相当复杂的相互关系，在合理扩展现有模式集之前，必须理解这些相互关系。
- Interoperability between CIM implementations seems to be problematic compared to the number of interoperable SNMP implementations available today.
- 与目前可互操作的SNMP实现数量相比，CIM实现之间的互操作性似乎存在问题。
- So far, CIM schemas have seen limited implementation and usage as an interface between management systems and network devices.
- 到目前为止，CIM模式作为管理系统和网络设备之间的接口的实现和使用有限。
Most devices have a builtin command line interface (CLI) for configuration and troubleshooting purposes. Network access to the CLI has traditionally been through the TELNET protocol, while the SSH protocol is gaining momentum to address security issues associated with TELNET. In the following, only CLIs that actually parse and execute commands are considered. (Menu-oriented interfaces are difficult for automation and thus not relevant here.)
大多数设备都有一个内置的命令行界面（CLI），用于配置和故障排除。传统上，对CLI的网络访问是通过TELNET协议进行的，而SSH协议正在获得解决与TELNET相关的安全问题的动力。下面只考虑实际解析和执行命令的CLI。（面向菜单的界面很难实现自动化，因此与此无关。）
+ Command line interfaces are generally task-oriented, which make them easier to use for human operators.
+ 命令行界面通常是面向任务的，这使得操作人员更容易使用它们。
+ A saved sequence of textual commands can easily be replayed. Simple substitutions can be made with arbitrary text processing tools.
+ 保存的文本命令序列可以轻松地重放。可以使用任意文本处理工具进行简单的替换。
+ It is usually necessary to learn at least parts of the command line interface of new devices in order to create the initial configuration. Once people have learned (parts of) the command line interface, it is natural for them to use the same interface and abstractions for automating configuration changes.
+ 为了创建初始配置，通常需要至少学习新设备的部分命令行界面。一旦人们了解了（部分）命令行界面，他们自然会使用相同的界面和抽象来自动化配置更改。
+ A command line interface does not require any special purpose applications (telnet and ssh are readily available on most systems today).
+ 命令行界面不需要任何特殊用途的应用程序（telnet和ssh在今天的大多数系统上都是现成的）。
+ Most command line interfaces provide context sensitive help that reduces the learning curve.
+ 大多数命令行界面提供了上下文相关的帮助，减少了学习过程。
- Some command line interfaces lack a common data model. It is very well possible that the same command on different devices, even from the same vendor, behaves differently.
- 一些命令行界面缺少通用数据模型。很可能不同设备上的同一命令，即使来自同一供应商，其行为也不同。
- The command line interface is primarily targeted to humans which can adapt to minor syntax and format changes easily. Using command line interfaces as a programmatic interface is troublesome because of parsing complexities.
- 命令行界面主要面向能够轻松适应较小语法和格式更改的人员。由于解析的复杂性，将命令行接口用作编程接口很麻烦。
- Command line interfaces often lack proper version control for the syntax and the semantics. It is therefore time consuming and error prone to maintain programs or scripts that interface with different versions of a command line interface.
- 命令行接口通常缺乏对语法和语义的适当版本控制。因此，维护与不同版本的命令行界面交互的程序或脚本非常耗时且容易出错。
- Since command line interfaces are proprietary, they can not be used efficiently to automate processes in an environment with a heterogenous set of devices.
- 由于命令行界面是专有的，因此在具有异构设备集的环境中，它们不能有效地用于自动化流程。
- The access control facilities, if present at all, are often ad-hoc and sometimes insufficient.
- 访问控制设施，如果有的话，通常是临时的，有时是不够的。
Many devices have an embedded web server which can be used to configure the device and to obtain status information. The commonly used protocol is HTTP, and information is rendered in HTML. Some devices also expect that clients have facilities such as Java or Java Script.
许多设备都有嵌入式web服务器，可用于配置设备和获取状态信息。常用的协议是HTTP，信息以HTML呈现。一些设备还希望客户端具有Java或Java脚本等功能。
+ Embedded web servers for configuration are end-user friendly and solution oriented.
+ 用于配置的嵌入式web服务器对最终用户友好且面向解决方案。
+ Embedded web servers are suitable for configuring consumer devices by inexperienced users.
+ 嵌入式web服务器适合由经验不足的用户配置消费设备。
+ Web server configuration is widely deployed, especially in boxes targeted to the consumer market.
+ Web服务器配置被广泛部署，特别是在面向消费者市场的机箱中。
+ There is no need for specialized applications to use embedded web servers since web browsers are commonly available today.
+ 由于现在web浏览器普遍可用，所以不需要专门的应用程序来使用嵌入式web服务器。
- Embedded web servers are management application hostile. Parsing HTML pages to extract useful information is extremely painful.
- 嵌入式web服务器不利于管理应用程序。解析HTML页面以提取有用信息是非常痛苦的。
- Replay of configuration is often problematic, either because the web pages rely on some active content or because different versions of the same device use different ways to interact with the user.
- 配置的重播通常是有问题的，要么是因为网页依赖于某些活动内容，要么是因为同一设备的不同版本使用不同的方式与用户交互。
- The access control facilities, if present at all, are often ad-hoc and sometimes insufficient.
- 访问控制设施，如果有的话，通常是临时的，有时是不够的。
In the late 1990's, some vendors started to use the Extensible Markup Language (XML) [XML] for describing device configurations and for protocols that can be used to retrieve and manipulate XML formatted configurations.
在20世纪90年代末，一些供应商开始使用可扩展标记语言（XML）[XML]来描述设备配置，以及用于检索和操作XML格式配置的协议。
+ XML is a machine readable format which is easy to process and there are many good off the shelf tools available.
+ XML是一种易于处理的机器可读格式，并且有许多现成的工具可用。
+ XML allows the description of structured data of almost arbitrary complexity.
+ XML允许描述几乎任意复杂度的结构化数据。
+ The basic syntax rules behind XML are relatively easy to learn.
+ XML背后的基本语法规则相对容易学习。
+ XML provides a document-oriented view of configuration data (similar to many proprietary configuration file formats).
+ XML提供了面向文档的配置数据视图（类似于许多专有配置文件格式）。
+ XML has a robust schema language XSD [XSD] for which many good off the shelf tools exist.
+ XML有一种健壮的模式语言XSD[XSD]，许多现成的工具都适用于该语言。
o XML alone is just syntax. XML schemas must be carefully designed to make XML truly useful as a data exchange format.
o XML本身就是语法。必须仔细设计XML模式，使XML真正成为有用的数据交换格式。
- XML is rather verbose. This either increases the bandwidth required to move management information around (which is an issue in e.g., wireless or asymmetric cable networks) or it requires that the systems involved have the processing power to do on the fly compression/decompression.
- XML相当冗长。这要么增加了移动管理信息所需的带宽（这在无线或非对称电缆网络中是一个问题），要么要求所涉及的系统具有进行动态压缩/解压缩的处理能力。
- There is a lack of commonly accepted standardized management specific XML schemas.
- 缺乏公认的标准化管理特定XML模式。
During the breakout session, the operators were asked to identify needs that have not been sufficiently addressed. The results produced during the breakout session were later discussed and resulted in the following list of operator requirements.
在分组会议期间，要求运营商确定尚未充分解决的需求。随后讨论了分组会议期间产生的结果，并得出以下操作员要求列表。
1. Ease of use is a key requirement for any network management technology from the operators point of view.
1. 从运营商的角度来看，易用性是任何网络管理技术的关键要求。
2. It is necessary to make a clear distinction between configuration data, data that describes operational state and statistics. Some devices make it very hard to determine which parameters were administratively configured and which were obtained via other mechanisms such as routing protocols.
2. 有必要明确区分配置数据、描述运行状态的数据和统计数据。有些设备很难确定哪些参数是通过管理配置的，哪些是通过其他机制（如路由协议）获得的。
3. It is required to be able to fetch separately configuration data, operational state data, and statistics from devices, and to be able to compare these between devices.
3. 它需要能够从设备中分别获取配置数据、操作状态数据和统计数据，并能够在设备之间进行比较。
4. It is necessary to enable operators to concentrate on the configuration of the network as a whole rather than individual devices.
4. 有必要使运营商将注意力集中在整个网络的配置上，而不是单个设备。
5. Support for configuration transactions across a number of devices would significantly simplify network configuration management.
5. 支持跨多个设备的配置事务将大大简化网络配置管理。
6. 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.
6. 给定配置A和配置B，应该能够生成从A到B所需的操作，并且状态变化和对网络和系统的影响最小。将配置更改造成的影响降至最低非常重要。
7. 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.
7. 转储和恢复配置的机制是操作员需要的基本操作。从/到设备的拉和推配置标准是可取的。
8. It must be easy to do consistency checks of configurations over time and between the ends of a link in order to determine the changes between two configurations and whether those configurations are consistent.
8. 为了确定两个配置之间的变化以及这些配置是否一致，必须很容易在一段时间内以及链路两端之间对配置进行一致性检查。
9. Network wide configurations are typically 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. It is desirable to extract, document, and standardize the common parts of these network wide configuration database schemas.
9. 网络范围的配置通常存储在中央主数据库中，并转换为可以推送到设备的格式，方法是生成CLI命令序列或推送到设备的完整配置文件。网络配置没有通用的数据库模式，尽管不同运营商使用的模型可能非常相似。需要提取、记录和标准化这些网络范围配置数据库模式的公共部分。
10. It is highly desirable that text processing tools such as diff, and version management tools such as RCS or CVS, can be used to process configurations, which implies that devices should not arbitrarily reorder data such as access control lists.
10. 非常希望使用diff等文本处理工具和RCS或CVS等版本管理工具来处理配置，这意味着设备不应随意对访问控制列表等数据重新排序。
11. 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.
11. 管理接口所需的访问控制粒度需要与操作需求相匹配。典型的需求是基于角色的访问控制模型和最小权限原则，其中用户只能获得执行所需任务所需的最小访问权限。
12. It must be possible to do consistency checks of access control lists across devices.
12. 必须能够跨设备对访问控制列表进行一致性检查。
13. It is important to distinguish between the distribution of configurations and the activation of a certain configuration. Devices should be able to hold multiple configurations.
13. 区分配置的分布和特定配置的激活是很重要的。设备应能容纳多种配置。
14. SNMP access control is data-oriented, while CLI access control is usually command (task) oriented. Depending on the management function, sometimes data-oriented or task-oriented access control makes more sense. As such, it is a requirement to support both data-oriented and task-oriented access control.
14. SNMP访问控制面向数据，而CLI访问控制通常面向命令（任务）。根据管理功能，有时面向数据或面向任务的访问控制更有意义。因此，需要同时支持面向数据和面向任务的访问控制。
So far, there is no published document that clearly defines the requirements of the operators.
到目前为止，还没有公开的文件明确规定运营商的要求。
During the discussions, many properties of the SNMP framework were identified.
在讨论过程中，确定了SNMP框架的许多属性。
1. It is usually not possible to retrieve complete device configurations via SNMP so that they can be compared with previous configurations or checked for consistency across devices. There is usually only incomplete coverage of device features via the SNMP interface, and there is a lack of differentiation between configuration data and operational state data for many features.
1. 通常无法通过SNMP检索完整的设备配置，以便与以前的配置进行比较或检查设备之间的一致性。通常，通过SNMP接口仅不完全覆盖设备功能，并且许多功能的配置数据和操作状态数据之间缺乏区分。
2. The quality of SNMP instrumentations is sometimes disappointing. SNMP access sometimes crashes systems or returns wrong data.
2. SNMP检测的质量有时令人失望。SNMP访问有时会使系统崩溃或返回错误数据。
3. MIB modules and their implementations are not available in a timely manner (sometimes MIB modules lag years behind) which forces users to use the CLI.
3. MIB模块及其实现无法及时提供（有时MIB模块落后数年），这迫使用户使用CLI。
4. Operators view current SNMP programming/scripting interfaces as being too low-level and thus too time consuming and inconvenient for practical use.
4. 运营商认为当前的SNMP编程/脚本接口级别太低，因此太耗时，不便于实际使用。
5. Lexicographic ordering is sometimes artificial with regard to internal data structures and causes either significant runtime overhead, or increases implementation costs or implementation delay or both.
5. 对于内部数据结构，词典排序有时是人为的，会导致大量的运行时开销，或增加实现成本或实现延迟，或两者兼而有之。
6. Poor performance for bulk data transfers. The typical examples are routing tables.
6. 批量数据传输的性能较差。典型的例子是路由表。
7. Poor performance on query operations that were not anticipated during the MIB design. A typical example is the following query: Which outgoing interface is being used for a specific destination address?
7. 在MIB设计期间没有预料到的查询操作上性能不佳。一个典型的例子是以下查询：哪个传出接口用于特定的目标地址？
8. The SNMP credentials and key management are considered complex, especially since they do not integrate well with other existing credential and key management systems.
8. SNMP凭据和密钥管理被认为是复杂的，特别是因为它们不能很好地与其他现有凭据和密钥管理系统集成。
9. The SMI language is hard to deal with and not very practical.
9. SMI语言很难处理，也不太实用。
10. MIB modules are often over-engineered in the sense that they contain lots of variables that operators do not look at.
10. MIB模块通常被过度设计，因为它们包含许多操作员看不到的变量。
11. SNMP traps are used to track state changes but often syslog messages are considered more useful since they usually contain more information to describe the problem. SNMP traps usually require subsequent get operations to figure out what the trap really means.
11. SNMP陷阱用于跟踪状态更改，但系统日志消息通常被认为更有用，因为它们通常包含更多描述问题的信息。SNMP陷阱通常需要后续的get操作来确定陷阱的真正含义。
12. Device manufacturers find SNMP instrumentations inherently difficult to implement, especially with complex table indexing schemes and table interrelationships.
12. 设备制造商发现SNMP工具本质上很难实现，特别是对于复杂的表索引方案和表之间的相互关系。
13. MIB modules often lack a description of how the various objects can be used to achieve certain management functions. (MIB modules can often be characterized as a list of ingredients without a recipe.)
13. MIB模块通常缺乏对如何使用各种对象来实现某些管理功能的描述。（MIB模块通常可以描述为没有配方的成分列表。）
14. The lack of structured types and various RPC interactions (methods) make MIB modules much more complex to design and implement.
14. 由于缺乏结构化类型和各种RPC交互（方法），MIB模块的设计和实现变得更加复杂。
15. The lack of query and aggregation capabilities (reduction of data) causes efficiency and scalability problems.
15. 缺乏查询和聚合功能（减少数据）会导致效率和可伸缩性问题。
16. The SNMP protocol was simplified in terms of the number of protocol operations and resource requirements on managed devices. It was not simplified in terms of usability by network operators or instrumentation implementors.
16. SNMP协议在协议操作数量和受管设备上的资源需求方面得到了简化。在可用性方面，网络运营商或仪器实施者并未对其进行简化。
17. There is a semantic mismatch between the low-level data-oriented abstraction level of MIB modules and the task-oriented abstraction level desired by network operators. Bridging the gap with tools is in principle possible, but in general it is expensive as it requires some serious development and programming efforts.
17. MIB模块的低级面向数据的抽象级别与网络运营商期望的面向任务的抽象级别之间存在语义不匹配。原则上，用工具弥补差距是可能的，但一般来说，这是昂贵的，因为它需要一些认真的开发和编程工作。
18. SNMP seems to work reasonably well for small devices which have a limited number of managed objects and where end-user management applications are shipped by the vendor. For more complex devices, SNMP becomes too expensive and too hard to use.
18. SNMP似乎适用于具有有限数量托管对象的小型设备，并且最终用户管理应用程序由供应商提供。对于更复杂的设备，SNMP变得过于昂贵且难以使用。
19. There is a disincentive for vendors to implement SNMP equivalent MIB modules for all their CLI commands because they do not see a valued proposition. This undermines the value of third party standard SNMP solutions.
19. 供应商不愿意为其所有CLI命令实现与SNMP等效的MIB模块，因为他们看不到有价值的建议。这削弱了第三方标准SNMP解决方案的价值。
20. Rapid feature development is in general not compatible with the standardization of the configuration interface.
20. 快速功能开发通常与配置接口的标准化不兼容。
1. Programmatic interfaces have to provide full coverage otherwise they will not be used by network operators since they have to revert to CLIs anyway.
1. 编程接口必须提供全覆盖，否则网络运营商将不会使用它们，因为它们必须恢复到CLI。
2. Operators perceive that equipment vendors do not implement MIB modules in a timely manner. Neither read-only nor read-write MIB modules are available on time today.
2. 操作员认为设备供应商没有及时实施MIB模块。今天，只读或读写MIB模块都不能按时提供。
3. The attendees perceive that right now it is too hard to implement useful MIB modules within network equipment.
3. 与会者认为，目前在网络设备中实现有用的MIB模块太难了。
4. Because of the previous items, SNMP is not widely used today for network device configuration, although there are notable exceptions.
4. 由于前面提到的内容，SNMP目前并未广泛用于网络设备配置，尽管存在明显的例外情况。
5. It is necessary to clearly distinguish between configuration data and operational data.
5. 必须明确区分配置数据和操作数据。
6. It would be nice to have a single data definition language for all programmatic interfaces (in case there happen to be multiple programmatic interfaces).
6. 最好为所有编程接口使用一种数据定义语言（以防出现多个编程接口）。
7. In general, there is a lack of input from the enterprise network space. Those enterprises who provided input tend to operate their networks like network operators.
7. 一般来说，缺乏来自企业网络空间的输入。提供投入的企业倾向于像网络运营商一样运营其网络。
8. It is required to be able to dump and reload a device configuration in a textual format in a standard manner across multiple vendors and device types.
8. 它需要能够跨多个供应商和设备类型以标准方式以文本格式转储和重新加载设备配置。
9. It is desirable to have a mechanism to distribute configurations to devices under transactional constraints.
9. 希望有一种机制在事务约束下将配置分发给设备。
10. Eliminating SNMP altogether is not an option.
10. 完全消除SNMP不是一个选项。
11. Robust access control is needed. In addition, it is desirable to be able to enable/disable individual MIB modules actually implemented on a device.
11. 需要鲁棒的访问控制。此外，希望能够启用/禁用设备上实际实现的各个MIB模块。
12. Textual configuration files should be able to contain international characters. Human-readable strings should utilize the least-bad internationalized character set and encoding, which this year almost certainly means UTF-8. Protocol elements should be in case insensitive ASCII.
12. 文本配置文件应该能够包含国际字符。人类可读的字符串应该使用最差的国际化字符集和编码，这在今年几乎肯定意味着UTF-8。协议元素应为不区分大小写的ASCII。
13. The deployed tools for event/alarm correlation, root cause analysis and logging are not sufficient.
13. 已部署的事件/警报关联、根本原因分析和日志记录工具不足。
14. There is a need to support a human interface and a programmatic interface.
14. 需要支持人机界面和编程界面。
15. The internal method routines for both interfaces should be the same to ensure that data exchanged between these two interfaces is always consistent.
15. 两个接口的内部方法例程应该相同，以确保这两个接口之间交换的数据始终一致。
16. The implementation costs have to be low on devices.
16. 设备的实施成本必须很低。
17. The implementation costs have to be low on managers.
17. 管理者的实施成本必须很低。
18. The specification costs for data models have to be low.
18. 数据模型的规范成本必须很低。
19. Standardization costs for data models have to be low.
19. 数据模型的标准化成本必须很低。
20. There should be a single data modeling language with a human friendly syntax.
20. 应该有一种具有人性化语法的单一数据建模语言。
21. The data modeling language must support compound data types.
21. 数据建模语言必须支持复合数据类型。
22. There is a need for data aggregation capabilities on the devices.
22. 需要在设备上提供数据聚合功能。
23. There should be a common data interchange format for instance data that allows easy post-processing and analysis.
23. 对于实例数据，应该有一种通用的数据交换格式，以便于后期处理和分析。
24. There is a need for a common data exchange format with single and multi-system transactions (which implies rollback across devices in error situations).
24. 需要一种具有单个和多个系统事务的通用数据交换格式（这意味着在错误情况下跨设备回滚）。
25. There is a need to reduce the semantic mismatch between current data models and the primitives used by operators.
25. 需要减少当前数据模型与运算符使用的原语之间的语义不匹配。
26. It should be possible to perform operations on selected subsets of management data.
26. 应该可以对选定的管理数据子集执行操作。
27. It is necessary to discover the capabilities of devices.
27. 有必要发现设备的功能。
28. There is a need for a secure transport, authentication, identity, and access control which integrates well with existing key and credential management infrastructure.
28. 需要一个安全的传输、身份验证、身份和访问控制，它与现有的密钥和凭证管理基础架构很好地集成。
29. It must be possible to define task oriented views and access control rules.
29. 必须能够定义面向任务的视图和访问控制规则。
30. The complete configuration of a device should be doable with a single protocol.
30. 设备的完整配置应该可以通过单一协议实现。
31. A configuration protocol must be efficient and reliable and it must scale in the number of transactions and devices.
31. 配置协议必须高效可靠，并且必须在事务和设备数量上进行扩展。
32. Devices must be able to support minimally interruptive configuration deltas.
32. 设备必须能够支持最小中断的配置增量。
33. A solution must support function call semantics (methods) to implement functions, such as a longest prefix match on a routing table.
33. 解决方案必须支持函数调用语义（方法）来实现函数，例如路由表上的最长前缀匹配。
1. The workshop recommends that the IETF stop forcing working groups to provide writable MIB modules. It should be the decision of the working group whether they want to provide writable objects or not.
1. 研讨会建议IETF停止强制工作组提供可写MIB模块。是否提供可写对象应由工作组决定。
2. The workshop recommends that a group be formed to investigate why current MIB modules do not contain all the objects needed by operators to monitor their networks.
2. 研讨会建议成立一个小组，调查为什么当前的MIB模块没有包含运营商监控其网络所需的所有对象。
3. The workshop recommends that a group be formed to investigate why the current SNMP protocol does not satisfy all the monitoring requirements of operators.
3. 研讨会建议成立一个小组，调查为什么当前的SNMP协议不能满足运营商的所有监控要求。
4. The workshop recommends, with strong consensus from both protocol developers and operators, that the IETF focus resources on the standardization of configuration management mechanisms.
4. 研讨会建议，在协议开发者和运营商的强烈共识下，IETF应将资源集中在配置管理机制的标准化上。
5. The workshop recommends, with strong consensus from the operators and rough consensus from the protocol developers, that the IETF/IRTF should spend resources on the development and standardization of XML-based device configuration and management technologies (such as common XML configuration schemas, exchange protocols and so on).
5. 研讨会建议，在运营商的强烈共识和协议开发人员的大致共识下，IETF/IRTF应将资源用于基于XML的设备配置和管理技术（如通用XML配置模式、交换协议等）的开发和标准化。
6. The workshop recommends, with strong consensus from the operators and rough consensus from the protocol developers, that the IETF/IRTF should not spend resources on developing HTML-based or HTTP-based methods for configuration management.
6. 研讨会建议，在运营商的强烈共识和协议开发人员的大致共识下，IETF/IRTF不应将资源用于开发基于HTML或HTTP的配置管理方法。
7. The workshop recommends, with rough consensus from the operators and strong consensus from the protocol developers, that the IETF should continue to spend resources on the evolution of the SMI/SPPI data definition languages as being done in the SMIng working group.
7. 研讨会建议，在运营商的大致共识和协议开发人员的强烈共识下，IETF应继续在SMI/SPPI数据定义语言的发展上投入资源，就像SMIng工作组所做的那样。
8. The workshop recommends, with split consensus from the operators and rough consensus from the protocol developers, that the IETF should spend resources on fixing the MIB development and standardization process.
8. 研讨会建议，在运营商意见分歧和协议开发人员意见大致一致的情况下，IETF应将资源用于修复MIB开发和标准化过程。
The workshop also discussed the following items and achieved rough consensus, but did not make a recommendation.
讲习班还讨论了下列项目，并达成了初步共识，但没有提出建议。
1. The workshop had split consensus from the operators and rough consensus from the protocol developers, that the IETF should not focus resources on CIM extensions.
1. 该研讨会分散了运营商和协议开发人员的共识，即IETF不应将资源集中在CIM扩展上。
2. The workshop had rough consensus from the protocol developers that the IETF should not spend resources on COPS-PR development. So far, the operators have only very limited experience with COPS-PR. In general, however, they felt that further development of COPS-PR might be a waste of resources as they assume that COPS-PR does not really address their requirements.
2. 该研讨会得到了协议开发人员的大致共识，即IETF不应将资源用于COPS-PR开发。到目前为止，运营商在COPS-PR方面的经验非常有限。但是，总的来说，他们认为进一步开发COPS-PR可能会浪费资源，因为他们认为COPS-PR不能真正满足他们的需求。
3. The workshop had rough consensus from the protocol developers that the IETF should not spend resources on SPPI PIB definitions. The operators had rough consensus that they do not care about SPPI PIBs.
3. 该研讨会得到了协议开发人员的大致共识，即IETF不应在SPPI PIB定义上花费资源。运营商大致一致认为，他们不关心SPPI PIB。
This document is a report of an IAB Network Management workshop. As such, it does not have any direct security implications for the Internet.
本文档是IAB网络管理研讨会的报告。因此，它对互联网没有任何直接的安全影响。
The editor would like to thank Dave Durham, Simon Leinen and John Schnizlein for taking detailed minutes during the workshop.
编辑要感谢Dave Durham、Simon Leinen和John Schnizlein在研讨会期间做了详细的记录。
Normative References
规范性引用文件
[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月。
[CIM] Distributed Management Task Force, "Common Information Model (CIM) Specification Version 2.2", DSP 0004, June 1999.
[CIM]分布式管理工作组，“公共信息模型（CIM）规范版本2.2”，DSP 0004，1999年6月。
[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月。
[RFC2748] Durham, D., Boyle, J., Cohen, R., Herzog, S., Rajan, R. and A. Sastry, "The COPS (Common Open Policy Service) Protocol", RFC 2748, January 2000.
[RFC2748]达勒姆，D.，博伊尔，J.，科恩，R.，赫尔佐格，S.，拉詹，R.和A.萨斯特里，“共同开放政策服务协议”，RFC 27482000年1月。
[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月。
[XML] Bray, T., Paoli, J. and C. Sperberg-McQueen, "Extensible Markup Language (XML) 1.0", W3C Recommendation, February 1998.
[XML]Bray，T.，Paoli，J.和C.Sperberg McQueen，“可扩展标记语言（XML）1.0”，W3C建议，1998年2月。
Informative References
资料性引用
[RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000.
[RFC2863]McCloghrie，K.和F.Kastenholz，“接口组MIB”，RFC 28632000年6月。
[XSD] David, D., "XML Schema Part 0: Primer", W3C Recommendation, May 2001.
[XSD]David，D.，“XML模式第0部分：入门”，W3C推荐，2001年5月。
Appendix - Participants
附录-参加者
Ran Atkinson Extreme Networks Rob Austein InterNetShare Andy Bierman Cisco Systems Steve Bellovin AT&T Randy Bush AT&T Leslie Daigle VeriSign David Durham Intel Vijay Gill Wes Hardaker Network Associates Laboratories Ed Kern Simon Leinen Switch Ken Lindahl University of California Berkeley David Partain Ericsson Andrew Partan UUnet/Verio/MFN Vern Paxson ICIR Aiko Pras Univeristy of Twente Randy Presuhn BMC Software Juergen Schoenwaelder University of Osnabrueck John Schnizlein Cisco Systems Mike St. Johns Ruediger Volk Deutsche Telekom Steve Waldbusser Margaret Wassermann Windriver Glen Waters Nortel Networks Bert Wijnen Lucent
阿特金森极端网络罗伯-奥斯坦网络安迪Bielman Cisco系统史提夫Belovin AT&T RANDY布什AT&T莱斯利Digige VelisGang-戴维DuraM英特尔Vijay-Gier-韦斯HADEK网络协会实验室ED Kern Fulm LeNeN交换机肯LunaHL加利福尼亚大学Paxis-Iri-Aiko Pras大学的TuntEn Rey PrimuHn BMC软件SujeWaldE.OsNabRuke大学John ShanZeLin Cisco系统Mike S.John Ruigiger-Vulk Dudiee Telkm史提夫WaldbsServer玛格丽特WaSerman Walth-Geln Wetter NordelNetworks伯特Wijnun-Lunter
Author's Address
作者地址
Comments should be submitted to the <nm-ws@ops.ietf.org> mailing list.
意见应提交给<nm-ws@ops.ietf.org>邮件列表。
Juergen Schoenwaelder International University Bremen P.O. Box 750 561 28725 Bremen Germany
德国不来梅Juergen Schoenwaeld国际大学邮政信箱750 561 28725不来梅
Phone: +49 421 200 3587
EMail: j.schoenwaelder@iu-bremen.de
Phone: +49 421 200 3587
EMail: j.schoenwaelder@iu-bremen.de
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。