Network Working Group R. Frye
Request for Comments: 3584 Vibrant Solutions
BCP: 74 D. Levi
Obsoletes: 2576 Nortel Networks
Category: Best Current Practice S. Routhier
Wind River Systems, Inc.
B. Wijnen
Lucent Technologies
August 2003
Network Working Group R. Frye
Request for Comments: 3584 Vibrant Solutions
BCP: 74 D. Levi
Obsoletes: 2576 Nortel Networks
Category: Best Current Practice S. Routhier
Wind River Systems, Inc.
B. Wijnen
Lucent Technologies
August 2003
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 Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
本文件规定了互联网社区的最佳现行做法，并要求进行讨论和提出改进建议。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
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 also describes how to convert MIB modules from SMIv1 format to SMIv2 format. This document obsoletes RFC 2576.
本文档旨在描述Internet标准网络管理框架（SNMPv3）第3版、Internet标准网络管理框架（SNMPv2）第2版和原始Internet标准网络管理框架（SNMPv1）之间的共存情况。本文档还描述了如何将MIB模块从SMIv1格式转换为SMIv2格式。本文件淘汰RFC 2576。
Table Of Contents
目录
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. SNMPv1 . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. SNMPv2 . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. SNMPv3 . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . 8
2.2. Compliance Statements. . . . . . . . . . . . . . . . . 9
2.3. Capabilities Statements. . . . . . . . . . . . . . . . 9
3. Translating Notification Parameters. . . . . . . . . . . . . 10
3.1. Translating SNMPv1 Notification Parameters to
SNMPv2 Notification Parameters . . . . . . . . . . . . 11
3.2. Translating SNMPv2 Notification Parameters to
SNMPv1 Notification Parameters . . . . . . . . . . . . 12
4. Approaches to Coexistence in a Multi-lingual Network . . . . 14
4.1. SNMPv1 and SNMPv2 Access to MIB Data . . . . . . . . . 14
4.2. Multi-lingual implementations. . . . . . . . . . . . . 15
4.2.1. Command Generator. . . . . . . . . . . . . . . 15
4.2.2. Command Responder. . . . . . . . . . . . . . . 16
4.2.2.1. Handling Counter64 . . . . . . . . . 16
4.2.2.2. Mapping SNMPv2 Exceptions. . . . . . 17
4.2.2.2.1. Mapping noSuchObject
and noSuchInstance. . . . 18
4.2.2.2.2. Mapping endOfMibView. . . 18
4.2.2.3. Processing An SNMPv1 GetReques . . . 18
4.2.2.4. Processing An SNMPv1 GetNextRequest. 19
4.2.2.5. Processing An SNMPv1 SetRequest. . . 20
4.2.3. Notification Originator. . . . . . . . . . . . 21
4.2.4. Notification Receiver. . . . . . . . . . . . . 21
4.3. Proxy Implementations. . . . . . . . . . . . . . . . . 22
4.3.1. Upstream Version Greater Than Downstream
Version. . . . . . . . . . . . . . . . . . . . 22
4.3.2. Upstream Version Less Than Downstream Version. 23
4.4. Error Status Mappings. . . . . . . . . . . . . . . . . 25
5. Message Processing Models and Security Models. . . . . . . . 26
5.1. Mappings . . . . . . . . . . . . . . . . . . . . . . . 26
5.2. The SNMPv1 MP Model and SNMPv1 Community-based
Security Model . . . . . . . . . . . . . . . . . . . . 26
5.2.1. Processing An Incoming Request . . . . . . . . 27
5.2.2. Generating An Outgoing Response. . . . . . . . 29
5.2.3. Generating An Outgoing Notification. . . . . . 29
5.2.4. Proxy Forwarding Of Requests . . . . . . . . . 30
5.3. The SNMP Community MIB Module. . . . . . . . . . . . . 30
6. Intellectual Property Statement. . . . . . . . . . . . . . . 42
7. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . 43
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. SNMPv1 . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. SNMPv2 . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. SNMPv3 . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . 8
2.2. Compliance Statements. . . . . . . . . . . . . . . . . 9
2.3. Capabilities Statements. . . . . . . . . . . . . . . . 9
3. Translating Notification Parameters. . . . . . . . . . . . . 10
3.1. Translating SNMPv1 Notification Parameters to
SNMPv2 Notification Parameters . . . . . . . . . . . . 11
3.2. Translating SNMPv2 Notification Parameters to
SNMPv1 Notification Parameters . . . . . . . . . . . . 12
4. Approaches to Coexistence in a Multi-lingual Network . . . . 14
4.1. SNMPv1 and SNMPv2 Access to MIB Data . . . . . . . . . 14
4.2. Multi-lingual implementations. . . . . . . . . . . . . 15
4.2.1. Command Generator. . . . . . . . . . . . . . . 15
4.2.2. Command Responder. . . . . . . . . . . . . . . 16
4.2.2.1. Handling Counter64 . . . . . . . . . 16
4.2.2.2. Mapping SNMPv2 Exceptions. . . . . . 17
4.2.2.2.1. Mapping noSuchObject
and noSuchInstance. . . . 18
4.2.2.2.2. Mapping endOfMibView. . . 18
4.2.2.3. Processing An SNMPv1 GetReques . . . 18
4.2.2.4. Processing An SNMPv1 GetNextRequest. 19
4.2.2.5. Processing An SNMPv1 SetRequest. . . 20
4.2.3. Notification Originator. . . . . . . . . . . . 21
4.2.4. Notification Receiver. . . . . . . . . . . . . 21
4.3. Proxy Implementations. . . . . . . . . . . . . . . . . 22
4.3.1. Upstream Version Greater Than Downstream
Version. . . . . . . . . . . . . . . . . . . . 22
4.3.2. Upstream Version Less Than Downstream Version. 23
4.4. Error Status Mappings. . . . . . . . . . . . . . . . . 25
5. Message Processing Models and Security Models. . . . . . . . 26
5.1. Mappings . . . . . . . . . . . . . . . . . . . . . . . 26
5.2. The SNMPv1 MP Model and SNMPv1 Community-based
Security Model . . . . . . . . . . . . . . . . . . . . 26
5.2.1. Processing An Incoming Request . . . . . . . . 27
5.2.2. Generating An Outgoing Response. . . . . . . . 29
5.2.3. Generating An Outgoing Notification. . . . . . 29
5.2.4. Proxy Forwarding Of Requests . . . . . . . . . 30
5.3. The SNMP Community MIB Module. . . . . . . . . . . . . 30
6. Intellectual Property Statement. . . . . . . . . . . . . . . 42
7. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . 43
8. Security Considerations. . . . . . . . . . . . . . . . . . . 43
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 44
9.1. Normative References . . . . . . . . . . . . . . . . . 44
9.2. Informative References . . . . . . . . . . . . . . . . 46
Appendix A. Change Log. . . . . . . . . . . . . . . . . . . . . 47
A.1. Changes From RFC 2576 . . . . . . . . . . . . . . . . . 47
A.2. Changes Between RFC 1908 and RFC 2576 . . . . . . . . . 49
Editors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 50
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 51
8. Security Considerations. . . . . . . . . . . . . . . . . . . 43
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 44
9.1. Normative References . . . . . . . . . . . . . . . . . 44
9.2. Informative References . . . . . . . . . . . . . . . . 46
Appendix A. Change Log. . . . . . . . . . . . . . . . . . . . . 47
A.1. Changes From RFC 2576 . . . . . . . . . . . . . . . . . 47
A.2. Changes Between RFC 1908 and RFC 2576 . . . . . . . . . 49
Editors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 50
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 51
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 RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
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 [RFC1157] which defines the Simple Network Management Protocol (SNMPv1), the protocol used for network access to managed objects.
- STD 15，RFC 1157[RFC1157]定义了简单网络管理协议（SNMPv1），该协议用于对受管对象进行网络访问。
- STD 16, RFC 1155 [RFC1155] 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[RFC1155]定义了管理信息的结构（SMIv1），即用于描述和命名对象以进行管理的机制。
- STD 16, RFC 1212 [RFC1212] which defines a more concise description mechanism, which is wholly consistent with the SMIv1.
- STD 16，RFC 1212[RFC1212]定义了一个更简洁的描述机制，它与SMIv1完全一致。
- RFC 1215 [RFC1215] which defines a convention for defining Traps for use with the SMIv1.
- RFC 1215[RFC1215]定义了一种约定，用于定义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) [RFC2578].
- STD 58，RFC 2578定义了管理信息结构（SMIv2）[RFC2578]的版本2。
- STD 58, RFC 2579 which defines common MIB "Textual Conventions" [RFC2579].
- STD 58，RFC 2579定义了通用MIB“文本约定”[RFC2579]。
- STD 58, RFC 2580 which defines Conformance Statements and requirements for defining agent and manager capabilities [RFC2580].
- STD 58，RFC 2580，定义了一致性声明和定义代理和经理能力的要求[RFC2580]。
- STD 62, RFC 3416 which defines the Protocol Operations used in processing [RFC3416].
- STD 62，RFC 3416定义了处理过程中使用的协议操作[RFC3416]。
- STD 62, RFC 3417 which defines the Transport Mappings used "on the wire" [RFC3417].
- STD 62，RFC 3417定义了“在线路上”使用的传输映射[RFC3417]。
- STD 62, RFC 3418 which defines the basic Management Information Base for monitoring and controlling some basic common functions of SNMP entities [RFC3418].
- STD 62，RFC 3418定义了用于监视和控制SNMP实体的一些基本通用功能的基本管理信息库[RFC3418]。
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 [RFC1901] is an Experimental definition for using SNMPv2 PDUs within a community-based message wrapper. This is referred to throughout this document as SNMPv2c.
- RFC1901[RFC1901]是在基于社区的消息包装器中使用SNMPv2 PDU的实验性定义。本文件通篇将其称为SNMPv2c。
SNMPv3 is defined by these documents:
SNMPv3由以下文件定义：
- STD 62, RFC 3411 which defines an Architecture for Describing SNMP Management Frameworks [RFC3411].
- STD 62，RFC 3411定义了用于描述SNMP管理框架的体系结构[RFC3411]。
- STD 62, RFC 3412 which defines Message Processing and Dispatching [RFC3412].
- STD 62，RFC 3412，定义了消息处理和调度[RFC3412]。
- STD 62, RFC 3413 which defines various SNMP Applications [RFC3413].
- STD 62，RFC 3413定义了各种SNMP应用程序[RFC3413]。
- STD 62, RFC 3414 which defines the User-based Security Model (USM), providing for both Authenticated and Private (encrypted) SNMP messages [RFC3414].
- STD 62，RFC 3414，定义了基于用户的安全模型（USM），提供了认证和私有（加密）SNMP消息[RFC3414]。
- STD 62, RFC 3415 which defines the View-based Access Control Model (VACM), providing the ability to limit access to different MIB objects on a per-user basis [RFC3415].
- STD 62，RFC 3415定义了基于视图的访问控制模型（VACM），提供了基于每个用户限制对不同MIB对象的访问的能力[RFC3415]。
SNMPv3 also uses the SNMPv2 definitions of RFCs 3416 through 3418 and the SMIv2 definitions of 2578 through 2580 described above. Note that text throughout this document that refers to SNMPv2 PDU types and protocol operations applies to both SNMPv2c and SNMPv3.
SNMPv3还使用上述RFC 3416至3418的SNMPv2定义和2578至2580的SMIv2定义。请注意，本文档中涉及SNMPv2 PDU类型和协议操作的文本适用于SNMPv2c和SNMPv3。
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 [ASN1] 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.
描述托管对象集合的SMIv2方法几乎是SMIv1中定义的方法的超集。例如，这两种方法都使用ASN.1[ASN1]的一个子集作为正式描述符号的基础。事实上，有人可能会注意到，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 SMIv1 MIB modules to conform to the SMIv2, the following changes SHALL be made:
使用SMIv1定义的MIB模块可以继续与使用SNMPv2 PDU的协议版本一起使用。但是，为了使SMIv1 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 a SYNTAX clause value of Counter, the object MUST have the value of its SYNTAX clause changed to Counter32.
(3) 对于语法子句值为Counter的任何对象，该对象必须将其语法子句的值更改为Counter32。
(4) 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.
(4) 对于语法子句值为Gauge的任何对象，该对象必须将其语法子句的值更改为Gauge32，或在适当情况下更改为Unsigned32。
(5) 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 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.
(5) 对于所有对象，ACCESS子句必须替换为MAX-ACCESS子句。MAX-ACCESS子句的值应与ACCESS子句的值相同，除非其他值作为对象的最大访问级别具有“协议意义”。特别是，可通过协议集操作显式创建实例的对象类型应具有“读取创建”的MAX-ACCESS子句。如果ACCESS子句的值为“write only”，则MAX-ACCESS子句的值必须为“read-write”，并且DESCRIPTION子句应注意，读取此对象将产生特定于实现的结果。请注意，在SMIv1中，ACCESS子句指定了所需的最小访问权限，而在SMIv2中，MAX-ACCESS子句指定了允许的最大访问权限。将ACCESS子句转换为MAX-ACCESS子句时应考虑这一点。
(6) 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.
(6) 对于所有对象，如果STATUS子句的值为“mandatory”或“optional”，则该值必须替换为“current”、“deprecated”或“过时”，具体取决于此类对象的当前使用情况。
(7) For any object not containing a DESCRIPTION clause, the object MUST have a DESCRIPTION clause defined.
(7) 对于不包含描述子句的任何对象，该对象必须定义描述子句。
(8) 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.
(8) 对于与没有INDEX子句的概念行相对应的任何对象，该对象必须定义INDEX子句或AUGMENTS子句。
(9) 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. The effect of this, and the preceding bullet, is to allow 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.
(9) 如果任何索引子句包含对语法为NetworkAddress的对象的引用，则必须创建一个新对象，并将其放置在此索引子句中，紧靠语法为NetworkAddress的对象的前面。此新对象的语法必须为INTEGER，它必须不可访问，并且其值必须始终为1。这和前面的项目符号的作用是允许将SMIv1格式的MIB模块转换为SMIv2格式的MIB模块，然后将其与SNMPv1协议一起使用，而不会影响现有的SNMPv1代理和管理器。
(10) 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).
（10） 对于语法为NetworkAddress的任何对象，必须将语法更改为IpAddress。请注意，强烈反对在新MIB文档中使用NetworkAddress（事实上，新MIB文档应该使用SMIv2编写，SMIv2不定义NetworkAddress）。
(11) 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.
（11） 对于包含DEFVAL子句且对象标识符值表示为子标识符集合的任何对象，必须将该值更改为引用单个ASN.1标识符。这可能需要定义一系列新的管理分配（对象标识符），以便定义单个ASN.1标识符。
(12) One or more OBJECT-GROUPS MUST be defined, and related objects MUST be collected into appropriate groups. Note that SMIv2 requires all OBJECT-TYPEs to be a member of at least one OBJECT-GROUP.
（12） 必须定义一个或多个对象组，并且必须将相关对象收集到适当的组中。请注意，SMIv2要求所有对象类型都必须是至少一个对象组的成员。
(13) 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".
（13） 对于实例化为直接从属于概念行的任何非列对象，该对象的STATUS子句的值必须更改为“过时”。
(14) For any conceptual row object that is not immediately subordinate to a conceptual table, the value of the STATUS clause of that object (and all subordinate objects) MUST be changed to "obsolete".
（14） 对于不直接从属于概念表的任何概念行对象，必须将该对象（以及所有从属对象）的STATUS子句的值更改为“过时”。
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 RFC 2578 [RFC2578], and the RowStatus and StorageType TEXTUAL-CONVENTIONs are described in section 2 of RFC 2579 [RFC2579].
(1) 使用SMIv1创建和删除概念行不一致。SMIv2纠正了这一点。因此，如果MIB模块在其生命周期的早期接受审查，并且它包含允许创建和删除概念行的概念表，那么与这些表相关的对象可能会被弃用，并替换为使用新方法定义的对象。基于SMIv2的方法可以在RFC 2578[RFC2578]的第7节中找到，而RowStatus和StorageType文本约定在RFC 2579[RFC2579]的第2节中描述。
(2) 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 SHOULD have the value of its SYNTAX clause changed to Integer32, or have an appropriate range specified.
(2) 对于具有整数值语法子句的任何对象，其中对应的整数没有范围限制（即，该整数既没有已定义的命名数字枚举集，也没有其值的上下限赋值），该对象应将其语法子句的值更改为Integer32，或指定适当的范围。
(3) 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.
(3) 对于具有字符串值语法子句的任何对象，其中对应的八位字符串没有大小限制（即八位字符串的长度没有上下界的赋值），应定义对象大小的界。
(4) 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.
(4) MIB模块中非正式定义的所有文本约定都应该使用text-CONVENTION宏重新定义。这样的更改不需要弃用以前使用非正式文本约定定义的对象。
(5) For any object which represents a measurement in some kind of units, a UNITS clause SHOULD be added to the definition of that object.
(5) 对于以某种单位表示度量的任何对象，应在该对象的定义中添加units子句。
(6) 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.
(6) 对于作为另一个概念行扩展的任何概念行，即，对于其从属列对象既存在又通过与另一个概念行相同的语义进行标识的概念行，应使用AUGMENTS子句代替作为扩展的概念行对应的对象的INDEX子句。
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 [RFC1215], and MUST reference SNMPv2-SMI instead.
(1) IMPORTS语句不能引用RFC-1215[RFC1215]，而必须引用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文档定义模块符合性声明可能很有用。
RFC 1303 [RFC1303] uses the MODULE-CONFORMANCE macro to describe an agent's capabilities with respect to one or more MIB modules.
RFC 1303[RFC1303]使用模块一致性宏来描述代理关于一个或多个MIB模块的能力。
Converting such a description for use with the SMIv2 requires these changes:
转换此类描述以用于SMIv2需要进行以下更改：
(1) The macro name AGENT-CAPABILITIES MUST be used instead of MODULE-CONFORMANCE.
(1) 必须使用宏名称AGENT-CAPABILITIES，而不是MODULE-compliance。
(2) The STATUS clause MUST 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 RFC 2580 [RFC2580].
(3) 如果合适，必须省略CREATION-REQUIRES子句的所有出现，或者进行更改，以使语义与RFC 2580[RFC2580]一致。
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 referred to in this document as 'SNMPv1 notification parameters'. The format of parameters used for SNMPv2 notification protocol operations is referred 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, and is equal to the value portion of that variable-binding (not the name portion, as both the name and value are OBJECT IDENTIFIERs).
- 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 concatenation of the SNMPv1 enterprise parameter and two additional sub-identifiers, '0', and the SNMPv1 specific-trap parameter.
(2) 如果SNMPv1通用陷阱参数为“企业特定（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 RFC 3418 [RFC3418]:
(3) 如果SNMPv1通用陷阱参数不是“企业特定（6）”，则SNMPv2 snmpTrapOID参数应为RFC 3418[RFC3418]第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 [RFC3418], 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[RFC3418]，该值应为SNMPv1 enterprise参数。
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 RFC 3418 [RFC3418], then the SNMPv1 enterprise parameter SHALL be set to the value of the variable-binding in the SNMPv2 variable-bindings whose name is
- 如果SNMPv2 snmpTrapOID参数是RFC 3418[RFC3418]中定义的标准陷阱之一，则SNMPv1 enterprise参数应设置为SNMPv2变量绑定中的变量绑定值，其名称为
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 RFC 3418 [RFC3418].
snmpTrapEnterprise.0，如果该变量绑定存在。如果不存在，SNMPv1企业参数应设置为RFC 3418[RFC3418]中定义的值“snmpTraps”。
- If the SNMPv2 snmpTrapOID parameter is not one of the standard traps as defined in RFC 3418 [RFC3418], then the SNMPv1 enterprise parameter SHALL be determined from the SNMPv2 snmpTrapOID parameter as follows:
- 如果SNMPv2 snmpTrapOID参数不是RFC 3418[RFC3418]中定义的标准陷阱之一，则应根据SNMPv2 snmpTrapOID参数确定SNMPv1 enterprise参数，如下所示：
- If the next-to-last sub-identifier of the snmpTrapOID value is zero, then the SNMPv1 enterprise SHALL be the SNMPv2 snmpTrapOID value with the last 2 sub-identifiers removed, otherwise
- 如果snmpTrapOID值的倒数第二个子标识符为零，则SNMPv1企业应为SNMPv2 snmpTrapOID值，并删除最后2个子标识符，否则
- If the next-to-last sub-identifier of the snmpTrapOID value is non-zero, then the SNMPv1 enterprise SHALL be the SNMPv2 snmpTrapOID value 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 RFC 3418 [RFC3418], the SNMPv1 generic-trap parameter SHALL be set as follows:
(3) 如果SNMPv2 snmpTrapOID参数是RFC 3418[RFC3418]中定义的标准陷阱之一，则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 RFC 3418 [RFC3418], 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参数是RFC 3418[RFC3418]中定义的标准陷阱之一，则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 (and note that the SNMPv2 variable-bindings do not include the variable-bindings containing sysUpTime.0, snmpTrapOID.0). 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.2.3 and section 4.3).
(6) SNMPv1变量绑定应为SNMPv2变量绑定（请注意，SNMPv2变量绑定不包括包含sysUpTime.0、snmpTrapOID.0的变量绑定）。但是，请注意，如果SNMPv2变量绑定包含类型为Counter64的任何对象，则无法执行到SNMPv1通知参数的转换。在这种情况下，通知不能编码在SNMPv1数据包中（因此不能使用SNMPv1发送通知，请参见第4.2.3节和第4.3节）。
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版本的网络元素相互通信。代理实现对于保护两个本地安全网络之间不安全链路上的通信也很有用。
Throughout section 4., 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:
在整个第4节中，本文件涉及“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的事务执行本文描述的翻译。
Further, note that there is no mention of 'SNMPv3 access to MIB data' in this document, as SNMPv3 uses SNMPv2 PDU types and protocol operations.
此外，请注意，本文档中未提及“SNMPv3访问MIB数据”，因为SNMPv3使用SNMPv2 PDU类型和协议操作。
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
此外，当选择SNMPv1作为消息版本时，命令生成器必须将GetBulk请求“降级”为GetNext请求
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.
传出请求。只需将操作类型更改为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. Also, SNMPv1 access to MIB data SHOULD NOT be used when processing SNMPv2c or SNMPv3 messages. 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错误代码。此外，在处理SNMPv2c或SNMPv3消息时，不应使用SNMPv1访问MIB数据。在代理转发的情况下，为了向后兼容，可以使用SNMPv1错误代码，而不改变转发的SNMPv2c或SNMPv3消息。
The following sections describe the behaviour of a command responder application which supports multiple SNMP message versions, and which uses SNMPv2 access to MIB data when processing an SNMPv1 message.
以下各节描述了命令响应程序应用程序的行为，该应用程序支持多个SNMP消息版本，并在处理SNMPv1消息时使用SNMPv2访问MIB数据。
The SMIv2 [RFC2578] defines one new syntax that is incompatible with SMIv1. This syntax is Counter64. All other syntaxes defined by SMIv2 are compatible with SMIv1.
SMIv2[RFC2578]定义了一种与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-
- 收到包含变量绑定（其名称字段指向Counter64类型的对象实例）的SNMPv1 GetRequest PDU后，应返回GetResponsePDU，并返回一个错误-
status of noSuchName and the error-index set to the variable binding that caused this error.
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 an 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 (if there is more than one then 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 (if there is more than one then 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.4, "Error Status Mappings".
- 应使用第4.4节“错误状态映射”中的表格将错误状态转换为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 SNMPv2 access to MIB data is used 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时，当SNMPv2访问MIB数据作为处理请求的一部分时，必须遵循以下过程。可能存在对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.4, "Error Status Mappings".
(1) 应使用第4.4节“错误状态映射”中的表格将错误状态转换为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 or endOfMibView exception occurs.
(1) 任何包含Counter64的SNMPv2语法的变量绑定都应被视为不在视图中，并且应根据需要多次访问MIB数据，直到返回Counter64以外的值，或者发生错误或endOfMibView异常。
(2) If there is any variable binding that contains an SNMPv2 exception endOfMibView (if there is more than one then 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 using SNMPv2 access to MIB data.
处理SNMPv1 SetRequest时，使用SNMPv2访问MIB数据时必须遵循以下步骤。
When such MIB access returns 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.4, "Error Status Mappings".
- 应使用第4.4节“错误状态映射”中的表格将错误状态转换为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 notification 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 [RFC3413], 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陷阱时，为了执行[RFC3413]第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 or notification receiver and the proxy, and the 'Downstream Version' refers to the version used between the proxy and the command responder or notification originator, 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 act as if the non-repeaters and max-repetitions fields were both set 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', and 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 and ensure that the error-index field is set to 0 before forwarding the response.
- 如果收到错误状态字段值为“tooBig”的GetResponse PDU，且该消息将使用SNMPv2c或SNMPv3消息版本转发，且代理收到的原始请求不是GetBulkRequest PDU，代理转发器应删除变量绑定字段的内容，并确保在转发响应之前将错误索引字段设置为0。
- 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-
- 如果收到错误状态字段值为“tooBig”的GetResponse PDU，并且将使用SNMPv2c或SNMPv3消息版本转发消息，并且代理收到的原始请求是GetBulkRequest PDU，则代理转发程序应重新发送转发的请求（该请求将被更改为GetNextRequest PDU）除去第一个变量绑定之外的所有变量绑定。代理转发商只能重新发送一次此类请求。如果生成的GetResponse PDU还包含值为“tooBig”的错误状态字段，则代理转发器应删除变量的内容-
bindings field, and change the error-status field to 'noError', and ensure that the error-index field is set to 0 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'. Further note that, while it might have been possible to fit more variable bindings if the proxy only re-sent the request multiple times, and stripped only a single variable binding from the request at a time, this is deemed too expensive. The approach described here preserves the behaviour of a GetBulkRequest as closely as possible, without incurring the cost of re-sending the request multiple times.
绑定字段，并将错误状态字段更改为“noError”，并确保在转发响应之前将错误索引字段设置为0。请注意，如果原始请求仅包含单个变量绑定，则代理可能会跳过重新发送请求，只需删除变量绑定并将错误状态更改为“noError”。进一步注意，如果代理只多次重新发送请求，并且一次只从请求中剥离一个变量绑定，那么可能会安装更多的变量绑定，但这被认为太昂贵了。这里描述的方法尽可能地保留GetBulkRequest的行为，而不会产生多次重新发送请求的成本。
- 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 objects.
请注意，当SNMPv1代理生成包含陷阱PDU的消息时，该陷阱PDU随后由一个或多个代理转发器使用SNMPv1以外的SNMP版本转发，SNMPv1代理生成的原始消息中的社区字符串和代理地址字段将通过使用snmpTrapAddress和SNMPTRAPAcommunity对象来保留。
- 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. However, when using such a configuration, one should be careful to use a different principal for communicating with the target agent when an incoming SNMPv2c or SNMPv3 request is received, to ensure that objects of type Counter64 are properly returned.
部署提示：当返回Counter64类型时，代理使用的重复GetNext请求的过程可能会很昂贵。部署代理时，可以通过配置代理向其转发请求的目标代理来避免这种情况，配置方式应确保代理与这些代理通信时所使用的主体实际上看不到Counter64类型的任何对象。然而，在使用这种配置时，当接收到传入的SNMPv2c或SNMPv3请求时，应小心使用不同的主体与目标代理通信，以确保正确返回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, and the message would be forwarded using the SNMPv1 message version, the error-status value is modified using the mappings in section 4.4.
- 如果收到的GetResponse PDU包含SNMPv2错误状态值ErrorValue、ErrorEncoding、ErrorType、ErrorLength、inconsistentValue、noAccess、notWritable、noCreation、inconsistentName、resourceUnavailable、commitFailed、undoFailed或authorizationError，则将使用SNMPv1消息版本转发消息，使用第4.4节中的映射修改错误状态值。
- 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 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.
- 如果收到SNMPv2陷阱PDU，并将使用SNMPv1消息版本转发，则代理应应用第3节中描述的翻译规则，并将通知作为陷阱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 Message Processing (MP) models are defined in this document:
为了使SNMPv1（和SNMPv2c）适应SNMP体系结构，本文档中定义了以下消息处理（MP）模型：
- The SNMPv1 Message Processing Model
- SNMPv1消息处理模型
- The SNMPv1 Community-Based Security Model
- 基于SNMPv1社区的安全模型
- 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 [RFC3411]. 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体系结构中使用的版本无关参数之间进行映射[RFC3411]。必须映射的参数包括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 RFC 1157 [RFC1157], 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消息的处理。消息的处理通常采用RFC 1157[RFC1157]中所述的相同方式进行，其区别和澄清如下所述。SNMPv1的SnmpMessageProcessingModel值为0（SNMPv2c的值为1）。
In RFC 1157 [RFC1157], 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:
在RFC 1157[RFC1157]中，第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 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.
- 如果snmpCommunityTransportTag是空字符串，则出于匹配目的将忽略它。如果snmpCommunityTransportTag不是空字符串，则接收消息的transportDomain和transportAddress必须与snmpCommunityTransportTag值选择的SNMPTargetAddr表中的一个条目匹配。当检查transportDomain和transportAddress是否与SNMPTargetADRDR表中的条目匹配时，将按照第5.3节所述使用SNMPTargetADRDR任务对象。
If no such entry can be found, an authentication failure occurs as described in RFC 1157 [RFC1157], and the snmpInBadCommunityNames counter is incremented.
如果找不到此类条目，则会发生RFC 1157[RFC1157]中所述的身份验证失败，并且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, which will be the value of snmpCommunitySecurityName from the selected row in the snmpCommunityTable.
- securityName，它将是snmpCommunityTable中选定行的snmpCommunitySecurityName的值。
- The scopedPDU. Note that this parameter will actually consist of three values, the contextSnmpEngineID (which will be the value of snmpCommunityContextEngineID from the selected entry in the snmpCommunityTable), the contextName (which will be the value of snmpCommunityContextName from the selected entry in the snmpCommunityTable), and the PDU. These must be separate values, since the first two do not actually appear in the message.
- 范围dpdu。请注意，此参数实际上将由三个值组成：contextSnmpEngineID（它将是snmpCommunityTable中选定项的snmpCommunityContextEngineID值）、contextName（它将是snmpCommunityTable中选定项的snmpCommunityContextName值）和PDU。这些值必须是单独的，因为前两个值实际上不会出现在消息中。
- The maxSizeResponseScopedPDU, which will be derived using the minimum of the maxMessageSize above, and the value of snmpTargetAddrMMS of the selected row in the snmpTargetAddrTable. If no such entry was selected, then this value will be derived from the maxMessageSize only.
- maxSizeResponseScopedPDU，它将使用上述maxMessageSize中的最小值和snmpTargetAddrTable中选定行的snmpTargetAddrMMS值导出。如果未选择此类条目，则此值将仅从maxMessageSize派生。
- The securityStateReference, which MUST contain the community string from the original request.
- 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 securityStateReference information of the original request.
生成传出响应不需要特殊处理。但是，传出响应中使用的社区字符串必须与原始请求中的社区字符串相同。原始社区字符串必须存在于原始请求的securityStateReference信息中。
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 transportDomain and transportAddress must match one of the entries in the snmpTargetAddrTable selected by the snmpCommunityTransportTag value.
- 如果snmpCommunityTransportTag是空字符串，则出于匹配目的将忽略它。如果snmpCommunityTransportTag不是空字符串，则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列的值。
In a proxy forwarding application, when a received request is to be forwarded using the SNMPv1 Message Processing Model, the parameters used for forwarding will be obtained by examining the SNMP-PROXY-MIB and the SNMP-TARGET-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:
在代理转发应用程序中，当使用SNMPv1消息处理模型转发接收到的请求时，将通过检查SNMP-proxy-MIB和SNMP-TARGET-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 no such entry can be found, the proxy forwarding application should follow the procedure described in RFC 3413 [RFC3413], section 3.5.1.1, item (2). This procedure states that the snmpProxyDrops counter [RFC3418] is incremented, and that a Response-PDU is generated by calling the Dispatcher using the returnResponsePdu abstract service interface.
如果找不到此类条目，则代理转发应用程序应遵循RFC 3413[RFC3413]第3.5.1.1节第（2）项中所述的程序。此过程说明snmpProxyDrops计数器[RFC3418]递增，并且通过使用returnResponsePdu抽象服务接口调用Dispatcher生成响应PDU。
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
SNMP-COMMUNITY-MIB包含用于社区字符串和独立于版本的SNMP消息参数之间映射的对象。此外，此MIB还提供了一种机制，用于对传入请求执行源地址验证，以及基于传出通知的目标地址选择社区字符串。这两个
features are accomplished by providing a tag in the snmpCommunityTable which selects sets of entries in the snmpTargetAddrTable [RFC3413]. 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.
功能是通过在snmpCommunityTable中提供一个标记来实现的，该标记选择SNMPTargetADRDR表[RFC3413]中的一组条目。此外，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). If use of the snmpTargetAddrTMask object is not mentioned in text describing matching addresses in the snmpTargetAddrTable, then its value MUST be ignored.
请注意，SNMPTargetADRTMAK对象仅在明确说明的情况下使用。特别是，在生成通知时不使用它（即，在生成通知时，SNMPTargetADRDR表中的条目仅指定单个地址）。如果在描述SNMPTargetADRDR表中匹配地址的文本中未提及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 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.
在检查传输地址是否与snmpTargetAddrTable中的条目匹配时，如果snmpTargetAddrTMask的值是长度为零的八位字节字符串，则将忽略掩码值，并且SNMPTargetADDRTADRADress的值必须与传输地址完全匹配。否则，snmptagetadrtmask值中每个八位字节的每个位对应于snmptagetadrdrtAddress值中相同八位字节的相同位。对于在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 "200308060000Z" -- 06 Aug 2003, midnight ORGANIZATION "SNMPv3 Working Group" CONTACT-INFO "WG-email: snmpv3@lists.tislabs.com Subscribe: majordomo@lists.tislabs.com In msg body: subscribe snmpv3
snmpCommunityMIB模块身份最后更新“200308060000Z”-2003年8月6日，午夜组织“SNMPv3工作组”联系方式工作组电子邮件：snmpv3@lists.tislabs.com订阅：majordomo@lists.tislabs.com在消息正文中：订阅snmpv3
Co-Chair: Russ Mundy SPARTA, Inc Postal: 7075 Samuel Morse Drive Columbia, MD 21045 USA EMail: mundy@tislabs.com Phone: +1 410-872-1515
联席主席：Russ Mundy SPARTA，Inc.邮政编码：7075美国马里兰州哥伦比亚塞缪尔莫尔斯大道21045电子邮件：mundy@tislabs.com电话：+1410-872-1515
Co-Chair: David Harrington Enterasys Networks Postal: 35 Industrial Way P. O. Box 5005 Rochester, New Hampshire 03866-5005 USA EMail: dbh@enterasys.com Phone: +1 603-337-2614
联席主席：David Harrington Enterasys Networks邮政：美国新罕布什尔州罗切斯特市工业路35号邮政信箱5005 03866-5005电子邮件：dbh@enterasys.com电话：+1603-337-2614
Co-editor: Rob Frye Vibrant Solutions
联合编辑：Rob Frye Vibrant Solutions
Postal: 2711 Prosperity Ave Fairfax, Virginia 22031 USA E-mail: rfrye@vibrant-1.com Phone: +1-703-270-2000
邮寄：美国弗吉尼亚州费尔法克斯繁荣大道2711号22031电子邮件：rfrye@vibrant-1.com电话：+1-703-270-2000
Co-editor: David B. Levi Nortel Networks Postal: 3505 Kesterwood Drive Knoxville, Tennessee 37918 E-mail: dlevi@nortelnetworks.com Phone: +1 865 686 0432
合编：David B.Levi Nortel Networks邮政：田纳西州诺克斯维尔凯斯特伍德大道3505号37918电子邮件：dlevi@nortelnetworks.com电话：+18656860432
Co-editor: Shawn A. Routhier Wind River Systems, Inc. Postal: 500 Wind River Way Alameda, CA 94501 E-mail: sar@epilogue.com Phone: +1 510 749 2095
合编：Shawn A.Routhier Wind River Systems，Inc.邮政编码：加利福尼亚州阿拉米达市Wind River Way 500邮编：94501电子邮件：sar@epilogue.com电话：+15107492095
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.
DESCRIPTION“此MIB模块定义有助于支持SNMPv1、SNMPv2c和SNMPv3共存的对象。
Copyright (C) The Internet Society (2003) This version of this MIB module is part of RFC 3584; see the RFC itself for full legal notices."
版权所有（C）互联网协会（2003）此MIB模块版本是RFC 3584的一部分；有关完整的法律通知，请参见RFC本身。”
REVISION "200308060000Z" -- 06 Aug 2003 DESCRIPTION "Updated the LAST-UPDATED, CONTACT-INFO, and REVISION clauses and added a copyright notice to the DESCRIPTION clause of the MIB module's MODULE-IDENTITY invocation.
修订版“200308060000Z”-2003年8月6日“说明”更新了最近更新的、联系信息和修订条款，并在MIB模块的模块标识调用的说明条款中添加了版权声明。
Updated the description of snmpCommunityTransportTag to make it consistent with the rest of the document.
更新了snmpCommunityTransportTag的描述，使其与文档的其余部分一致。
Updated the description of `snmpTargetAddrMMS' to
将“snmpTargetAddrMMS”的说明更新为
clarify that a value of 0 means that the maximum message size is unknown.
澄清值0表示最大消息大小未知。
Changed the name of 'snmpCommunityGroup' to snmpCommunityTableGroup to avoid a name conflict with the SNMPv2-MIB.
将“snmpCommunityGroup”的名称更改为snmpCommunityTableGroup，以避免与SNMPv2 MIB发生名称冲突。
Updated DESCRIPTION of snmpCommunityName.
更新了snmpCommunityName的说明。
Updated DESCRIPTION of snmpTrapCommunity.
snmptrap社区的更新描述。
Added snmpCommunityMIBFullCompliance.
增加了snmpCommunityMIBFullCompliance。
This version published as RFC 3584."
此版本作为RFC 3584发布。”
REVISION "200003060000Z" -- 6 Mar 2000 DESCRIPTION "This version published as RFC 2576."
修订版“2000036000Z”-2000年3月6日描述“本版本发布为RFC 2576。”
::= { snmpModules 18 }
::= { snmpModules 18 }
-- Administrative assignments ************************************
-- Administrative assignments ************************************
snmpCommunityMIBObjects
OBJECT IDENTIFIER ::= { snmpCommunityMIB 1 }
snmpCommunityMIBObjects
OBJECT IDENTIFIER ::= { snmpCommunityMIB 1 }
snmpCommunityMIBConformance
OBJECT IDENTIFIER ::= { snmpCommunityMIB 2 }
snmpCommunityMIBConformance
OBJECT IDENTIFIER ::= { snmpCommunityMIB 2 }
--
-- The snmpCommunityTable contains a database of community
-- strings. This table provides mappings between community
-- strings, and the parameters required for View-based Access
-- Control.
--
--
-- 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
snmpCommunityEntry对象类型语法snmpCommunityEntry MAX-ACCESS不可访问状态当前
DESCRIPTION
"Information about a particular community string."
INDEX { IMPLIED snmpCommunityIndex }
::= { snmpCommunityTable 1 }
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. There is no SIZE constraint
specified for this object because RFC 1157 does not
impose any explicit limitation on the length of community
strings (their size is constrained indirectly by the
SNMP message size)."
::= { 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. There is no SIZE constraint
specified for this object because RFC 1157 does not
impose any explicit limitation on the length of community
strings (their size is constrained indirectly by the
SNMP message size)."
::= { 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
snmpCommunityContextEngineID对象类型
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.
语法SnmpEngineID MAX-ACCESS read create STATUS current DESCRIPTION“contextEngineID，指示在使用snmpCommunityName的相应实例指定的社区字符串时访问管理信息的上下文的位置。
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 which are used in two ways: - to specify the transport endpoints from which an SNMP entity will accept management requests, and - to specify the transport endpoints to which a notification may be sent using the community string matching the corresponding instance of snmpCommunityName. In either case, if the value of this object has zero-length, transport endpoints are not checked when either authenticating messages containing this community string, nor when generating notifications.
snmpCommunityTransportTag对象类型语法SnmpTagValue MAX-ACCESS读取创建状态当前描述“此对象指定一组传输终结点，这些终结点以两种方式使用：-指定SNMP实体将从中接受管理请求的传输终结点，以及-指定可以使用与相应snmpCommunityName实例匹配的社区字符串向其发送通知的传输终结点。”。在任何一种情况下，如果此对象的值的长度为零，则在验证包含此社区字符串的消息或生成通知时，都不会检查传输端点。
The transports identified by this object are specified in the snmpTargetAddrTable. Entries in that table whose snmpTargetAddrTagList contains this tag value are identified.
此对象标识的传输在SNMPTargetADRDR表中指定。标识SNMPTargetADRDTagList包含此标记值的表中的条目。
If a management request containing a community string
如果管理请求包含社区字符串
that matches the corresponding instance of snmpCommunityName is received on a transport endpoint other than the transport endpoints identified by this object the request is deemed unauthentic.
与snmpCommunityName的对应实例匹配的请求将在传输端点上接收，而不是在此对象标识的传输端点上接收。该请求被视为不真实。
When a notification is to be sent using an entry in
this table, if the destination transport endpoint of
the notification does not match one of the transport
endpoints selected by this object, the notification
is not sent."
DEFVAL { ''H } -- the empty string
::= { snmpCommunityEntry 6 }
When a notification is to be sent using an entry in
this table, if the destination transport endpoint of
the notification does not match one of the transport
endpoints selected by this object, the notification
is not sent."
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
SNMPTargetAddExtEntry的SNMPTargetAddExtTable对象类型语法序列
MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table of mask and maximum message size (mms) values associated with the snmpTargetAddrTable.
MAX-ACCESS not ACCESS STATUS current DESCRIPTION“与snmpTargetAddrTable关联的掩码和最大消息大小（mms）值表。
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
此对象的值允许SNMPTargetADRDR表中的一个条目指定多个地址。掩码值用于选择传输地址的哪些位必须与snmpTargetAddrAddress的相应实例的位匹配，以便
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. 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.
与SNMPTargetADRDR表中的特定条目匹配的传输地址。掩码值中为1的位表示传输地址中的位，该位必须与SNMPtageTadrAddress值中的位匹配。掩码中的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. Note that a value of 0 means
that the maximum message size is unknown."
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. Note that a value of 0 means
that the maximum message size is unknown."
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
"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. There is no SIZE
constraint specified for this object because RFC 1157
does not impose any explicit limitation on the length
of community strings (their size is constrained
indirectly by the SNMP message size)."
::= { snmpCommunityMIBObjects 4 }
snmpTrapCommunity OBJECT-TYPE
SYNTAX OCTET STRING
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"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. There is no SIZE
constraint specified for this object because RFC 1157
does not impose any explicit limitation on the length
of community strings (their size is constrained
indirectly by the SNMP message size)."
::= { 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 { snmpCommunityTableGroup }
MODULE——此模块为强制组{snmpCommunityTableGroup}
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 MIN-ACCESS read-only DESCRIPTION "Write access is not required."
对象snmpCommunityStorageType 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 }
snmpCommunityMIBFullCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP engines which implement the SNMP-COMMUNITY-MIB with full read-create access."
snmpCommunityMIBFullCompliance MODULE-COMPLIANCE STATUS当前描述“实现SNMP-COMMUNITY-MIB和完全读取创建访问的SNMP引擎的符合性声明。”
MODULE -- this module
MANDATORY-GROUPS { snmpCommunityTableGroup }
::= { snmpCommunityMIBCompliances 3 }
MODULE -- this module
MANDATORY-GROUPS { snmpCommunityTableGroup }
::= { snmpCommunityMIBCompliances 3 }
snmpCommunityTableGroup OBJECT-GROUP OBJECTS { snmpCommunityName, snmpCommunitySecurityName, snmpCommunityContextEngineID, snmpCommunityContextName, snmpCommunityTransportTag, snmpCommunityStorageType,
snmpCommunityTableGroup对象组对象{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 }
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
translating to SNMPv2c or SNMPv3."
::= { snmpCommunityMIBGroups 3 }
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 }
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 (Enterasys Networks) David Levi (Nortel Networks) Brian O'Keefe (Hewlett Packard) Jon Saperia (IronBridge Networks, Inc.) Steve Waldbusser (International Network Services)
Jeff Case（SNMP研究公司）David Harrington（企业网络公司）David Levi（北电网络公司）Brian O'Keefe（惠普公司）Jon Saperia（铁桥网络公司）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数据进行未经授权的访问，否则将是安全的。
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 (also known as confidentiality). 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转发）将失去使用身份验证和隐私的安全优势（也称为机密性）。需要仔细配置代理以解决此类情况。处理此类情况的一种方法可能是使用加密隧道。
There are a number of management objects defined in this MIB module with a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. These are the tables and objects and their sensitivity/vulnerability:
此MIB模块中定义了许多管理对象，其MAX-ACCESS子句为read-write和/或read-create。在某些网络环境中，此类对象可能被视为敏感或易受攻击。在没有适当保护的非安全环境中支持SET操作可能会对网络操作产生负面影响。以下是表和对象及其敏感度/漏洞：
- The snmpCommunityTable allows creation and deletion of community strings, which is potentially a serious security hole. Access to this table should be greatly restricted, preferably by only allowing write access using SNMPv3 VACM and USM, with authentication and privacy.
- snmpCommunityTable允许创建和删除社区字符串，这可能是一个严重的安全漏洞。对该表的访问应该受到很大的限制，最好只允许使用SNMPv3 VACM和USM进行写访问，并具有身份验证和隐私。
- The snmpTargetAddrExtTable contains write-able objects which may also be considered sensitive, and so access to it should be restricted as well.
- SNMPTargetAddExtTable包含可写对象，这些对象也可能被视为敏感对象，因此对它的访问也应该受到限制。
Some of the readable objects in this MIB module (i.e., objects with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. These are the tables and objects and their sensitivity/vulnerability:
在某些网络环境中，此MIB模块中的某些可读对象（即具有MAX-ACCESS而非not ACCESS的对象）可能被视为敏感或易受攻击。因此，在通过SNMP通过网络发送这些对象时，控制甚至获取和/或通知对这些对象的访问，甚至可能加密这些对象的值，这一点非常重要。以下是表和对象及其敏感度/漏洞：
- The snmpCommunityTable 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 objects in the snmpCommunityTable, and in particular, to make it inaccessible when using the 'public' community string.
- snmpCommunityTable有可能公开社区字符串，这些字符串提供了对更多信息的访问，而不是使用通常的“公共”社区字符串。因此，安全管理员可能希望限制snmpCommunityTable中对象的可访问性，特别是在使用“public”社区字符串时使其不可访问。
SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module.
SNMPv3之前的SNMP版本未包含足够的安全性。即使网络本身是安全的（例如通过使用IPSec），即使如此，也无法控制安全网络上的谁可以访问和获取/设置（读取/更改/创建/删除）此MIB模块中的对象。
It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy).
建议实施者考虑SNMPv3框架所提供的安全特性（参见[RCFC310]，第8节），包括对SNMPv3加密机制的完全支持（用于身份验证和隐私）。
Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them.
此外，不建议部署SNMPv3之前的SNMP版本。相反，建议部署SNMPv3并启用加密安全性。然后，客户/运营商应负责确保授予访问此MIB模块实例权限的SNMP实体已正确配置为仅授予那些拥有确实获取或设置（更改/创建/删除）对象的合法权限的主体（用户）访问对象。
[RFC1155] Rose, M. and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based internets", STD 16, RFC 1155, May 1990.
[RFC1155]Rose，M.和K.McCloghrie，“基于TCP/IP的互联网管理信息的结构和识别”，STD 16，RFC 1155，1990年5月。
[RFC1157] Case, J., Fedor, M., Schoffstall, M. and C. Davin, "Simple Network Management Protocol (SNMP)", STD 15, RFC 1157, May 1990.
[RFC1157]Case，J.，Fedor，M.，Schoffstall，M.和C.Davin，“简单网络管理协议（SNMP）”，STD 15，RFC 1157，1990年5月。
[RFC1212] Rose, M. and K. McCloghrie, Eds., "Concise MIB Definitions", STD 16, RFC 1212, March 1991.
[RFC1212]Rose，M.和K.McCloghrie编辑，“简明MIB定义”，STD 16，RFC 1212，1991年3月。
[RFC1215] Rose, M., "A Convention for Defining Traps for use with the SNMP", RFC 1215, March 1991.
[RFC1215]Rose，M.，“定义用于SNMP的陷阱的约定”，RFC1215，1991年3月。
[RFC1303] McCloghrie, K. and M. Rose, "A Convention for Describing SNMP-based Agents", RFC 1303, February 1992.
[RFC1303]McCloghrie，K.和M.Rose，“描述基于SNMP的代理的约定”，RFC 1303，1992年2月。
[RFC1901] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, January 1996.
[RFC1901]Case，J.，McCloghrie，K.，Rose，M.和S.Waldbusser，“基于社区的SNMPv2简介”，RFC 19011996年1月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2578] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", RFC 2578, STD 58, April 1999.
[RFC2578]McCloghrie，K.，Perkins，D.和J.Schoenwaeld，“管理信息的结构版本2（SMIv2）”，RFC 2578，STD 58，1999年4月。
[RFC2579] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999.
[RFC2579]McCloghrie，K.，Perkins，D.和J.Schoenwaeld，“SMIv2的文本约定”，STD 58，RFC 2579，1999年4月。
[RFC2580] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999.
[RFC2580]McCloghrie，K.，Perkins，D.和J.Schoenwaeld，“SMIv2的一致性声明”，STD 58，RFC 25801999年4月。
[RFC3411] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002.
[RFC3411]Harrington，D.，Presohn，R.和B.Wijnen，“描述简单网络管理协议（SNMP）管理框架的体系结构”，STD 62，RFC 3411，2002年12月。
[RFC3412] Case, J., Harrington, D., Presuhn, R. and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3412, December 2002.
[RFC3412]Case，J.，Harrington，D.，Presohn，R.和B.Wijnen，“简单网络管理协议（SNMP）的消息处理和调度”，STD 62，RFC 3412，2002年12月。
[RFC3413] Levi, D., Meyer, P. and B. Stewart, "Simple Network Management Protocol (SNMP) Applications", STD 62, RFC 3413, December 2002.
[RFC3413]Levi，D.，Meyer，P.和B.Stewart，“简单网络管理协议（SNMP）应用”，STD 62，RFC 3413，2002年12月。
[RFC3414] Blumenthal, U. and B. Wijnen, "The User-Based Security Model (USM) for Version 3 of the Simple Network Management Protocol (SNMP)", STD 62, RFC 3414, December 2002.
[RFC3414]Blumenthal，U.和B.Wijnen，“简单网络管理协议（SNMP）第3版的基于用户的安全模型（USM）”，STD 62，RFC 3414，2002年12月。
[RFC3415] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3415, December 2002.
[RFC3415]Wijnen，B.，Presohn，R.和K.McCloghrie，“用于简单网络管理协议（SNMP）的基于视图的访问控制模型（VACM）”，STD 62，RFC 3415，2002年12月。
[RFC3416] Presuhn, R., Ed., "Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMPv2)", STD 62, RFC 3416, December 2002.
[RFC3416]Presohn，R.，Ed.“简单网络管理协议（SNMPv2）的协议操作版本2”，STD 62，RFC 3416，2002年12月。
[RFC3417] Presuhn, R., Ed., "Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2)", STD 62, RFC 3417, December 2002.
[RFC3417]Presohn，R.，Ed.“简单网络管理协议（SNMPv2）版本2的传输映射”，STD 62，RFC 34172002年12月。
[RFC3418] Presuhn, R., Ed., "Management Information Base (MIB) for Version 2 of the Simple Network Management Protocol (SNMP)", STD 62, RFC 3418, December 2002.
[RFC3418]Presohn，R.，Ed.“简单网络管理协议（SNMP）版本2的管理信息库（MIB）”，STD 62，RFC 3418，2002年12月。
[ASN1] Information processing systems - Open Systems Interconnection - Specification of Abstract Syntax Notation One (ASN.1), International Organization for Standardization. International Standard 8824, (December, 1987).
[ASN1]信息处理系统.开放系统互连.抽象语法符号1规范（ASN.1），国际标准化组织。国际标准8824（1987年12月）。
[RFC1908] 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.
[RFC1908]Case，J.，McCloghrie，K.，Rose，M.和S.Waldbusser，“互联网标准网络管理框架第1版和第2版之间的共存”，RFC 1908，1996年1月。
[RFC2089] Levi, D. and B. Wijnen, "Mapping SNMPv2 onto SNMPv1 within a bilingual SNMP agent", RFC 2089, January 1997.
[RFC2089]Levi，D.和B.Wijnen，“在双语SNMP代理中将SNMPv2映射到SNMPv1”，RFC 2089，1997年1月。
[RFC2576] Frye, R., Levi, D., Routhier, S. and B. Wijnen, "Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework", RFC 2576, March 2000.
[RFC2576]Frye，R.，Levi，D.，Routhier，S.和B.Wijnen，“互联网标准网络管理框架第1版、第2版和第3版之间的共存”，RFC 25762000年3月。
[RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002.
[RFC3410]Case，J.，Mundy，R.，Partain，D.和B.Stewart，“互联网标准管理框架的介绍和适用性声明”，RFC 34102002年12月。
Section numbers below refer to the old section numbers from RFC 2576. Some section numbers have changed since RFC 2576.
以下章节编号指RFC 2576中的旧章节编号。自RFC 2576以来，部分章节编号已更改。
- Added text to abstract about conversion of MIBs from SMIv1 to SMIv2.
- 在摘要中添加了有关MIB从SMIv1到SMIv2转换的文本。
- Added note at end of section 1.3 that all discussion of SNMPv2 PDU types and protocol operations applies to both SNMPv2c and SNMPv3.
- 在第1.3节末尾添加注释，所有关于SNMPv2 PDU类型和协议操作的讨论均适用于SNMPv2c和SNMPv3。
- Added text at end of section 1.4 to clarify that there is no such thing as 'SNMPv3 access to MIB data', as SNMPv3 just uses SNMPv2 PDU types and protocol operations.
- 在第1.4节末尾添加了文本，以澄清不存在“SNMPv3访问MIB数据”的情况，因为SNMPv3只使用SNMPv2 PDU类型和协议操作。
- Moved section 1.4 to the beginning of section 4.
- 将第1.4节移至第4节开头。
- Changed "MUST" to "SHOULD" in item (3) of the first list in Section 2.1.1 to since unconstrained INTEGER is not actually illegal in SMIv2.
- 将第2.1.1节第一个列表第（3）项中的“必须”改为“应该”，因为无约束整数在SMIv2中实际上并不非法。
- Changed "SHOULD" to "MUST" in item (13) of the first list in Section 2.1.1 to clarify that collecting related objects into groups is required when translating a MIB module from SMIv1 to SMIv2.
- 将第2.1.1节第一个列表第（13）项中的“应该”更改为“必须”，以澄清在将MIB模块从SMIv1转换为SMIv2时，需要将相关对象收集到组中。
- Re-organized bullets in section 2.1.1 to improve clarity.
- 重新组织第2.1.1节中的项目符号，以提高清晰度。
- Changed "SHOULD" to "MUST" in items (1) and (2) of Section 2.3 since those updates are indeed required when translating a capabilities statement from the language defined by RFC 1303 into SMIv2.
- 将第2.3节第（1）项和第（2）项中的“应该”改为“必须”，因为将能力声明从RFC 1303定义的语言翻译成SMIv2时确实需要这些更新。
- In the second bullet of the last part of Section 3 listing the SNMPv2 notification parameters, clarified that the snmpTrapOID parameter refers to the value portion (not the name portion) of the second variable-binding, and changed the wording in the text under bullet (1) of Section 3.2 from "the snmpTrapOID" to "the snmpTrapOID value" to emphasize this point.
- 在列出SNMPv2通知参数的第3节最后一部分的第二个项目符号中，阐明了snmpTrapOID参数指的是第二个变量绑定的值部分（而不是名称部分），并将第3.2节项目符号（1）下文本中的措辞从“snmpTrapOID”改为“snmpTrapOID值”强调这一点。
- In bullet (6) of Section 3.2 emphasized that the SNMPv2 variable-bindings do not include sysUpTime.0 an snmpTrapOID.0.
- 在第3.2节的项目符号（6）中，强调SNMPv2变量绑定不包括sysUpTime.0和snmpTrapOID.0。
- In Section 4.2 clarified that the 'Upstream Version' refers to the version used between the command generator or notification receiver and the proxy, and the 'Downstream Version' refers to the
- 在第4.2节中，澄清了“上游版本”是指命令生成器或通知接收方与代理之间使用的版本，“下游版本”是指
version used between the proxy and the command responder or notification originator. RFC 2576 neglected to mention the notification receiver and notification originator.
代理和命令响应者或通知发起人之间使用的版本。RFC 2576忽略了通知接收人和通知发起人。
- In Section 4.1.2 added text noting that SNMPv1 access to MIB data SHOULD NOT be used when processing SNMPv2c or SNMPv3 messages and re-worded final paragraph to note that the sub-sections that follow are concerned solely with command responders that use SNMPv2 access to MIB data while processing an SNMPv1 request.
- 在第4.1.2节中，添加了注意到在处理SNMPv2c或SNMPv3消息时不应使用SNMPv1访问MIB数据的文本，并对最后一段进行了改写，以注意以下小节仅涉及在处理SNMPv1请求时使用SNMPv2访问MIB数据的命令响应者。
- Re-worded first bullet, section 4.2.1, to make it more readable.
- 修改了第4.2.1节中的第一个项目符号，使其更具可读性。
- In Section 4.2.1 clarified that the error-index field must be set to zero in a translated GetResponse-PDU with an error-status of 'tooBig' and made explicit the rationale for retrying a GetBulkRequest-PDU only once.
- 在第4.2.1节中，澄清了在错误状态为“tooBig”的转换GetResponse PDU中，错误索引字段必须设置为零，并明确了仅重试GetBulkRequest PDU一次的理由。
- Added text to the Deployment Hint in Section 4.2.2 to clarify that different principals should be used for SNMPv1 requests and SNMPv2/v3c requests if for SNMPv1 requests a principal for which Counter64 objects are not-in-view is used.
- 在第4.2.2节中的部署提示中添加了文本，以澄清如果SNMPv1请求使用了Counter64对象不在视图中的主体，则SNMPv1请求和SNMPv2/v3c请求应使用不同的主体。
- In Section 5.2.1 clarified that the securityName value and the scopedPDU's contextSnmpEngineID and contextName values come from the selected entry in the snmpCommunityTable. Also clarified how maxSizeResponseScopedPDU is determined and that securityStateReference must contain the community string of the original request.
- 在第5.2.1节中，澄清了securityName值和scopedPDU的contextSnmpEngineID和contextName值来自snmpCommunityTable中的选定条目。还阐明了maxSizeResponseScopedPDU是如何确定的，以及securityStateReference必须包含原始请求的社区字符串。
- Added Section 5.2.4 on Proxy Forwarding Of Requests.
- 增加了关于请求代理转发的第5.2.4节。
- In Section 5.3 clarified that snmpTargetAddrTMask is to be ignored whenever its use is not explicitly called for.
- 在第5.3节中，阐明了在未明确要求使用SNMPargetadRtmask时，应忽略SNMPargetadRtmask。
- Updated the LAST-UPDATED, CONTACT-INFO, and REVISION clauses and added a copyright notice to the DESCRIPTION clause of the MIB module's MODULE-IDENTITY invocation.
- 更新了LAST-Updated、CONTACT-INFO和REVISION子句，并在MIB模块的module-IDENTITY调用的DESCRIPTION子句中添加了版权声明。
- Added text to DESCRIPTION of snmpCommunityName and snmpTrapCommunity to clarify why the object has no size restriction.
- 在snmpCommunityName和snmpTrapCommunity的描述中添加了文本，以澄清对象没有大小限制的原因。
- Updated the description of snmpCommunityTransportTag to make it consistent with the rest of the document.
- 更新了snmpCommunityTransportTag的描述，使其与文档的其余部分一致。
- Updated the description of 'snmpTargetAddrMMS' to clarify that a value of 0 means that the maximum message size is unknown.
- 更新了“snmpTargetAddrMMS”的说明，以澄清值0表示最大消息大小未知。
- Changed the name of 'snmpCommunityGroup' to 'snmpCommunityTableGroup' in order to resolve a name conflict with the SNMPv2-MIB.
- 将“snmpCommunityGroup”的名称更改为“snmpCommunityTableGroup”，以解决与SNMPv2 MIB的名称冲突。
- Added compliance statement to SNMP-COMMUNITY-MIB for full read-create compliance.
- 在SNMP-COMMUNITY-MIB中添加了符合性声明，以实现完全读取和创建符合性。
- Divided references into Normative References and Informative Reference and updated them to point to current documents.
- 将参考文件分为规范性参考文件和信息性参考文件，并对其进行更新，以指向当前文件。
- Inserted current year into all copyright notices.
- 将本年度插入所有版权声明。
- Corrected various typographical and grammatical errors.
- 纠正了各种印刷和语法错误。
- 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 parameters 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 RFC 2089 the SNMPv2 to SNMPv1 mapping within a multi-lingual SNMP Engine.
- 从RFC 2089中包括（并扩展）多语言SNMP引擎中的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版本时代理转发器行为的描述。
Editors' Addresses
编辑地址
Rob Frye Vibrant Solutions 2711 Prosperity Ave Fairfax, Virginia 22031 U.S.A.
美国弗吉尼亚州费尔法克斯繁荣大道2711号Rob Frye Vibrant Solutions，邮编：22031。
Phone: +1 703 270 2000
EMail: rfrye@vibrant-1.com
Phone: +1 703 270 2000
EMail: rfrye@vibrant-1.com
David B. Levi Nortel Networks 3505 Kesterwood Drive Knoxville, TN 37918 U.S.A.
David B.Levi Nortel Networks美国田纳西州诺克斯维尔凯斯特伍德大道3505号，邮编37918。
Phone: +1 865 686 0432
EMail: dlevi@nortelnetworks.com
Phone: +1 865 686 0432
EMail: dlevi@nortelnetworks.com
Shawn A. Routhier Wind River Systems, Inc. 500 Wind River Way Alameda, CA 94501 U.S.A.
Shawn A.Routhier Wind River Systems，Inc.美国加利福尼亚州阿拉米达市风河道500号，邮编：94501。
Phone: + 1 510 749 2095
EMail: sar@epilogue.com
Phone: + 1 510 749 2095
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: bwijnen@lucent.com
Phone: +31 348 407 775
EMail: bwijnen@lucent.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。