Network Working Group J. Case
Request for Comments: 3410 SNMP Research, Inc.
Obsoletes: 2570 R. Mundy
Category: Informational Network Associates Laboratories
D. Partain
Ericsson
B. Stewart
Retired
December 2002
Network Working Group J. Case
Request for Comments: 3410 SNMP Research, Inc.
Obsoletes: 2570 R. Mundy
Category: Informational Network Associates Laboratories
D. Partain
Ericsson
B. Stewart
Retired
December 2002
Introduction and Applicability Statements for Internet Standard Management Framework
Internet标准管理框架的介绍和适用性声明
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 (2002). All Rights Reserved.
版权所有（C）互联网协会（2002年）。版权所有。
Abstract
摘要
The purpose of this document is to provide an overview of the third version of the Internet-Standard Management Framework, termed the SNMP version 3 Framework (SNMPv3). This Framework is derived from and builds upon both the original Internet-Standard Management Framework (SNMPv1) and the second Internet-Standard Management Framework (SNMPv2).
本文档的目的是提供Internet标准管理框架的第三个版本的概述，称为SNMP版本3框架（SNMPv3）。该框架源自并建立在原始互联网标准管理框架（SNMPv1）和第二个互联网标准管理框架（SNMPv2）的基础上。
The architecture is designed to be modular to allow the evolution of the Framework over time.
该体系结构被设计为模块化，以允许随着时间的推移框架的演变。
The document explains why using SNMPv3 instead of SNMPv1 or SNMPv2 is strongly recommended. The document also recommends that RFCs 1157, 1441, 1901, 1909 and 1910 be retired by moving them to Historic status. This document obsoletes RFC 2570.
本文档解释了为什么强烈建议使用SNMPv3而不是SNMPv1或SNMPv2。该文件还建议通过将RFC 1157、1441、1901、1909和1910移至历史状态，使其退役。本文件淘汰了RFC 2570。
Table of Contents
目录
1 Introduction ................................................. 2
2 The Internet Standard Management Framework ................... 3
2.1 Basic Structure and Components ............................. 4
2.2 Architecture of the Internet Standard Management Framework . 4
3 The SNMPv1 Management Framework .............................. 5
3.1 The SNMPv1 Data Definition Language ........................ 6
3.2 Management Information ..................................... 6
3.3 Protocol Operations ........................................ 7
3.4 SNMPv1 Security and Administration ......................... 7
4 The SNMPv2 Management Framework .............................. 8
5 The SNMPv3 Working Group ..................................... 8
6 SNMPv3 Framework Module Specifications ....................... 10
6.1 Data Definition Language ................................... 11
6.2 MIB Modules ................................................ 12
6.3 Protocol Operations and Transport Mappings ................. 13
6.4 SNMPv3 Security and Administration ......................... 13
7 Document Summaries ........................................... 14
7.1 Structure of Management Information ........................ 14
7.1.1 Base SMI Specification ................................... 15
7.1.2 Textual Conventions ...................................... 15
7.1.3 Conformance Statements ................................... 16
7.2 Protocol Operations ........................................ 16
7.3 Transport Mappings ......................................... 16
7.4 Protocol Instrumentation ................................... 17
7.5 Architecture / Security and Administration ................. 17
7.6 Message Processing and Dispatch (MPD) ...................... 17
7.7 SNMP Applications .......................................... 18
7.8 User-based Security Model (USM) ............................ 18
7.9 View-based Access Control (VACM) ........................... 19
7.10 SNMPv3 Coexistence and Transition ......................... 19
8 Standardization Status ....................................... 20
8.1 SMIv1 Status ............................................... 20
8.2 SNMPv1 and SNMPv2 Standardization Status ................... 21
8.3 Working Group Recommendation ............................... 22
9 Security Considerations ...................................... 22
10 References .................................................. 22
11 Editor's Addresses .......................................... 26
12 Full Copyright Statement .................................... 27
1 Introduction ................................................. 2
2 The Internet Standard Management Framework ................... 3
2.1 Basic Structure and Components ............................. 4
2.2 Architecture of the Internet Standard Management Framework . 4
3 The SNMPv1 Management Framework .............................. 5
3.1 The SNMPv1 Data Definition Language ........................ 6
3.2 Management Information ..................................... 6
3.3 Protocol Operations ........................................ 7
3.4 SNMPv1 Security and Administration ......................... 7
4 The SNMPv2 Management Framework .............................. 8
5 The SNMPv3 Working Group ..................................... 8
6 SNMPv3 Framework Module Specifications ....................... 10
6.1 Data Definition Language ................................... 11
6.2 MIB Modules ................................................ 12
6.3 Protocol Operations and Transport Mappings ................. 13
6.4 SNMPv3 Security and Administration ......................... 13
7 Document Summaries ........................................... 14
7.1 Structure of Management Information ........................ 14
7.1.1 Base SMI Specification ................................... 15
7.1.2 Textual Conventions ...................................... 15
7.1.3 Conformance Statements ................................... 16
7.2 Protocol Operations ........................................ 16
7.3 Transport Mappings ......................................... 16
7.4 Protocol Instrumentation ................................... 17
7.5 Architecture / Security and Administration ................. 17
7.6 Message Processing and Dispatch (MPD) ...................... 17
7.7 SNMP Applications .......................................... 18
7.8 User-based Security Model (USM) ............................ 18
7.9 View-based Access Control (VACM) ........................... 19
7.10 SNMPv3 Coexistence and Transition ......................... 19
8 Standardization Status ....................................... 20
8.1 SMIv1 Status ............................................... 20
8.2 SNMPv1 and SNMPv2 Standardization Status ................... 21
8.3 Working Group Recommendation ............................... 22
9 Security Considerations ...................................... 22
10 References .................................................. 22
11 Editor's Addresses .......................................... 26
12 Full Copyright Statement .................................... 27
This document is an introduction to the third version of the Internet-Standard Management Framework, termed the SNMP version 3 Management Framework (SNMPv3) and has multiple purposes.
本文档介绍Internet标准管理框架的第三个版本，称为SNMP版本3管理框架（SNMPv3），具有多种用途。
First, it describes the relationship between the SNMP version 3 (SNMPv3) specifications and the specifications of the SNMP version 1 (SNMPv1) Management Framework, the SNMP version 2 (SNMPv2) Management Framework, and the Community-based Administrative Framework for SNMPv2.
首先，它描述了SNMP版本3（SNMPv3）规范与SNMP版本1（SNMPv1）管理框架规范、SNMP版本2（SNMPv2）管理框架规范以及基于社区的SNMPv2管理框架规范之间的关系。
Second, it provides a roadmap to the multiple documents which contain the relevant specifications.
其次，它提供了包含相关规范的多个文档的路线图。
Third, this document provides a brief easy-to-read summary of the contents of each of the relevant specification documents.
第三，本文档提供了每个相关规范文档内容的简单易读的摘要。
This document is intentionally tutorial in nature and, as such, may occasionally be "guilty" of oversimplification. In the event of a conflict or contradiction between this document and the more detailed documents for which this document is a roadmap, the specifications in the more detailed documents shall prevail.
本文件本质上是教程，因此，有时可能会因过于简单而“有罪”。如果本文件与本文件作为路线图的更详细文件之间存在冲突或矛盾，应以更详细文件中的规范为准。
Further, the detailed documents attempt to maintain separation between the various component modules in order to specify well-defined interfaces between them. This roadmap document, however, takes a different approach and attempts to provide an integrated view of the various component modules in the interest of readability.
此外，详细文档试图保持各个组件模块之间的分离，以便指定它们之间定义良好的接口。然而，本路线图文档采用了不同的方法，并试图提供各种组件模块的集成视图，以提高可读性。
This document is a work product of the SNMPv3 Working Group of the Internet Engineering Task Force (IETF).
本文件是互联网工程任务组（IETF）SNMPv3工作组的工作成果。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [1].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、RFC 2119[1]中的描述进行解释。
The third version of the Internet Standard Management Framework (the SNMPv3 Framework) is derived from and builds upon both the original Internet-Standard Management Framework (SNMPv1) and the second Internet-Standard Management Framework (SNMPv2).
第三个版本的互联网标准管理框架（SNMPv3框架）源自并建立在原始互联网标准管理框架（SNMPv1）和第二个互联网标准管理框架（SNMPv2）的基础上。
All versions (SNMPv1, SNMPv2, and SNMPv3) of the Internet Standard Management SNMP Framework share the same basic structure and components. Furthermore, all versions of the specifications of the Internet Standard Management Framework follow the same architecture.
Internet标准管理SNMP框架的所有版本（SNMPv1、SNMPv2和SNMPv3）共享相同的基本结构和组件。此外，Internet标准管理框架规范的所有版本都遵循相同的体系结构。
An enterprise deploying the Internet Standard Management Framework contains four basic components:
部署Internet标准管理框架的企业包含四个基本组件：
* several (typically many) managed nodes, each with an SNMP entity which provides remote access to management instrumentation (traditionally called an agent);
* 多个（通常为多个）受管节点，每个节点都有一个SNMP实体，该实体提供对管理工具（传统上称为代理）的远程访问；
* at least one SNMP entity with management applications (typically called a manager),
* 至少一个具有管理应用程序（通常称为管理器）的SNMP实体，
* a management protocol used to convey management information between the SNMP entities, and
* 用于在SNMP实体之间传输管理信息的管理协议，以及
* management information.
* 管理信息。
The management protocol is used to convey management information between SNMP entities such as managers and agents.
管理协议用于在管理器和代理等SNMP实体之间传递管理信息。
This basic structure is common to all versions of the Internet Standard Management Framework; i.e., SNMPv1, SNMPv2, and SNMPv3.
这个基本结构对于所有版本的互联网标准管理框架都是通用的；i、 例如，SNMPv1、SNMPv2和SNMPv3。
The specifications of the Internet Standard Management Framework are based on a modular architecture. This framework is more than just a protocol for moving data. It consists of:
Internet标准管理框架的规范基于模块化架构。这个框架不仅仅是一个移动数据的协议。它包括：
* a data definition language,
* 数据定义语言，
* definitions of management information (the Management Information Base, or MIB),
* 管理信息的定义（管理信息库或MIB），
* a protocol definition, and
* 协议定义，以及
* security and administration.
* 安全和管理。
Over time, as the Framework has evolved from SNMPv1, through SNMPv2, to SNMPv3, the definitions of each of these architectural components have become richer and more clearly defined, but the fundamental architecture has remained consistent.
随着时间的推移，随着框架从SNMPv1到SNMPv2再到SNMPv3的发展，这些架构组件的定义变得更加丰富和清晰，但基本架构保持一致。
One prime motivator for this modularity was to enable the ongoing evolution of the Framework, as is documented in RFC 1052 [2]. When originally envisioned, this capability was to be used to ease the transition from SNMP-based management of internets to management based on OSI protocols. To this end, the framework was architected
这种模块化的一个主要动机是支持框架的持续发展，如RFC 1052[2]所述。最初设想时，该功能用于简化从基于SNMP的Internet管理到基于OSI协议的管理的过渡。为此，对框架进行了架构设计
with a protocol-independent data definition language and Management Information Base along with a MIB-independent protocol. This separation was designed to allow the SNMP-based protocol to be replaced without requiring the management information to be redefined or reinstrumented. History has shown that the selection of this architecture was the right decision for the wrong reason -- it turned out that this architecture has eased the transition from SNMPv1 to SNMPv2 and from SNMPv2 to SNMPv3 rather than easing the transition away from management based on the Simple Network Management Protocol.
具有独立于协议的数据定义语言和管理信息库以及独立于MIB的协议。这种分离旨在允许替换基于SNMP的协议，而无需重新定义或重新执行管理信息。历史表明，选择这种体系结构是出于错误的原因做出的正确决定——事实证明，这种体系结构缓解了从SNMPv1到SNMPv2以及从SNMPv2到SNMPv3的过渡，而不是缓解了从基于简单网络管理协议的管理过渡。
The SNMPv3 Framework builds and extends these architectural principles by:
SNMPv3框架通过以下方式构建和扩展这些体系结构原则：
* building on these four basic architectural components, in some cases incorporating them from the SNMPv2 Framework by reference, and
* 以这四个基本架构组件为基础，在某些情况下，通过引用将它们从SNMPv2框架中合并，以及
* by using these same layering principles in the definition of new capabilities in the security and administration portion of the architecture.
* 通过在架构的安全和管理部分的新功能定义中使用这些相同的分层原则。
Those who are familiar with the architecture of the SNMPv1 Management Framework and the SNMPv2 Management Framework will find many familiar concepts in the architecture of the SNMPv3 Management Framework. However, in some cases, the terminology may be somewhat different.
熟悉SNMPv1管理框架和SNMPv2管理框架体系结构的人将在SNMPv3管理框架体系结构中找到许多熟悉的概念。然而，在某些情况下，术语可能有所不同。
The original Internet-Standard Network Management Framework (SNMPv1) is defined in the following documents:
原始互联网标准网络管理框架（SNMPv1）在以下文档中定义：
* STD 16, RFC 1155 [3] which defines the Structure of Management Information (SMI), the mechanisms used for describing and naming objects for the purpose of management.
* STD 16，RFC 1155[3]定义了管理信息（SMI）的结构，即用于描述和命名对象以进行管理的机制。
* STD 16, RFC 1212 [4] which defines a more concise description mechanism for describing and naming management information objects, but which is wholly consistent with the SMI.
* STD 16，RFC 1212[4]定义了一种更简洁的描述机制，用于描述和命名管理信息对象，但与SMI完全一致。
* STD 15, RFC 1157 [5] which defines the Simple Network Management Protocol (SNMP), the protocol used for network access to managed objects and event notification. Note this document also defines an initial set of event notifications.
* STD 15，RFC 1157[5]，其中定义了简单网络管理协议（SNMP），该协议用于网络访问受管对象和事件通知。注意：本文档还定义了一组初始事件通知。
Additionally, two documents are generally considered companions to these three:
此外，两份文件通常被认为是这三份文件的附带文件：
* STD 17, RFC 1213 [6] which contains definitions for the base set of management information
* STD 17，RFC 1213[6]，其中包含管理信息基本集的定义
* RFC 1215 [7] defines a concise description mechanism for defining event notifications, which are called traps in the SNMPv1 protocol. It also specifies the generic traps from RFC 1157 in the concise notation.
* RFC 1215[7]定义了一种用于定义事件通知的简明描述机制，在SNMPv1协议中称为陷阱。它还以简明的表示法指定了RFC 1157中的通用陷阱。
These documents describe the four parts of the first version of the SNMP Framework.
这些文档描述了SNMP框架第一版的四个部分。
The first two and the last document, i.e., RFCs 1155, 1212, and 1215, describe the SNMPv1 data definition language and are often collectively referred to as "SMIv1". Note that due to the initial requirement that the SMI be protocol-independent, the first two SMI documents do not provide a means for defining event notifications (traps). Instead, the SNMP protocol document defines a few standardized event notifications (generic traps) and provides a means for additional event notifications to be defined. The last document specifies a straight-forward approach towards defining event notifications used with the SNMPv1 protocol. At the time that it was written, use of traps in the Internet-Standard network management framework was controversial. As such, RFC 1215 was put forward with the status of "Informational", which was never updated because it was believed that the second version of the SNMP Framework would replace the first version.
前两个和最后一个文档，即RFCs 1155、1212和1215，描述了SNMPv1数据定义语言，通常统称为“SMIv1”。注意，由于最初要求SMI独立于协议，前两个SMI文档没有提供定义事件通知（陷阱）的方法。相反，SNMP协议文档定义了一些标准化的事件通知（通用陷阱），并提供了定义其他事件通知的方法。最后一个文档指定了定义SNMPv1协议使用的事件通知的直接方法。在撰写时，在互联网标准网络管理框架中使用陷阱是有争议的。因此，RFC 1215的状态为“信息性”，从未更新，因为据信SNMP框架的第二个版本将取代第一个版本。
The data definition language described in the first two documents was first used to define the now-historic MIB-I as specified in RFC 1066 [8], and was subsequently used to define MIB-II as specified in RFC 1213 [6].
前两个文档中描述的数据定义语言首先用于定义RFC 1066[8]中规定的现在的历史MIB-I，随后用于定义RFC 1213[6]中规定的MIB-II。
Later, after the publication of MIB-II, a different approach to the management information definition was taken from the earlier approach of having a single committee staffed by generalists work on a single document to define the Internet-Standard MIB. Rather, many mini-MIB documents were produced in a parallel and distributed fashion by groups chartered to produce a specification for a focused portion of the Internet-Standard MIB and staffed by personnel with expertise in those particular areas ranging from various aspects of network management, to system management, and application management.
后来，在MIB-II发布后，管理信息定义采用了一种不同的方法，不同于以前的方法，即由一个由多面手组成的委员会处理一份文件，以定义互联网标准MIB。相反，许多迷你MIB文档是由特许的集团以并行和分发的方式生成的，这些集团为互联网标准MIB的一个重点部分制定了规范，并配备了从网络管理的各个方面到系统管理和应用程序管理等特定领域具有专业知识的人员。
The third document, STD 15 [5], describes the SNMPv1 protocol operations performed by protocol data units (PDUs) on lists of variable bindings and describes the format of SNMPv1 messages. The operators defined by SNMPv1 are: get, get-next, get-response, set-request, and trap. Typical layering of SNMP on a connectionless transport service is also defined.
第三份文件STD 15[5]描述了协议数据单元（PDU）在变量绑定列表上执行的SNMPv1协议操作，并描述了SNMPv1消息的格式。SNMPv1定义的操作符有：get、get next、get response、set request和trap。还定义了无连接传输服务上SNMP的典型分层。
STD 15 [5] also describes an approach to security and administration. Many of these concepts are carried forward and some, particularly security, are extended by the SNMPv3 Framework.
STD 15[5]还描述了一种安全和管理方法。这些概念中的许多都得到了继承，一些概念（尤其是安全性）通过SNMPv3框架得到了扩展。
The SNMPv1 Framework describes the encapsulation of SNMPv1 PDUs in SNMP messages between SNMP entities and distinguishes between application entities and protocol entities. In SNMPv3, these are renamed applications and engines, respectively.
SNMPv1框架描述了SNMPv1 PDU在SNMP实体之间的SNMP消息中的封装，并区分了应用程序实体和协议实体。在SNMPv3中，它们分别被重命名为应用程序和引擎。
The SNMPv1 Framework also introduces the concept of an authentication service supporting one or more authentication schemes. In addition to authentication, SNMPv3 defines the additional security capability referred to as privacy. (Note: some literature from the security community would describe SNMPv3 security capabilities as providing data integrity, source authenticity, and confidentiality.) The modular nature of the SNMPv3 Framework permits both changes and additions to the security capabilities.
SNMPv1框架还引入了支持一个或多个认证方案的认证服务的概念。除了身份验证之外，SNMPv3还定义了称为隐私的附加安全功能。（注意：安全社区的一些文献将SNMPv3安全功能描述为提供数据完整性、源真实性和机密性。）SNMPv3框架的模块化特性允许对安全功能进行更改和添加。
Finally, the SNMPv1 Framework introduces access control based on a concept called an SNMP MIB view. The SNMPv3 Framework specifies a fundamentally similar concept called view-based access control. With this capability, SNMPv3 provides the means for controlling access to information on managed devices.
最后，SNMPv1框架引入了基于称为SNMP MIB视图的概念的访问控制。SNMPv3框架指定了一个基本相似的概念，称为基于视图的访问控制。通过此功能，SNMPv3提供了控制对受管设备上信息的访问的方法。
However, while the SNMPv1 Framework anticipated the definition of multiple authentication schemes, it did not define any such schemes other than a trivial authentication scheme based on community strings. This was a known fundamental weakness in the SNMPv1 Framework but it was thought at that time that the definition of commercial grade security might be contentious in its design and difficult to get approved because "security" means many different things to different people. To that end, and because some users do not require strong authentication, the SNMPv1 architected an authentication service as a separate block to be defined "later" and the SNMPv3 Framework provides an architecture for use within that block as well as a definition for its subsystems.
然而，尽管SNMPv1框架预期会定义多个身份验证方案，但除了基于社区字符串的普通身份验证方案之外，它没有定义任何此类方案。这是SNMPv1框架中已知的一个基本弱点，但当时人们认为，商业级安全性的定义在其设计中可能存在争议，很难获得批准，因为“安全性”对不同的人意味着许多不同的东西。为此，由于一些用户不需要强身份验证，SNMPv1将身份验证服务构建为一个单独的块，稍后再定义，SNMPv3框架提供了一个在该块中使用的体系结构及其子系统的定义。
The SNMPv2 Management Framework is described in [8-13] and coexistence and transition issues relating to SNMPv1 and SNMPv2 are discussed in [15].
[8-13]中描述了SNMPv2管理框架，[15]中讨论了与SNMPv1和SNMPv2相关的共存和过渡问题。
SNMPv2 provides several advantages over SNMPv1, including:
与SNMPv1相比，SNMPv2提供了几个优势，包括：
* expanded data types (e.g., 64 bit counter)
* 扩展数据类型（例如，64位计数器）
* improved efficiency and performance (get-bulk operator)
* 提高效率和性能（获得批量运营商）
* confirmed event notification (inform operator)
* 确认事件通知（通知操作员）
* richer error handling (errors and exceptions)
* 更丰富的错误处理（错误和异常）
* improved sets, especially row creation and deletion
* 改进的集合，特别是行创建和删除
* fine tuning of the data definition language
* 数据定义语言的微调
However, the SNMPv2 Framework, as described in these documents, is incomplete in that it does not meet the original design goals of the SNMPv2 project. The unmet goals included provision of security and administration delivering so-called "commercial grade" security with:
然而，这些文件中描述的SNMPv2框架是不完整的，因为它不符合SNMPv2项目的原始设计目标。未实现的目标包括提供安全和管理，提供所谓的“商业级”安全，包括：
* authentication: origin identification, message integrity, and some aspects of replay protection;
* 身份验证：源标识、消息完整性和重播保护的某些方面；
* privacy: confidentiality;
* 隐私：保密；
* authorization and access control; and
* 授权和访问控制；和
* suitable remote configuration and administration capabilities for these features.
* 适用于这些功能的远程配置和管理功能。
The SNMPv3 Management Framework, as described in this document and the companion documents, addresses these significant deficiencies.
如本文件和配套文件所述，SNMPv3管理框架解决了这些重大缺陷。
This document, and its companion documents, were produced by the SNMPv3 Working Group of the Internet Engineering Task Force (IETF). The SNMPv3 Working Group was chartered to prepare recommendations for the next generation of SNMP. The goal of the Working Group was to produce the necessary set of documents that provide a single standard for the next generation of core SNMP functions. The single, most critical need in the next generation is a definition of security and administration that makes SNMP-based management transactions secure
本文件及其配套文件由互联网工程任务组（IETF）的SNMPv3工作组编制。SNMPv3工作组被授权为下一代SNMP编写建议。工作组的目标是生成必要的文档集，为下一代核心SNMP功能提供单一标准。下一代中最关键的需求是定义安全性和管理，使基于SNMP的管理事务更加安全
in a way which is useful for users who wish to use SNMPv3 to manage networks, the systems that make up those networks, and the applications which reside on those systems, including manager-to-agent, agent-to-manager, and manager-to-manager transactions.
对于希望使用SNMPv3管理网络、构成这些网络的系统以及驻留在这些系统上的应用程序（包括管理者到代理、代理到管理者以及管理者到管理者事务）的用户来说，这是非常有用的。
In the several years prior to the chartering of the Working Group, there were a number of activities aimed at incorporating security and other improvements to SNMP. These efforts included:
在工作组成立之前的几年里，开展了一些旨在将安全性和其他改进纳入SNMP的活动。这些努力包括：
* "SNMP Security" circa 1991-1992 (RFC 1351 - RFC 1353),
* “SNMP安全”大约在1991-1992年（RFC 1351-RFC 1353），
* "SMP" circa 1992-1993, and
* “SMP”约1992-1993年，以及
* "The Party-based SNMPv2" (sometimes called "SNMPv2p") circa 1993-1995 (RFC 1441 - RFC 1452).
* “基于政党的SNMPv2”（有时称为“SNMPv2p”）大约在1993-1995年（RFC 1441-RFC 1452）。
Each of these efforts incorporated commercial grade, industrial strength security including authentication, privacy, authorization, view-based access control, and administration, including remote configuration.
每项工作都结合了商业级、工业级安全，包括身份验证、隐私、授权、基于视图的访问控制和管理，包括远程配置。
These efforts fed the development of the SNMPv2 Management Framework as described in RFCs 1902 - 1908. However, the Framework described in those RFCs had no standards-based security and administrative framework of its own; rather, it was associated with multiple security and administrative frameworks, including:
这些努力促进了RFCs 1902-1908中所述SNMPv2管理框架的开发。然而，这些RFC中描述的框架本身没有基于标准的安全和管理框架；相反，它与多种安全和管理框架相关联，包括：
* "The Community-based SNMPv2" (SNMPv2c) as described in RFC 1901 [16],
* RFC 1901[16]中描述的“基于社区的SNMPv2”（SNMPv2c），
* "SNMPv2u" as described in RFCs 1909 and 1910, and
* RFCs 1909和1910中所述的“SNMPv2u”，以及
* "SNMPv2*."
* “SNMPv2*”
SNMPv2c had the most support within the IETF but had no security and administration whereas both SNMPv2u and SNMPv2* had security but lacked a consensus of support within the IETF.
SNMPv2c在IETF中得到最多的支持，但没有安全性和管理，而SNMPv2u和SNMPv2*都有安全性，但在IETF中缺乏一致的支持。
The SNMPv3 Working Group was chartered to produce a single set of specifications for the next generation of SNMP, based upon a convergence of the concepts and technical elements of SNMPv2u and SNMPv2*, as was suggested by an advisory team which was formed to provide a single recommended approach for SNMP evolution.
SNMPv3工作组根据SNMPv2u和SNMPv2*的概念和技术要素的融合，被授权为下一代SNMP制定一套规范，这是由一个咨询小组建议的，该小组的成立是为了为SNMP演进提供单一的推荐方法。
In so doing, the Working Group charter defined the following objectives:
为此，《工作组章程》确定了以下目标：
* accommodate the wide range of operational environments with differing management demands;
* 适应各种不同管理需求的操作环境；
* facilitate the need to transition from previous, multiple protocols to SNMPv3;
* 促进从以前的多协议过渡到SNMPv3的需要；
* facilitate the ease of setup and maintenance activities.
* 便于安装和维护活动。
In the initial work of the SNMPv3 Working Group, the group focused on security and administration, including:
在SNMPv3工作组的初始工作中，工作组重点关注安全和管理，包括：
* authentication and privacy,
* 认证和隐私，
* authorization and view-based access control, and
* 授权和基于视图的访问控制，以及
* standards-based remote configuration of the above.
* 基于标准的上述远程配置。
The SNMPv3 Working Group did not "reinvent the wheel", but reused the SNMPv2 Draft Standard documents, i.e., RFCs 1902 through 1908 for those portions of the design that were outside the focused scope.
SNMPv3工作组没有“重新发明轮子”，而是将SNMPv2标准草案文件（即RFCs 1902至1908）重新用于重点范围之外的设计部分。
Rather, the primary contributors to the SNMPv3 Working Group, and the Working Group in general, devoted their considerable efforts to addressing the missing link -- security and administration -- and in the process made invaluable contributions to the state-of-the-art of management.
相反，SNMPv3工作组和整个工作组的主要贡献者付出了巨大的努力来解决缺失的环节——安全和管理——并在这一过程中为最先进的管理做出了宝贵的贡献。
They produced a design based on a modular architecture with evolutionary capabilities with emphasis on layering. As a result, SNMPv3 can be thought of as SNMPv2 with additional security and administration capabilities.
他们设计了一个基于模块化架构的设计，具有进化能力，强调分层。因此，SNMPv3可以被认为是SNMPv2，具有额外的安全性和管理功能。
In doing so, the Working Group achieved the goal of producing a single specification which has not only the endorsement of the IETF but also has security and administration.
通过这样做，工作组实现了产生一个单一规范的目标，该规范不仅得到IETF的认可，而且还具有安全性和管理性。
The specification of the SNMPv3 Management Framework is partitioned in a modular fashion among several documents. It is the intention of the SNMPv3 Working Group that, with proper care, any or all of the individual documents can be revised, upgraded, or replaced as requirements change, new understandings are obtained, and new technologies become available.
SNMPv3管理框架的规范以模块化的方式在多个文档中进行划分。SNMPv3工作组的目的是，在适当谨慎的情况下，随着需求的变化、新的理解和新技术的出现，可以对任何或所有单独的文件进行修订、升级或替换。
Whenever feasible, the initial document set which defines the SNMPv3 Management Framework leverages prior investments defining and implementing the SNMPv2 Management Framework by incorporating by reference each of the specifications of the SNMPv2 Management Framework.
在可行的情况下，定义SNMPv3管理框架的初始文件集通过引用SNMPv2管理框架的每个规范，利用先前定义和实施SNMPv2管理框架的投资。
The SNMPv3 Framework augments those specifications with specifications for security and administration for SNMPv3.
SNMPv3框架使用SNMPv3的安全性和管理规范来扩充这些规范。
The documents which specify the SNMPv3 Management Framework follow the same architecture as those of the prior versions and can be organized for expository purposes into four main categories as follows:
指定SNMPv3管理框架的文档遵循与先前版本相同的体系结构，为了便于解释，可以将其组织为以下四个主要类别：
* the data definition language,
* 数据定义语言，
* Management Information Base (MIB) modules,
* 管理信息库（MIB）模块，
* protocol operations, and
* 协议操作，以及
* security and administration.
* 安全和管理。
The first three sets of documents are incorporated from SNMPv2. The documents in the fourth set are new to SNMPv3, but, as described previously, build on significant prior related works.
前三套文件合并自SNMPv2。第四组中的文档是SNMPv3的新文档，但如前所述，它们是建立在之前重要的相关工作的基础上的。
The specifications of the data definition language include STD 58, RFC 2578, "Structure of Management Information Version 2 (SMIv2)" [17], and related specifications. These documents are updates of RFCs 1902 - 1904 [9-11] which have evolved independently from the other parts of the framework and were republished with minor editorial changes as STD 58, RFCs 2578 - 2580 [17-19] when promoted from Draft Standard to full Standard.
数据定义语言的规范包括STD 58、RFC 2578、“管理信息结构版本2（SMIv2）”[17]和相关规范。这些文件是RFCs 1902-1904[9-11]的更新版本，其独立于框架的其他部分，并在从标准草案升级为完整标准时，重新发布了STD 58、RFCs 2578-2580[17-19]等微小的编辑变更。
The Structure of Management Information (SMIv2) defines fundamental data types, an object model, and the rules for writing and revising MIB modules. Related specifications include STD 58, RFCs 2579, 2580.
管理信息结构（SMIv2）定义了基本数据类型、对象模型以及编写和修改MIB模块的规则。相关规范包括STD 58、RFCs 2579、2580。
STD 58, RFC 2579, "Textual Conventions for SMIv2" [18], defines an initial set of shorthand abbreviations which are available for use within all MIB modules for the convenience of human readers and writers.
STD 58，RFC 2579，“SMIv2的文本约定”[18]，定义了一组初始速记缩写，可在所有MIB模块中使用，以方便读者和作者。
STD 58, RFC 2580, "Conformance Statements for SMIv2" [19], defines the format for compliance statements which are used for describing requirements for agent implementations and capability statements which can be used to document the characteristics of particular implementations.
STD 58，RFC 2580，“SMIv2的合规性声明”[19]定义了用于描述代理实施要求的合规性声明的格式，以及可用于记录特定实施特征的能力声明。
The term "SMIv2" is somewhat ambiguous because users of the term intend it to have at least two different meanings. Sometimes the term is used to refer the entire data definition language of STD 58, defined collectively in RFCs 2578 - 2580 whereas at other times it is used to refer to only the portion of the data definition language defined in RFC 2578. This ambiguity is unfortunate but is rarely a significant problem in practice.
术语“SMIv2”有点模棱两可，因为该术语的用户希望它至少有两种不同的含义。有时，该术语用于指代STD 58的整个数据定义语言，在RFC 2578-2580中共同定义，而在其他时间，它仅用于指代RFC 2578中定义的数据定义语言的一部分。这种模糊性是不幸的，但在实践中很少是一个重大问题。
MIB modules usually contain object definitions, may contain definitions of event notifications, and sometimes include compliance statements specified in terms of appropriate object and event notification groups. As such, MIB modules define the management information maintained by the instrumentation in managed nodes, made remotely accessible by management agents, conveyed by the management protocol, and manipulated by management applications.
MIB模块通常包含对象定义，可能包含事件通知的定义，有时还包括根据适当的对象和事件通知组指定的符合性声明。因此，MIB模块定义了由托管节点中的仪表维护的管理信息，这些信息由管理代理远程访问，由管理协议传输，并由管理应用程序操作。
MIB modules are defined according to the rules defined in the documents which specify the data definition language, principally the SMI as supplemented by the related specifications.
MIB模块是根据指定数据定义语言的文档中定义的规则定义的，主要是由相关规范补充的SMI。
There is a large and growing number of standards-track MIB modules, as defined in the periodically updated "Internet Official Protocol Standards" list [20]. As of this writing, there are more than 100 standards-track MIB modules with a total number of defined objects exceeding 10,000. In addition, there is an even larger and growing number of enterprise-specific MIB modules defined unilaterally by various vendors, research groups, consortia, and the like resulting in an unknown and virtually uncountable number of defined objects.
正如定期更新的“互联网官方协议标准”列表[20]中所定义的，跟踪MIB模块的标准越来越多。在撰写本文时，共有100多个标准跟踪MIB模块，定义的对象总数超过10000个。此外，由各种供应商、研究小组、财团等单方面定义的企业特定MIB模块数量甚至更大，而且还在不断增加，导致定义的对象数量未知且几乎无法计数。
In general, management information defined in any MIB module, regardless of the version of the data definition language used, can be used with any version of the protocol. For example, MIB modules defined in terms of the SNMPv1 SMI (SMIv1) are compatible with the SNMPv3 Management Framework and can be conveyed by the protocols specified therein. Furthermore, MIB modules defined in terms of the SNMPv2 SMI (SMIv2) are compatible with SNMPv1 protocol operations and can be conveyed by it. However, there is one noteworthy exception: the Counter64 datatype which can be defined in a MIB module defined
通常，在任何MIB模块中定义的管理信息，无论使用的数据定义语言的版本如何，都可以与协议的任何版本一起使用。例如，根据SNMPv1 SMI（SMIv1）定义的MIB模块与SNMPv3管理框架兼容，并且可以通过其中指定的协议传送。此外，根据SNMPv2 SMI（SMIv2）定义的MIB模块与SNMPv1协议操作兼容，并可由其传输。但是，有一个值得注意的例外：Counter64数据类型可以在定义的MIB模块中定义
in SMIv2 format but which cannot be conveyed by an SNMPv1 protocol engine. It can be conveyed by an SNMPv2 or an SNMPv3 engine, but cannot be conveyed by an engine which exclusively supports SNMPv1.
采用SMIv2格式，但无法通过SNMPv1协议引擎传输。它可以由SNMPv2或SNMPv3引擎传送，但不能由专门支持SNMPv1的引擎传送。
The specifications for the protocol operations and transport mappings of the SNMPv3 Framework are incorporated by reference to the two SNMPv2 Framework documents which have subsequently been updated.
SNMPv3框架的协议操作和传输映射规范通过参考两个SNMPv2框架文件合并，这两个文件随后进行了更新。
The specification for protocol operations is found in STD 62, RFC 3416, "Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMP)" [21].
协议操作规范见STD 62，RFC 3416，“简单网络管理协议（SNMP）的协议操作版本2”[21]。
The SNMPv3 Framework is designed to allow various portions of the architecture to evolve independently. For example, it might be possible for a new specification of protocol operations to be defined within the Framework to allow for additional protocol operations.
SNMPv3框架旨在允许体系结构的各个部分独立发展。例如，可以在框架内定义协议操作的新规范，以允许附加的协议操作。
The specification of transport mappings is found in STD 62, RFC 3417, "Transport Mappings for the Simple Network Management Protocol (SNMP)" [22].
传输映射的规范见STD 62，RFC 3417，“简单网络管理协议（SNMP）的传输映射”[22]。
The document series pertaining to SNMPv3 Security and Administration defined by the SNMPv3 Working Group consists of seven documents at this time:
SNMPv3工作组定义的与SNMPv3安全和管理相关的文档系列目前由七个文档组成：
RFC 3410, "Introduction and Applicability Statements for the Internet-Standard Management Framework", which is this document.
RFC 3410，“互联网标准管理框架的介绍和适用性声明”，即本文件。
STD 62, RFC 3411, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks" [23], describes the overall architecture with special emphasis on the architecture for security and administration.
STD 62，RFC 3411，“描述简单网络管理协议（SNMP）管理框架的体系结构”[23]，描述了总体体系结构，特别强调了安全和管理体系结构。
STD 62, RFC 3412, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)" [24], describes the possibility of multiple message processing models and the dispatcher portion that can be a part of an SNMP protocol engine.
STD 62，RFC 3412，“简单网络管理协议（SNMP）的消息处理和调度”[24]，描述了多个消息处理模型的可能性以及可以作为SNMP协议引擎一部分的调度程序部分。
STD 62, RFC 3413, "Simple Network Management Protocol (SNMP) Applications" [25], describes the five initial types of applications that can be associated with an SNMPv3 engine and their elements of procedure.
STD 62，RFC 3413，“简单网络管理协议（SNMP）应用程序”[25]，描述了可与SNMPv3引擎关联的五种初始应用程序类型及其程序元素。
STD 62, RFC 3414, "User-Based Security Model (USM) for Version 3 of the Simple Network Management Protocol (SNMPv3)" [26], describes the threats against which protection is provided, as well as the mechanisms, protocols, and supporting data used to provide SNMP message-level security with the user-based security model.
STD 62，RFC 3414，“简单网络管理协议（SNMPv3）第3版的基于用户的安全模型（USM）”[26]描述了提供保护的威胁，以及用于使用基于用户的安全模型提供SNMP消息级安全的机制、协议和支持数据。
STD 62, RFC 3415, "View-based Access Control Model (VCAM) for the Simple Network Management Protocol (SNMP)" [27], describes how view-based access control can be applied within command responder and notification originator applications.
STD 62，RFC 3415，“用于简单网络管理协议（SNMP）的基于视图的访问控制模型（VCAM）”[27]，描述了如何在命令响应程序和通知发起者应用程序中应用基于视图的访问控制。
RFC 2576, "SNMPv3 Coexistence and Transition" [28], describes coexistence between the SNMPv3 Management Framework, the SNMPv2 Management Framework, and the original SNMPv1 Management Framework, and is in the process of being updated by a Work in Progress.
RFC 2576，“SNMPv3共存和转换”[28]，描述了SNMPv3管理框架、SNMPv2管理框架和原始SNMPv1管理框架之间的共存，并正在通过正在进行的工作进行更新。
The following sections provide brief summaries of each document with slightly more detail than is provided in the overviews above.
以下各节提供了每个文件的简要摘要，其详细程度略高于上述概述。
Management information is viewed as a collection of managed objects, residing in a virtual information store, termed the Management Information Base (MIB). Collections of related objects are defined in MIB modules. These modules are written in the SNMP data definition language, which evolved from an adapted subset of OSI's Abstract Syntax Notation One (ASN.1) [29] language. STD 58, RFCs 2578, 2579, 2580, collectively define the data definition language, specify the base data types for objects, specify a core set of short-hand specifications for data types called textual conventions, and specify a few administrative assignments of object identifier (OID) values.
管理信息被视为托管对象的集合，驻留在虚拟信息存储中，称为管理信息库（MIB）。相关对象的集合在MIB模块中定义。这些模块是用SNMP数据定义语言编写的，该语言是从OSI的抽象语法符号一（ASN.1）[29]语言的一个子集演变而来的。STD 58、RFCs 2578、2579、2580共同定义了数据定义语言，指定了对象的基本数据类型，为称为文本约定的数据类型指定了一组核心的速记规范，并指定了一些对象标识符（OID）值的管理赋值。
The SMI is divided into three parts: module definitions, object definitions, and notification definitions.
SMI分为三个部分：模块定义、对象定义和通知定义。
(1) Module definitions are used when describing information modules. An ASN.1 macro, MODULE-IDENTITY, is used to convey concisely the semantics of an information module.
(1) 描述信息模块时使用模块定义。ASN.1宏MODULE-IDENTITY用于简洁地传达信息模块的语义。
(2) Object definitions are used when describing managed objects. An ASN.1 macro, OBJECT-TYPE, is used to convey concisely the syntax and semantics of a managed object.
(2) 描述托管对象时使用对象定义。ASN.1宏OBJECT-TYPE用于简洁地传达托管对象的语法和语义。
(3) Notification definitions are used when describing unsolicited transmissions of management information. An ASN.1 macro, NOTIFICATION-TYPE, is used to convey concisely the syntax and semantics of a notification.
(3) 通知定义用于描述管理信息的非请求传输。ASN.1宏NOTIFICATION-TYPE用于简洁地传达通知的语法和语义。
As noted earlier, the term "SMIv2" is somewhat ambiguous because users of the term intend it to have at least two different meanings. Sometimes the term is used to refer to the entire data definition language of STD 58, defined collectively in RFCs 2578 - 2580 whereas at other times it is used to refer to only the portion of the data definition language defined in RFC 2578. This ambiguity is unfortunate but is rarely a significant problem in practice.
如前所述，“SMIv2”一词有点含糊不清，因为该词的用户希望它至少有两种不同的含义。有时，该术语用于指代STD 58的整个数据定义语言，在RFC 2578-2580中共同定义，而在其他时间，它仅用于指代RFC 2578中定义的数据定义语言的一部分。这种模糊性是不幸的，但在实践中很少是一个重大问题。
STD 58, RFC 2578 specifies the base data types for the data definition language, which include: Integer32, enumerated integers, Unsigned32, Gauge32, Counter32, Counter64, TimeTicks, INTEGER, OCTET STRING, OBJECT IDENTIFIER, IpAddress, Opaque, and BITS. It also assigns values to several object identifiers. STD 58, RFC 2578 further defines the following constructs of the data definition language:
STD 58、RFC 2578指定数据定义语言的基本数据类型，包括：整数32、枚举整数、无符号32、量规32、计数器32、计数器64、时间刻度、整数、八位字符串、对象标识符、IpAddress、不透明和位。它还将值分配给多个对象标识符。STD 58、RFC 2578进一步定义了数据定义语言的以下结构：
* IMPORTS to allow the specification of items that are used in a MIB module, but defined in another MIB module.
* 导入以允许指定在MIB模块中使用但在另一MIB模块中定义的项。
* MODULE-IDENTITY to specify for a MIB module a description and administrative information such as contact and revision history.
* MODULE-IDENTITY为MIB模块指定描述和管理信息，如联系人和修订历史记录。
* OBJECT-IDENTITY and OID value assignments to specify an OID value.
* 用于指定OID值的对象标识和OID值指定。
* OBJECT-TYPE to specify the data type, status, and the semantics of managed objects.
* OBJECT-TYPE指定托管对象的数据类型、状态和语义。
* SEQUENCE type assignment to list the columnar objects in a table.
* 序列类型指定以列出表中的列对象。
* NOTIFICATION-TYPE construct to specify an event notification.
* NOTIFICATION-TYPE构造以指定事件通知。
When designing a MIB module, it is often useful to specify, in a short-hand way, the semantics for a set of objects with similar behavior. This is done by defining a new data type using a base data type specified in the SMI. Each new type has a different name, and specifies a base type with more restrictive semantics. These newly defined types are termed textual conventions, and are used for the convenience of humans reading a MIB module and potentially by "intelligent" management applications. It is the purpose of STD 58,
在设计MIB模块时，用一种简单的方式指定一组具有类似行为的对象的语义通常很有用。这是通过使用SMI中指定的基本数据类型定义新数据类型来完成的。每个新类型都有不同的名称，并指定具有更严格语义的基类型。这些新定义的类型称为文本约定，用于方便人们阅读MIB模块，也可能用于“智能”管理应用程序。这是STD 58的目的，
RFC 2579, Textual Conventions for SMIv2 [18], to define the construct, TEXTUAL-CONVENTION, of the data definition language used to define such new types and to specify an initial set of textual conventions available to all MIB modules.
RFC 2579，SMIv2的文本约定[18]，用于定义用于定义此类新类型的数据定义语言的构造，text-CONVENTION，并指定可用于所有MIB模块的初始文本约定集。
It may be useful to define the acceptable lower-bounds of implementation, along with the actual level of implementation achieved. It is the purpose of STD 58, RFC 2580, Conformance Statements for SMIv2 [19], to define the constructs of the data definition language used for these purposes. There are two kinds of constructs:
定义可接受的实现下限以及实现的实际实现水平可能很有用。STD 58、RFC 2580、SMIv2的一致性声明[19]旨在定义用于这些目的的数据定义语言的结构。有两种构造：
(1) Compliance statements are used when describing requirements for agents with respect to object and event notification definitions. The MODULE-COMPLIANCE construct is used to convey concisely such requirements.
(1) 合规性声明用于描述代理对对象和事件通知定义的要求。模块合规性结构用于简洁地传达此类需求。
(2) Capability statements are used when describing capabilities of agents with respect to object and event notification definitions. The AGENT-CAPABILITIES construct is used to convey concisely such capabilities.
(2) Capability语句用于描述代理关于对象和事件通知定义的功能。AGENT-CAPABILITIES结构用于简洁地传达此类功能。
Finally, collections of related objects and collections of related event notifications are grouped together to form a unit of conformance. The OBJECT-GROUP construct is used to convey concisely the objects in and the semantics of an object group. The NOTIFICATION-GROUP construct is used to convey concisely the event notifications in and the semantics of an event notification group.
最后，相关对象的集合和相关事件通知的集合被分组在一起以形成一致性单元。对象组结构用于简洁地表达对象组中的对象和对象组的语义。NOTIFICATION-GROUP构造用于简洁地传递事件通知以及事件通知组的语义。
The management protocol provides for the exchange of messages which convey management information between the agents and the management stations. The form of these messages is a message "wrapper" which encapsulates a Protocol Data Unit (PDU).
管理协议提供了在代理和管理站之间传递管理信息的消息交换。这些消息的形式是封装协议数据单元（PDU）的消息“包装器”。
It is the purpose of STD 62, RFC 3416, "Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMP)" [21], to define the operations of the protocol with respect to the sending and receiving of the PDUs.
STD 62，RFC 3416，“简单网络管理协议（SNMP）的协议操作版本2”[21]的目的是定义与PDU发送和接收相关的协议操作。
SNMP messages may be used over a variety of protocol suites. It is the purpose of STD 62, RFC 3417, "Transport Mappings for the Simple Network Management Protocol (SNMP)" [22], to define how SNMP messages
SNMP消息可以通过各种协议套件使用。STD 62，RFC 3417，“简单网络管理协议（SNMP）的传输映射”[22]旨在定义SNMP消息的传输方式
map onto an initial set of transport domains. Other mappings may be defined in the future.
映射到传输域的初始集合。将来可能会定义其他映射。
Although several mappings are defined, the mapping onto UDP is the preferred mapping. As such, to provide for the greatest level of interoperability, systems which choose to deploy other mappings should also provide for proxy service to the UDP mapping.
虽然定义了多个映射，但到UDP的映射是首选映射。因此，为了提供最高级别的互操作性，选择部署其他映射的系统还应提供到UDP映射的代理服务。
It is the purpose of STD 62, RFC 3418, "Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)" [30], to define managed objects which describe the behavior of portions of an SNMP entity.
STD 62，RFC 3418，“简单网络管理协议（SNMP）的管理信息库（MIB）”[30]的目的是定义描述SNMP实体各部分行为的受管对象。
It is the purpose of STD 62, RFC 3411, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks" [23], to define an architecture for specifying Management Frameworks. While addressing general architectural issues, it focuses on aspects related to security and administration. It defines a number of terms used throughout the SNMPv3 Management Framework and, in so doing, clarifies and extends the naming of:
STD 62 RFC 3411“描述简单网络管理协议（SNMP）管理框架的体系结构”[23]的目的是定义用于指定管理框架的体系结构。在解决一般体系结构问题的同时，它关注与安全性和管理相关的方面。它定义了SNMPv3管理框架中使用的许多术语，并在此过程中澄清和扩展了以下名称：
* engines and applications,
* 发动机和应用，
* entities (service providers such as the engines in agents and managers),
* 实体（服务提供商，如代理和经理中的引擎），
* identities (service users), and
* 身份（服务用户），以及
* management information, including support for multiple logical contexts.
* 管理信息，包括对多个逻辑上下文的支持。
The document contains a small MIB module which is implemented by all authoritative SNMPv3 protocol engines.
该文档包含一个由所有权威SNMPv3协议引擎实现的小型MIB模块。
STD 62, RFC 3412, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)" [24], describes the Message Processing and Dispatching for SNMP messages within the SNMP architecture. It defines the procedures for dispatching potentially multiple versions of SNMP messages to the proper SNMP Message Processing Models, and for dispatching PDUs to SNMP applications. This document also describes one Message Processing Model - the SNMPv3 Message Processing Model.
STD 62，RFC 3412，“简单网络管理协议（SNMP）的消息处理和调度”[24]，描述了SNMP体系结构中SNMP消息的消息处理和调度。它定义了将可能多个版本的SNMP消息分派到适当的SNMP消息处理模型以及将PDU分派到SNMP应用程序的过程。本文档还描述了一种消息处理模型——SNMPv3消息处理模型。
An SNMPv3 protocol engine MUST support at least one Message Processing Model. An SNMPv3 protocol engine MAY support more than one, for example in a multi-lingual system which provides simultaneous support of SNMPv3 and SNMPv1 and/or SNMPv2c. For example, such a tri-lingual system which provides simultaneous support for SNMPv1, SNMPv2c, and SNMPv3 supports three message processing models.
SNMPv3协议引擎必须至少支持一种消息处理模型。SNMPv3协议引擎可以支持多个，例如在多语言系统中，多语言系统同时支持SNMPv3和SNMPv1和/或SNMPv2c。例如，这种同时支持SNMPv1、SNMPv2c和SNMPv3的三种语言系统支持三种消息处理模型。
It is the purpose of STD 62, RFC 3413, "Simple Network Management Protocol (SNMP) Applications" [25] to describe the five types of applications which can be associated with an SNMP engine. They are: Command Generators, Command Responders, Notification Originators, Notification Receivers, and Proxy Forwarders.
STD 62、RFC 3413“简单网络管理协议（SNMP）应用程序”[25]旨在描述可与SNMP引擎关联的五种应用程序。它们是：命令生成器、命令响应者、通知发起者、通知接收者和代理转发器。
The document also defines MIB modules for specifying targets of management operations (including notifications), for notification filtering, and for proxy forwarding.
该文档还定义了MIB模块，用于指定管理操作的目标（包括通知）、通知筛选和代理转发。
STD 62, RFC 3414, the "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)" [26] describes the User-based Security Model for SNMPv3. It defines the Elements of Procedure for providing SNMP message-level security.
STD 62，RFC 3414，“简单网络管理协议（SNMPv3）版本3的基于用户的安全模型（USM）”[26]描述了SNMPv3的基于用户的安全模型。它定义了用于提供SNMP消息级安全性的过程元素。
The document describes the two primary and two secondary threats which are defended against by the User-based Security Model. They are: modification of information, masquerade, message stream modification, and disclosure.
本文档描述了基于用户的安全模型防御的两个主要和两个次要威胁。它们是：信息修改、伪装、消息流修改和公开。
The USM utilizes MD5 [31] and the Secure Hash Algorithm [32] as keyed hashing algorithms [33] for digest computation to provide data integrity:
USM使用MD5[31]和安全哈希算法[32]作为摘要计算的键控哈希算法[33]，以提供数据完整性：
* to directly protect against data modification attacks,
* 为了直接防止数据修改攻击，
* to indirectly provide data origin authentication, and
* 间接提供数据源身份验证，以及
* to defend against masquerade attacks.
* 防御伪装攻击。
The USM uses loosely synchronized monotonically increasing time indicators to defend against certain message stream modification attacks. Automatic clock synchronization mechanisms based on the protocol are specified without dependence on third-party time sources and concomitant security considerations.
USM使用松散同步的单调递增时间指示器来抵御某些消息流修改攻击。基于该协议的自动时钟同步机制是在不依赖第三方时间源和伴随的安全考虑的情况下指定的。
The USM uses the Data Encryption Standard (DES) [34] in the cipher block chaining mode (CBC) if disclosure protection is desired. Support for DES in the USM is optional, primarily because export and usage restrictions in many countries make it difficult to export and use products which include cryptographic technology.
如果需要公开保护，USM在密码块链接模式（CBC）中使用数据加密标准（DES）[34]。USM中对DES的支持是可选的，主要是因为许多国家的出口和使用限制使得出口和使用包括加密技术的产品变得困难。
The document also includes a MIB suitable for remotely monitoring and managing the configuration parameters for the USM, including key distribution and key management.
该文件还包括一个MIB，适用于远程监控和管理USM的配置参数，包括密钥分发和密钥管理。
An entity may provide simultaneous support for multiple security models as well as multiple authentication and privacy protocols. All of the protocols used by the USM are based on pre-placed keys, i.e., private key mechanisms. The SNMPv3 architecture permits the use of symmetric and asymmetric mechanisms and protocols (asymmetric mechanisms are commonly called public key cryptography) but, as of this writing, there are no SNMPv3 security models on the IETF standards track that use public key cryptography.
实体可以同时支持多个安全模型以及多个身份验证和隐私协议。USM使用的所有协议都基于预先放置的密钥，即私钥机制。SNMPv3体系结构允许使用对称和非对称机制和协议（非对称机制通常称为公钥密码术），但在撰写本文时，IETF标准轨道上没有使用公钥密码术的SNMPv3安全模型。
Work is underway to specify how AES is to be used within the User-based Security Model (USM). This will be a separate document.
正在进行工作，以指定如何在基于用户的安全模型（USM）中使用AES。这将是一份单独的文件。
The purpose of STD 62, RFC 3415, the "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)" [27], is to describe the View-based Access Control Model for use in the SNMP architecture. The VACM can simultaneously be associated in a single engine implementation with multiple Message Processing Models and multiple Security Models.
STD 62 RFC 3415“简单网络管理协议（SNMP）基于视图的访问控制模型（VACM）”[27]的目的是描述SNMP体系结构中使用的基于视图的访问控制模型。VACM可以在单个引擎实现中同时与多个消息处理模型和多个安全模型相关联。
It is architecturally possible to have multiple, different, Access Control Models active and present simultaneously in a single engine implementation, but this is expected to be *_very_* rare in practice and *_far_* less common than simultaneous support for multiple Message Processing Models and/or multiple Security Models.
在体系结构上，可以在单个引擎实现中同时激活和呈现多个不同的访问控制模型，但这在实践中非常罕见，并且远不如同时支持多个消息处理模型和/或多个安全模型。
The purpose of RFC 2576, "Coexistence between Version 1, Version 2, and Version 3 of the Internet-Standard Network Management Framework" [28], is to describe coexistence between the SNMPv3 Management Framework, the SNMPv2 Management Framework, and the original SNMPv1 Management Framework. In particular, this document describes four aspects of coexistence:
RFC 2576“互联网标准网络管理框架版本1、版本2和版本3之间的共存”[28]的目的是描述SNMPv3管理框架、SNMPv2管理框架和原始SNMPv1管理框架之间的共存。本文件特别描述了共存的四个方面：
* Conversion of MIB documents from SMIv1 to SMIv2 format
* 将MIB文档从SMIv1转换为SMIv2格式
* Mapping of notification parameters
* 通知参数的映射
* Approaches to coexistence between entities which support the various versions of SNMP in a multi-lingual network, in particular the processing of protocol operations in multi-lingual implementations, as well as behavior of proxy implementations
* 在多语言网络中支持不同版本SNMP的实体之间共存的方法，特别是多语言实现中协议操作的处理，以及代理实现的行为
* The SNMPv1 Message Processing Model and Community-Based Security Model, which provides mechanisms for adapting SNMPv1 and SNMPv2c into the View-Based Access Control Model (VACM) [27]
* SNMPv1消息处理模型和基于社区的安全模型，提供了将SNMPv1和SNMPv2c适应基于视图的访问控制模型（VACM）的机制[27]
Readers should consult the latest version of the "Internet Official Protocol Standards" list [20] to determine the standardization status of any document.
读者应查阅最新版本的“互联网官方协议标准”列表[20]，以确定任何文件的标准化状态。
However, the SNMPv3 Working Group explicitly requested that text be included in this document to amplify on the status of SMIv1, SNMPv1, and SNMPv2c.
然而，SNMPv3工作组明确要求在本文件中包含文本，以详述SMIv1、SNMPv1和SNMPv2c的状态。
SMIv1, as described in STD 16, RFCs 1155 and 1212, was promoted to full Standard status in 1990 and has remained a Standard even after SMIv2 reached full Standard (see RFC 2026 [35] for more information about the Internet Standards Process). In many cases, a Standard is declared "Historic" when its replacement reaches full Standard. For example, MIB-1 [8] was declared "Historic" when MIB-2 [6] reached full Standard. Similarly, when SMIv2 reached full Standard, it might have been reasonable at that time to retire SMIv1 and declare it to be "Historic" but as the result of a conscious decision, STD 16, RFCs 1155 and 1212 continue to have the standardization status of full "Standard" but are not recommended. These documents were not declared "Historic" and remain on the standards track because they provide normative references for other documents on the standards track and cannot be declared "Historic" without rendering the documents which rely on them to also become "Historic". Consequently, STD 16 retains its standardization status but is not recommended because it has been superseded by the newer SMIv2 specifications which are identified somewhat later in this document.
如STD 16、RFCs 1155和1212所述，SMIv1于1990年被提升为完全标准状态，即使在SMIv2达到完全标准后仍然是标准（有关互联网标准流程的更多信息，请参见RFC 2026[35]）。在许多情况下，当替换标准达到完全标准时，该标准被宣布为“历史性”标准。例如，当MIB-2[6]达到完全标准时，MIB-1[8]被宣布为“历史”。同样，当SMIv2达到完全标准时，在当时退出SMIv1并宣布其为“历史性”可能是合理的，但由于有意识的决定，STD 16、RFCs 1155和1212继续具有完全“标准”的标准化状态，但不推荐使用。这些文件未被宣布为“历史文件”，并保留在标准轨道上，因为它们为标准轨道上的其他文件提供了规范性参考，并且在不使依赖它们的文件也成为“历史文件”的情况下，不能被宣布为“历史文件”。因此，STD 16保留其标准化状态，但不推荐使用，因为它已被本文件稍后确定的较新SMIv2规范所取代。
On a pragmatic level, since about 1993 it has been wise for users of the data definition language to use SMIv2 for all new work because the realities of the marketplace have occasionally required the support of data definitions in both the SMIv1 and SMIv2 formats. While there are tools widely available at low cost or no cost to translate SMIv2 definitions to SMIv1 definitions, it is impractical
从实用的角度来看，自1993年以来，数据定义语言的用户在所有新工作中使用SMIv2是明智的，因为市场的现实偶尔需要SMIv1和SMIv2格式的数据定义支持。虽然有很多工具可以低成本或免费将SMIv2定义转换为SMIv1定义，但这是不切实际的
to build automatic tools that automatically translate SMIv1 definitions to SMIv2 definitions. Consequently, if one works in primarily SMIv2, the cost of providing data definitions in both SMIv1 and SMIv2 formats is trivial. In contrast, if one works primarily in SMIv1 format, providing data definitions in both SMIv1 and SMIv2 is significantly more expensive. The market requirements today for providing data definitions in SMIv1 format are greatly diminished when compared to those of 1993, and SMIv2 continues to be the strongly preferred format even though SMIv1 has not been declared "Historic". Indeed, the IETF currently requires that new MIB modules be written using SMIv2.
构建自动将SMIv1定义转换为SMIv2定义的自动工具。因此，如果主要使用SMIv2，则以SMIv1和SMIv2格式提供数据定义的成本很低。相比之下，如果主要以SMIv1格式工作，则在SMIv1和SMIv2中提供数据定义的成本要高得多。与1993年相比，目前市场对以SMIv1格式提供数据定义的要求大大降低了，尽管SMIv1尚未被宣布为“历史”格式，但SMIv2仍然是首选格式。实际上，IETF目前要求使用SMIv2编写新的MIB模块。
Protocol operations via SNMPv1 and SNMPv2c message wrappers support only trivial authentication based on plain-text community strings and, as a result, are fundamentally insecure. When the SNMPv3 specifications for security and administration, which include strong security, reached full Standard status, the full Standard SNMPv1, formerly STD 15 [5], and the experimental SNMPv2c specifications described in RFC 1901 [16] were declared Historic due to their weaknesses with respect to security and to send a clear message that the third version of the Internet Standard Management Framework is the framework of choice. The Party-based SNMPv2 (SNMPv2p), SNMPv2u, and SNMPv2* were either declared Historic circa 1995 or were never on the standards track.
通过SNMPv1和SNMPv2c消息包装器进行的协议操作只支持基于纯文本社区字符串的普通身份验证，因此从根本上讲是不安全的。当SNMPv3安全和管理规范（包括强安全性）达到完全标准状态时，完整标准SNMPv1（以前为STD 15[5]）和RFC 1901[16]中描述的实验性SNMPv2c规范由于其在安全方面的弱点而被宣布为历史性的，并发出一个明确的信息，即第三版互联网标准管理框架是首选框架。以政党为基础的SNMPv2（SNMPv2p）、SNMPv2u和SNMPv2*要么在1995年左右被宣布为历史性的，要么从未进入标准轨道。
On a pragmatic level, it is expected that a number of vendors will continue to produce and users will continue to deploy and use multi-lingual implementations that support SNMPv1 and/or SNMPv2c as well as SNMPv3. It should be noted that the IETF standards process does not control actions of vendors or users who may choose to promote or deploy historic protocols, such as SNMPv1 and SNMPv2c, in spite of known short-comings. However, it is not expected that vendors will produce nor that users will deploy multi-lingual implementations that support the Party-based SNMPv2p (SNMPv2p), SNMPv2u, or SNMPv2*.
在实际层面上，预计许多供应商将继续生产，用户将继续部署和使用支持SNMPv1和/或SNMPv2c以及SNMPv3的多语言实现。应注意的是，IETF标准过程并不控制可能选择推广或部署历史协议（如SNMPv1和SNMPv2c）的供应商或用户的行为，尽管存在已知的缺陷。但是，预计供应商不会生产或用户不会部署支持基于参与方的SNMPv2p（SNMPv2p）、SNMPv2u或SNMPv2*的多语言实现。
Indeed, as described above, one of the SNMPv3 specifications for security and administration, RFC 2576, Coexistence between Version 1, Version 2, and Version 3 of the Internet-Standard Management Framework [28], addresses these issues.
事实上，如上所述，SNMPv3安全和管理规范之一RFC 2576，即互联网标准管理框架第1版、第2版和第3版之间的共存[28]，解决了这些问题。
Of course, it is important that users deploying multi-lingual systems with insecure protocols exercise sufficient due diligence to insure that configurations limit access via SNMPv1 and SNMPv2c appropriately, in keeping with the organization's security policy, just as they should carefully limit access granted via SNMPv3 with a security level of no authentication and no privacy which is roughly
当然，重要的是，使用不安全协议部署多语言系统的用户应进行充分的尽职调查，以确保配置适当限制通过SNMPv1和SNMPv2c的访问，以符合组织的安全策略，正如他们应该小心地限制通过SNMPv3授予的访问权限，安全级别为无身份验证和无隐私，这大致相当于
equivalent from a security point of view. For example, it is probably unwise to allow SNMPv1 or SNMPv2c a greater level of access than is provided to unauthenticated SNMPv3 users, e.g., it does not make sense to guard the front door with armed guards, trained attack dogs, moats and drawbridges while providing unfettered access through an open back door.
从安全性的角度来看是等效的。例如，与未经认证的SNMPv3用户相比，允许SNMPv1或SNMPv2c具有更高的访问级别可能是不明智的，例如，使用武装警卫、训练有素的攻击犬、护城河和吊桥来守卫前门，同时通过打开的后门提供不受限制的访问是没有意义的。
The SNMPv1 framework, SNMPv2 framework, and SNMPv2c had limited capabilities for administering the SNMPv1 and SNMPv2c protocols. For example, there are no objects defined to view and configure communities or destinations for notifications (traps and informs). The result has been vendor defined mechanisms for administration that range from proprietary format configuration files that cannot be viewed or configured via SNMP to enterprise specific object definitions. The SNMPv3 framework provides a rich standards-based approach to administration which, by design, can be used for the SNMPv1 and SNMPv2c protocols. Thus, to foster interoperability of administration of SNMPv1 and SNMPv2c protocols in multi-lingual systems, the mechanisms and objects specified in [25], [27], and [28] should be used to supplement or replace the equivalent proprietary mechanisms.
SNMPv1框架、SNMPv2框架和SNMPv2c管理SNMPv1和SNMPv2c协议的能力有限。例如，没有定义用于查看和配置社区或通知目的地（陷阱和通知）的对象。其结果是供应商定义的管理机制，范围从无法通过SNMP查看或配置的专有格式配置文件到特定于企业的对象定义。SNMPv3框架提供了一种丰富的基于标准的管理方法，通过设计，该方法可用于SNMPv1和SNMPv2c协议。因此，为了促进多语言系统中SNMPv1和SNMPv2c协议管理的互操作性，应使用[25]、[27]和[28]中规定的机制和对象来补充或替换等效的专有机制。
Based on the explanations above, the SNMPv3 Working Group recommends that RFCs 1157, 1441, 1901, 1909 and 1910 be reclassified as Historical documents.
根据上述解释，SNMPv3工作组建议将RFC 1157、1441、1901、1909和1910重新归类为历史文件。
As this document is primarily a roadmap document, it introduces no new security considerations. The reader is referred to the relevant sections of each of the referenced documents for information about security considerations.
由于本文档主要是一个路线图文档，因此没有引入新的安全注意事项。读者可参考各参考文件的相关章节，了解有关安全注意事项的信息。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March, 1997.
[1] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[2] Cerf, V., "IAB Recommendations for the Development of Internet Network Management Standards", RFC 1052, April 1988.
[2] Cerf，V.，“IAB关于制定互联网网络管理标准的建议”，RFC 1052，1988年4月。
[3] Rose, M. and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based internets", STD 16, RFC 1155, May 1990.
[3] Rose，M.和K.McCloghrie，“基于TCP/IP的互联网管理信息的结构和识别”，STD 16，RFC 1155，1990年5月。
[4] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 16, RFC 1212, March 1991.
[4] Rose，M.和K.McCloghrie，“简明MIB定义”，STD 16，RFC 1212，1991年3月。
[5] Case, J., Fedor, M., Schoffstall, M. and Davin, J., "Simple Network Management Protocol", STD 15, RFC 1157, May 1990.
[5] Case，J.，Fedor，M.，Schoffstall，M.和Davin，J.，“简单网络管理协议”，STD 15，RFC 1157，1990年5月。
[6] McCloghrie, K. and M. Rose, "Management Information Base for Network Management of TCP/IP-based internets: MIB-II", STD 17, RFC 1213, March 1991.
[6] McCloghrie，K.和M.Rose，“基于TCP/IP的互联网网络管理的管理信息库：MIB-II”，STD 17，RFC 1213，1991年3月。
[7] Rose, M., "A Convention for Defining Traps for use with the SNMP", RFC 1215, March 1991.
[7] Rose，M.“定义用于SNMP的陷阱的约定”，RFC1215，1991年3月。
[8] McCloghrie, K. and M. Rose, "Management Information Base for Network Management of TCP/IP-based Internets", RFC 1156, March 1990.
[8] McCloghrie，K.和M.Rose，“基于TCP/IP的互联网网络管理的管理信息库”，RFC 1156，1990年3月。
[9] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Structure of Management Information for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1902, January 1996.
[9] Case，J.，McCloghrie，K.，Rose，M.和S.Waldbusser，“简单网络管理协议（SNMPv2）版本2的管理信息结构”，RFC 1902，1996年1月。
[10] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Textual Conventions for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1903, January 1996.
[10] Case，J.，McCloghrie，K.，Rose，M.和S.Waldbusser，“简单网络管理协议（SNMPv2）版本2的文本约定”，RFC 1903，1996年1月。
[11] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Conformance Statements for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1904, January 1996.
[11] Case，J.，McCloghrie，K.，Rose，M.和S.Waldbusser，“简单网络管理协议（SNMPv2）版本2的一致性声明”，RFC 1904，1996年1月。
[12] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1905, January 1996.
[12] Case，J.，McCloghrie，K.，Rose，M.和S.Waldbusser，“简单网络管理协议（SNMPv2）版本2的协议操作”，RFC 1905，1996年1月。
[13] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1906, January 1996.
[13] Case，J.，McCloghrie，K.，Rose，M.和S.Waldbusser，“简单网络管理协议（SNMPv2）版本2的传输映射”，RFC 1906，1996年1月。
[14] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Management Information Base for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1907, January 1996.
[14] Case，J.，McCloghrie，K.，Rose，M.和S.Waldbusser，“简单网络管理协议（SNMPv2）版本2的管理信息库”，RFC 1907，1996年1月。
[15] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Coexistence between Version 1 and Version 2 of the Internet-Standard Network Management Framework", RFC 2576, January 1996.
[15] Case，J.，McCloghrie，K.，Rose，M.和S.Waldbusser，“互联网标准网络管理框架第1版和第2版之间的共存”，RFC 2576，1996年1月。
[16] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, January 1996.
[16] Case，J.，McCloghrie，K.，Rose，M.和S.Waldbusser，“基于社区的SNMPv2简介”，RFC 19011996年1月。
[17] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
[17] McCloghrie，K.，Perkins，D.，Schoenwaeld，J.，Case，J.，Rose，M.和S.Waldbusser，“管理信息的结构版本2（SMIv2）”，STD 58，RFC 2578，1999年4月。
[18] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999.
[18] McCloghrie，K.，Perkins，D.，Schoenwaeld，J.，Case，J.，Rose，M.和S.Waldbusser，“SMIv2的文本约定”，STD 58，RFC 2579，1999年4月。
[19] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999.
[19] McCloghrie，K.，Perkins，D.，Schoenwaeld，J.，Case，J.，Rose，M.和S.Waldbusser，“SMIv2的一致性声明”，STD 58，RFC 25801999年4月。
[20] "Official Internet Protocol Standards", http://www.rfc-editor.org/rfcxx00.html also STD0001.
[20] “官方互联网协议标准”，http://www.rfc-editor.org/rfcxx00.html 另外还有std001。
[21] Presuhn, R., Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3416, December 2002.
[21] Presohn，R.，Case，J.，McCloghrie，K.，Rose，M.和S.Waldbusser，“简单网络管理协议（SNMP）的协议操作版本2”，STD 62，RFC 3416，2002年12月。
[22] Presuhn, R., Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Transport Mappings for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3417, December 2002.
[22] Presohn，R.，Case，J.，McCloghrie，K.，Rose，M.和S.Waldbusser，“简单网络管理协议（SNMP）的传输映射”，STD 62，RFC 34172002年12月。
[23] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002.
[23] Harrington，D.，Presohn，R.和B.Wijnen，“描述简单网络管理协议（SNMP）管理框架的体系结构”，STD 62，RFC 3411，2002年12月。
[24] Case, J., Harrington, D., Presuhn, R. and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3412, December 2002.
[24] Case，J.，Harrington，D.，Presohn，R.和B.Wijnen，“简单网络管理协议（SNMP）的消息处理和调度”，STD 62，RFC 3412，2002年12月。
[25] Levi, D., Meyer, P. and B. Stewart, "Simple Network Management Protocol (SNMP) Applications", STD 62, RFC 3413, December 2002.
[25] Levi，D.，Meyer，P.和B.Stewart，“简单网络管理协议（SNMP）应用”，STD 62，RFC 3413，2002年12月。
[26] Blumenthal, U. and B. Wijnen, "User-Based Security Model (USM) for Version 3 of the Simple Network Management Protocol (SNMPv3)", STD 62, RFC 3414, December 2002.
[26] Blumenthal，U.和B.Wijnen，“简单网络管理协议（SNMPv3）第3版的基于用户的安全模型（USM）”，STD 62，RFC 3414，2002年12月。
[27] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3415, December 2002.
[27] Wijnen，B.，Presohn，R.和K.McCloghrie，“用于简单网络管理协议（SNMP）的基于视图的访问控制模型（VACM）”，STD 62，RFC 3415，2002年12月。
[28] Frye, R., Levi, D., Routhier, S. and B. Wijnen, "Coexistence between Version 1, Version 2, and Version 3 of the Internet-Standard Network Management Framework", RFC 2576, March 2000.
[28] Frye，R.，Levi，D.，Routhier，S.和B.Wijnen，“互联网标准网络管理框架第1版、第2版和第3版之间的共存”，RFC 2576，2000年3月。
[29] Information processing systems - Open Systems Interconnection - Specification of Abstract Syntax Notation One (ASN.1), International Organization for Standardization. International Standard 8824, (December, 1987).
[29] 信息处理系统.开放系统互连.国际标准化组织抽象语法符号1（ASN.1）规范。国际标准8824（1987年12月）。
[30] Presuhn, R., Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3418, December 2002.
[30] Presohn，R.，Case，J.，McCloghrie，K.，Rose，M.和S.Waldbusser，“简单网络管理协议（SNMP）的管理信息库（MIB）”，STD 62，RFC 3418，2002年12月。
[31] Rivest, R., "Message Digest Algorithm MD5", RFC 1321, April 1992.
[31] Rivest，R.，“消息摘要算法MD5”，RFC 13211992年4月。
[32] Secure Hash Algorithm. NIST FIPS 180-1, (April, 1995)
http://csrc.nist.gov/fips/fip180-1.txt (ASCII)
http://csrc.nist.gov/fips/fip180-1.ps (Postscript)
[32] Secure Hash Algorithm. NIST FIPS 180-1, (April, 1995)
http://csrc.nist.gov/fips/fip180-1.txt (ASCII)
http://csrc.nist.gov/fips/fip180-1.ps (Postscript)
[33] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[33] Krawczyk，H.，Bellare，M.和R.Canetti，“HMAC：用于消息身份验证的键控哈希”，RFC2104，1997年2月。
[34] Data Encryption Standard, National Institute of Standards and Technology. Federal Information Processing Standard (FIPS) Publication 46-1. Supersedes FIPS Publication 46, (January, 1977; reaffirmed January, 1988).
[34] 数据加密标准，国家标准与技术研究所。联邦信息处理标准（FIPS）出版物46-1。取代FIPS第46号出版物（1977年1月；1988年1月重申）。
[35] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October, 1996.
[35] Bradner，S.，“互联网标准过程——第3版”，BCP 9，RFC 2026，1996年10月。
Jeffrey Case SNMP Research, Inc. 3001 Kimberlin Heights Road Knoxville, TN 37920-9716 USA
Jeffrey Case SNMP Research，Inc.美国田纳西州诺克斯维尔金伯利高地路3001号，邮编37920-9716
Phone: +1 865 573 1434
EMail: case@snmp.com
Phone: +1 865 573 1434
EMail: case@snmp.com
Russ Mundy Network Associates Laboratories 15204 Omega Drive, Suite 300 Rockville, MD 20850-4601 USA
Russ Mundy Network Associates实验室美国马里兰州罗克维尔市欧米茄大道15204号300室20850-4601
Phone: +1 301 947 7107
EMail: mundy@tislabs.com
Phone: +1 301 947 7107
EMail: mundy@tislabs.com
David Partain Ericsson P.O. Box 1248 SE-581 12 Linkoping Sweden
David Partain Ericsson邮政信箱1248 SE-581 12 Linkoping瑞典
Phone: +46 13 28 41 44
EMail: David.Partain@ericsson.com
Phone: +46 13 28 41 44
EMail: David.Partain@ericsson.com
Bob Stewart Retired
鲍勃·斯图尔特退休了
Copyright (C) The Internet Society (2002). All Rights Reserved.
版权所有（C）互联网协会（2002年）。版权所有。
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 assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
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编辑功能的资金目前由互联网协会提供。