Network Working Group R. Frye
Request for Comments: 2576 CoSine Communications
Category: Standards Track D. Levi
Nortel Networks
S. Routhier
Integrated Systems Inc.
B. Wijnen
Lucent Technologies
March 2000
Network Working Group R. Frye
Request for Comments: 2576 CoSine Communications
Category: Standards Track D. Levi
Nortel Networks
S. Routhier
Integrated Systems Inc.
B. Wijnen
Lucent Technologies
March 2000
Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework
Internet标准网络管理框架版本1、版本2和版本3之间的共存
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
Abstract
摘要
The purpose of this document is to describe coexistence between version 3 of the Internet-standard Network Management Framework, (SNMPv3), version 2 of the Internet-standard Network Management Framework (SNMPv2), and the original Internet-standard Network Management Framework (SNMPv1). This document obsoletes RFC 1908 [13] and RFC2089 [14].
本文档旨在描述Internet标准网络管理框架（SNMPv3）第3版、Internet标准网络管理框架（SNMPv2）第2版和原始Internet标准网络管理框架（SNMPv1）之间的共存情况。本文件废除了RFC 1908[13]和RFC2089[14]。
Table Of Contents
目录
1 Overview ..................................................... 2
1.1 SNMPv1 ..................................................... 3
1.2 SNMPv2 ..................................................... 4
1.3 SNMPv3 ..................................................... 4
1.4 SNMPv1 and SNMPv2 Access to MIB Data ....................... 5
2 SMI and Management Information Mappings ...................... 5
2.1 MIB Modules ................................................ 6
2.1.1 Object Definitions ....................................... 6
2.1.2 Trap and Notification Definitions ........................ 9
2.2 Compliance Statements ...................................... 9
2.3 Capabilities Statements .................................... 10
1 Overview ..................................................... 2
1.1 SNMPv1 ..................................................... 3
1.2 SNMPv2 ..................................................... 4
1.3 SNMPv3 ..................................................... 4
1.4 SNMPv1 and SNMPv2 Access to MIB Data ....................... 5
2 SMI and Management Information Mappings ...................... 5
2.1 MIB Modules ................................................ 6
2.1.1 Object Definitions ....................................... 6
2.1.2 Trap and Notification Definitions ........................ 9
2.2 Compliance Statements ...................................... 9
2.3 Capabilities Statements .................................... 10
3 Translating Notifications Parameters ......................... 10
3.1 Translating SNMPv1 Notification Parameters to SNMPv2
Notification Parameters ................................... 12
3.2 Translating SNMPv2 Notification Parameters to SNMPv1
Notification Parameters ................................... 13
4 Approaches to Coexistence in a Multi-lingual Network ......... 14
4.1 Multi-lingual implementations .............................. 15
4.1.1 Command Generator ........................................ 15
4.1.2 Command Responder ........................................ 15
4.1.2.1 Handling Counter64 ..................................... 16
4.1.2.2 Mapping SNMPv2 Exceptions .............................. 16
4.1.2.2.1 Mapping noSuchObject and noSuchInstance .............. 17
4.1.2.2.2 Mapping endOfMibView ................................. 17
4.1.2.3 Processing An SNMPv1 GetRequest ........................ 18
4.1.2.4 Processing An SNMPv1 GetNextRequest .................... 19
4.1.2.5 Processing An SNMPv1 SetRequest ........................ 20
4.1.3 Notification Originator .................................. 20
4.1.4 Notification Receiver .................................... 21
4.2 Proxy Implementations ...................................... 21
4.2.1 Upstream Version Greater Than Downstream Version ......... 21
4.2.2 Upstream Version Less Than Downstream Version ............ 22
4.3 Error Status Mappings ...................................... 24
5 Message Processing Models and Security Models ................ 25
5.1 Mappings ................................................... 25
5.2 The SNMPv1 MP Model and SNMPv1 Community-based Security
Model ..................................................... 26
5.2.1 Processing An Incoming Request ........................... 26
5.2.2 Generating An Outgoing Response .......................... 28
5.2.3 Generating An Outgoing Notification ...................... 28
5.3 The SNMP Community MIB Module .............................. 29
6 Intellectual Property ........................................ 39
7 Acknowledgments .............................................. 39
8 Security Considerations ...................................... 40
9 References ................................................... 40
10 Editor's Addresses .......................................... 42
A. Changes From RFC1908 ........................................ 43
Full Copyright Statement ....................................... 44
3 Translating Notifications Parameters ......................... 10
3.1 Translating SNMPv1 Notification Parameters to SNMPv2
Notification Parameters ................................... 12
3.2 Translating SNMPv2 Notification Parameters to SNMPv1
Notification Parameters ................................... 13
4 Approaches to Coexistence in a Multi-lingual Network ......... 14
4.1 Multi-lingual implementations .............................. 15
4.1.1 Command Generator ........................................ 15
4.1.2 Command Responder ........................................ 15
4.1.2.1 Handling Counter64 ..................................... 16
4.1.2.2 Mapping SNMPv2 Exceptions .............................. 16
4.1.2.2.1 Mapping noSuchObject and noSuchInstance .............. 17
4.1.2.2.2 Mapping endOfMibView ................................. 17
4.1.2.3 Processing An SNMPv1 GetRequest ........................ 18
4.1.2.4 Processing An SNMPv1 GetNextRequest .................... 19
4.1.2.5 Processing An SNMPv1 SetRequest ........................ 20
4.1.3 Notification Originator .................................. 20
4.1.4 Notification Receiver .................................... 21
4.2 Proxy Implementations ...................................... 21
4.2.1 Upstream Version Greater Than Downstream Version ......... 21
4.2.2 Upstream Version Less Than Downstream Version ............ 22
4.3 Error Status Mappings ...................................... 24
5 Message Processing Models and Security Models ................ 25
5.1 Mappings ................................................... 25
5.2 The SNMPv1 MP Model and SNMPv1 Community-based Security
Model ..................................................... 26
5.2.1 Processing An Incoming Request ........................... 26
5.2.2 Generating An Outgoing Response .......................... 28
5.2.3 Generating An Outgoing Notification ...................... 28
5.3 The SNMP Community MIB Module .............................. 29
6 Intellectual Property ........................................ 39
7 Acknowledgments .............................................. 39
8 Security Considerations ...................................... 40
9 References ................................................... 40
10 Editor's Addresses .......................................... 42
A. Changes From RFC1908 ........................................ 43
Full Copyright Statement ....................................... 44
The purpose of this document is to describe coexistence between version 3 of the Internet-standard Network Management Framework, termed the SNMP version 3 framework (SNMPv3), version 2 of the Internet-standard Network Management Framework, termed the SNMP version 2 framework (SNMPv2), and the original Internet-standard Network Management Framework (SNMPv1).
本文件旨在描述Internet标准网络管理框架第3版（称为SNMP第3版框架（SNMPv3））和Internet标准网络管理框架第2版（称为SNMP第2版框架（SNMPv2））之间的共存关系，以及最初的互联网标准网络管理框架（SNMPv1）。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119 [15].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC2119[15]中所述进行解释。
There are four general aspects of coexistence described in this document. Each of these is described in a separate section:
本文件描述了共存的四个一般方面。每一项都在单独的章节中描述：
- Conversion of MIB documents between SMIv1 and SMIv2 formats is documented in section 2.
- 第2节记录了SMIv1和SMIv2格式之间MIB文档的转换。
- Mapping of notification parameters is documented in section 3.
- 第3节记录了通知参数的映射。
- Approaches to coexistence between entities which support the various versions of SNMP in a multi-lingual network is documented in section 4. This section addresses the processing of protocol operations in multi-lingual implementations, as well as behaviour of proxy implementations.
- 第4节介绍了在多语言网络中支持不同版本SNMP的实体之间共存的方法。本节介绍多语言实现中协议操作的处理，以及代理实现的行为。
- The SNMPv1 Message Processing Model and Community-Based Security Model, which provides mechanisms for adapting SNMPv1 into the View-Based Access Control Model (VACM) [20], is documented in section 5 (this section also addresses the SNMPv2c Message Processing Model and Community-Based Security Model).
- SNMPv1消息处理模型和基于社区的安全模型提供了将SNMPv1适应基于视图的访问控制模型（VACM）[20]的机制，第5节对此进行了说明（本节还讨论了SNMPv2c消息处理模型和基于社区的安全模型）。
SNMPv1 is defined by these documents:
SNMPv1由以下文件定义：
- STD 15, RFC 1157 [2] which defines the Simple Network Management Protocol (SNMPv1), the protocol used for network access to managed objects.
- STD 15，RFC 1157[2]定义了简单网络管理协议（SNMPv1），该协议用于对受管对象进行网络访问。
- STD 16, RFC 1155 [1] which defines the Structure of Management Information (SMIv1), the mechanisms used for describing and naming objects for the purpose of management.
- STD 16，RFC 1155[1]定义了管理信息的结构（SMIv1），即用于描述和命名对象以进行管理的机制。
- STD 16, RFC 1212 [3] which defines a more concise description mechanism, which is wholly consistent with the SMIv1.
- STD 16，RFC 1212[3]定义了一个更简洁的描述机制，它与SMIv1完全一致。
- RFC 1215 [4] which defines a convention for defining Traps for use with the SMIv1.
- RFC 1215[4]定义了一种约定，用于定义用于SMIv1的陷阱。
Note that throughout this document, the term 'SMIv1' is used. This term generally refers to the information presented in RFC 1155, RFC 1212, and RFC 1215.
请注意，在本文档中使用了术语“SMIv1”。该术语通常指RFC 1155、RFC 1212和RFC 1215中提供的信息。
SNMPv2 is defined by these documents:
SNMPv2由以下文件定义：
- STD 58, RFC 2578 which defines Version 2 of the Structure of Management Information (SMIv2) [7].
- STD 58，RFC 2578定义了管理信息结构（SMIv2）[7]的版本2。
- STD 58, RFC 2579 which defines common MIB "Textual Conventions" [8].
- STD 58，RFC 2579定义了通用MIB“文本约定”[8]。
- STD 58, RFC 2580 which defines Conformance Statements and requirements for defining agent and manager capabilities [9].
- STD 58，RFC 2580，定义了一致性声明和定义代理和经理能力的要求[9]。
- RFC 1905 which defines the Protocol Operations used in processing [10].
- RFC 1905定义了处理中使用的协议操作[10]。
- RFC 1906 which defines the Transport Mappings used "on the wire" [11].
- RFC 1906定义了“在线路上”使用的传输映射[11]。
- RFC 1907 which defines the basic Management Information Base for monitoring and controlling some basic common functions of SNMP entities [12].
- RFC 1907定义了用于监视和控制SNMP实体的一些基本公共功能的基本管理信息库[12]。
Note that SMIv2 as used throughout this document refers to the first three documents listed above (RFCs 2578, 2579, and 2580).
请注意，本文档中使用的SMIv2指的是上面列出的前三个文档（RFCs 2578、2579和2580）。
The following document augments the definition of SNMPv2:
以下文件补充了SNMPv2的定义：
- RFC 1901 [6] is an Experimental definition for using SNMPv2 PDUs within a community-based message wrapper. This is referred to throughout this document as SNMPv2c.
- RFC1901[6]是在基于社区的消息包装器中使用SNMPv2 PDU的实验性定义。本文件通篇将其称为SNMPv2c。
SNMPv3 is defined by these documents:
SNMPv3由以下文件定义：
- RFC 2571 which defines an Architecture for Describing SNMP Management Frameworks [16].
- RFC 2571定义了用于描述SNMP管理框架的体系结构[16]。
- RFC 2572 which defines Message Processing and Dispatching [17].
- RFC 2572定义了消息处理和调度[17]。
- RFC 2573 which defines various SNMP Applications [18].
- RFC 2573定义了各种SNMP应用程序[18]。
- RFC 2574 which defines the User-based Security Model (USM), providing for both Authenticated and Private (encrypted) SNMP messages [19].
- RFC 2574定义了基于用户的安全模型（USM），同时提供了经过身份验证和私有（加密）的SNMP消息[19]。
- RFC 2575 which defines the View-based Access Control Model (VACM), providing the ability to limit access to different MIB objects on a per-user basis [20].
- RFC 2575定义了基于视图的访问控制模型（VACM），提供了基于每个用户限制对不同MIB对象的访问的能力[20]。
SNMPv3 also uses the SNMPv2 definitions of RFCs 1905 through 1907 and the SMIv2 definitions of 2578 through 2580 described above.
SNMPv3还使用上述RFC 1905至1907的SNMPv2定义和2578至2580的SMIv2定义。
In several places, this document refers to 'SNMPv1 Access to MIB Data' and 'SNMPv2 Access to MIB Data'. These terms refer to the part of an SNMP agent which actually accesses instances of MIB objects, and which actually initiates generation of notifications. Differences between the two types of access to MIB data are:
在一些地方，本文件提到了“SNMPv1访问MIB数据”和“SNMPv2访问MIB数据”。这些术语指的是SNMP代理的一部分，它实际访问MIB对象的实例，并实际启动通知的生成。对MIB数据的两种访问类型之间的区别是：
- Error-status values generated.
- 生成错误状态值。
- Generation of exception codes.
- 生成异常代码。
- Use of the Counter64 data type.
- 计数器64数据类型的使用。
- The format of parameters provided when a notification is generated.
- 生成通知时提供的参数格式。
SNMPv1 access to MIB data may generate SNMPv1 error-status values, will never generate exception codes nor use the Counter64 data type, and will provide SNMPv1 format parameters for generating notifications. Note also that SNMPv1 access to MIB data will actually never generate a readOnly error (a noSuchName error would always occur in the situation where one would expect a readOnly error).
SNMPv1对MIB数据的访问可能会生成SNMPv1错误状态值，不会生成异常代码，也不会使用Counter64数据类型，并且会提供SNMPv1格式参数以生成通知。还要注意的是，SNMPv1对MIB数据的访问实际上永远不会产生只读错误（noSuchName错误总是发生在期望出现只读错误的情况下）。
SNMPv2 access to MIB data may generate SNMPv2 error-status values, may generate exception codes, may use the Counter64 data type, and will provide SNMPv2 format parameters for generating notifications. Note that SNMPv2 access to MIB data will never generate readOnly, noSuchName, or badValue errors.
SNMPv2对MIB数据的访问可能会生成SNMPv2错误状态值，可能会生成异常代码，可能会使用Counter64数据类型，并将提供SNMPv2格式参数以生成通知。请注意，SNMPv2对MIB数据的访问永远不会生成只读、noSuchName或badValue错误。
Note that a particular multi-lingual implementation may choose to implement all access to MIB data as SNMPv2 access to MIB data, and perform the translations described herein for SNMPv1-based transactions.
注意，特定多语言实现可以选择将对MIB数据的所有访问实现为对MIB数据的SNMPv2访问，并针对基于SNMPv1的事务执行本文描述的翻译。
The SMIv2 approach towards describing collections of managed objects is nearly a proper superset of the approach defined in the SMIv1. For example, both approaches use an adapted subset of ASN.1 (1988)
描述托管对象集合的SMIv2方法几乎是SMIv1中定义的方法的超集。例如，两种方法都使用了ASN.1（1988）的一个子集
[11] as the basis for a formal descriptive notation. Indeed, one might note that the SMIv2 approach largely codifies the existing practice for defining MIB modules, based on extensive experience with the SMIv1.
[11] 作为正式描述符号的基础。事实上，有人可能会注意到，SMIv2方法在很大程度上编纂了定义MIB模块的现有实践，这是基于SMIv1的丰富经验。
The following sections consider the three areas: MIB modules, compliance statements, and capabilities statements.
以下部分考虑了三个方面：MIB模块、遵从语句和能力语句。
MIB modules defined using the SMIv1 may continue to be used with protocol versions which use SNMPv2 PDUs. However, for the MIB modules to conform to the SMIv2, the following changes SHALL be made:
使用SMIv1定义的MIB模块可以继续与使用SNMPv2 PDU的协议版本一起使用。但是，为了使MIB模块符合SMIv2，应进行以下更改：
In general, conversion of a MIB module does not require the deprecation of the objects contained therein. If the definition of an object is truly inadequate for its intended purpose, the object SHALL be deprecated or obsoleted, otherwise deprecation is not required.
通常，MIB模块的转换不需要对其中包含的对象进行弃用。如果某一对象的定义确实不适合其预期用途，则该对象应弃用或废弃，否则不需要弃用。
(1) The IMPORTS statement MUST reference SNMPv2-SMI, instead of RFC1155-SMI and RFC-1212.
(1) IMPORTS语句必须引用SNMPv2 SMI，而不是RFC1155-SMI和RFC-1212。
(2) The MODULE-IDENTITY macro MUST be invoked immediately after any IMPORTs statement.
(2) 必须在任何IMPORTs语句之后立即调用MODULE-IDENTITY宏。
(3) For any object with an integer-valued SYNTAX clause, in which the corresponding INTEGER does not have a range restriction (i.e., the INTEGER has neither a defined set of named-number enumerations nor an assignment of lower- and upper-bounds on its value), the object MUST have the value of its SYNTAX clause changed to Integer32, or have an appropriate range specified.
(3) 对于具有整数值语法子句的任何对象，其中对应的整数没有范围限制（即，该整数既没有已定义的命名数字枚举集，也没有其值的上下限赋值），该对象必须将其语法子句的值更改为Integer32，或指定适当的范围。
(4) For any object with a SYNTAX clause value of Counter, the object MUST have the value of its SYNTAX clause changed to Counter32.
(4) 对于语法子句值为Counter的任何对象，该对象必须将其语法子句的值更改为Counter32。
(5) For any object with a SYNTAX clause value of Gauge, the object MUST have the value of its SYNTAX clause changed to Gauge32, or Unsigned32 where appropriate.
(5) 对于语法子句值为Gauge的任何对象，该对象必须将其语法子句的值更改为Gauge32，或在适当情况下更改为Unsigned32。
(6) For all objects, the ACCESS clause MUST be replaced by a MAX-ACCESS clause. The value of the MAX-ACCESS clause SHALL be the same as that of the ACCESS clause unless some other value makes "protocol sense" as the maximal level of access for the object. In particular, object types for which instances can be explicitly created by a protocol set operation, SHALL have a
(6) 对于所有对象，ACCESS子句必须替换为MAX-ACCESS子句。MAX-ACCESS子句的值应与ACCESS子句的值相同，除非其他值作为对象的最大访问级别具有“协议意义”。特别是，可通过协议集操作显式创建实例的对象类型应具有
MAX-ACCESS clause of "read-create". If the value of the ACCESS clause is "write-only", then the value of the MAX-ACCESS clause MUST be "read-write", and the DESCRIPTION clause SHALL note that reading this object will result in implementation-specific results. Note that in SMIv1, the ACCESS clause specifies the minimal required access, while in SMIv2, the MAX-ACCESS clause specifies the maximum allowed access. This should be considered when converting an ACCESS clause to a MAX-ACCESS clause.
“读取-创建”的MAX-ACCESS子句。如果ACCESS子句的值为“write only”，则MAX-ACCESS子句的值必须为“read-write”，并且DESCRIPTION子句应注意，读取此对象将产生特定于实现的结果。请注意，在SMIv1中，ACCESS子句指定了所需的最小访问权限，而在SMIv2中，MAX-ACCESS子句指定了允许的最大访问权限。将ACCESS子句转换为MAX-ACCESS子句时应考虑这一点。
(7) For all objects, if the value of the STATUS clause is "mandatory" or "optional", the value MUST be replaced with "current", "deprecated", or "obsolete" depending on the current usage of such objects.
(7) 对于所有对象，如果STATUS子句的值为“mandatory”或“optional”，则该值必须替换为“current”、“deprecated”或“过时”，具体取决于此类对象的当前使用情况。
(8) For any object not containing a DESCRIPTION clause, the object MUST have a DESCRIPTION clause defined.
(8) 对于不包含描述子句的任何对象，该对象必须定义描述子句。
(9) For any object corresponding to a conceptual row which does not have an INDEX clause, the object MUST have either an INDEX clause or an AUGMENTS clause defined.
(9) 对于与没有INDEX子句的概念行相对应的任何对象，该对象必须定义INDEX子句或AUGMENTS子句。
(10) If any INDEX clause contains a reference to an object with a syntax of NetworkAddress, then a new object MUST be created and placed in this INDEX clause immediately preceding the object whose syntax is NetworkAddress. This new object MUST have a syntax of INTEGER, it MUST be not-accessible, and its value MUST always be 1. This approach allows one to convert a MIB module in SMIv1 format to one in SMIv2 format, and then use it with the SNMPv1 protocol with no impact to existing SNMPv1 agents and managers.
（10） 如果任何索引子句包含对语法为NetworkAddress的对象的引用，则必须创建一个新对象，并将其放置在此索引子句中，紧靠语法为NetworkAddress的对象的前面。此新对象的语法必须为INTEGER，它必须不可访问，并且其值必须始终为1。这种方法允许将SMIv1格式的MIB模块转换为SMIv2格式的MIB模块，然后将其与SNMPv1协议一起使用，而不会影响现有的SNMPv1代理和管理器。
(11) For any object with a SYNTAX of NetworkAddress, the SYNTAX MUST be changed to IpAddress. Note that the use of NetworkAddress in new MIB documents is strongly discouraged (in fact, new MIB documents should be written using SMIv2, which does not define NetworkAddress).
（11） 对于语法为NetworkAddress的任何对象，必须将语法更改为IpAddress。请注意，强烈反对在新MIB文档中使用NetworkAddress（事实上，新MIB文档应该使用SMIv2编写，SMIv2不定义NetworkAddress）。
(12) For any object containing a DEFVAL clause with an OBJECT IDENTIFIER value which is expressed as a collection of sub-identifiers, the value MUST be changed to reference a single ASN.1 identifier. This may require defining a series of new administrative assignments (OBJECT IDENTIFIERS) in order to define the single ASN.1 identifier.
（12） 对于包含DEFVAL子句且对象标识符值表示为子标识符集合的任何对象，必须将该值更改为引用单个ASN.1标识符。这可能需要定义一系列新的管理分配（对象标识符），以便定义单个ASN.1标识符。
(13) One or more OBJECT-GROUPS MUST be defined, and related objects SHOULD be collected into appropriate groups. Note that SMIv2 requires all OBJECT-TYPEs to be a member of at least one OBJECT-GROUP.
（13） 必须定义一个或多个对象组，并将相关对象收集到适当的组中。请注意，SMIv2要求所有对象类型都必须是至少一个对象组的成员。
Other changes are desirable, but not necessary:
其他变更是可取的，但不是必要的：
(1) Creation and deletion of conceptual rows is inconsistent using the SMIv1. The SMIv2 corrects this. As such, if the MIB module undergoes review early in its lifetime, and it contains conceptual tables which allow creation and deletion of conceptual rows, then the objects relating to those tables MAY be deprecated and replaced with objects defined using the new approach. The approach based on SMIv2 can be found in section 7 of RFC2578 [7], and the RowStatus and StorageType TEXTUAL-CONVENTIONs are described in section 2 of RFC2579 [8].
(1) 使用SMIv1创建和删除概念行不一致。SMIv2纠正了这一点。因此，如果MIB模块在其生命周期的早期接受审查，并且它包含允许创建和删除概念行的概念表，那么与这些表相关的对象可能会被弃用，并替换为使用新方法定义的对象。基于SMIv2的方法可以在RFC2578[7]的第7节中找到，RowStatus和StorageType文本约定在RFC2579[8]的第2节中描述。
(2) For any object with a string-valued SYNTAX clause, in which the corresponding OCTET STRING does not have a size restriction (i.e., the OCTET STRING has no assignment of lower- and upper-bounds on its length), the bounds for the size of the object SHOULD be defined.
(2) 对于具有字符串值语法子句的任何对象，其中对应的八位字符串没有大小限制（即八位字符串的长度没有上下界的赋值），应定义对象大小的界。
(3) All textual conventions informally defined in the MIB module SHOULD be redefined using the TEXTUAL-CONVENTION macro. Such a change would not necessitate deprecating objects previously defined using an informal textual convention.
(3) MIB模块中非正式定义的所有文本约定都应该使用text-CONVENTION宏重新定义。这样的更改不需要弃用以前使用非正式文本约定定义的对象。
(4) For any object which represents a measurement in some kind of units, a UNITS clause SHOULD be added to the definition of that object.
(4) 对于以某种单位表示度量的任何对象，应在该对象的定义中添加units子句。
(5) For any conceptual row which is an extension of another conceptual row, i.e., for which subordinate columnar objects both exist and are identified via the same semantics as the other conceptual row, an AUGMENTS clause SHOULD be used in place of the INDEX clause for the object corresponding to the conceptual row which is an extension.
(5) 对于作为另一个概念行扩展的任何概念行，即，对于其从属列对象既存在又通过与另一个概念行相同的语义进行标识的概念行，应使用AUGMENTS子句代替作为扩展的概念行对应的对象的INDEX子句。
Finally, to avoid common errors in SMIv1 MIB modules:
最后，为了避免SMIv1 MIB模块中的常见错误：
(1) For any non-columnar object that is instanced as if it were immediately subordinate to a conceptual row, the value of the STATUS clause of that object MUST be changed to "obsolete".
(1) 对于实例化为直接从属于概念行的任何非列对象，该对象的STATUS子句的值必须更改为“过时”。
(2) For any conceptual row object that is not contained immediately subordinate to a conceptual table, the value of the STATUS clause of that object (and all subordinate objects) MUST be changed to "obsolete".
(2) 对于不直接从属于概念表的任何概念行对象，必须将该对象（以及所有从属对象）的STATUS子句的值更改为“过时”。
If a MIB module is changed to conform to the SMIv2, then each occurrence of the TRAP-TYPE macro MUST be changed to a corresponding invocation of the NOTIFICATION-TYPE macro:
如果将MIB模块更改为符合SMIv2，则陷阱类型宏的每次出现都必须更改为通知类型宏的相应调用：
(1) The IMPORTS statement MUST NOT reference RFC-1215 [4], and MUST reference SNMPv2-SMI instead.
(1) IMPORTS语句不能引用RFC-1215[4]，而必须引用SNMPv2 SMI。
(2) The ENTERPRISE clause MUST be removed.
(2) 必须删除企业条款。
(3) The VARIABLES clause MUST be renamed to the OBJECTS clause.
(3) 必须将VARIABLES子句重命名为OBJECTS子句。
(4) A STATUS clause MUST be added, with an appropriate value. Normally the value should be 'current,' although 'deprecated' or 'obsolete' may be used as needed.
(4) 必须添加具有适当值的STATUS子句。通常情况下，该值应为“当前”，但根据需要可以使用“已弃用”或“已过时”。
(5) The value of an invocation of the NOTIFICATION-TYPE macro is an OBJECT IDENTIFIER, not an INTEGER, and MUST be changed accordingly. Specifically, if the value of the ENTERPRISE clause is not 'snmp' then the value of the invocation SHALL be the value of the ENTERPRISE clause extended with two sub-identifiers, the first of which has the value 0, and the second has the value of the invocation of the TRAP-TYPE. If the value of the ENTERPRISE clause is 'snmp', then the value of the invocation of the NOTIFICATION-TYPE macro SHALL be mapped in the same manner as described in section 3.1 in this document.
(5) NOTIFICATION-TYPE宏调用的值是对象标识符，而不是整数，必须相应地更改。具体而言，如果ENTERPRISE子句的值不是“snmp”，则调用的值应是扩展了两个子标识符的ENTERPRISE子句的值，第一个子标识符的值为0，第二个子标识符的值为陷阱类型调用的值。如果企业条款的值为“snmp”，则通知类型宏调用的值应以本文件第3.1节所述的相同方式映射。
(6) A DESCRIPTION clause MUST be added, if not already present.
(6) 如果尚未出现描述子句，则必须添加描述子句。
(7) One or more NOTIFICATION-GROUPs MUST be defined, and related notifications MUST be collected into those groups. Note that SMIv2 requires that all NOTIFICATION-TYPEs be a member of at least one NOTIFICATION-GROUP.
(7) 必须定义一个或多个通知组，并且必须将相关通知收集到这些组中。请注意，SMIv2要求所有通知类型都是至少一个通知组的成员。
For those information modules which are "standards track", a corresponding invocation of the MODULE-COMPLIANCE macro and related OBJECT-GROUP and/or NOTIFICATION-GROUP macros MUST be included within the information module (or in a companion information module), and any commentary text in the information module which relates to compliance SHOULD be removed. Typically this editing can occur when the information module undergoes review.
对于属于“标准跟踪”的信息模块，信息模块（或配套信息模块）中必须包含对模块合规性宏和相关对象组和/或通知组宏的相应调用，信息模块中与合规性相关的任何注释文本都应删除。通常，当信息模块进行审查时，会进行此编辑。
Note that a MODULE-COMPLIANCE statement is not required for a MIB document that is not on the standards track (for example, an enterprise MIB), though it may be useful in some circumstances to define a MODULE-COMPLIANCE statement for such a MIB document.
请注意，不在标准轨道上的MIB文档（例如，企业MIB）不需要模块符合性声明，但在某些情况下，为此类MIB文档定义模块符合性声明可能很有用。
RFC1303 [5] uses the MODULE-CONFORMANCE macro to describe an agent's capabilities with respect to one or more MIB modules. Converting such a description for use with the SMIv2 requires these changes:
RFC1303[5]使用MODULE-CONNECTION宏来描述代理与一个或多个MIB模块相关的功能。转换此类描述以用于SMIv2需要进行以下更改：
(1) The macro name AGENT-CAPABILITIES SHOULD be used instead of MODULE-CONFORMANCE.
(1) 应使用宏名称AGENT-CAPABILITIES，而不是MODULE-compliance。
(2) The STATUS clause SHOULD be added, with a value of 'current'.
(2) 应添加STATUS子句，其值为“current”。
(3) All occurrences of the CREATION-REQUIRES clause MUST either be omitted if appropriate, or be changed such that the semantics are consistent with RFC2580 [9].
(3) CREATION-REQUIRES子句的所有出现都必须在适当的情况下省略，或者进行更改，以使语义与RFC2580[9]一致。
In order to ease coexistence, object groups defined in an SMIv1 compliant MIB module may be referenced by the INCLUDES clause of an invocation of the AGENT-CAPABILITIES macro: upon encountering a reference to an OBJECT IDENTIFIER subtree defined in an SMIv1 MIB module, all leaf objects which are subordinate to the subtree and have a STATUS clause value of mandatory are deemed to be INCLUDED. (Note that this method is ambiguous when different revisions of an SMIv1 MIB have different sets of mandatory objects under the same subtree; in such cases, the only solution is to rewrite the MIB using the SMIv2 in order to define the object groups unambiguously.)
为了简化共存，符合SMIv1的MIB模块中定义的对象组可以通过调用AGENT-CAPABILITIES宏的include子句引用：在遇到对SMIv1 MIB模块中定义的对象标识符子树的引用时，所有从属于子树且STATUS子句值为mandatory的叶对象都被视为包含在内。（请注意，当SMIv1 MIB的不同版本在同一子树下具有不同的强制对象集时，此方法是不明确的；在这种情况下，唯一的解决方案是使用SMIv2重写MIB，以便明确定义对象组。）
This section describes how parameters used for generating notifications are translated between the format used for SNMPv1 notification protocol operations and the format used for SNMPv2 notification protocol operations. The parameters used to generate a notification are called 'notification parameters'. The format of parameters used for SNMPv1 notification protocol operations is refered to in this document as 'SNMPv1 notification parameters'. The format of parameters used for SNMPv2 notification protocol operations is refered to in this document as 'SNMPv2 notification parameters'.
本节介绍如何在用于SNMPv1通知协议操作的格式和用于SNMPv2通知协议操作的格式之间转换用于生成通知的参数。用于生成通知的参数称为“通知参数”。用于SNMPv1通知协议操作的参数格式在本文档中称为“SNMPv1通知参数”。用于SNMPv2通知协议操作的参数格式在本文档中称为“SNMPv2通知参数”。
The situations where notification parameters MUST be translated are:
必须转换通知参数的情况有：
- When an entity generates a set of notification parameters in a particular format, and the configuration of the entity indicates that the notification must be sent using an SNMP message version that requires the other format for notification parameters.
- 当一个实体生成一组特定格式的通知参数，并且该实体的配置指示必须使用需要其他格式的通知参数的SNMP消息版本发送通知时。
- When a proxy receives a notification that was sent using an SNMP message version that requires one format of notification parameters, and must forward the notification using an SNMP message version that requires the other format of notification parameters.
- 当代理收到使用需要一种通知参数格式的SNMP消息版本发送的通知，并且必须使用需要其他通知参数格式的SNMP消息版本转发通知时。
In addition, it MAY be desirable to translate notification parameters in a notification receiver application in order to present notifications to the end user in a consistent format.
此外，可能希望翻译通知接收器应用程序中的通知参数，以便以一致的格式向最终用户呈现通知。
Note that for the purposes of this section, the set of notification parameters is independent of whether the notification is to be sent as a trap or an inform.
请注意，就本节而言，通知参数集与通知是作为陷阱还是通知发送无关。
SNMPv1 notification parameters consist of:
SNMPv1通知参数包括：
- An enterprise parameter (OBJECT IDENTIFIER).
- 企业参数（对象标识符）。
- An agent-addr parameter (NetworkAddress).
- 代理地址参数（网络地址）。
- A generic-trap parameter (INTEGER).
- 通用陷阱参数（整数）。
- A specific-trap parameter (INTEGER).
- 特定的陷阱参数（整数）。
- A time-stamp parameter (TimeTicks).
- 时间戳参数（TimeTicks）。
- A list of variable-bindings (VarBindList).
- 变量绑定列表（VarBindList）。
SNMPv2 notification parameters consist of:
SNMPv2通知参数包括：
- A sysUpTime parameter (TimeTicks). This appears in the first variable-binding in an SNMPv2-Trap-PDU or InformRequest-PDU.
- 系统正常运行时间参数（TimeTicks）。这出现在SNMPv2陷阱PDU或InformRequest PDU中的第一个变量绑定中。
- An snmpTrapOID parameter (OBJECT IDENTIFIER). This appears in the second variable-binding in an SNMPv2-Trap-PDU or InformRequest-PDU.
- snmpTrapOID参数（对象标识符）。这出现在SNMPv2陷阱PDU或InformRequest PDU中的第二个变量绑定中。
- A list of variable-bindings (VarBindList). This refers to all but the first two variable-bindings in an SNMPv2-Trap-PDU or InformRequest-PDU.
- 变量绑定列表（VarBindList）。这指的是SNMPv2陷阱PDU或InformRequest PDU中除前两个变量外的所有变量绑定。
3.1. Translating SNMPv1 Notification Parameters to SNMPv2 Notification Parameters
3.1. 将SNMPv1通知参数转换为SNMPv2通知参数
The following procedure describes how to translate SNMPv1 notification parameters into SNMPv2 notification parameters:
以下过程描述了如何将SNMPv1通知参数转换为SNMPv2通知参数：
(1) The SNMPv2 sysUpTime parameter SHALL be taken directly from the SNMPv1 time-stamp parameter.
(1) SNMPv2 sysUpTime参数应直接取自SNMPv1时间戳参数。
(2) If the SNMPv1 generic-trap parameter is 'enterpriseSpecific(6)', the SNMPv2 snmpTrapOID parameter SHALL be the concatentation of the SNMPv1 enterprise parameter and two additional sub-identifiers, '0', and the SNMPv1 specific-trap parameter.
(2) 如果SNMPv1通用陷阱参数为“enterpriseSpecific（6）”，则SNMPv2 snmpTrapOID参数应为SNMPv1企业参数和两个附加子标识符“0”以及SNMPv1特定陷阱参数的集中。
(3) If the SNMPv1 generic-trap parameter is not ' enterpriseSpecific(6)', the SNMPv2 snmpTrapOID parameter SHALL be the corresponding trap as defined in section 2 of RFC1907 [12]:
(3) 如果SNMPv1通用陷阱参数不是“企业特定（6）”，则SNMPv2 snmpTrapOID参数应为RFC1907[12]第2节中定义的相应陷阱：
generic-trap parameter snmpTrapOID.0
====================== =============
0 1.3.6.1.6.3.1.1.5.1 (coldStart)
1 1.3.6.1.6.3.1.1.5.2 (warmStart)
2 1.3.6.1.6.3.1.1.5.3 (linkDown)
3 1.3.6.1.6.3.1.1.5.4 (linkUp)
4 1.3.6.1.6.3.1.1.5.5 (authenticationFailure)
5 1.3.6.1.6.3.1.1.5.6 (egpNeighborLoss)
generic-trap parameter snmpTrapOID.0
====================== =============
0 1.3.6.1.6.3.1.1.5.1 (coldStart)
1 1.3.6.1.6.3.1.1.5.2 (warmStart)
2 1.3.6.1.6.3.1.1.5.3 (linkDown)
3 1.3.6.1.6.3.1.1.5.4 (linkUp)
4 1.3.6.1.6.3.1.1.5.5 (authenticationFailure)
5 1.3.6.1.6.3.1.1.5.6 (egpNeighborLoss)
(4) The SNMPv2 variable-bindings SHALL be the SNMPv1 variable-bindings. In addition, if the translation is being performed by a proxy in order to forward a received trap, three additional variable-bindings will be appended, if these three additional variable-bindings do not already exist in the SNMPv1 variable-bindings. The name portion of the first additional variable binding SHALL contain snmpTrapAddress.0, and the value SHALL contain the SNMPv1 agent-addr parameter. The name portion of the second additional variable binding SHALL contain snmpTrapCommunity.0, and the value SHALL contain the value of the community-string field from the received SNMPv1 message which contained the SNMPv1 Trap-PDU. The name portion of the third additional variable binding SHALL contain snmpTrapEnterprise.0 [12], and the value SHALL be the SNMPv1 enterprise parameter.
(4) SNMPv2变量绑定应为SNMPv1变量绑定。此外，如果代理正在执行转换以转发接收到的陷阱，那么如果SNMPv1变量绑定中不存在这三个附加变量绑定，则将附加三个附加变量绑定。第一个附加变量绑定的名称部分应包含snmpTrapAddress.0，该值应包含SNMPv1 agent addr参数。第二个附加变量绑定的名称部分应包含snmpTrapCommunity.0，该值应包含来自接收到的包含SNMPv1陷阱PDU的SNMPv1消息的社区字符串字段的值。第三个附加变量绑定的名称部分应包含snmpTrapEnterprise.0[12]，该值应为SNMPv1企业参数。
3.2. Translating SNMPv2 Notification Parameters to SNMPv1 Notification Parameters
3.2. 将SNMPv2通知参数转换为SNMPv1通知参数
The following procedure describes how to translate SNMPv2 notification parameters into SNMPv1 notification parameters:
以下过程描述了如何将SNMPv2通知参数转换为SNMPv1通知参数：
(1) The SNMPv1 enterprise parameter SHALL be determined as follows:
(1) SNMPv1企业参数的确定如下：
- If the SNMPv2 snmpTrapOID parameter is one of the standard traps as defined in RFC1907 [12], then the SNMPv1 enterprise parameter SHALL be set to the value of the variable-binding in the SNMPv2 variable-bindings whose name is snmpTrapEnterprise.0 if that variable-binding exists. If it does not exist, the SNMPv1 enterprise parameter SHALL be set to the value ' snmpTraps' as defined in RFC1907 [12].
- 如果SNMPv2 snmpTrapOID参数是RFC1907[12]中定义的标准陷阱之一，则SNMPv1 enterprise参数应设置为SNMPv2变量绑定中的变量绑定值，如果该变量绑定存在，则其名称为snmpTrapOID.0。如果不存在，则SNMPv1企业参数应设置为RFC1907[12]中定义的值“snmpTraps”。
- If the SNMPv2 snmpTrapOID parameter is not one of the standard traps as defined in RFC1907 [12], then the SNMPv1 enterprise parameter SHALL be determined from the SNMPv2 snmpTrapOID parameter as follows:
- 如果SNMPv2 snmpTrapOID参数不是RFC1907[12]中定义的标准陷阱之一，则应根据SNMPv2 snmpTrapOID参数确定SNMPv1 enterprise参数，如下所示：
- If the next-to-last sub-identifier of the snmpTrapOID is zero, then the SNMPv1 enterprise SHALL be the SNMPv2 snmpTrapOID with the last 2 sub-identifiers removed, otherwise
- 如果snmpTrapOID的下一个到最后一个子标识符为零，则SNMPv1企业应为删除最后2个子标识符的SNMPv2 snmpTrapOID，否则
- If the next-to-last sub-identifier of the snmpTrapOID is non-zero, then the SNMPv1 enterprise SHALL be the SNMPv2 snmpTrapOID with the last sub-identifier removed.
- 如果snmpTrapOID的倒数第二个子标识符为非零，则SNMPv1企业应为删除了最后一个子标识符的SNMPv2 snmpTrapOID。
(2) The SNMPv1 agent-addr parameter SHALL be determined based on the situation in which the translation occurs.
(2) SNMPv1 agent addr参数应根据翻译发生的情况确定。
- If the translation occurs within a notification originator application, and the notification is to be sent over IP, the SNMPv1 agent-addr parameter SHALL be set to the IP address of the SNMP entity in which the notification originator resides. If the notification is to be sent over some other transport, the SNMPv1 agent-addr parameter SHALL be set to 0.0.0.0.
- 如果转换发生在通知发起人应用程序中，且通知将通过IP发送，则SNMPv1 agent addr参数应设置为通知发起人所在SNMP实体的IP地址。如果通过其他传输发送通知，则SNMPv1 agent addr参数应设置为0.0.0.0。
- If the translation occurs within a proxy application, the proxy must attempt to extract the original source of the notification from the variable-bindings. If the SNMPv2 variable-bindings contains a variable binding whose name is snmpTrapAddress.0, the agent-addr parameter SHALL be set to the value of that variable binding. Otherwise, the SNMPv1 agent-addr parameter SHALL be set to 0.0.0.0.
- 如果转换发生在代理应用程序中，则代理必须尝试从变量绑定中提取通知的原始源。如果SNMPv2变量绑定包含一个名为snmpTrapAddress.0的变量绑定，则代理addr参数应设置为该变量绑定的值。否则，SNMPv1 agent addr参数应设置为0.0.0.0。
(3) If the SNMPv2 snmpTrapOID parameter is one of the standard traps as defined in RFC1907 [12], the SNMPv1 generic-trap parameter SHALL be set as follows:
(3) 如果SNMPv2 snmpTrapOID参数是RFC1907[12]中定义的标准陷阱之一，则SNMPv1通用陷阱参数应设置如下：
snmpTrapOID.0 parameter generic-trap
=============================== ============
1.3.6.1.6.3.1.1.5.1 (coldStart) 0
1.3.6.1.6.3.1.1.5.2 (warmStart) 1
1.3.6.1.6.3.1.1.5.3 (linkDown) 2
1.3.6.1.6.3.1.1.5.4 (linkUp) 3
1.3.6.1.6.3.1.1.5.5 (authenticationFailure) 4
1.3.6.1.6.3.1.1.5.6 (egpNeighborLoss) 5
snmpTrapOID.0 parameter generic-trap
=============================== ============
1.3.6.1.6.3.1.1.5.1 (coldStart) 0
1.3.6.1.6.3.1.1.5.2 (warmStart) 1
1.3.6.1.6.3.1.1.5.3 (linkDown) 2
1.3.6.1.6.3.1.1.5.4 (linkUp) 3
1.3.6.1.6.3.1.1.5.5 (authenticationFailure) 4
1.3.6.1.6.3.1.1.5.6 (egpNeighborLoss) 5
Otherwise, the SNMPv1 generic-trap parameter SHALL be set to 6.
否则，SNMPv1通用陷阱参数应设置为6。
(4) If the SNMPv2 snmpTrapOID parameter is one of the standard traps as defined in RFC1907 [12], the SNMPv1 specific-trap parameter SHALL be set to zero. Otherwise, the SNMPv1 specific-trap parameter SHALL be set to the last sub-identifier of the SNMPv2 snmpTrapOID parameter.
(4) 如果SNMPv2 snmpTrapOID参数是RFC1907[12]中定义的标准陷阱之一，则SNMPv1特定陷阱参数应设置为零。否则，SNMPv1特定陷阱参数应设置为SNMPv2 snmpTrapOID参数的最后一个子标识符。
(5) The SNMPv1 time-stamp parameter SHALL be taken directly from the SNMPv2 sysUpTime parameter.
(5) SNMPv1时间戳参数应直接取自SNMPv2系统正常运行时间参数。
(6) The SNMPv1 variable-bindings SHALL be the SNMPv2 variable-bindings. Note, however, that if the SNMPv2 variable-bindings contain any objects whose type is Counter64, the translation to SNMPv1 notification parameters cannot be performed. In this case, the notification cannot be encoded in an SNMPv1 packet (and so the notification cannot be sent using SNMPv1, see section 4.1.3 and section 4.2).
(6) SNMPv1变量绑定应为SNMPv2变量绑定。但是，请注意，如果SNMPv2变量绑定包含类型为Counter64的任何对象，则无法执行到SNMPv1通知参数的转换。在这种情况下，通知不能编码在SNMPv1数据包中（因此不能使用SNMPv1发送通知，请参见第4.1.3节和第4.2节）。
There are two basic approaches to coexistence in a multi-lingual network, multi-lingual implementations and proxy implementations. Multi-lingual implementations allow elements in a network to communicate with each other using an SNMP version which both elements support. This allows a multi-lingual implementation to communicate with any mono-lingual implementation, regardless of the SNMP version supported by the mono-lingual implementation.
在多语言网络中，有两种基本的共存方法：多语言实现和代理实现。多语言实现允许网络中的元素使用两个元素都支持的SNMP版本相互通信。这允许多语言实现与任何单语言实现进行通信，而不管单语言实现支持哪种SNMP版本。
Proxy implementations provide a mechanism for translating between SNMP versions using a third party network element. This allows network elements which support only a single, but different, SNMP version to communicate with each other. Proxy implementations are also useful for securing communications over an insecure link between two locally secure networks.
代理实现提供了一种使用第三方网络元素在SNMP版本之间进行转换的机制。这允许仅支持单一但不同的SNMP版本的网络元素相互通信。代理实现对于保护两个本地安全网络之间不安全链路上的通信也很有用。
This approach requires an entity to support multiple SNMP message versions. Typically this means supporting SNMPv1, SNMPv2c, and SNMPv3 message versions. The behaviour of various types of SNMP applications which support multiple message versions is described in the following sections. This approach allows entities which support multiple SNMP message versions to coexist with and communicate with entities which support only a single SNMP message version.
此方法要求实体支持多个SNMP消息版本。通常这意味着支持SNMPv1、SNMPv2c和SNMPv3消息版本。以下各节介绍了支持多个消息版本的各种类型的SNMP应用程序的行为。此方法允许支持多个SNMP消息版本的实体与仅支持单个SNMP消息版本的实体共存并与之通信。
A command generator must select an appropriate message version when sending requests to another entity. One way to achieve this is to consult a local database to select the appropriate message version.
命令生成器在向其他实体发送请求时必须选择适当的消息版本。实现这一点的一种方法是查阅本地数据库以选择适当的消息版本。
In addition, a command generator MUST 'downgrade' GetBulk requests to GetNext requests when selecting SNMPv1 as the message version for an outgoing request. This is done by simply changing the operation type to GetNext, ignoring any non-repeaters and max-repetitions values, and setting error-status and error-index to zero.
此外，当选择SNMPv1作为传出请求的消息版本时，命令生成器必须将GetBulk请求“降级”为GetNext请求。只需将操作类型更改为GetNext，忽略任何非中继器和最大重复次数值，并将错误状态和错误索引设置为零，即可完成此操作。
A command responder must be able to deal with both SNMPv1 and SNMPv2 access to MIB data. There are three aspects to dealing with this. A command responder must:
命令响应程序必须能够处理对MIB数据的SNMPv1和SNMPv2访问。处理这个问题有三个方面。命令响应者必须：
- Deal correctly with SNMPv2 access to MIB data that returns a Counter64 value while processing an SNMPv1 message,
- 正确处理SNMPv2对MIB数据的访问，该MIB数据在处理SNMPv1消息时返回Counter64值，
- Deal correctly with SNMPv2 access to MIB data that returns one of the three exception values while processing an SNMPv1 message, and
- 正确处理SNMPv2对MIB数据的访问，该MIB数据在处理SNMPv1消息时返回三个异常值之一，以及
- Map SNMPv2 error codes returned from SNMPv2 access to MIB data into SNMPv1 error codes when processing an SNMPv1 message.
- 处理SNMPv1消息时，将SNMPv2访问MIB数据返回的SNMPv2错误代码映射为SNMPv1错误代码。
Note that SNMPv1 error codes SHOULD NOT be used without any change when processing SNMPv2c or SNMPv3 messages, except in the case of proxy forwarding. In the case of proxy forwarding, for backwards compatibility, SNMPv1 error codes may be used without any change in a forwarded SNMPv2c or SNMPv3 message.
请注意，在处理SNMPv2c或SNMPv3消息时，除非在代理转发的情况下，否则不应在没有任何更改的情况下使用SNMPv1错误代码。在代理转发的情况下，为了向后兼容，可以使用SNMPv1错误代码，而不改变转发的SNMPv2c或SNMPv3消息。
The following sections describe the behaviour of a command responder application which supports multiple SNMP message versions, and which uses some combination of SNMPv1 and SNMPv2 access to MIB data.
以下部分描述了命令响应程序应用程序的行为，该应用程序支持多个SNMP消息版本，并使用SNMPv1和SNMPv2的某些组合来访问MIB数据。
The SMIv2 [7] defines one new syntax that is incompatible with SMIv1. This syntax is Counter64. All other syntaxes defined by SMIv2 are compatible with SMIv1.
SMIv2[7]定义了一种与SMIv1不兼容的新语法。此语法是Counter64。SMIv2定义的所有其他语法都与SMIv1兼容。
The impact on multi-lingual command responders is that they MUST NOT ever return a variable binding containing a Counter64 value in a response to a request that was received using the SNMPv1 message version.
对多语言命令响应程序的影响是，它们决不能在使用SNMPv1消息版本接收的请求响应中返回包含Counter64值的变量绑定。
Multi-lingual command responders SHALL take the approach that object instances whose type is Counter64 are implicitly excluded from view when processing an SNMPv1 message. So:
多语言命令响应者在处理SNMPv1消息时，应采取将类型为Counter64的对象实例隐式排除在视图之外的方法。因此：
- On receipt of an SNMPv1 GetRequest-PDU containing a variable binding whose name field points to an object instance of type Counter64, a GetResponsePDU SHALL be returned, with an error-status of noSuchName and the error-index set to the variable binding that caused this error.
- 收到包含变量绑定的SNMPv1 GetRequest PDU（其名称字段指向Counter64类型的对象实例）后，应返回GetResponsePDU，错误状态为noSuchName，错误索引设置为导致此错误的变量绑定。
- On an SNMPv1 GetNextRequest-PDU, any object instance which contains a syntax of Counter64 SHALL be skipped, and the next accessible object instance that does not have the syntax of Counter64 SHALL be retrieved. If no such object instance exists, then an error-status of noSuchName SHALL be returned, and the error-index SHALL be set to the variable binding that caused this error.
- 在SNMPv1 GetNextRequest PDU上，应跳过包含Counter64语法的任何对象实例，并应检索下一个不具有Counter64语法的可访问对象实例。如果不存在此类对象实例，则应返回noSuchName的错误状态，并将错误索引设置为导致此错误的变量绑定。
- Any SNMPv1 request which contains a variable binding with a Counter64 value is ill-formed, so the foregoing rules do not apply. If that error is detected, a response SHALL NOT be returned, since it would contain a copy of the ill-formed variable binding. Instead, the offending PDU SHALL be discarded and the counter snmpInASNParseErrs SHALL be incremented.
- 任何包含带有Counter64值的变量绑定的SNMPv1请求都是格式错误的，因此上述规则不适用。如果检测到该错误，则不应返回响应，因为它将包含格式错误的变量绑定的副本。相反，应丢弃有问题的PDU，并增加计数器snmpinasnparsers。
SNMPv2 provides a feature called exceptions, which allow an SNMPv2 Response PDU to return as much management information as possible, even when an error occurs. However, SNMPv1 does not support exceptions, and so an SNMPv1 Response PDU cannot return any management information, and can only return an error-status and error-index value.
SNMPv2提供了一种称为异常的功能，它允许SNMPv2响应PDU返回尽可能多的管理信息，即使在发生错误时也是如此。但是，SNMPv1不支持异常，因此SNMPv1响应PDU不能返回任何管理信息，只能返回错误状态和错误索引值。
When an SNMPv1 request is received, a command responder MUST check any variable bindings returned using SNMPv2 access to MIB data for exception values, and convert these exception values into SNMPv1 error codes.
当收到SNMPv1请求时，命令响应程序必须检查使用SNMPv2访问MIB数据返回的任何变量绑定是否存在异常值，并将这些异常值转换为SNMPv1错误代码。
The type of exception that can be returned when accessing MIB data and the action taken depends on the type of SNMP request.
访问MIB数据时可返回的异常类型以及所采取的操作取决于SNMP请求的类型。
- For a GetRequest, a noSuchObject or noSuchInstance exception may be returned.
- 对于GetRequest，可能会返回noSuchObject或noSuchInstance异常。
- For a GetNextRequest, an endOfMibView exception may be returned.
- 对于GetNextRequest，可能会返回endOfMibView异常。
- No exceptions will be returned for a SetRequest, and a GetBulkRequest should only be received in an SNMPv2c or SNMPv3 message, so these request types may be ignored when mapping exceptions.
- SetRequest不会返回任何异常，GetBulkRequest只应在SNMPv2c或SNMPv3消息中接收，因此在映射异常时可能会忽略这些请求类型。
Note that when a response contains multiple exceptions, it is an implementation choice as to which variable binding the error-index should reference.
请注意，当响应包含多个异常时，错误索引应该引用哪个绑定变量是一个实现选择。
A noSuchObject or noSuchInstance exception generated by an SNMPv2 access to MIB data indicates that the requested object instance can not be returned. The SNMPv1 error code for this condition is noSuchName, and so the error-status field of the response PDU SHALL be set to noSuchName. Also, the error-index field SHALL be set to the index of the variable binding for which an exception occurred (there may be more than one and it is an implementation decision as to which is used), and the variable binding list from the original request SHALL be returned with the response PDU.
SNMPv2访问MIB数据时生成的noSuchObject或noSuchInstance异常表示无法返回请求的对象实例。此条件下的SNMPv1错误代码为noSuchName，因此响应PDU的错误状态字段应设置为noSuchName。此外，应将错误索引字段设置为发生异常的变量绑定的索引（可能有多个，这是关于使用哪一个的实现决策），并且原始请求中的变量绑定列表应与响应PDU一起返回。
When an SNMPv2 access to MIB data returns a variable binding containing an endOfMibView exception, it indicates that there are no object instances available which lexicographically follow the object in the request. In an SNMPv1 agent, this condition normally results in a noSuchName error, and so the error-status field of the response PDU SHALL be set to noSuchName. Also, the error-index field SHALL be set to the index of the variable binding for which an exception occurred (there may be more than one and it is an implementation decision as to which is used), and the variable binding list from the original request SHALL be returned with the response PDU.
当SNMPv2对MIB数据的访问返回一个包含endOfMibView异常的变量绑定时，它表示没有在请求中按字典顺序跟随对象的对象实例可用。在SNMPv1代理中，这种情况通常会导致noSuchName错误，因此响应PDU的错误状态字段应设置为noSuchName。此外，应将错误索引字段设置为发生异常的变量绑定的索引（可能有多个，这是关于使用哪一个的实现决策），并且原始请求中的变量绑定列表应与响应PDU一起返回。
When processing an SNMPv1 GetRequest, the following procedures MUST be followed when using an SNMPv2 access to MIB data.
处理SNMPv1 GetRequest时，使用SNMPv2访问MIB数据时必须遵循以下过程。
When such an access to MIB data returns response data using SNMPv2 syntax and error-status values, then:
当这种对MIB数据的访问使用SNMPv2语法和错误状态值返回响应数据时，则：
(1) If the error-status is anything other than noError,
(1) 如果错误状态不是noError，
- The error status SHALL be translated to an SNMPv1 error-status using the table in section 4.3, "Error Status Mappings".
- 应使用第4.3节“错误状态映射”中的表格将错误状态转换为SNMPv1错误状态。
- The error-index SHALL be set to the position (in the original request) of the variable binding that caused the error-status.
- 错误索引应设置为导致错误状态的变量绑定的位置（在原始请求中）。
- The variable binding list of the response PDU SHALL be made exactly the same as the variable binding list that was received in the original request.
- 响应PDU的变量绑定列表应与原始请求中收到的变量绑定列表完全相同。
(2) If the error-status is noError, the variable bindings SHALL be checked for any SNMPv2 exception (noSuchObject or noSuchInstance) or an SNMPv2 syntax that is unknown to SNMPv1 (Counter64). If there are any such variable bindings, one of those variable bindings SHALL be selected (it is an implementation choice as to which is selected), and:
(2) 如果错误状态为noError，则应检查变量绑定是否存在SNMPv2异常（noSuchObject或noSuchInstance）或SNMPv1未知的SNMPv2语法（计数器64）。如果存在任何此类变量绑定，则应选择其中一个变量绑定（这是选择的实现选项），并且：
- The error-status SHALL be set to noSuchName,
- 错误状态应设置为noSuchName，
- The error-index SHALL be set to the position (in the variable binding list of the original request) of the selected variable binding, and
- 错误索引应设置为所选变量绑定的位置（在原始请求的变量绑定列表中），以及
- The variable binding list of the response PDU SHALL be exactly the same as the variable binding list that was received in the original request.
- 响应PDU的变量绑定列表应与原始请求中收到的变量绑定列表完全相同。
(3) If there are no such variable bindings, then:
(3) 如果没有此类变量绑定，则：
- The error-status SHALL be set to noError,
- 错误状态应设置为无错误，
- The error-index SHALL be set to zero, and
- 误差指数应设置为零，并且
- The variable binding list of the response SHALL be composed from the data as it is returned by the access to MIB data.
- 响应的变量绑定列表应由访问MIB数据返回的数据组成。
When processing an SNMPv1 GetNextRequest, the following procedures MUST be followed when an SNMPv2 access to MIB data is called as part of processing the request. There may be repetitive accesses to MIB data to try to find the first object which lexicographically follows each of the objects in the request. This is implementation specific. These procedures are followed only for data returned when using SNMPv2 access to MIB data. Data returned using SNMPv1 access to MIB data may be treated in the normal manner for an SNMPv1 request.
处理SNMPv1 GetNextRequest时，在处理请求时调用对MIB数据的SNMPv2访问时，必须遵循以下过程。可能存在对MIB数据的重复访问，以尝试查找第一个对象，该对象按字典顺序跟随请求中的每个对象。这是特定于实现的。只有在使用SNMPv2访问MIB数据时返回的数据才遵循这些过程。使用SNMPv1访问MIB数据返回的数据可以按照SNMPv1请求的正常方式处理。
First, if the access to MIB data returns an error-status of anything other than noError:
首先，如果对MIB数据的访问返回非noError的错误状态：
(1) The error status SHALL be translated to an SNMPv1 error-status using the table in section 4.3, "Error Status Mappings".
(1) 应使用第4.3节“错误状态映射”中的表格将错误状态转换为SNMPv1错误状态。
(2) The error-index SHALL be set to the position (in the original request) of the variable binding that caused the error-status.
(2) 错误索引应设置为导致错误状态的变量绑定的位置（在原始请求中）。
(3) The variable binding list of the response PDU SHALL be exactly the same as the variable binding list that was received in the original request.
(3) 响应PDU的变量绑定列表应与原始请求中收到的变量绑定列表完全相同。
Otherwise, if the access to MIB data returns an error-status of noError:
否则，如果对MIB数据的访问返回noError错误状态：
(1) Any variable bindings containing an SNMPv2 syntax of Counter64 SHALL be considered to be not in view, and MIB data SHALL be accessed as many times as is required until either a value other than Counter64 is returned, or an error occurs.
(1) 任何包含Counter64的SNMPv2语法的变量绑定都应视为不在视图中，并且应根据需要多次访问MIB数据，直到返回Counter64以外的值或发生错误。
(2) If there is any variable binding that contains an SNMPv2 exception endOfMibView (there may be more than one, it is an implementation decision as to which is chosen):
(2) 如果存在任何包含SNMPv2异常endOfMibView的变量绑定（可能有多个，选择哪一个是实现决策）：
- The error-status SHALL be set to noSuchName,
- 错误状态应设置为noSuchName，
- The error-index SHALL be set to the position (in the variable binding list of the original request) of the variable binding that returned such an SNMPv2 exception, and
- 错误索引应设置为返回此类SNMPv2异常的变量绑定的位置（在原始请求的变量绑定列表中），以及
- The variable binding list of the response PDU SHALL be exactly the same as the variable binding list that was received in the original request.
- 响应PDU的变量绑定列表应与原始请求中收到的变量绑定列表完全相同。
(3) If there are no such variable bindings, then:
(3) 如果没有此类变量绑定，则：
- The error-status SHALL be set to noError,
- 错误状态应设置为无错误，
- The error-index SHALL be set to zero, and
- 误差指数应设置为零，并且
- The variable binding list of the response SHALL be composed from the data as it is returned by the access to MIB data.
- 响应的变量绑定列表应由访问MIB数据返回的数据组成。
When processing an SNMPv1 SetRequest, the following procedures MUST be followed when calling SNMPv2 MIB access routines.
处理SNMPv1 SetRequest时，调用SNMPv2 MIB访问例程时必须遵循以下过程。
When such MIB access routines return response data using SNMPv2 syntax and error-status values, and the error-status is anything other than noError, then:
如果此类MIB访问例程使用SNMPv2语法和错误状态值返回响应数据，并且错误状态不是noError，则：
- The error status SHALL be translated to an SNMPv1 error-status using the table in section 4.3, "Error Status Mappings".
- 应使用第4.3节“错误状态映射”中的表格将错误状态转换为SNMPv1错误状态。
- The error-index SHALL be set to the position (in the original request) of the variable binding that caused the error-status.
- 错误索引应设置为导致错误状态的变量绑定的位置（在原始请求中）。
- The variable binding list of the response PDU SHALL be made exactly the same as the variable binding list that was received in the original request.
- 响应PDU的变量绑定列表应与原始请求中收到的变量绑定列表完全相同。
A notification originator must be able to translate between SNMPv1 notifications parameters and SNMPv2 notification parameters in order to send a notification using a particular SNMP message version. If a notification is generated using SNMPv1 notification parameters, and configuration information specifies that notifications be sent using SNMPv2c or SNMPv3, the notification parameters must be translated to SNMPv2 notification parameters. Likewise, if a notification is generated using SNMPv2 notification parameters, and configuration information specifies that notifications be sent using SNMPv1, the notification parameters must be translated to SNMPv1 notification parameters. In this case, if the notification cannot be translated (due to the presence of a Counter64 type), it will not be sent using SNMPv1.
通知发起人必须能够在SNMPv1通知参数和SNMPv2通知参数之间进行转换，以便使用特定的SNMP消息版本发送通知。如果使用SNMPv1通知参数生成通知，并且配置信息指定使用SNMPv2c或SNMPv3发送通知，则必须将通知参数转换为SNMPv2通知参数。同样，如果使用SNMPv2通知参数生成通知，并且配置信息指定使用SNMPv1发送通知，则必须将通知参数转换为SNMPv1通知参数。在这种情况下，如果通知无法翻译（由于存在Counter64类型），则不会使用SNMPv1发送通知。
When a notification originator generates a notification, using parameters obtained from the SNMP-TARGET-MIB and SNMP-NOTIFICATION-MIB, if the SNMP version used to generate the notification is SNMPv1, the PDU type used will always be a TrapPDU, regardless of whether the value of snmpNotifyType is trap(1) or inform(2).
当通知发起人使用从SNMP-TARGET-MIB和SNMP-notification-MIB获得的参数生成通知时，如果用于生成通知的SNMP版本是SNMPv1，则使用的PDU类型将始终是TrapPDU，而不管snmpNotifyType的值是陷阱（1）还是通知（2）。
Note also that access control and notification filtering are performed in the usual manner for notifications, regardless of the SNMP message version to be used when sending a notification. The parameters for performing access control are found in the usual manner (i.e., from inspecting the SNMP-TARGET-MIB and SNMP-NOTIFICATION-MIB). In particular, when generating an SNMPv1 Trap, in order to perform the access check specified in [18], section 3.3, bullet (3), the notification originator may need to generate a value for snmpTrapOID.0 as described in section 3.1, bullets (2) and (3) of this document. If the SNMPv1 notification parameters being used were previously translated from a set of SNMPv2 notification parameters, this value may already be known, in which case it need not be generated.
还请注意，访问控制和通知过滤是以通知的常规方式执行的，而与发送通知时使用的SNMP消息版本无关。执行访问控制的参数以通常的方式找到（即，通过检查SNMP-TARGET-MIB和SNMP-NOTIFICATION-MIB）。特别是，在生成SNMPv1陷阱时，为了执行[18]第3.3节项目符号（3）中规定的访问检查，通知发起人可能需要按照本文件第3.1节项目符号（2）和（3）中的说明为snmpTrapOID.0生成一个值。如果所使用的SNMPv1通知参数先前是从一组SNMPv2通知参数转换而来的，则该值可能已经已知，在这种情况下，不需要生成该值。
There are no special requirements of a notification receiver. However, an implementation may find it useful to allow a higher level application to request whether notifications should be delivered to a higher level application using SNMPv1 notification parameter or SNMPv2 notification parameters. The notification receiver would then translate notification parameters when required in order to present a notification using the desired set of parameters.
通知接收人没有特殊要求。然而，实现可能会发现允许更高级别的应用程序请求是否应使用SNMPv1通知参数或SNMPv2通知参数将通知传递给更高级别的应用程序是有用的。然后，通知接收方将在需要时转换通知参数，以便使用所需的参数集呈现通知。
A proxy implementation may be used to enable communication between entities which support different SNMP message versions. This is accomplished in a proxy forwarder application by performing translations on PDUs. These translations depend on the PDU type, the SNMP version of the packet containing a received PDU, and the SNMP version to be used to forward a received PDU. The following sections describe these translations. In all cases other than those described below, the proxy SHALL forward a received PDU without change, subject to size constraints as defined in section 5.3 (Community MIB) of this document. Note that in the following sections, the 'Upstream Version' refers to the version used between the command generator and the proxy, and the 'Downstream Version' refers to the version used between the proxy and the command responder, regardless of the PDU type or direction.
代理实现可用于支持不同SNMP消息版本的实体之间的通信。这是通过在PDU上执行翻译在代理转发器应用程序中实现的。这些转换取决于PDU类型、包含接收到的PDU的数据包的SNMP版本以及用于转发接收到的PDU的SNMP版本。以下各节介绍这些翻译。在除下文所述情况外的所有情况下，代理人应根据本文件第5.3节（社区MIB）中定义的大小限制，在不作更改的情况下转发收到的PDU。请注意，在以下章节中，“上游版本”指的是命令生成器和代理之间使用的版本，“下游版本”指的是代理和命令响应程序之间使用的版本，无论PDU类型或方向如何。
- If a GetBulkRequest-PDU is received and must be forwarded using the SNMPv1 message version, the proxy forwarder SHALL set the non-repeaters and max-repetitions fields to 0, and SHALL set the tag of the PDU to GetNextRequest-PDU.
- 如果收到GetBulkRequest PDU且必须使用SNMPv1消息版本转发，则代理转发器应将非中继器和最大重复字段设置为0，并将PDU的标记设置为GetNextRequest PDU。
- If a GetResponse-PDU is received whose error-status field has a value of 'tooBig', the message will be forwarded using the SNMPv2c or SNMPv3 message version, and the original request received by the proxy was not a GetBulkRequest-PDU, the proxy forwarder SHALL remove the contents of the variable-bindings field before forwarding the response.
- 如果收到错误状态字段值为“tooBig”的GetResponse PDU，则将使用SNMPv2c或SNMPv3消息版本转发消息，并且代理收到的原始请求不是GetBulkRequest PDU，则代理转发器应在转发响应之前删除变量绑定字段的内容。
- If a GetResponse-PDU is received whose error-status field has a value of 'tooBig,' and the message will be forwarded using the SNMPv2c or SNMPv3 message version, and the original request received by the proxy was a GetBulkRequest-PDU, the proxy forwarder SHALL re-send the forwarded request (which would have been altered to be a GetNextRequest-PDU) with all but the first variable-binding removed. The proxy forwarder SHALL only re-send such a request a single time. If the resulting GetResponse-PDU also contains an error-status field with a value of 'tooBig,' then the proxy forwarder SHALL remove the contents of the variable-bindings field, and change the error-status field to 'noError' before forwarding the response. Note that if the original request only contained a single variable-binding, the proxy may skip re-sending the request and simply remove the variable-bindings and change the error-status to 'noError.'
- 如果接收到错误状态字段值为“tooBig”的GetResponse PDU，并且该消息将使用SNMPv2c或SNMPv3消息版本转发，并且代理收到的原始请求是GetBulkRequest PDU，则代理转发器应重新发送转发的请求（该请求将被更改为GetNextRequest PDU）除去第一个变量绑定之外的所有变量绑定。代理转发商只能重新发送一次此类请求。如果生成的GetResponse PDU还包含值为“tooBig”的错误状态字段，则代理转发器应删除变量绑定字段的内容，并在转发响应之前将错误状态字段更改为“noError”。请注意，如果原始请求仅包含单个变量绑定，则代理可能会跳过重新发送请求，只需删除变量绑定并将错误状态更改为“noError”
- If a Trap-PDU is received, and will be forwarded using the SNMPv2c or SNMPv3 message version, the proxy SHALL apply the translation rules described in section 3, and SHALL forward the notification as an SNMPv2-Trap-PDU.
- 如果收到陷阱PDU，并将使用SNMPv2c或SNMPv3消息版本转发，则代理应应用第3节中描述的翻译规则，并应将通知作为SNMPv2陷阱PDU转发。
Note that when an SNMPv1 agent generates a message containing a Trap-PDU which is subsequently forwarded by one or more proxy forwarders using SNMP versions other than SNMPv1, the community string and agent-addr fields from the original message generated by the SNMPv1 agent will be preserved through the use of the snmpTrapAddress and snmpTrapCommunity nobjects.
请注意，当SNMPv1代理生成包含陷阱PDU的消息时，该陷阱PDU随后由一个或多个代理转发器使用SNMPv1以外的SNMP版本转发，SNMPv1代理生成的原始消息中的社区字符串和代理地址字段将通过使用snmpTrapAddress和SNMPTRAPComunity nobjects来保留。
- If a GetResponse-PDU is received in response to a GetRequest-PDU (previously generated by the proxy) which contains variable-bindings of type Counter64 or which contain an SNMPv2 exception code, and the message would be forwarded using the SNMPv1 message version, the proxy MUST generate an alternate response PDU consisting of the request-id and variable bindings from the original SNMPv1 request, containing a noSuchName error-status value, and containing an error-index value indicating the position of the variable-binding containing the Counter64 type or exception code.
- 如果收到GetResponse PDU以响应GetRequest PDU（以前由代理生成），该PDU包含Counter64类型的变量绑定或包含SNMPv2异常代码，并且该消息将使用SNMPv1消息版本转发，代理必须生成一个备用响应PDU，该PDU由原始SNMPv1请求的请求id和变量绑定组成，包含noSuchName错误状态值，并包含一个错误索引值，指示包含Counter64类型或异常代码的变量绑定的位置。
- If a GetResponse-PDU is received in response to a GetNextRequest-PDU (previously generated by the proxy) which contains variable-bindings that contain an SNMPv2 exception code, and the message would be forwarded using the SNMPv1 message version, the proxy MUST generate an alternate response PDU consisting of the request-id and variable bindings from the original SNMPv1 request, containing a noSuchName error-status value, and containing an error-index value indicating the position of the variable-binding containing the exception code.
- 如果收到GetResponse PDU以响应GetNextRequest PDU（以前由代理生成），该PDU包含包含SNMPv2异常代码的变量绑定，并且该消息将使用SNMPv1消息版本转发，代理必须生成一个备用响应PDU，该PDU由原始SNMPv1请求的请求id和变量绑定组成，包含noSuchName错误状态值，并包含一个错误索引值，指示包含异常代码的变量绑定的位置。
- If a GetResponse-PDU is received in response to a GetNextRequest-PDU (previously generated by the proxy) which contains variable-bindings of type Counter64, the proxy MUST re-send the entire GetNextRequest-PDU, with the following modifications. For any variable bindings in the received GetResponse which contained Counter64 types, the proxy substitutes the object names of these variable bindings for the corresponding object names in the previously-sent GetNextRequest. The proxy MUST repeat this process until no Counter64 objects are returned. Note that an implementation may attempt to optimize this process of skipping Counter64 objects. One approach to such an optimization would be to replace the last sub-identifier of the object names of varbinds containing a Counter64 type with 65535 if that sub-identifier is less than 65535, or with 4294967295 if that sub-identifier is greater than 65535. This approach should skip multiple instances of the same Counter64 object, while maintaining compatibility with some broken agent implementations (which only use 16-bit integers for sub-identifiers).
- 如果收到GetResponse PDU以响应包含Counter64类型的变量绑定的GetNextRequest PDU（以前由代理生成），则代理必须通过以下修改重新发送整个GetNextRequest PDU。对于接收到的GetResponse中包含Counter64类型的任何变量绑定，代理将用这些变量绑定的对象名替换先前发送的GetNextRequest中相应的对象名。代理必须重复此过程，直到不返回任何Counter64对象。请注意，实现可能会尝试优化跳过Counter64对象的过程。这种优化的一种方法是，如果包含Counter64类型的varbinds的对象名的最后一个子标识符小于65535，则将其替换为65535；如果该子标识符大于65535，则将其替换为4294967295。这种方法应该跳过同一个Counter64对象的多个实例，同时保持与某些中断代理实现（只使用16位整数作为子标识符）的兼容性。
Deployment Hint: The process of repeated GetNext requests used by a proxy when Counter64 types are returned can be expensive. When deploying a proxy, this can be avoided by configuring the target agents to which the proxy forwards requests in a manner such that any objects of type Counter64 are in fact not-in-view for the principal that the proxy is using when communicating with these agents.
部署提示：当返回Counter64类型时，代理使用的重复GetNext请求的过程可能会很昂贵。部署代理时，可以通过配置代理向其转发请求的目标代理来避免这种情况，配置方式应确保代理与这些代理通信时所使用的主体实际上看不到Counter64类型的任何对象。
- If a GetResponse-PDU is received which contains an SNMPv2 error-status value of wrongValue, wrongEncoding, wrongType, wrongLength, inconsistentValue, noAccess, notWritable, noCreation, inconsistentName, resourceUnavailable, commitFailed, undoFailed, or authorizationError, the error-status value is modified using the mappings in section 4.3.
- 如果收到的GetResponse PDU包含SNMPv2错误状态值ErrorValue、ErrorEncoding、ErrorType、ErrorLength、inconsistentValue、noAccess、notWritable、noCreation、inconsistentName、resourceUnavailable、commitFailed、undoFailed或authorizationError，则使用第4.3节中的映射修改错误状态值。
- If an SNMPv2-Trap-PDU is received, and will be forwarded using the SNMPv1 message version, the proxy SHALL apply the translation rules described in section 3, and SHALL forward the notification
- 如果收到SNMPv2陷阱PDU，并将使用SNMPv1消息版本转发，则代理应应用第3节中描述的翻译规则，并转发通知
as a Trap-PDU. Note that if the translation fails due to the existence of a Counter64 data-type in the received SNMPv2-Trap-PDU, the trap cannot be forwarded using SNMPv1.
作为陷阱PDU。请注意，如果由于接收到的SNMPv2陷阱PDU中存在Counter64数据类型而导致转换失败，则无法使用SNMPv1转发陷阱。
- If an InformRequest-PDU is received, any configuration information indicating that it would be forwarded using the SNMPv1 message version SHALL be ignored. An InformRequest-PDU can only be forwarded using the SNMPv2c or SNMPv3 message version. The InformRequest-PDU may still be forwarded if there is other configuration information indicating that it should be forwarded using SNMPv2c or SNMPv3.
- 如果接收到InformRequest PDU，则应忽略指示将使用SNMPv1消息版本转发的任何配置信息。InformRequest PDU只能使用SNMPv2c或SNMPv3消息版本转发。如果有其他配置信息指示应使用SNMPv2c或SNMPv3转发InformRequest PDU，则仍可转发该PDU。
The following tables shows the mappings of SNMPv1 error-status values into SNMPv2 error-status values, and the mappings of SNMPv2 error-status values into SNMPv1 error-status values.
下表显示了SNMPv1错误状态值到SNMPv2错误状态值的映射，以及SNMPv2错误状态值到SNMPv1错误状态值的映射。
SNMPv1 error-status SNMPv2 error-status
=================== ===================
noError noError
tooBig tooBig
noSuchName noSuchName
badValue badValue
genErr genErr
SNMPv1 error-status SNMPv2 error-status
=================== ===================
noError noError
tooBig tooBig
noSuchName noSuchName
badValue badValue
genErr genErr
SNMPv2 error-status SNMPv1 error-status
=================== ===================
noError noError
tooBig tooBig
genErr genErr
wrongValue badValue
wrongEncoding badValue
wrongType badValue
wrongLength badValue
inconsistentValue badValue
noAccess noSuchName
notWritable noSuchName
noCreation noSuchName
inconsistentName noSuchName
resourceUnavailable genErr
commitFailed genErr
undoFailed genErr
authorizationError noSuchName
SNMPv2 error-status SNMPv1 error-status
=================== ===================
noError noError
tooBig tooBig
genErr genErr
wrongValue badValue
wrongEncoding badValue
wrongType badValue
wrongLength badValue
inconsistentValue badValue
noAccess noSuchName
notWritable noSuchName
noCreation noSuchName
inconsistentName noSuchName
resourceUnavailable genErr
commitFailed genErr
undoFailed genErr
authorizationError noSuchName
Whenever the SNMPv2 error-status value of authorizationError is translated to an SNMPv1 error-status value of noSuchName, the value of snmpInBadCommunityUses MUST be incremented.
每当authorizationError的SNMPv2错误状态值转换为noSuchName的SNMPv1错误状态值时，snmpInBadCommunityUses的值必须递增。
In order to adapt SNMPv1 (and SNMPv2c) into the SNMP architecture, the following models are defined in this document:
为了使SNMPv1（和SNMPv2c）适应SNMP体系结构，本文档中定义了以下模型：
- The SNMPv1 Message Processing Model
- SNMPv1消息处理模型
- The SNMPv1 Community-Based Security Model
- 基于SNMPv1社区的安全模型
The following models are also described in this document:
本文件还介绍了以下型号：
- The SNMPv2c Message Processing Model
- SNMPv2c消息处理模型
- The SNMPv2c Community-Based Security Model
- 基于SNMPv2c社区的安全模型
In most respects, the SNMPv1 Message Processing Model and the SNMPv2c Message Processing Model are identical, and so these are not discussed independently in this document. Differences between the two models are described as required.
在大多数方面，SNMPv1消息处理模型和SNMPv2c消息处理模型是相同的，因此在本文档中不单独讨论。这两种模型之间的差异根据需要进行描述。
Similarly, the SNMPv1 Community-Based Security Model and the SNMPv2c Community-Based Security Model are nearly identical, and so are not discussed independently. Differences between these two models are also described as required.
类似地，基于SNMPv1社区的安全模型和基于SNMPv2c社区的安全模型几乎相同，因此不单独讨论。这两种模型之间的差异也根据需要进行了描述。
The SNMPv1 (and SNMPv2c) Message Processing Model and Security Model require mappings between parameters used in SNMPv1 (and SNMPv2c) messages, and the version independent parameters used in the SNMP architecture [16]. The parameters which MUST be mapped consist of the SNMPv1 (and SNMPv2c) community name, and the SNMP securityName and contextEngineID/contextName pair. A MIB module (the SNMP-COMMUNITY-MIB) is provided in this document in order to perform these mappings. This MIB provides mappings in both directions, that is, a community name may be mapped to a securityName, contextEngineID, and contextName, or the combination of securityName, contextEngineID, and contextName may be mapped to a community name.
SNMPv1（和SNMPv2c）消息处理模型和安全模型要求在SNMPv1（和SNMPv2c）消息中使用的参数与SNMP体系结构中使用的版本无关参数之间进行映射[16]。必须映射的参数包括SNMPv1（和SNMPv2c）社区名称，以及SNMP securityName和contextEngineID/contextName对。为了执行这些映射，本文提供了一个MIB模块（SNMP-COMMUNITY-MIB）。此MIB提供两个方向的映射，即，社区名称可以映射到securityName、contextEngineID和contextName，或者securityName、contextEngineID和contextName的组合可以映射到社区名称。
The SNMPv1 Message Processing Model handles processing of SNMPv1 messages. The processing of messages is handled generally in the same manner as described in RFC1157 [2], with differences and clarifications as described in the following sections. The SnmpMessageProcessingModel value for SNMPv1 is 0 (the value for SNMPv2c is 1).
SNMPv1消息处理模型处理SNMPv1消息的处理。消息的处理通常采用RFC1157[2]中所述的相同方式进行，其区别和澄清如下所述。SNMPv1的SnmpMessageProcessingModel值为0（SNMPv2c的值为1）。
In RFC1157 [2], section 4.1, item (3) for an entity which receives a message, states that various parameters are passed to the 'desired authentication scheme.' The desired authentication scheme in this case is the SNMPv1 Community-Based Security Model, which will be called using the processIncomingMsg ASI. The parameters passed to this ASI are:
在RFC1157[2]中，第4.1节第（3）项针对接收消息的实体，规定将各种参数传递给“期望的身份验证方案”。在这种情况下，期望的身份验证方案是基于SNMPv1社区的安全模型，将使用processIncomingMsg ASI调用该模型。传递给此ASI的参数为：
- The messageProcessingModel, which will be 0 (or 1 for SNMPv2c).
- messageProcessingModel，它将是0（对于SNMPv2c，它将是1）。
- The maxMessageSize, which should be the maximum size of a message that the receiving entity can generate (since there is no such value in the received message).
- maxMessageSize，它应该是接收实体可以生成的消息的最大大小（因为接收到的消息中没有这样的值）。
- The securityParameters, which consist of the community string and the message's source and destination transport domains and addresses.
- securityParameters，由社区字符串以及消息的源和目标传输域和地址组成。
- The securityModel, which will be 1 (or 2 for SNMPv2c).
- securityModel，将为1（对于SNMPv2c，为2）。
- The securityLevel, which will be noAuthNoPriv.
- 安全级别，将是noAuthNoPriv。
- The wholeMsg and wholeMsgLength.
- 总长度和总长度。
The Community-Based Security Model will attempt to select a row in the snmpCommunityTable. This is done by performing a search through the snmpCommunityTable in lexicographic order. The first entry for which the following matching criteria are satisfied will be selected:
基于社区的安全模型将尝试在snmpCommunityTable中选择一行。这是通过按字典顺序在snmpCommunityTable中执行搜索来完成的。将选择满足以下匹配条件的第一个条目：
- The community string is equal to the snmpCommunityName value.
- 社区字符串等于snmpCommunityName值。
- If the snmpCommunityTransportTag is an empty string, it is ignored for the purpose of matching. If the snmpCommunityTransportTag is not an empty string, the transportDomain and transportAddress from which the message was received must match one of the entries in the snmpTargetAddrTable selected by the snmpCommunityTransportTag
- 如果snmpCommunityTransportTag是空字符串，则出于匹配目的将忽略它。如果snmpCommunityTransportTag不是空字符串，则接收消息的transportDomain和transportAddress必须与snmpCommunityTransportTag选择的SNMPTargetAddr表中的一个条目匹配
value. The snmpTargetAddrTMask object is used as described in section 5.3 when checking whether the transportDomain and transportAddress matches a entry in the snmpTargetAddrTable.
价值当检查transportDomain和transportAddress是否与SNMPTargetADRDR表中的条目匹配时，将按照第5.3节所述使用SNMPTargetADRDR任务对象。
If no such entry can be found, an authentication failure occurs as described in RFC1157 [2], and the snmpInBadCommunityNames counter is incremented.
如果找不到此类条目，则会发生RFC1157[2]中所述的身份验证失败，并且snmpInBadCommunityNames计数器将递增。
The parameters returned from the Community-Based Security Model are:
从基于社区的安全模型返回的参数为：
- The securityEngineID, which will always be the local value of snmpEngineID.0.
- securityEngineID，它将始终是snmpEngineID.0的本地值。
- The securityName.
- 安全名称。
- The scopedPDU. Note that this parameter will actually consist of three values, the contextSnmpEngineID, the contextName, and the PDU. These must be separate values, since the first two do not actually appear in the message.
- 范围dpdu。请注意，此参数实际上将由三个值组成：contextSnmpEngineID、contextName和PDU。这些值必须是单独的，因为前两个值实际上不会出现在消息中。
- The maxSizeResponseScopedPDU.
- maxSizeResponseScopedPDU。
- The securityStateReference.
- securityStateReference。
The appropriate SNMP application will then be called (depending on the value of the contextEngineID and the request type in the PDU) using the processPdu ASI. The parameters passed to this ASI are:
然后将使用processPdu ASI调用相应的SNMP应用程序（取决于contextEngineID的值和PDU中的请求类型）。传递给此ASI的参数为：
- The messageProcessingModel, which will be 0 (or 1 for SNMPv2c).
- messageProcessingModel，它将是0（对于SNMPv2c，它将是1）。
- The securityModel, which will be 1 (or 2 for SNMPv2c).
- securityModel，将为1（对于SNMPv2c，为2）。
- The securityName, which was returned from the call to processIncomingMsg.
- securityName，从调用processIncomingMsg返回。
- The securityLevel, which is noAuthNoPriv.
- 安全级别，即noAuthNoPriv。
- The contextEngineID, which was returned as part of the ScopedPDU from the call to processIncomingMsg.
- contextEngineID，它是从processIncomingMsg调用返回的ScopedPDU的一部分。
- The contextName, which was returned as part of the ScopedPDU from the call to processIncomingMsg.
- contextName，在调用processIncomingMsg时作为ScopedPDU的一部分返回。
- The pduVersion, which should indicate an SNMPv1 version PDU (if the message version was SNMPv2c, this would be an SNMPv2 version PDU).
- PDU版本，它应该指示SNMPv1版本PDU（如果消息版本为SNMPv2c，则这将是SNMPv2版本PDU）。
- The PDU, which was returned as part of the ScopedPDU from the call to processIncomingMsg.
- PDU，作为对processIncomingMsg的调用的ScopedPDU的一部分返回。
- The maxSizeResponseScopedPDU which was returned from the call to processIncomingMsg.
- 调用processIncomingMsg返回的maxSizeResponseScopedPDU。
- The stateReference which was returned from the call to processIncomingMsg.
- 调用processIncomingMsg返回的stateReference。
The SNMP application should process the request as described previously in this document. Note that access control is applied by an SNMPv3 command responder application as usual. The parameters as passed to the processPdu ASI will be used in calls to the isAccessAllowed ASI.
SNMP应用程序应按照本文档前面所述处理请求。注意，访问控制通常由SNMPv3命令响应程序应用。传递给processPdu ASI的参数将用于调用isAccessAllowed ASI。
There is no special processing required for generating an outgoing response. However, the community string used in an outgoing response must be the same as the community string from the original request. The original community string MUST be present in the stateReference information of the original request.
生成传出响应不需要特殊处理。但是，传出响应中使用的社区字符串必须与原始请求中的社区字符串相同。原始社区字符串必须存在于原始请求的stateReference信息中。
In a multi-lingual SNMP entity, the parameters used for generating notifications will be obtained by examining the SNMP-TARGET-MIB and SNMP-NOTIFICATION-MIB. These parameters will be passed to the SNMPv1 Message Processing Model using the sendPdu ASI. The SNMPv1 Message Processing Model will attempt to locate an appropriate community string in the snmpCommunityTable based on the parameters passed to the sendPdu ASI. This is done by performing a search through the snmpCommunityTable in lexicographic order. The first entry for which the following matching criteria are satisfied will be selected:
在多语言SNMP实体中，用于生成通知的参数将通过检查SNMP-TARGET-MIB和SNMP-NOTIFICATION-MIB获得。这些参数将使用sendPdu ASI传递给SNMPv1消息处理模型。SNMPv1消息处理模型将根据传递给sendPdu ASI的参数，尝试在snmpCommunityTable中定位适当的社区字符串。这是通过按字典顺序在snmpCommunityTable中执行搜索来完成的。将选择满足以下匹配条件的第一个条目：
- The securityName must be equal to the snmpCommunitySecurityName value.
- securityName必须等于snmpCommunitySecurityName值。
- The contextEngineID must be equal to the snmpCommunityContextEngineID value.
- contextEngineID必须等于snmpCommunityContextEngineID值。
- The contextName must be equal to the snmpCommunityContextName value.
- contextName必须等于snmpCommunityContextName值。
- If the snmpCommunityTransportTag is an empty string, it is ignored for the purpose of matching. If the snmpCommunityTransportTag is not an empty string, the
- 如果snmpCommunityTransportTag是空字符串，则出于匹配目的将忽略它。如果snmpCommunityTransportTag不是空字符串，则
transportDomain and transportAddress must match one of the entries in the snmpTargetAddrTable selected by the snmpCommunityTransportTag value.
transportDomain和transportAddress必须与snmpCommunityTransportTag值选择的SNMPTargetAddR表中的一个条目匹配。
If no such entry can be found, the notification is not sent. Otherwise, the community string used in the outgoing notification will be the value of the snmpCommunityName column of the selected row.
如果找不到此类条目，则不会发送通知。否则，传出通知中使用的社区字符串将是所选行的snmpCommunityName列的值。
The SNMP-COMMUNITY-MIB contains objects for mapping between community strings and version-independent SNMP message parameters. In addition, this MIB provides a mechanism for performing source address validation on incoming requests, and for selecting community strings based on target addresses for outgoing notifications. These two features are accomplished by providing a tag in the snmpCommunityTable which selects sets of entries in the snmpTargetAddrTable [18]. In addition, the SNMP-COMMUNITY-MIB augments the snmpTargetAddrTable with a transport address mask value and a maximum message size value. These values are used only where explicitly stated. In cases where the snmpTargetAddrTable is used without mention of these augmenting values, the augmenting values should be ignored.
SNMP-COMMUNITY-MIB包含用于社区字符串和独立于版本的SNMP消息参数之间映射的对象。此外，此MIB还提供了一种机制，用于对传入请求执行源地址验证，以及基于传出通知的目标地址选择社区字符串。这两个特性是通过在snmpCommunityTable中提供一个标记来实现的，该标记选择SNMPTargetADRDR表中的一组条目[18]。此外，SNMP-COMMUNITY-MIB使用传输地址掩码值和最大消息大小值来扩充SNMPTargetADRDR表。这些值仅在明确说明的情况下使用。如果使用SNMPTargetADRDR表时未提及这些扩充值，则应忽略这些扩充值。
The mask value, snmpTargetAddrTMask, allows selected entries in the snmpTargetAddrTable to specify multiple addresses (rather than just a single address per entry). This would typically be used to specify a subnet in an snmpTargetAddrTable rather than just a single address. The mask value is used to select which bits of a transport address must match bits of the corresponding instance of snmpTargetAddrTAddress, in order for the transport address to match a particular entry in the snmpTargetAddrTable. The value of an instance of snmpTargetAddrTMask must always be an OCTET STRING whose length is either zero or the same as that of the corresponding instance of snmpTargetAddrTAddress.
掩码值SNMPTargetADRDRSK允许SNMPTargetADRDR表中的选定条目指定多个地址（而不是每个条目仅指定一个地址）。这通常用于指定SNMPTargetADRDR表中的子网，而不仅仅是单个地址。掩码值用于选择传输地址的哪些位必须与SNMPTargetADRDR地址的相应实例的位匹配，以便传输地址与SNMPTargetADRDR表中的特定条目匹配。snmptagetadrtmask实例的值必须始终是长度为零或与snmptagetadrtAddress对应实例的长度相同的八位字符串。
Note that the snmpTargetAddrTMask object is only used where explicitly stated. In particular, it is not used when generating notifications (i.e., when generating notifications, entries in the snmpTargetAddrTable only specify individual addresses).
请注意，SNMPTargetADRTMAK对象仅在明确说明的情况下使用。特别是，在生成通知时不使用它（即，在生成通知时，SNMPTargetADRDR表中的条目仅指定单个地址）。
When checking whether a transport address matches an entry in the snmpTargetAddrTable, if the value of snmpTargetAddrTMask is a zero-length OCTET STRING, the mask value is ignored, and the value of snmpTargetAddrTAddress must exactly match a transport address. Otherwise, each bit of each octet in the snmpTargetAddrTMask value corresponds to the same bit of the same octet in the
在检查传输地址是否与snmpTargetAddrTable中的条目匹配时，如果snmpTargetAddrTMask的值是长度为零的八位字节字符串，则将忽略掩码值，并且SNMPTargetADDRTADRADress的值必须与传输地址完全匹配。否则，SNMPTargetADRTMAK值中每个八位字节的每个位对应于
snmpTargetAddrTAddress value. For bits that are set in the snmpTargetAddrTMask value (i.e., bits equal to 1), the corresponding bits in the snmpTargetAddrTAddress value must match the bits in a transport address. If all such bits match, the transport address is matched by that snmpTargetAddrTable entry. Otherwise, the transport address is not matched.
snmptagedrdrdradress值。对于在SNMPtageTadRtmask值中设置的位（即等于1的位），SNMPtageTadRtmAddress值中的相应位必须与传输地址中的位匹配。如果所有这些位都匹配，则传输地址与SNMPTargetADRDR表条目匹配。否则，传输地址不匹配。
The maximum message size value, snmpTargetAddrMMS, is used to determine the maximum message size acceptable to another SNMP entity when the value cannot be determined from the protocol.
当无法从协议中确定最大消息大小值时，最大消息大小值snmpTargetAddrMMS用于确定另一个SNMP实体可接受的最大消息大小。
SNMP-COMMUNITY-MIB DEFINITIONS ::= BEGIN
SNMP-COMMUNITY-MIB DEFINITIONS ::= BEGIN
IMPORTS IpAddress, MODULE-IDENTITY, OBJECT-TYPE, Integer32, snmpModules FROM SNMPv2-SMI RowStatus, StorageType FROM SNMPv2-TC SnmpAdminString, SnmpEngineID FROM SNMP-FRAMEWORK-MIB SnmpTagValue, snmpTargetAddrEntry FROM SNMP-TARGET-MIB MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF;
从SNMPv2 SMI RowStatus导入IpAddress、MODULE-IDENTITY、OBJECT-TYPE、Integer32、snmpModules，从SNMPv2 TC SNMPAdministring导入StorageType，从SNMP-FRAMEWORK-MIB SnmpTagValue导入SnmpEngineID，从SNMP-TARGET-MIB MODULE-COMPLIANCE导入SNMPTargetAddress，从SNMPv2 CONF导入对象组；
snmpCommunityMIB MODULE-IDENTITY LAST-UPDATED "200003060000Z" -- 6 Mar 2000, midnight ORGANIZATION "SNMPv3 Working Group" CONTACT-INFO "WG-email: snmpv3@lists.tislabs.com Subscribe: majordomo@lists.tislabs.com In msg body: subscribe snmpv3
snmpCommunityMIB模块身份最后更新“2000036000Z”-2000年3月6日，午夜组织“SNMPv3工作组”联系方式工作组电子邮件：snmpv3@lists.tislabs.com订阅：majordomo@lists.tislabs.com在消息正文中：订阅snmpv3
Chair: Russ Mundy TIS Labs at Network Associates Postal: 3060 Washington Rd Glenwood MD 21738 USA Email: mundy@tislabs.com Phone: +1-301-854-6889
主席：美国网络协会Russ Mundy TIS实验室邮编：美国马里兰州格伦伍德华盛顿路3060号邮编：21738电子邮件：mundy@tislabs.com电话：+1-301-854-6889
Co-editor: Rob Frye CoSine Communications Postal: 1200 Bridge Parkway Redwood City, CA 94065 USA E-mail: rfrye@cosinecom.com Phone: +1 703 725 1130
共同编辑：Rob Frye CoSine通信邮政：1200 Bridge Parkway美国加利福尼亚州红木市94065电子邮件：rfrye@cosinecom.com电话：+17037251130
Co-editor: David B. Levi Nortel Networks Postal: 3505 Kesterwood Drive Knoxville, TN 37918 E-mail: dlevi@nortelnetworks.com Phone: +1 423 686 0432
合编：David B.Levi Nortel Networks邮政：3505 Kesterwood Drive Knoxville，TN 37918电子邮件：dlevi@nortelnetworks.com电话：+14236860432
Co-editor: Shawn A. Routhier Integrated Systems Inc. Postal: 333 North Ave 4th Floor Wakefield, MA 01880 E-mail: sar@epilogue.com Phone: +1 781 245 0804
合编：Shawn A.Routhier Integrated Systems Inc.邮政编码：马萨诸塞州威克菲尔德北街333号4楼邮编：01880电子邮件：sar@epilogue.com电话：+1781240804
Co-editor: Bert Wijnen Lucent Technologies Postal: Schagen 33 3461 GL Linschoten Netherlands Email: bwijnen@lucent.com Phone: +31-348-407-775 "
合编：Bert Wijnen-Lucent Technologies邮政：Schagen 33 3461 GL Linschoten荷兰电子邮件：bwijnen@lucent.com电话：+31-348-407-775”
DESCRIPTION
"This MIB module defines objects to help support coexistence
between SNMPv1, SNMPv2c, and SNMPv3."
REVISION "200003060000Z" -- 6 Mar 2000
DESCRIPTION "This version published as RFC 2576."
REVISION "199905130000Z" -- 13 May 1999
DESCRIPTION "The Initial Revision"
::= { snmpModules 18 }
DESCRIPTION
"This MIB module defines objects to help support coexistence
between SNMPv1, SNMPv2c, and SNMPv3."
REVISION "200003060000Z" -- 6 Mar 2000
DESCRIPTION "This version published as RFC 2576."
REVISION "199905130000Z" -- 13 May 1999
DESCRIPTION "The Initial Revision"
::= { snmpModules 18 }
-- Administrative assignments ****************************************
-- Administrative assignments ****************************************
snmpCommunityMIBObjects OBJECT IDENTIFIER ::= { snmpCommunityMIB 1 }
snmpCommunityMIBConformance OBJECT IDENTIFIER ::= { snmpCommunityMIB 2 }
snmpCommunityMIBObjects OBJECT IDENTIFIER ::= { snmpCommunityMIB 1 }
snmpCommunityMIBConformance OBJECT IDENTIFIER ::= { snmpCommunityMIB 2 }
--
-- The snmpCommunityTable contains a database of community strings.
-- This table provides mappings between community strings, and the
--
-- The snmpCommunityTable contains a database of community strings.
-- This table provides mappings between community strings, and the
-- parameters required for View-based Access Control. --
--基于视图的访问控制所需的参数--
snmpCommunityTable OBJECT-TYPE
SYNTAX SEQUENCE OF SnmpCommunityEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The table of community strings configured in the SNMP
engine's Local Configuration Datastore (LCD)."
::= { snmpCommunityMIBObjects 1 }
snmpCommunityTable OBJECT-TYPE
SYNTAX SEQUENCE OF SnmpCommunityEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The table of community strings configured in the SNMP
engine's Local Configuration Datastore (LCD)."
::= { snmpCommunityMIBObjects 1 }
snmpCommunityEntry OBJECT-TYPE
SYNTAX SnmpCommunityEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Information about a particular community string."
INDEX { IMPLIED snmpCommunityIndex }
::= { snmpCommunityTable 1 }
snmpCommunityEntry OBJECT-TYPE
SYNTAX SnmpCommunityEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Information about a particular community string."
INDEX { IMPLIED snmpCommunityIndex }
::= { snmpCommunityTable 1 }
SnmpCommunityEntry ::= SEQUENCE {
snmpCommunityIndex SnmpAdminString,
snmpCommunityName OCTET STRING,
snmpCommunitySecurityName SnmpAdminString,
snmpCommunityContextEngineID SnmpEngineID,
snmpCommunityContextName SnmpAdminString,
snmpCommunityTransportTag SnmpTagValue,
snmpCommunityStorageType StorageType,
snmpCommunityStatus RowStatus
}
SnmpCommunityEntry ::= SEQUENCE {
snmpCommunityIndex SnmpAdminString,
snmpCommunityName OCTET STRING,
snmpCommunitySecurityName SnmpAdminString,
snmpCommunityContextEngineID SnmpEngineID,
snmpCommunityContextName SnmpAdminString,
snmpCommunityTransportTag SnmpTagValue,
snmpCommunityStorageType StorageType,
snmpCommunityStatus RowStatus
}
snmpCommunityIndex OBJECT-TYPE
SYNTAX SnmpAdminString (SIZE(1..32))
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The unique index value of a row in this table."
::= { snmpCommunityEntry 1 }
snmpCommunityIndex OBJECT-TYPE
SYNTAX SnmpAdminString (SIZE(1..32))
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The unique index value of a row in this table."
::= { snmpCommunityEntry 1 }
snmpCommunityName OBJECT-TYPE
SYNTAX OCTET STRING
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The community string for which a row in this table
represents a configuration."
::= { snmpCommunityEntry 2 }
snmpCommunityName OBJECT-TYPE
SYNTAX OCTET STRING
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The community string for which a row in this table
represents a configuration."
::= { snmpCommunityEntry 2 }
snmpCommunitySecurityName OBJECT-TYPE
SYNTAX SnmpAdminString (SIZE(1..32))
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"A human readable string representing the corresponding
value of snmpCommunityName in a Security Model
independent format."
::= { snmpCommunityEntry 3 }
snmpCommunitySecurityName OBJECT-TYPE
SYNTAX SnmpAdminString (SIZE(1..32))
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"A human readable string representing the corresponding
value of snmpCommunityName in a Security Model
independent format."
::= { snmpCommunityEntry 3 }
snmpCommunityContextEngineID OBJECT-TYPE SYNTAX SnmpEngineID MAX-ACCESS read-create STATUS current DESCRIPTION "The contextEngineID indicating the location of the context in which management information is accessed when using the community string specified by the corresponding instance of snmpCommunityName.
snmpCommunityContextEngineID对象类型语法SnmpEngineID MAX-ACCESS read create STATUS current DESCRIPTION“当使用snmpCommunityName的相应实例指定的社区字符串时，指示访问管理信息的上下文位置的contextEngineID。
The default value is the snmpEngineID of the entity in
which this object is instantiated."
::= { snmpCommunityEntry 4 }
The default value is the snmpEngineID of the entity in
which this object is instantiated."
::= { snmpCommunityEntry 4 }
snmpCommunityContextName OBJECT-TYPE
SYNTAX SnmpAdminString (SIZE(0..32))
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The context in which management information is accessed
when using the community string specified by the corresponding
instance of snmpCommunityName."
DEFVAL { ''H } -- the empty string
::= { snmpCommunityEntry 5 }
snmpCommunityContextName OBJECT-TYPE
SYNTAX SnmpAdminString (SIZE(0..32))
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The context in which management information is accessed
when using the community string specified by the corresponding
instance of snmpCommunityName."
DEFVAL { ''H } -- the empty string
::= { snmpCommunityEntry 5 }
snmpCommunityTransportTag OBJECT-TYPE SYNTAX SnmpTagValue MAX-ACCESS read-create STATUS current DESCRIPTION "This object specifies a set of transport endpoints from which a command responder application will accept management requests. If a management request containing this community is received on a transport endpoint other than the transport endpoints identified by this object, the request is deemed unauthentic.
snmpCommunityTransportTag对象类型语法SnmpTagValue MAX-ACCESS读取创建状态当前描述“此对象指定一组传输端点，命令响应程序应用程序将从中接受管理请求。如果在此对象标识的传输端点以外的传输端点上接收到包含此社区的管理请求，则该请求被视为未经验证。
The transports identified by this object are specified
指定了此对象标识的传输
in the snmpTargetAddrTable. Entries in that table whose snmpTargetAddrTagList contains this tag value are identified.
在snmpTargetAddrTable中。标识SNMPTargetADRDTagList包含此标记值的表中的条目。
If the value of this object has zero-length, transport
endpoints are not checked when authenticating messages
containing this community string."
DEFVAL { ''H } -- the empty string
::= { snmpCommunityEntry 6 }
If the value of this object has zero-length, transport
endpoints are not checked when authenticating messages
containing this community string."
DEFVAL { ''H } -- the empty string
::= { snmpCommunityEntry 6 }
snmpCommunityStorageType OBJECT-TYPE
SYNTAX StorageType
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The storage type for this conceptual row in the
snmpCommunityTable. Conceptual rows having the value
'permanent' need not allow write-access to any
columnar object in the row."
::= { snmpCommunityEntry 7 }
snmpCommunityStorageType OBJECT-TYPE
SYNTAX StorageType
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The storage type for this conceptual row in the
snmpCommunityTable. Conceptual rows having the value
'permanent' need not allow write-access to any
columnar object in the row."
::= { snmpCommunityEntry 7 }
snmpCommunityStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this conceptual row in the snmpCommunityTable.
snmpCommunityStatus对象类型语法RowStatus MAX-ACCESS read create STATUS current DESCRIPTION“SNMPCommunitySTABLE中此概念行的状态。
An entry in this table is not qualified for activation until instances of all corresponding columns have been initialized, either through default values, or through Set operations. The snmpCommunityName and snmpCommunitySecurityName objects must be explicitly set.
在通过默认值或Set操作初始化所有对应列的实例之前，此表中的条目不符合激活条件。必须显式设置snmpCommunityName和snmpCommunitySecurityName对象。
There is no restriction on setting columns in this table
when the value of snmpCommunityStatus is active(1)."
::= { snmpCommunityEntry 8 }
There is no restriction on setting columns in this table
when the value of snmpCommunityStatus is active(1)."
::= { snmpCommunityEntry 8 }
-- -- The snmpTargetAddrExtTable --
----SNMPTargetAddExtTable--
snmpTargetAddrExtTable OBJECT-TYPE SYNTAX SEQUENCE OF SnmpTargetAddrExtEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table of mask and mms values associated with the
SNMPTARGETADREXTTABLE SNMPTARGETADREXTENTRY MAX-ACCESS的对象类型语法序列不可访问状态当前描述“与该对象关联的掩码和mms值表”
snmpTargetAddrTable.
snmpTargetAddrTable。
The snmpTargetAddrExtTable augments the
snmpTargetAddrTable with a transport address mask value
and a maximum message size value. The transport address
mask allows entries in the snmpTargetAddrTable to define
a set of addresses instead of just a single address.
The maximum message size value allows the maximum
message size of another SNMP entity to be configured for
use in SNMPv1 (and SNMPv2c) transactions, where the
message format does not specify a maximum message size."
::= { snmpCommunityMIBObjects 2 }
The snmpTargetAddrExtTable augments the
snmpTargetAddrTable with a transport address mask value
and a maximum message size value. The transport address
mask allows entries in the snmpTargetAddrTable to define
a set of addresses instead of just a single address.
The maximum message size value allows the maximum
message size of another SNMP entity to be configured for
use in SNMPv1 (and SNMPv2c) transactions, where the
message format does not specify a maximum message size."
::= { snmpCommunityMIBObjects 2 }
snmpTargetAddrExtEntry OBJECT-TYPE
SYNTAX SnmpTargetAddrExtEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Information about a particular mask and mms value."
AUGMENTS { snmpTargetAddrEntry }
::= { snmpTargetAddrExtTable 1 }
snmpTargetAddrExtEntry OBJECT-TYPE
SYNTAX SnmpTargetAddrExtEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Information about a particular mask and mms value."
AUGMENTS { snmpTargetAddrEntry }
::= { snmpTargetAddrExtTable 1 }
SnmpTargetAddrExtEntry ::= SEQUENCE {
snmpTargetAddrTMask OCTET STRING,
snmpTargetAddrMMS Integer32
}
SnmpTargetAddrExtEntry ::= SEQUENCE {
snmpTargetAddrTMask OCTET STRING,
snmpTargetAddrMMS Integer32
}
snmpTargetAddrTMask OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..255)) MAX-ACCESS read-create STATUS current DESCRIPTION "The mask value associated with an entry in the snmpTargetAddrTable. The value of this object must have the same length as the corresponding instance of snmpTargetAddrTAddress, or must have length 0. An attempt to set it to any other value will result in an inconsistentValue error.
SNMPTargetADRDRTMAK对象类型语法八位字符串（大小（0..255））MAX-ACCESS读取创建状态当前说明“与SNMPTargetADRDR表中的条目关联的掩码值。此对象的值必须与snmpTargetAddRtaAddress的相应实例具有相同的长度，或者长度必须为0。尝试将其设置为任何其他值将导致值不一致错误。
The value of this object allows an entry in the snmpTargetAddrTable to specify multiple addresses. The mask value is used to select which bits of a transport address must match bits of the corresponding instance of snmpTargetAddrTAddress, in order for the transport address to match a particular entry in the snmpTargetAddrTable. Bits which are 1 in the mask value indicate bits in the transport address which must match bits in the snmpTargetAddrTAddress value.
此对象的值允许SNMPTargetADRDR表中的一个条目指定多个地址。掩码值用于选择传输地址的哪些位必须与SNMPTargetADRDR地址的相应实例的位匹配，以便传输地址与SNMPTargetADRDR表中的特定条目匹配。掩码值中为1的位表示传输地址中的位，该位必须与SNMPtageTadrAddress值中的位匹配。
Bits which are 0 in the mask indicate bits in the transport address which need not match. If the length of the mask is 0, the mask should be treated as if all its bits were 1 and its length were equal to the length of the corresponding value of snmpTargetAddrTable.
掩码中的0位表示传输地址中不需要匹配的位。如果掩码的长度为0，则应将掩码视为其所有位均为1，且其长度等于snmpTargetAddrTable对应值的长度。
This object may not be modified while the value of the
corresponding instance of snmpTargetAddrRowStatus is
active(1). An attempt to set this object in this case
will result in an inconsistentValue error."
DEFVAL { ''H }
::= { snmpTargetAddrExtEntry 1 }
This object may not be modified while the value of the
corresponding instance of snmpTargetAddrRowStatus is
active(1). An attempt to set this object in this case
will result in an inconsistentValue error."
DEFVAL { ''H }
::= { snmpTargetAddrExtEntry 1 }
snmpTargetAddrMMS OBJECT-TYPE
SYNTAX Integer32 (0|484..2147483647)
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The maximum message size value associated with an entry
in the snmpTargetAddrTable."
DEFVAL { 484 }
::= { snmpTargetAddrExtEntry 2 }
snmpTargetAddrMMS OBJECT-TYPE
SYNTAX Integer32 (0|484..2147483647)
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The maximum message size value associated with an entry
in the snmpTargetAddrTable."
DEFVAL { 484 }
::= { snmpTargetAddrExtEntry 2 }
--
-- The snmpTrapAddress and snmpTrapCommunity objects are included
-- in notifications that are forwarded by a proxy, which were
-- originally received as SNMPv1 Trap messages.
--
--
-- The snmpTrapAddress and snmpTrapCommunity objects are included
-- in notifications that are forwarded by a proxy, which were
-- originally received as SNMPv1 Trap messages.
--
snmpTrapAddress OBJECT-TYPE
SYNTAX IpAddress
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"The value of the agent-addr field of a Trap PDU which
is forwarded by a proxy forwarder application using
an SNMP version other than SNMPv1. The value of this
object SHOULD contain the value of the agent-addr field
from the original Trap PDU as generated by an SNMPv1
agent."
::= { snmpCommunityMIBObjects 3 }
snmpTrapAddress OBJECT-TYPE
SYNTAX IpAddress
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"The value of the agent-addr field of a Trap PDU which
is forwarded by a proxy forwarder application using
an SNMP version other than SNMPv1. The value of this
object SHOULD contain the value of the agent-addr field
from the original Trap PDU as generated by an SNMPv1
agent."
::= { snmpCommunityMIBObjects 3 }
snmpTrapCommunity OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION
snmpTrapCommunity对象类型语法八位字符串MAX-ACCESS可用于通知状态当前描述
"The value of the community string field of an SNMPv1
message containing a Trap PDU which is forwarded by a
a proxy forwarder application using an SNMP version
other than SNMPv1. The value of this object SHOULD
contain the value of the community string field from
the original SNMPv1 message containing a Trap PDU as
generated by an SNMPv1 agent."
::= { snmpCommunityMIBObjects 4 }
"The value of the community string field of an SNMPv1
message containing a Trap PDU which is forwarded by a
a proxy forwarder application using an SNMP version
other than SNMPv1. The value of this object SHOULD
contain the value of the community string field from
the original SNMPv1 message containing a Trap PDU as
generated by an SNMPv1 agent."
::= { snmpCommunityMIBObjects 4 }
-- Conformance Information *******************************************
-- Conformance Information *******************************************
snmpCommunityMIBCompliances OBJECT IDENTIFIER
::= { snmpCommunityMIBConformance 1 }
snmpCommunityMIBGroups OBJECT IDENTIFIER
::= { snmpCommunityMIBConformance 2 }
snmpCommunityMIBCompliances OBJECT IDENTIFIER
::= { snmpCommunityMIBConformance 1 }
snmpCommunityMIBGroups OBJECT IDENTIFIER
::= { snmpCommunityMIBConformance 2 }
-- Compliance statements
--合规声明
snmpCommunityMIBCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP engines which implement the SNMP-COMMUNITY-MIB."
snmpCommunityMIBCompliance MODULE-COMPLIANCE STATUS当前描述“实现SNMP-COMMUNITY-MIB的SNMP引擎的符合性声明。”
MODULE -- this module MANDATORY-GROUPS { snmpCommunityGroup }
MODULE——此模块为强制组{snmpCommunityGroup}
OBJECT snmpCommunityName MIN-ACCESS read-only DESCRIPTION "Write access is not required."
对象snmpCommunityName最小访问只读描述“不需要写访问。”
OBJECT snmpCommunitySecurityName MIN-ACCESS read-only DESCRIPTION "Write access is not required."
对象snmpCommunitySecurityName最小访问只读描述“不需要写访问。”
OBJECT snmpCommunityContextEngineID MIN-ACCESS read-only DESCRIPTION "Write access is not required."
对象snmpCommunityContextEngineID最小访问只读描述“不需要写访问。”
OBJECT snmpCommunityContextName MIN-ACCESS read-only DESCRIPTION "Write access is not required."
对象snmpCommunityContextName最小访问只读描述“不需要写访问。”
OBJECT snmpCommunityTransportTag MIN-ACCESS read-only DESCRIPTION "Write access is not required."
对象snmpCommunityTransportTag MIN-ACCESS只读说明“不需要写访问。”
OBJECT snmpCommunityStorageType
对象snmpCommunityStorageType
MIN-ACCESS read-only DESCRIPTION "Write access is not required."
MIN-ACCESS只读说明“不需要写访问。”
OBJECT snmpCommunityStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required."
对象snmpCommunityStatus MIN-ACCESS只读说明“不需要写访问。”
::= { snmpCommunityMIBCompliances 1 }
::= { snmpCommunityMIBCompliances 1 }
snmpProxyTrapForwardCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"The compliance statement for SNMP engines which
contain a proxy forwarding application which is
capable of forwarding SNMPv1 traps using SNMPv2c
or SNMPv3."
MODULE -- this module
MANDATORY-GROUPS { snmpProxyTrapForwardGroup }
::= { snmpCommunityMIBCompliances 2 }
snmpProxyTrapForwardCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"The compliance statement for SNMP engines which
contain a proxy forwarding application which is
capable of forwarding SNMPv1 traps using SNMPv2c
or SNMPv3."
MODULE -- this module
MANDATORY-GROUPS { snmpProxyTrapForwardGroup }
::= { snmpCommunityMIBCompliances 2 }
snmpCommunityGroup OBJECT-GROUP
OBJECTS {
snmpCommunityName,
snmpCommunitySecurityName,
snmpCommunityContextEngineID,
snmpCommunityContextName,
snmpCommunityTransportTag,
snmpCommunityStorageType,
snmpCommunityStatus,
snmpTargetAddrTMask,
snmpTargetAddrMMS
}
STATUS current
DESCRIPTION
"A collection of objects providing for configuration
of community strings for SNMPv1 (and SNMPv2c) usage."
::= { snmpCommunityMIBGroups 1 }
snmpCommunityGroup OBJECT-GROUP
OBJECTS {
snmpCommunityName,
snmpCommunitySecurityName,
snmpCommunityContextEngineID,
snmpCommunityContextName,
snmpCommunityTransportTag,
snmpCommunityStorageType,
snmpCommunityStatus,
snmpTargetAddrTMask,
snmpTargetAddrMMS
}
STATUS current
DESCRIPTION
"A collection of objects providing for configuration
of community strings for SNMPv1 (and SNMPv2c) usage."
::= { snmpCommunityMIBGroups 1 }
snmpProxyTrapForwardGroup OBJECT-GROUP
OBJECTS {
snmpTrapAddress,
snmpTrapCommunity
}
STATUS current
DESCRIPTION
"Objects which are used by proxy forwarding applications
when translating traps between SNMP versions. These are
used to preserve SNMPv1-specific information when
snmpProxyTrapForwardGroup OBJECT-GROUP
OBJECTS {
snmpTrapAddress,
snmpTrapCommunity
}
STATUS current
DESCRIPTION
"Objects which are used by proxy forwarding applications
when translating traps between SNMP versions. These are
used to preserve SNMPv1-specific information when
translating to SNMPv2c or SNMPv3."
::= { snmpCommunityMIBGroups 3 }
translating to SNMPv2c or SNMPv3."
::= { snmpCommunityMIBGroups 3 }
END
终止
The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何努力来确定任何此类权利。有关IETF在标准跟踪和标准相关文件中权利的程序信息，请参见BCP-11。可从IETF秘书处获得可供发布的权利声明副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涉及实施本标准所需技术的专有权利。请将信息发送给IETF执行董事。
This document is the result of the efforts of the SNMPv3 Working Group. The design of the SNMP-COMMUNITY-MIB incorporates work done by the authors of SNMPv2*:
本文件是SNMPv3工作组努力的结果。SNMP-COMMUNITY-MIB的设计结合了SNMPv2*的作者所做的工作：
Jeff Case (SNMP Research, Inc.) David Harrington (Cabletron Systems Inc.) David Levi (SNMP Research, Inc.) Brian O'Keefe (Hewlett Packard) Jon Saperia (IronBridge Networks, Inc.) Steve Waldbusser (International Network Services)
Jeff Case（SNMP Research，Inc.）David Harrington（Cabletron Systems Inc.）David Levi（SNMP Research，Inc.）Brian O'Keefe（Hewlett-Packard）Jon Saperia（IronBridge Networks，Inc.）Steve Waldbusser（国际网络服务）
Although SNMPv1 and SNMPv2 do not provide any security, allowing community names to be mapped into securityName/contextName provides the ability to use view-based access control to limit the access of unsecured SNMPv1 and SNMPv2 operations. In fact, it is important for network administrators to make use of this capability in order to avoid unauthorized access to MIB data that would otherwise be secure.
尽管SNMPv1和SNMPv2不提供任何安全性，但允许将社区名称映射到securityName/contextName提供了使用基于视图的访问控制来限制对不安全的SNMPv1和SNMPv2操作的访问的能力。事实上，网络管理员必须利用此功能，以避免对MIB数据进行未经授权的访问，否则将是安全的。
Further, the SNMP-COMMUNITY-MIB has the potential to expose community strings which provide access to more information than that which is available using the usual 'public' community string. For this reason, a security administrator may wish to limit accessibility to the SNMP-COMMUNITY-MIB, and in particular, to make it inaccessible when using the 'public' community string.
此外，SNMP-COMMUNITY-MIB有可能公开社区字符串，这些字符串提供对更多信息的访问，而不是使用通常的“公共”社区字符串。因此，安全管理员可能希望限制SNMP-COMMUNITY-MIB的可访问性，特别是在使用“public”社区字符串时使其不可访问。
When a proxy implementation translates messages between SNMPv1 (or SNMPv2c) and SNMPv3, there may be a loss of security. For example, an SNMPv3 message received using authentication and privacy which is subsequently forwarded using SNMPv1 will lose the security benefits of using authentication and privacy. Careful configuration of proxies is required to address such situations. One approach to deal with such situations might be to use an encrypted tunnel.
当代理实现在SNMPv1（或SNMPv2c）和SNMPv3之间转换消息时，可能会丢失安全性。例如，使用身份验证和隐私接收的SNMPv3消息随后使用SNMPv1转发，将失去使用身份验证和隐私的安全优势。需要仔细配置代理以解决此类情况。处理此类情况的一种方法可能是使用加密隧道。
[1] Rose, M. and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based internets", STD 16, RFC 1155, May 1990.
[1] Rose，M.和K.McCloghrie，“基于TCP/IP的互联网管理信息的结构和识别”，STD 16，RFC 1155，1990年5月。
[2] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, May 1990.
[2] Case，J.，Fedor，M.，Schoffstall，M.和J.Davin，“简单网络管理协议”，STD 15，RFC 1157，1990年5月。
[3] McCloghrie, K. and M. Rose, Editors, "Concise MIB Definitions", STD 16, RFC 1212, March 1991.
[3] McCloghrie，K.和M.Rose，编辑，“简明MIB定义”，STD 16，RFC 1212，1991年3月。
[4] Rose, M., "A Convention for Defining Traps for use with the SNMP", RFC 1215, March 1991.
[4] Rose，M.“定义用于SNMP的陷阱的约定”，RFC1215，1991年3月。
[5] McCloghrie, K. and M. Rose, "A Convention for Describing SNMP-based Agents", RFC 1303, February 1992.
[5] McCloghrie，K.和M.Rose，“描述基于SNMP的代理的约定”，RFC 1303，1992年2月。
[6] Case, J., McCloghrie, K., Rose, M. and S.Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, January 1996.
[6] Case，J.，McCloghrie，K.，Rose，M.和S.Waldbusser，“基于社区的SNMPv2简介”，RFC 19011996年1月。
[7] 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.
[7] McCloghrie，K.，Perkins，D.，Schoenwaeld，J.，Case，J.，Rose，M.和S.Waldbusser，“管理信息的结构版本2（SMIv2）”，STD 58，RFC 2578，1999年4月。
[8] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999.
[8] McCloghrie，K.，Perkins，D.，Schoenwaeld，J.，Case，J.，Rose，M.和S.Waldbusser，“SMIv2的文本约定”，STD 58，RFC 2579，1999年4月。
[9] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999.
[9] McCloghrie，K.，Perkins，D.，Schoenwaeld，J.，Case，J.，Rose，M.和S.Waldbusser，“SMIv2的一致性声明”，STD 58，RFC 25801999年4月。
[10] 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.
[10] Case，J.，McCloghrie，K.，Rose，M.和S.Waldbusser，“简单网络管理协议（SNMPv2）版本2的协议操作”，RFC 1905，1996年1月。
[11] 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.
[11] Case，J.，McCloghrie，K.，Rose，M.和S.Waldbusser，“简单网络管理协议（SNMPv2）版本2的传输映射”，RFC 1906，1996年1月。
[12] 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.
[12] Case，J.，McCloghrie，K.，Rose，M.和S.Waldbusser，“简单网络管理协议（SNMPv2）版本2的管理信息库”，RFC 1907，1996年1月。
[13] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Coexistence between Version 1 and Version 2 of the Internet-standard Network Management Framework", RFC 1908, January 1996.
[13] Case，J.，McCloghrie，K.，Rose，M.和S.Waldbusser，“互联网标准网络管理框架第1版和第2版之间的共存”，RFC 1908，1996年1月。
[14] Levi, D. and B. Wijnen, "Mapping SNMPv2 onto SNMPv1 within a bi-lingual SNMP agent", RFC 2089, January 1997.
[14] Levi，D.和B.Wijnen，“在双语SNMP代理中将SNMPv2映射到SNMPv1”，RFC 2089，1997年1月。
[15] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[15] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[16] Harrington, D. and B. Wijnen, "An Architecture for Describing SNMP Management Frameworks", RFC 2571, May 1999.
[16] Harrington，D.和B.Wijnen，“描述SNMP管理框架的体系结构”，RFC 2571，1999年5月。
[17] Case, J., Harrington, D. and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 2572, May 1999.
[17] Case，J.，Harrington，D.和B.Wijnen，“简单网络管理协议（SNMP）的消息处理和调度”，RFC 2572，1999年5月。
[18] Levi, D., Meyer, P. and B. Stewart, "SNMP Applications", RFC 2573, May 1999.
[18] Levi，D.，Meyer，P.和B.Stewart，“SNMP应用”，RFC2573，1999年5月。
[19] Blumenthal, U. and Wijnen, B., "The User-Based Security Model for Version 3 of the Simple Network Management Protocol (SNMP)", RFC 2574, May 1999.
[19] Blumenthal，U.和Wijnen，B.，“简单网络管理协议（SNMP）第3版基于用户的安全模型”，RFC 2574，1999年5月。
[20] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access Control Model for the Simple Network Management Protocol (SNMP)", RFC 2575, May 1999.
[20] Wijnen，B.，Presuhn，R.和K.McCloghrie，“简单网络管理协议（SNMP）基于视图的访问控制模型”，RFC2575，1999年5月。
Rob Frye CoSine Communications 1200 Bridge Parkway Redwood City, CA 94065 U.S.A.
美国加利福尼亚州红木市1200桥公园路Rob Frye CoSine Communications邮编：94065。
Phone: +1 703 725 1130
EMail: rfrye@cosinecom.com
Phone: +1 703 725 1130
EMail: rfrye@cosinecom.com
David B. Levi Nortel Networks 3505 Kesterwood Drive Knoxville, TN 37918 U.S.A.
David B.Levi Nortel Networks美国田纳西州诺克斯维尔凯斯特伍德大道3505号，邮编37918。
Phone: +1 423 686 0432
EMail: dlevi@nortelnetworks.com
Phone: +1 423 686 0432
EMail: dlevi@nortelnetworks.com
Shawn A. Routhier Integrated Systems Inc. 333 North Ave 4th Floor Wakefield MA 01880 U.S.A.
美国马萨诸塞州韦克菲尔德北大街333号4楼Shawn A.Routhier集成系统公司01880。
Phone: + 1 781 245 0804
EMail: sar@epilogue.com
Phone: + 1 781 245 0804
EMail: sar@epilogue.com
Bert Wijnen Lucent Technologies Schagen 33 3461 GL Linschoten Netherlands
Bert Wijnen-Lucent Technologies Schagen 33 3461德国劳埃德船级社荷兰
Phone: +31 348 407-775
EMail: wijnen@lucent.com
Phone: +31 348 407-775
EMail: wijnen@lucent.com
A. Changes From RFC1908
A.与RFC1908的变更
- Editorial changes to comply with current RFC requirements.
- 编辑更改以符合当前RFC要求。
- Added/updated copyright statements.
- 新增/更新版权声明。
- Added Intellectual Property section.
- 增加了知识产权部分。
- Replaced old introduction with complete new introduction/overview.
- 用完整的新介绍/概述替换旧介绍。
- Added content for the Security Considerations Section.
- 添加了安全注意事项部分的内容。
- Updated References to current documents.
- 更新了对当前文件的引用。
- Updated text to use current SNMP terminology.
- 更新了使用当前SNMP术语的文本。
- Added coexistence for/with SNMPv3.
- 添加了与SNMPv3的共存。
- Added description for SNMPv1 and SNMPv2c Message Processing Models and SNMPv1 and SNMPv2c Community-based Security Models.
- 增加了对SNMPv1和SNMPv2c消息处理模型以及基于SNMPv1和SNMPv2c社区的安全模型的说明。
- Added snmpCommunityMIB so that SNMPv1 and SNMPv2 community strings can be mapped into the SNMP Version Independent paramaters which can then be used for access control using the standard SNMPv3 View-based Access Control Model and the snmpVacmMIB.
- 添加了snmpCommunityMIB，以便SNMPv1和SNMPv2社区字符串可以映射到SNMP版本独立的参数，然后可以使用标准的基于SNMPv3视图的访问控制模型和SNMPvCMIB用于访问控制。
- Added two MIB objects such that when an SNMPv1 notification (trap) must be converted into an SNMPv2 notification we add those two objects in order to preserve information about the address and community of the originating SNMPv1 agent.
- 添加了两个MIB对象，以便当SNMPv1通知（陷阱）必须转换为SNMPv2通知时，我们添加这两个对象，以保留有关原始SNMPv1代理的地址和社区的信息。
- Included (and extended) from RFC2089 the SNMPv2 to SNMPv1 mapping within a multi-lingual SNMP Engine.
- 在多语言SNMP引擎中包含（并扩展）从RFC2089到SNMPv2到SNMPv1的映射。
- Use keywords from RFC 2119 to describe requirements for compliance.
- 使用RFC 2119中的关键字描述法规遵从性要求。
- Changed/added some rules for converting a MIB module from SMIv1 to SMIv2.
- 更改/添加了一些将MIB模块从SMIv1转换为SMIv2的规则。
- Extended and improved the description of Proxy Forwarder behaviour when multiple SNMP versions are involved.
- 扩展并改进了涉及多个SNMP版本时代理转发器行为的描述。
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
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编辑功能的资金目前由互联网协会提供。