draft-ietf-snmpv3-coex-07.txt   rfc2576.txt 
INTERNET-DRAFT Rob Frye
CoSine Communications Network Working Group R. Frye
David B. Levi Request for Comments: 2576 CoSine Communications
Category: Standards Track D. Levi
Nortel Networks Nortel Networks
Shawn A. Routhier S. Routhier
Integrated Systems Inc. Integrated Systems Inc.
Bert Wijnen B. Wijnen
IBM T.J. Watson Research Lucent Technologies
10 Jan 2000 March 2000
Coexistence between Version 1, Version 2, and Version 3 Coexistence between Version 1, Version 2, and Version 3
of the Internet-standard Network Management Framework of the Internet-standard Network Management Framework
<draft-ietf-snmpv3-coex-07.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document specifies an Internet standards track protocol for the
all provisions of Section 10 of RFC2026. Internet-Drafts are working Internet community, and requests discussion and suggestions for
documents of the Internet Engineering Task Force (IETF), its areas, improvements. Please refer to the current edition of the "Internet
and its working groups. Note that other groups may also distribute Official Protocol Standards" (STD 1) for the standardization state
working documents as Internet-Drafts. and status of this protocol. Distribution of this memo is unlimited.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (1999). All Rights Reserved. Copyright (C) The Internet Society (2000). All Rights Reserved.
Abstract Abstract
The purpose of this document is to describe coexistence between The purpose of this document is to describe coexistence between
version 3 of the Internet-standard Network Management Framework, version 3 of the Internet-standard Network Management Framework,
(SNMPv3), version 2 of the Internet-standard Network Management (SNMPv3), version 2 of the Internet-standard Network Management
Framework (SNMPv2), and the original Internet-standard Network Framework (SNMPv2), and the original Internet-standard Network
Management Framework (SNMPv1). This document obsoletes RFC 1908 [13] Management Framework (SNMPv1). This document obsoletes RFC 1908 [13]
and RFC2089 [14]. and RFC2089 [14].
Table Of Contents Table Of Contents
1 Overview ..................................................... 4 1 Overview ..................................................... 2
1.1 SNMPv1 ..................................................... 4 1.1 SNMPv1 ..................................................... 3
1.2 SNMPv2 ..................................................... 5 1.2 SNMPv2 ..................................................... 4
1.3 SNMPv3 ..................................................... 6 1.3 SNMPv3 ..................................................... 4
1.4 SNMPv1 and SNMPv2 Access to MIB Data ....................... 6 1.4 SNMPv1 and SNMPv2 Access to MIB Data ....................... 5
2 SMI and Management Information Mappings ...................... 8 2 SMI and Management Information Mappings ...................... 5
2.1 MIB Modules ................................................ 8 2.1 MIB Modules ................................................ 6
2.1.1 Object Definitions ....................................... 8 2.1.1 Object Definitions ....................................... 6
2.1.2 Trap and Notification Definitions ........................ 11 2.1.2 Trap and Notification Definitions ........................ 9
2.2 Compliance Statements ...................................... 12 2.2 Compliance Statements ...................................... 9
2.3 Capabilities Statements .................................... 12 2.3 Capabilities Statements .................................... 10
3 Translating Notifications Parameters ......................... 13 3 Translating Notifications Parameters ......................... 10
3.1 Translating SNMPv1 Notification Parameters to SNMPv2 3.1 Translating SNMPv1 Notification Parameters to SNMPv2
Notification Parameters ................................... 14 Notification Parameters ................................... 12
3.2 Translating SNMPv2 Notification Parameters to SNMPv1 3.2 Translating SNMPv2 Notification Parameters to SNMPv1
Notification Parameters ................................... 15 Notification Parameters ................................... 13
4 Approaches to Coexistence in a Multi-lingual Network ......... 18 4 Approaches to Coexistence in a Multi-lingual Network ......... 14
4.1 Multi-lingual implementations .............................. 18 4.1 Multi-lingual implementations .............................. 15
4.1.1 Command Generator ........................................ 18 4.1.1 Command Generator ........................................ 15
4.1.2 Command Responder ........................................ 19 4.1.2 Command Responder ........................................ 15
4.1.2.1 Handling Counter64 ..................................... 19 4.1.2.1 Handling Counter64 ..................................... 16
4.1.2.2 Mapping SNMPv2 Exceptions .............................. 20 4.1.2.2 Mapping SNMPv2 Exceptions .............................. 16
4.1.2.2.1 Mapping noSuchObject and noSuchInstance .............. 21 4.1.2.2.1 Mapping noSuchObject and noSuchInstance .............. 17
4.1.2.2.2 Mapping endOfMibView ................................. 21 4.1.2.2.2 Mapping endOfMibView ................................. 17
4.1.2.3 Processing An SNMPv1 GetRequest ........................ 21 4.1.2.3 Processing An SNMPv1 GetRequest ........................ 18
4.1.2.4 Processing An SNMPv1 GetNextRequest .................... 22 4.1.2.4 Processing An SNMPv1 GetNextRequest .................... 19
4.1.2.5 Processing An SNMPv1 SetRequest ........................ 24 4.1.2.5 Processing An SNMPv1 SetRequest ........................ 20
4.1.3 Notification Originator .................................. 24 4.1.3 Notification Originator .................................. 20
4.1.4 Notification Receiver .................................... 25 4.1.4 Notification Receiver .................................... 21
4.2 Proxy Implementations ...................................... 25 4.2 Proxy Implementations ...................................... 21
4.2.1 Upstream Version Greater Than Downstream Version ......... 25 4.2.1 Upstream Version Greater Than Downstream Version ......... 21
4.2.2 Upstream Version Less Than Downstream Version ............ 26 4.2.2 Upstream Version Less Than Downstream Version ............ 22
4.3 Error Status Mappings ...................................... 28 4.3 Error Status Mappings ...................................... 24
5 Message Processing Models and Security Models ................ 30 5 Message Processing Models and Security Models ................ 25
5.1 Mappings ................................................... 30 5.1 Mappings ................................................... 25
5.2 The SNMPv1 MP Model and SNMPv1 Community-based Security 5.2 The SNMPv1 MP Model and SNMPv1 Community-based Security
Model ..................................................... 30 Model ..................................................... 26
5.2.1 Processing An Incoming Request ........................... 31 5.2.1 Processing An Incoming Request ........................... 26
5.2.2 Generating An Outgoing Response .......................... 33 5.2.2 Generating An Outgoing Response .......................... 28
5.2.3 Generating An Outgoing Notification ...................... 33 5.2.3 Generating An Outgoing Notification ...................... 28
5.3 The SNMP Community MIB Module .............................. 34 5.3 The SNMP Community MIB Module .............................. 29
6 Intellectual Property ........................................ 45 6 Intellectual Property ........................................ 39
7 Acknowledgments .............................................. 46 7 Acknowledgments .............................................. 39
8 Security Considerations ...................................... 47 8 Security Considerations ...................................... 40
9 References ................................................... 48 9 References ................................................... 40
10 Editor's Addresses .......................................... 50 10 Editor's Addresses .......................................... 42
A. Full Copyright Statement .................................... 51 A. Changes From RFC1908 ........................................ 43
Full Copyright Statement ....................................... 44
1. Overview 1. Overview
The purpose of this document is to describe coexistence between The purpose of this document is to describe coexistence between
version 3 of the Internet-standard Network Management Framework, version 3 of the Internet-standard Network Management Framework,
termed the SNMP version 3 framework (SNMPv3), version 2 of the termed the SNMP version 3 framework (SNMPv3), version 2 of the
Internet-standard Network Management Framework, termed the SNMP Internet-standard Network Management Framework, termed the SNMP
version 2 framework (SNMPv2), and the original Internet-standard version 2 framework (SNMPv2), and the original Internet-standard
Network Management Framework (SNMPv1). Network Management Framework (SNMPv1).
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC2119 [15]. document are to be interpreted as described in RFC2119 [15].
There are four general aspects of coexistence described in this There are four general aspects of coexistence described in this
document. Each of these is described in a separate section: document. Each of these is described in a separate section:
- Conversion of MIB documents between SMIv1 and SMIv2 formats is - Conversion of MIB documents between SMIv1 and SMIv2 formats is
documented in section 2. documented in section 2.
- Mapping of notification parameters is documented in section 3. - Mapping of notification parameters is documented in section 3.
- Approaches to coexistence between entities which support the - Approaches to coexistence between entities which support the
various versions of SNMP in a multi-lingual network is various versions of SNMP in a multi-lingual network is
documented in section 4. This section addresses the documented in section 4. This section addresses the processing
processing of protocol operations in multi-lingual of protocol operations in multi-lingual implementations, as
implementations, as well as behaviour of proxy well as behaviour of proxy implementations.
implementations.
- The SNMPv1 Message Processing Model and Community-Based - The SNMPv1 Message Processing Model and Community-Based
Security Model, which provides mechanisms for adapting SNMPv1 Security Model, which provides mechanisms for adapting SNMPv1
into the View-Based Access Control Model (VACM) [20], is into the View-Based Access Control Model (VACM) [20], is
documented in section 5 (this section also addresses the documented in section 5 (this section also addresses the
SNMPv2c Message Processing Model and Community-Based Security SNMPv2c Message Processing Model and Community-Based Security
Model). Model).
1.1. SNMPv1 1.1. SNMPv1
SNMPv1 is defined by these documents: SNMPv1 is defined by these documents:
- STD 15, RFC 1157 [2] which defines the Simple Network - STD 15, RFC 1157 [2] which defines the Simple Network
Management Protocol (SNMPv1), the protocol used for network Management Protocol (SNMPv1), the protocol used for network
access to managed objects. access to managed objects.
- STD 16, RFC 1155 [1] which defines the Structure of Management - STD 16, RFC 1155 [1] which defines the Structure of Management
Information (SMIv1), the mechanisms used for describing and Information (SMIv1), the mechanisms used for describing and
naming objects for the purpose of management. naming objects for the purpose of management.
- STD 16, RFC 1212 [3] which defines a more concise description - STD 16, RFC 1212 [3] which defines a more concise description
mechanism, which is wholly consistent with the SMIv1. mechanism, which is wholly consistent with the SMIv1.
- RFC 1215 [4] which defines a convention for defining Traps for - RFC 1215 [4] which defines a convention for defining Traps for
use with the SMIv1. use with the SMIv1.
Note that throughout this document, the term 'SMIv1' is used. This Note that throughout this document, the term 'SMIv1' is used. This
term generally refers to the information presented in RFC 1155, RFC term generally refers to the information presented in RFC 1155, RFC
1212, and RFC 1215. 1212, and RFC 1215.
1.2. SNMPv2 1.2. SNMPv2
SNMPv2 is defined by these documents: SNMPv2 is defined by these documents:
- STD 58, RFC 2578 which defines Version 2 of the Structure of - STD 58, RFC 2578 which defines Version 2 of the Structure of
Management Information (SMIv2) [7]. Management Information (SMIv2) [7].
- STD 58, RFC 2579 which defines common MIB "Textual - STD 58, RFC 2579 which defines common MIB "Textual Conventions"
Conventions" [8]. [8].
- STD 58, RFC 2580 which defines Conformance Statements and - STD 58, RFC 2580 which defines Conformance Statements and
requirements for defining agent and manager capabilities [9]. requirements for defining agent and manager capabilities [9].
- RFC 1905 which defines the Protocol Operations used in - RFC 1905 which defines the Protocol Operations used in
processing [10]. processing [10].
- RFC 1906 which defines the Transport Mappings used "on the - RFC 1906 which defines the Transport Mappings used "on the
wire" [11]. wire" [11].
- RFC 1907 which defines the basic Management Information Base - RFC 1907 which defines the basic Management Information Base
for monitoring and controlling some basic common functions of for monitoring and controlling some basic common functions of
SNMP entities [12]. SNMP entities [12].
Note that SMIv2 as used throughout this document refers to the first Note that SMIv2 as used throughout this document refers to the first
three documents listed above (RFCs 2578, 2579, and 2580). three documents listed above (RFCs 2578, 2579, and 2580).
The following document augments the definition of SNMPv2: The following document augments the definition of SNMPv2:
- RFC 1901 [6] is an Experimental definition for using SNMPv2 - RFC 1901 [6] is an Experimental definition for using SNMPv2
PDUs within a community-based message wrapper. This is PDUs within a community-based message wrapper. This is
referred to throughout this document as SNMPv2c. referred to throughout this document as SNMPv2c.
1.3. SNMPv3 1.3. SNMPv3
SNMPv3 is defined by these documents: SNMPv3 is defined by these documents:
- RFC 2571 which defines an Architecture for Describing SNMP - RFC 2571 which defines an Architecture for Describing SNMP
Management Frameworks [16]. Management Frameworks [16].
- RFC 2572 which defines Message Processing and Dispatching - RFC 2572 which defines Message Processing and Dispatching [17].
[17].
- RFC 2573 which defines various SNMP Applications [18]. - RFC 2573 which defines various SNMP Applications [18].
- RFC 2574 which defines the User-based Security Model (USM), - RFC 2574 which defines the User-based Security Model (USM),
providing for both Authenticated and Private (encrypted) SNMP providing for both Authenticated and Private (encrypted) SNMP
messages [19]. messages [19].
- RFC 2575 which defines the View-based Access Control Model - RFC 2575 which defines the View-based Access Control Model
(VACM), providing the ability to limit access to different MIB (VACM), providing the ability to limit access to different MIB
objects on a per-user basis [20]. objects on a per-user basis [20].
SNMPv3 also uses the SNMPv2 definitions of RFCs 1905 through 1907 and SNMPv3 also uses the SNMPv2 definitions of RFCs 1905 through 1907 and
the SMIv2 definitions of 2578 through 2580 described above. the SMIv2 definitions of 2578 through 2580 described above.
1.4. SNMPv1 and SNMPv2 Access to MIB Data 1.4. SNMPv1 and SNMPv2 Access to MIB Data
In several places, this document refers to 'SNMPv1 Access to MIB In several places, this document refers to 'SNMPv1 Access to MIB
Data' and 'SNMPv2 Access to MIB Data'. These terms refer to the part Data' and 'SNMPv2 Access to MIB Data'. These terms refer to the part
of an SNMP agent which actually accesses instances of MIB objects, of an SNMP agent which actually accesses instances of MIB objects,
and which actually initiates generation of notifications. and which actually initiates generation of notifications.
Differences between the two types of access to MIB data are: Differences between the two types of access to MIB data are:
- Error-status values generated. - Error-status values generated.
- Generation of exception codes. - Generation of exception codes.
- Use of the Counter64 data type. - Use of the Counter64 data type.
- The format of parameters provided when a notification is - The format of parameters provided when a notification is
generated. generated.
SNMPv1 access to MIB data may generate SNMPv1 error-status values, SNMPv1 access to MIB data may generate SNMPv1 error-status values,
will never generate exception codes nor use the Counter64 data type, will never generate exception codes nor use the Counter64 data type,
and will provide SNMPv1 format parameters for generating and will provide SNMPv1 format parameters for generating
notifications. Note also that SNMPv1 access to MIB data will notifications. Note also that SNMPv1 access to MIB data will
actually never generate a readOnly error (a noSuchName error would actually never generate a readOnly error (a noSuchName error would
always occur in the situation where one would expect a readOnly always occur in the situation where one would expect a readOnly
error). error).
SNMPv2 access to MIB data may generate SNMPv2 error-status values, SNMPv2 access to MIB data may generate SNMPv2 error-status values,
skipping to change at page 8, line 32 skipping to change at page 6, line 27
modules to conform to the SMIv2, the following changes SHALL be made: modules to conform to the SMIv2, the following changes SHALL be made:
2.1.1. Object Definitions 2.1.1. Object Definitions
In general, conversion of a MIB module does not require the In general, conversion of a MIB module does not require the
deprecation of the objects contained therein. If the definition of deprecation of the objects contained therein. If the definition of
an object is truly inadequate for its intended purpose, the object an object is truly inadequate for its intended purpose, the object
SHALL be deprecated or obsoleted, otherwise deprecation is not SHALL be deprecated or obsoleted, otherwise deprecation is not
required. required.
(1) The IMPORTS statement MUST reference SNMPv2-SMI, instead of (1) The IMPORTS statement MUST reference SNMPv2-SMI, instead of
RFC1155-SMI and RFC-1212. RFC1155-SMI and RFC-1212.
(2) The MODULE-IDENTITY macro MUST be invoked immediately after any (2) The MODULE-IDENTITY macro MUST be invoked immediately after any
IMPORTs statement. IMPORTs statement.
(3) For any object with an integer-valued SYNTAX clause, in which the (3) For any object with an integer-valued SYNTAX clause, in which
corresponding INTEGER does not have a range restriction (i.e., the the corresponding INTEGER does not have a range restriction
INTEGER has neither a defined set of named-number enumerations nor (i.e., the INTEGER has neither a defined set of named-number
an assignment of lower- and upper-bounds on its value), the object enumerations nor an assignment of lower- and upper-bounds on its
MUST have the value of its SYNTAX clause changed to Integer32, or value), the object MUST have the value of its SYNTAX clause
have an appropriate range specified. changed to Integer32, or have an appropriate range specified.
(4) For any object with a SYNTAX clause value of Counter, the object (4) For any object with a SYNTAX clause value of Counter, the object
MUST have the value of its SYNTAX clause changed to Counter32. MUST have the value of its SYNTAX clause changed to Counter32.
(5) For any object with a SYNTAX clause value of Gauge, the object MUST (5) For any object with a SYNTAX clause value of Gauge, the object
have the value of its SYNTAX clause changed to Gauge32, or MUST have the value of its SYNTAX clause changed to Gauge32, or
Unsigned32 where appropriate. Unsigned32 where appropriate.
(6) For all objects, the ACCESS clause MUST be replaced by a MAX-ACCESS (6) For all objects, the ACCESS clause MUST be replaced by a MAX-
clause. The value of the MAX-ACCESS clause SHALL be the same as ACCESS clause. The value of the MAX-ACCESS clause SHALL be the
that of the ACCESS clause unless some other value makes "protocol same as that of the ACCESS clause unless some other value makes
sense" as the maximal level of access for the object. In "protocol sense" as the maximal level of access for the object.
particular, object types for which instances can be explicitly In particular, object types for which instances can be
created by a protocol set operation, SHALL have a MAX-ACCESS clause explicitly created by a protocol set operation, SHALL have a
of "read-create". If the value of the ACCESS clause is "write- MAX-ACCESS clause of "read-create". If the value of the ACCESS
only", then the value of the MAX-ACCESS clause MUST be "read- clause is "write-only", then the value of the MAX-ACCESS clause
write", and the DESCRIPTION clause SHALL note that reading this MUST be "read-write", and the DESCRIPTION clause SHALL note that
object will result in implementation-specific results. Note that reading this object will result in implementation-specific
in SMIv1, the ACCESS clause specifies the minimal required access, results. Note that in SMIv1, the ACCESS clause specifies the
while in SMIv2, the MAX-ACCESS clause specifies the maximum allowed minimal required access, while in SMIv2, the MAX-ACCESS clause
access. This should be considered when converting an ACCESS clause specifies the maximum allowed access. This should be considered
to a MAX-ACCESS clause. when converting an ACCESS clause to a MAX-ACCESS clause.
(7) For all objects, if the value of the STATUS clause is "mandatory" (7) For all objects, if the value of the STATUS clause is
or "optional", the value MUST be replaced with "current", "mandatory" or "optional", the value MUST be replaced with
"deprecated", or "obsolete" depending on the current usage of such "current", "deprecated", or "obsolete" depending on the current
objects. usage of such objects.
(8) For any object not containing a DESCRIPTION clause, the object MUST (8) For any object not containing a DESCRIPTION clause, the object
have a DESCRIPTION clause defined. MUST have a DESCRIPTION clause defined.
(9) For any object corresponding to a conceptual row which does not (9) For any object corresponding to a conceptual row which does not
have an INDEX clause, the object MUST have either an INDEX clause have an INDEX clause, the object MUST have either an INDEX
or an AUGMENTS clause defined. clause or an AUGMENTS clause defined.
(10) If any INDEX clause contains a reference to an object with a syntax (10) If any INDEX clause contains a reference to an object with a
of NetworkAddress, then a new object MUST be created and placed in syntax of NetworkAddress, then a new object MUST be created and
this INDEX clause immediately preceding the object whose syntax is placed in this INDEX clause immediately preceding the object
NetworkAddress. This new object MUST have a syntax of INTEGER, it whose syntax is NetworkAddress. This new object MUST have a
MUST be not-accessible, and its value MUST always be 1. This syntax of INTEGER, it MUST be not-accessible, and its value MUST
approach allows one to convert a MIB module in SMIv1 format to one always be 1. This approach allows one to convert a MIB module
in SMIv2 format, and then use it wih the SNMPv1 protocol with no in SMIv1 format to one in SMIv2 format, and then use it with the
impact to existing SNMPv1 agents and managers. SNMPv1 protocol with no impact to existing SNMPv1 agents and
managers.
(11) For any object with a SYNTAX of NetworkAddress, the SYNTAX MUST be (11) For any object with a SYNTAX of NetworkAddress, the SYNTAX MUST
changed to IpAddress. Note that the use of NetworkAddress in new be changed to IpAddress. Note that the use of NetworkAddress in
MIB documents is strongly discouraged (in fact, new MIB documents new MIB documents is strongly discouraged (in fact, new MIB
should be written using SMIv2, which does not define documents should be written using SMIv2, which does not define
NetworkAddress). NetworkAddress).
(12) For any object containing a DEFVAL clause with an OBJECT IDENTIFIER (12) For any object containing a DEFVAL clause with an OBJECT
value which is expressed as a collection of sub-identifiers, the IDENTIFIER value which is expressed as a collection of sub-
value MUST be changed to reference a single ASN.1 identifier. This identifiers, the value MUST be changed to reference a single
may require defining a series of new administrative assignments ASN.1 identifier. This may require defining a series of new
(OBJECT IDENTIFIERS) in order to define the single ASN.1 administrative assignments (OBJECT IDENTIFIERS) in order to
identifier. define the single ASN.1 identifier.
(13) One or more OBJECT-GROUPS MUST be defined, and related objects (13) One or more OBJECT-GROUPS MUST be defined, and related objects
SHOULD be collected into appropriate groups. Note that SMIv2 SHOULD be collected into appropriate groups. Note that SMIv2
requires all OBJECT-TYPEs to be a member of at least one OBJECT- requires all OBJECT-TYPEs to be a member of at least one
GROUP. OBJECT-GROUP.
Other changes are desirable, but not necessary: Other changes are desirable, but not necessary:
(1) Creation and deletion of conceptual rows is inconsistent using the (1) Creation and deletion of conceptual rows is inconsistent using
SMIv1. The SMIv2 corrects this. As such, if the MIB module the SMIv1. The SMIv2 corrects this. As such, if the MIB module
undergoes review early in its lifetime, and it contains conceptual undergoes review early in its lifetime, and it contains
tables which allow creation and deletion of conceptual rows, then conceptual tables which allow creation and deletion of
the objects relating to those tables MAY be deprecated and replaced conceptual rows, then the objects relating to those tables MAY
with objects defined using the new approach. The approach based on be deprecated and replaced with objects defined using the new
SMIv2 can be found in section 7 of RFC2578 [7], and the RowStatus approach. The approach based on SMIv2 can be found in section 7
and StorageType TEXTUAL-CONVENTIONs are described in section 2 of of RFC2578 [7], and the RowStatus and StorageType TEXTUAL-
RFC2579 [8]. CONVENTIONs are described in section 2 of RFC2579 [8].
(2) For any object with a string-valued SYNTAX clause, in which the (2) For any object with a string-valued SYNTAX clause, in which the
corresponding OCTET STRING does not have a size restriction (i.e., corresponding OCTET STRING does not have a size restriction
the OCTET STRING has no assignment of lower- and upper-bounds on (i.e., the OCTET STRING has no assignment of lower- and upper-
its length), the bounds for the size of the object SHOULD be bounds on its length), the bounds for the size of the object
defined. SHOULD be defined.
(3) All textual conventions informally defined in the MIB module SHOULD (3) All textual conventions informally defined in the MIB module
be redefined using the TEXTUAL-CONVENTION macro. Such a change SHOULD be redefined using the TEXTUAL-CONVENTION macro. Such a
would not necessitate deprecating objects previously defined using change would not necessitate deprecating objects previously
an informal textual convention. defined using an informal textual convention.
(4) For any object which represents a measurement in some kind of (4) For any object which represents a measurement in some kind of
units, a UNITS clause SHOULD be added to the definition of that units, a UNITS clause SHOULD be added to the definition of that
object. object.
(5) For any conceptual row which is an extension of another conceptual (5) For any conceptual row which is an extension of another
row, i.e., for which subordinate columnar objects both exist and conceptual row, i.e., for which subordinate columnar objects
are identified via the same semantics as the other conceptual row, both exist and are identified via the same semantics as the
an AUGMENTS clause SHOULD be used in place of the INDEX clause for other conceptual row, an AUGMENTS clause SHOULD be used in place
the object corresponding to the conceptual row which is an of the INDEX clause for the object corresponding to the
extension. conceptual row which is an extension.
Finally, to avoid common errors in SMIv1 MIB modules: Finally, to avoid common errors in SMIv1 MIB modules:
(1) For any non-columnar object that is instanced as if it were (1) For any non-columnar object that is instanced as if it were
immediately subordinate to a conceptual row, the value of the immediately subordinate to a conceptual row, the value of the
STATUS clause of that object MUST be changed to "obsolete". STATUS clause of that object MUST be changed to "obsolete".
(2) For any conceptual row object that is not contained immediately (2) For any conceptual row object that is not contained immediately
subordinate to a conceptual table, the value of the STATUS clause subordinate to a conceptual table, the value of the STATUS
of that object (and all subordinate objects) MUST be changed to clause of that object (and all subordinate objects) MUST be
"obsolete". changed to "obsolete".
2.1.2. Trap and Notification Definitions 2.1.2. Trap and Notification Definitions
If a MIB module is changed to conform to the SMIv2, then each 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 occurrence of the TRAP-TYPE macro MUST be changed to a corresponding
invocation of the NOTIFICATION-TYPE macro: invocation of the NOTIFICATION-TYPE macro:
(1) The IMPORTS statement MUST NOT reference RFC-1215 [4], and MUST (1) The IMPORTS statement MUST NOT reference RFC-1215 [4], and MUST
reference SNMPv2-SMI instead. reference SNMPv2-SMI instead.
(2) The ENTERPRISE clause MUST be removed. (2) The ENTERPRISE clause MUST be removed.
(3) The VARIABLES clause MUST be renamed to the OBJECTS clause. (3) The VARIABLES clause MUST be renamed to the OBJECTS clause.
(4) A STATUS clause MUST be added, with an appropriate value. Normally (4) A STATUS clause MUST be added, with an appropriate value.
the value should be 'current,' although 'deprecated' or 'obsolete' Normally the value should be 'current,' although 'deprecated' or
may be used as needed. 'obsolete' may be used as needed.
(5) The value of an invocation of the NOTIFICATION-TYPE macro is an (5) The value of an invocation of the NOTIFICATION-TYPE macro is an
OBJECT IDENTIFIER, not an INTEGER, and MUST be changed accordingly. OBJECT IDENTIFIER, not an INTEGER, and MUST be changed
Specifically, if the value of the ENTERPRISE clause is not 'snmp' accordingly. Specifically, if the value of the ENTERPRISE
then the value of the invocation SHALL be the value of the clause is not 'snmp' then the value of the invocation SHALL be
ENTERPRISE clause extended with two sub-identifiers, the first of the value of the ENTERPRISE clause extended with two sub-
which has the value 0, and the second has the value of the identifiers, the first of which has the value 0, and the second
invocation of the TRAP-TYPE. If the value of the ENTERPRISE clause has the value of the invocation of the TRAP-TYPE. If the value
is 'snmp', then the value of the invocation of the NOTIFICATION- of the ENTERPRISE clause is 'snmp', then the value of the
TYPE macro SHALL be mapped in the same manner as described in invocation of the NOTIFICATION-TYPE macro SHALL be mapped in the
section 3.1 in this document. same manner as described in section 3.1 in this document.
(6) A DESCRIPTION clause MUST be added, if not already present. (6) A DESCRIPTION clause MUST be added, if not already present.
(7) One or more NOTIFICATION-GROUPs MUST be defined, and related (7) One or more NOTIFICATION-GROUPs MUST be defined, and related
notifications MUST be collected into those groups. Note that SMIv2 notifications MUST be collected into those groups. Note that
requires that all NOTIFICATION-TYPEs be a member of at least one SMIv2 requires that all NOTIFICATION-TYPEs be a member of at
NOTIFICATION-GROUP. least one NOTIFICATION-GROUP.
2.2. Compliance Statements 2.2. Compliance Statements
For those information modules which are "standards track", a For those information modules which are "standards track", a
corresponding invocation of the MODULE-COMPLIANCE macro and related corresponding invocation of the MODULE-COMPLIANCE macro and related
OBJECT-GROUP and/or NOTIFICATION-GROUP macros MUST be included within OBJECT-GROUP and/or NOTIFICATION-GROUP macros MUST be included within
the information module (or in a companion information module), and the information module (or in a companion information module), and
any commentary text in the information module which relates to any commentary text in the information module which relates to
compliance SHOULD be removed. Typically this editing can occur when compliance SHOULD be removed. Typically this editing can occur when
the information module undergoes review. the information module undergoes review.
skipping to change at page 12, line 26 skipping to change at page 10, line 16
document that is not on the standards track (for example, an document that is not on the standards track (for example, an
enterprise MIB), though it may be useful in some circumstances to enterprise MIB), though it may be useful in some circumstances to
define a MODULE-COMPLIANCE statement for such a MIB document. define a MODULE-COMPLIANCE statement for such a MIB document.
2.3. Capabilities Statements 2.3. Capabilities Statements
RFC1303 [5] uses the MODULE-CONFORMANCE macro to describe an agent's RFC1303 [5] uses the MODULE-CONFORMANCE macro to describe an agent's
capabilities with respect to one or more MIB modules. Converting capabilities with respect to one or more MIB modules. Converting
such a description for use with the SMIv2 requires these changes: such a description for use with the SMIv2 requires these changes:
(1) The macro name AGENT-CAPABILITIES SHOULD be used instead of MODULE- (1) The macro name AGENT-CAPABILITIES SHOULD be used instead of
CONFORMANCE. MODULE-CONFORMANCE.
(2) The STATUS clause SHOULD be added, with a value of 'current'. (2) The STATUS clause SHOULD be added, with a value of 'current'.
(3) All occurrences of the CREATION-REQUIRES clause MUST either be (3) All occurrences of the CREATION-REQUIRES clause MUST either be
omitted if appropriate, or be changed such that the semantics are omitted if appropriate, or be changed such that the semantics
consistent with RFC2580 [9]. are consistent with RFC2580 [9].
In order to ease coexistence, object groups defined in an SMIv1 In order to ease coexistence, object groups defined in an SMIv1
compliant MIB module may be referenced by the INCLUDES clause of an compliant MIB module may be referenced by the INCLUDES clause of an
invocation of the AGENT-CAPABILITIES macro: upon encountering a invocation of the AGENT-CAPABILITIES macro: upon encountering a
reference to an OBJECT IDENTIFIER subtree defined in an SMIv1 MIB reference to an OBJECT IDENTIFIER subtree defined in an SMIv1 MIB
module, all leaf objects which are subordinate to the subtree and module, all leaf objects which are subordinate to the subtree and
have a STATUS clause value of mandatory are deemed to be INCLUDEd. have a STATUS clause value of mandatory are deemed to be INCLUDED.
(Note that this method is ambiguous when different revisions of an (Note that this method is ambiguous when different revisions of an
SMIv1 MIB have different sets of mandatory objects under the same SMIv1 MIB have different sets of mandatory objects under the same
subtree; in such cases, the only solution is to rewrite the MIB using subtree; in such cases, the only solution is to rewrite the MIB using
the SMIv2 in order to define the object groups unambiguously.) the SMIv2 in order to define the object groups unambiguously.)
3. Translating Notifications Parameters 3. Translating Notifications Parameters
This section describes how parameters used for generating This section describes how parameters used for generating
notifications are translated between the format used for SNMPv1 notifications are translated between the format used for SNMPv1
notification protocol operations and the format used for SNMPv2 notification protocol operations and the format used for SNMPv2
notification protocol operations. The parameters used to generate a notification protocol operations. The parameters used to generate a
notification are called 'notification parameters.' The format of notification are called 'notification parameters'. The format of
parameters used for SNMPv1 notification protocol operations is parameters used for SNMPv1 notification protocol operations is
refered to in this document as 'SNMPv1 notification parameters.' The refered to in this document as 'SNMPv1 notification parameters'. The
format of parameters used for SNMPv2 notification protocol operations format of parameters used for SNMPv2 notification protocol operations
is refered to in this document as 'SNMPv2 notification parameters.' is refered to in this document as 'SNMPv2 notification parameters'.
The situations where notification parameters MUST be translated are: The situations where notification parameters MUST be translated are:
- When an entity generates a set of notification parameters in a - When an entity generates a set of notification parameters in a
particular format, and the configuration of the entity particular format, and the configuration of the entity
indicates that the notification must be sent using an SNMP indicates that the notification must be sent using an SNMP
message version that requires the other format for message version that requires the other format for notification
notification parameters. parameters.
- When a proxy receives a notification that was sent using an - When a proxy receives a notification that was sent using an
SNMP message version that requires one format of notification SNMP message version that requires one format of notification
parameters, and must forward the notification using an SNMP parameters, and must forward the notification using an SNMP
message version that requires the other format of notification message version that requires the other format of notification
parameters. parameters.
In addition, it MAY be desirable to translate notification parameters In addition, it MAY be desirable to translate notification parameters
in a notification receiver application in order to present in a notification receiver application in order to present
notifications to the end user in a consistent format. notifications to the end user in a consistent format.
Note that for the purposes of this section, the set of notification Note that for the purposes of this section, the set of notification
parameters is independent of whether the notification is to be sent parameters is independent of whether the notification is to be sent
as a trap or an inform. as a trap or an inform.
SNMPv1 notification parameters consist of: SNMPv1 notification parameters consist of:
- An enterprise parameter (OBJECT IDENTIFIER). - An enterprise parameter (OBJECT IDENTIFIER).
- An agent-addr parameter (NetworkAddress). - An agent-addr parameter (NetworkAddress).
- A generic-trap parameter (INTEGER). - A generic-trap parameter (INTEGER).
- A specific-trap parameter (INTEGER). - A specific-trap parameter (INTEGER).
- A time-stamp parameter (TimeTicks). - A time-stamp parameter (TimeTicks).
- A list of variable-bindings (VarBindList). - A list of variable-bindings (VarBindList).
SNMPv2 notification parameters consist of: SNMPv2 notification parameters consist of:
- A sysUpTime parameter (TimeTicks). This appears in the first - A sysUpTime parameter (TimeTicks). This appears in the first
variable-binding in an SNMPv2-Trap-PDU or InformRequest-PDU. variable-binding in an SNMPv2-Trap-PDU or InformRequest-PDU.
- An snmpTrapOID parameter (OBJECT IDENTIFIER). This appears in - An snmpTrapOID parameter (OBJECT IDENTIFIER). This appears in
the second variable-binding in an SNMPv2-Trap-PDU or the second variable-binding in an SNMPv2-Trap-PDU or
InformRequest-PDU. InformRequest-PDU.
- A list of variable-bindings (VarBindList). This refers to all - A list of variable-bindings (VarBindList). This refers to all
but the first two variable-bindings in an SNMPv2-Trap-PDU or but the first two variable-bindings in an SNMPv2-Trap-PDU or
InformRequest-PDU. InformRequest-PDU.
3.1. Translating SNMPv1 Notification Parameters to SNMPv2 Notification 3.1. Translating SNMPv1 Notification Parameters to SNMPv2 Notification
Parameters Parameters
The following procedure describes how to translate SNMPv1 The following procedure describes how to translate SNMPv1
notification parameters into SNMPv2 notification parameters: notification parameters into SNMPv2 notification parameters:
(1) The SNMPv2 sysUpTime parameter SHALL be taken directly from the (1) The SNMPv2 sysUpTime parameter SHALL be taken directly from the
SNMPv1 time-stamp parameter. SNMPv1 time-stamp parameter.
(2) If the SNMPv1 generic-trap parameter is 'enterpriseSpecific(6)', (2) If the SNMPv1 generic-trap parameter is 'enterpriseSpecific(6)',
the SNMPv2 snmpTrapOID parameter SHALL be the concatentation of the the SNMPv2 snmpTrapOID parameter SHALL be the concatentation of
SNMPv1 enterprise parameter and two additional sub-identifiers, the SNMPv1 enterprise parameter and two additional sub-
'0', and the SNMPv1 specific-trap parameter. identifiers, '0', and the SNMPv1 specific-trap parameter.
(3) If the SNMPv1 generic-trap parameter is not (3) If the SNMPv1 generic-trap parameter is not '
'enterpriseSpecific(6)', the SNMPv2 snmpTrapOID parameter SHALL be enterpriseSpecific(6)', the SNMPv2 snmpTrapOID parameter SHALL
the corresponding trap as defined in section 2 of RFC1907 [12]: be the corresponding trap as defined in section 2 of RFC1907
[12]:
generic-trap parameter snmpTrapOID.0 generic-trap parameter snmpTrapOID.0
====================== ============= ====================== =============
0 1.3.6.1.6.3.1.1.5.1 (coldStart) 0 1.3.6.1.6.3.1.1.5.1 (coldStart)
1 1.3.6.1.6.3.1.1.5.2 (warmStart) 1 1.3.6.1.6.3.1.1.5.2 (warmStart)
2 1.3.6.1.6.3.1.1.5.3 (linkDown) 2 1.3.6.1.6.3.1.1.5.3 (linkDown)
3 1.3.6.1.6.3.1.1.5.4 (linkUp) 3 1.3.6.1.6.3.1.1.5.4 (linkUp)
4 1.3.6.1.6.3.1.1.5.5 (authenticationFailure) 4 1.3.6.1.6.3.1.1.5.5 (authenticationFailure)
5 1.3.6.1.6.3.1.1.5.6 (egpNeighborLoss) 5 1.3.6.1.6.3.1.1.5.6 (egpNeighborLoss)
(4) The SNMPv2 variable-bindings SHALL be the SNMPv1 variable-bindings. (4) The SNMPv2 variable-bindings SHALL be the SNMPv1 variable-
In addition, if the translation is being performed by a proxy in bindings. In addition, if the translation is being performed by
order to forward a received trap, three additional variable- a proxy in order to forward a received trap, three additional
bindings will be appended, if these three additional variable- variable-bindings will be appended, if these three additional
bindings do not already exist in the SNMPv1 variable-bindings. The variable-bindings do not already exist in the SNMPv1 variable-
name portion of the first additional variable binding SHALL contain bindings. The name portion of the first additional variable
snmpTrapAddress.0, and the value SHALL contain the SNMPv1 agent- binding SHALL contain snmpTrapAddress.0, and the value SHALL
addr parameter. The name portion of the second additional variable contain the SNMPv1 agent-addr parameter. The name portion of
binding SHALL contain snmpTrapCommunity.0, and the value SHALL the second additional variable binding SHALL contain
contain the value of the community-string field from the received snmpTrapCommunity.0, and the value SHALL contain the value of
SNMPv1 message which contained the SNMPv1 Trap-PDU. The name the community-string field from the received SNMPv1 message
portion of the third additional variable binding SHALL contain which contained the SNMPv1 Trap-PDU. The name portion of the
snmpTrapEnterprise.0 [12], and the value SHALL be the SNMPv1 third additional variable binding SHALL contain
enterprise parameter. snmpTrapEnterprise.0 [12], and the value SHALL be the SNMPv1
enterprise parameter.
3.2. Translating SNMPv2 Notification Parameters to SNMPv1 Notification 3.2. Translating SNMPv2 Notification Parameters to SNMPv1 Notification
Parameters Parameters
The following procedure describes how to translate SNMPv2 The following procedure describes how to translate SNMPv2
notification parameters into SNMPv1 notification parameters: notification parameters into SNMPv1 notification parameters:
(1) The SNMPv1 enterprise parameter SHALL be determined as follows: (1) The SNMPv1 enterprise parameter SHALL be determined as follows:
- If the SNMPv2 snmpTrapOID parameter is one of the standard - If the SNMPv2 snmpTrapOID parameter is one of the standard
traps as defined in RFC1907 [12], then the SNMPv1 enterprise traps as defined in RFC1907 [12], then the SNMPv1 enterprise
parameter SHALL be set to the value of the variable-binding in parameter SHALL be set to the value of the variable-binding in
the SNMPv2 variable-bindings whose name is the SNMPv2 variable-bindings whose name is snmpTrapEnterprise.0
snmpTrapEnterprise.0 if that variable-binding exists. If it if that variable-binding exists. If it does not exist, the
does not exist, the SNMPv1 enterprise parameter SHALL be set SNMPv1 enterprise parameter SHALL be set to the value '
to the value 'snmpTraps' as defined in RFC1907 [12]. snmpTraps' as defined in RFC1907 [12].
- If the SNMPv2 snmpTrapOID parameter is not one of the standard - If the SNMPv2 snmpTrapOID parameter is not one of the standard
traps as defined in RFC1907 [12], then the SNMPv1 enterprise traps as defined in RFC1907 [12], then the SNMPv1 enterprise
parameter SHALL be determined from the SNMPv2 snmpTrapOID parameter SHALL be determined from the SNMPv2 snmpTrapOID
parameter as follows: parameter as follows:
- If the next-to-last sub-identifier of the snmpTrapOID is - If the next-to-last sub-identifier of the snmpTrapOID is
zero, then the SNMPv1 enterprise SHALL be the SNMPv2 zero, then the SNMPv1 enterprise SHALL be the SNMPv2
snmpTrapOID with the last 2 sub-identifiers removed, snmpTrapOID with the last 2 sub-identifiers removed,
otherwise otherwise
- If the next-to-last sub-identifier of the snmpTrapOID is - If the next-to-last sub-identifier of the snmpTrapOID is
non-zero, then the SNMPv1 enterprise SHALL be the SNMPv2 non-zero, then the SNMPv1 enterprise SHALL be the SNMPv2
snmpTrapOID with the last sub-identifier removed. snmpTrapOID with the last sub-identifier removed.
(2) The SNMPv1 agent-addr parameter SHALL be determined based on the (2) The SNMPv1 agent-addr parameter SHALL be determined based on the
situation in which the translation occurs. situation in which the translation occurs.
- If the translation occurs within a notification originator - If the translation occurs within a notification originator
application, and the notification is to be sent over IP, the application, and the notification is to be sent over IP, the
SNMPv1 agent-addr parameter SHALL be set to the IP address of SNMPv1 agent-addr parameter SHALL be set to the IP address of
the SNMP entity in which the notification originator resides. the SNMP entity in which the notification originator resides.
If the notification is to be sent over some other transport, If the notification is to be sent over some other transport,
the SNMPv1 agent-addr parameter SHALL be set to 0.0.0.0. the SNMPv1 agent-addr parameter SHALL be set to 0.0.0.0.
- If the translation occurs within a proxy application, the - If the translation occurs within a proxy application, the proxy
proxy must attempt to extract the original source of the must attempt to extract the original source of the notification
notification from the variable-bindings. If the SNMPv2 from the variable-bindings. If the SNMPv2 variable-bindings
variable-bindings contains a variable binding whose name is contains a variable binding whose name is snmpTrapAddress.0,
snmpTrapAddress.0, the agent-addr parameter SHALL be set to the agent-addr parameter SHALL be set to the value of that
the value of that variable binding. Otherwise, the SNMPv1 variable binding. Otherwise, the SNMPv1 agent-addr parameter
agent-addr parameter SHALL be set to 0.0.0.0. SHALL be set to 0.0.0.0.
(3) If the SNMPv2 snmpTrapOID parameter is one of the standard traps as (3) If the SNMPv2 snmpTrapOID parameter is one of the standard traps
defined in RFC1907 [12], the SNMPv1 generic-trap parameter SHALL be as defined in RFC1907 [12], the SNMPv1 generic-trap parameter
set as follows: SHALL be set as follows:
snmpTrapOID.0 parameter generic-trap 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.1 (coldStart) 0
1.3.6.1.6.3.1.1.5.2 (warmStart) 1 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.3 (linkDown) 2
1.3.6.1.6.3.1.1.5.4 (linkUp) 3 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.5 (authenticationFailure) 4
1.3.6.1.6.3.1.1.5.6 (egpNeighborLoss) 5 1.3.6.1.6.3.1.1.5.6 (egpNeighborLoss) 5
Otherwise, the SNMPv1 generic-trap parameter SHALL be set to 6. Otherwise, the SNMPv1 generic-trap parameter SHALL be set to 6.
(4) If the SNMPv2 snmpTrapOID parameter is one of the standard traps as (4) If the SNMPv2 snmpTrapOID parameter is one of the standard traps
defined in RFC1907 [12], the SNMPv1 specific-trap parameter SHALL as defined in RFC1907 [12], the SNMPv1 specific-trap parameter
be set to zero. Otherwise, the SNMPv1 specific-trap parameter SHALL be set to zero. Otherwise, the SNMPv1 specific-trap
SHALL be set to the last sub-identifier of the SNMPv2 snmpTrapOID parameter SHALL be set to the last sub-identifier of the SNMPv2
parameter. snmpTrapOID parameter.
(5) The SNMPv1 time-stamp parameter SHALL be taken directly from the (5) The SNMPv1 time-stamp parameter SHALL be taken directly from the
SNMPv2 sysUpTime parameter. SNMPv2 sysUpTime parameter.
(6) The SNMPv1 variable-bindings SHALL be the SNMPv2 variable-bindings. (6) The SNMPv1 variable-bindings SHALL be the SNMPv2 variable-
Note, however, that if the SNMPv2 variable-bindings contain any bindings. Note, however, that if the SNMPv2 variable-bindings
objects whose type is Counter64, the translation to SNMPv1 contain any objects whose type is Counter64, the translation to
notification parameters cannot be performed. In this case, the SNMPv1 notification parameters cannot be performed. In this
notification cannot be encoded in an SNMPv1 packet (and so the case, the notification cannot be encoded in an SNMPv1 packet
notification cannot be sent using SNMPv1, see section 4.1.3 and (and so the notification cannot be sent using SNMPv1, see
section 4.2). section 4.1.3 and section 4.2).
4. Approaches to Coexistence in a Multi-lingual Network 4. Approaches to Coexistence in a Multi-lingual Network
There are two basic approaches to coexistence in a multi-lingual There are two basic approaches to coexistence in a multi-lingual
network, multi-lingual implementations and proxy implementations. network, multi-lingual implementations and proxy implementations.
Multi-lingual implementations allow elements in a network to Multi-lingual implementations allow elements in a network to
communicate with each other using an SNMP version which both elements communicate with each other using an SNMP version which both elements
support. This allows a multi-lingual implementation to communicate support. This allows a multi-lingual implementation to communicate
with any mono-lingual implementation, regardless of the SNMP version with any mono-lingual implementation, regardless of the SNMP version
supported by the mono-lingual implementation. supported by the mono-lingual implementation.
skipping to change at page 19, line 11 skipping to change at page 15, line 33
outgoing request. This is done by simply changing the operation type outgoing request. This is done by simply changing the operation type
to GetNext, ignoring any non-repeaters and max-repetitions values, to GetNext, ignoring any non-repeaters and max-repetitions values,
and setting error-status and error-index to zero. and setting error-status and error-index to zero.
4.1.2. Command Responder 4.1.2. Command Responder
A command responder must be able to deal with both SNMPv1 and SNMPv2 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 access to MIB data. There are three aspects to dealing with this. A
command responder must: command responder must:
- Deal correctly with SNMPv2 access to MIB data that returns a - Deal correctly with SNMPv2 access to MIB data that returns a
Counter64 value while processing an SNMPv1 message, Counter64 value while processing an SNMPv1 message,
- Deal correctly with SNMPv2 access to MIB data that returns one - Deal correctly with SNMPv2 access to MIB data that returns one
of the three exception values while processing an SNMPv1 of the three exception values while processing an SNMPv1
message, and message, and
- Map SNMPv2 error codes returned from SNMPv2 access to MIB data - Map SNMPv2 error codes returned from SNMPv2 access to MIB data
into SNMPv1 error codes when processing an SNMPv1 message. into SNMPv1 error codes when processing an SNMPv1 message.
Note that SNMPv1 error codes SHOULD NOT be used without any change Note that SNMPv1 error codes SHOULD NOT be used without any change
when processing SNMPv2c or SNMPv3 messages, except in the case of when processing SNMPv2c or SNMPv3 messages, except in the case of
proxy forwarding. In the case of proxy forwarding, for backwards proxy forwarding. In the case of proxy forwarding, for backwards
compatibility, SNMPv1 error codes may be used without any change in a compatibility, SNMPv1 error codes may be used without any change in a
forwarded SNMPv2c or SNMPv3 message. forwarded SNMPv2c or SNMPv3 message.
The following sections describe the behaviour of a command responder The following sections describe the behaviour of a command responder
application which supports multiple SNMP message versions, and which application which supports multiple SNMP message versions, and which
uses some combination of SNMPv1 and SNMPv2 access to MIB data. uses some combination of SNMPv1 and SNMPv2 access to MIB data.
skipping to change at page 19, line 46 skipping to change at page 16, line 20
The impact on multi-lingual command responders is that they MUST NOT The impact on multi-lingual command responders is that they MUST NOT
ever return a variable binding containing a Counter64 value in a ever return a variable binding containing a Counter64 value in a
response to a request that was received using the SNMPv1 message response to a request that was received using the SNMPv1 message
version. version.
Multi-lingual command responders SHALL take the approach that object Multi-lingual command responders SHALL take the approach that object
instances whose type is Counter64 are implicitly excluded from view instances whose type is Counter64 are implicitly excluded from view
when processing an SNMPv1 message. So: when processing an SNMPv1 message. So:
- On receipt of an SNMPv1 GetRequest-PDU containing a variable - On receipt of an SNMPv1 GetRequest-PDU containing a variable
binding whose name field points to an object instance of type binding whose name field points to an object instance of type
Counter64, a GetResponsePDU SHALL be returned, with an error- Counter64, a GetResponsePDU SHALL be returned, with an error-
status of noSuchName and the error-index set to the variable status of noSuchName and the error-index set to the variable
binding that caused this error. binding that caused this error.
- On an SNMPv1 GetNextRequest-PDU, any object instance which - On an SNMPv1 GetNextRequest-PDU, any object instance which
contains a syntax of Counter64 SHALL be skipped, and the next contains a syntax of Counter64 SHALL be skipped, and the next
accessible object instance that does not have the syntax of accessible object instance that does not have the syntax of
Counter64 SHALL be retrieved. If no such object instance Counter64 SHALL be retrieved. If no such object instance
exists, then an error-status of noSuchName SHALL be returned, exists, then an error-status of noSuchName SHALL be returned,
and the error-index SHALL be set to the variable binding that and the error-index SHALL be set to the variable binding that
caused this error. caused this error.
- Any SNMPv1 request which contains a variable binding with a - Any SNMPv1 request which contains a variable binding with a
Counter64 value is ill-formed, so the foregoing rules do not Counter64 value is ill-formed, so the foregoing rules do not
apply. If that error is detected, a response SHALL NOT be apply. If that error is detected, a response SHALL NOT be
returned, since it would contain a copy of the ill-formed returned, since it would contain a copy of the ill-formed
variable binding. Instead, the offending PDU SHALL be variable binding. Instead, the offending PDU SHALL be
discarded and the counter snmpInASNParseErrs SHALL be discarded and the counter snmpInASNParseErrs SHALL be
incremented. incremented.
4.1.2.2. Mapping SNMPv2 Exceptions 4.1.2.2. Mapping SNMPv2 Exceptions
SNMPv2 provides a feature called exceptions, which allow an SNMPv2 SNMPv2 provides a feature called exceptions, which allow an SNMPv2
Response PDU to return as much management information as possible, Response PDU to return as much management information as possible,
even when an error occurs. However, SNMPv1 does not support even when an error occurs. However, SNMPv1 does not support
exceptions, and so an SNMPv1 Response PDU cannot return any exceptions, and so an SNMPv1 Response PDU cannot return any
management information, and can only return an error-status and management information, and can only return an error-status and
error-index value. error-index value.
When an SNMPv1 request is received, a command responder MUST check When an SNMPv1 request is received, a command responder MUST check
any variable bindings returned using SNMPv2 access to MIB data for any variable bindings returned using SNMPv2 access to MIB data for
exception values, and convert these exception values into SNMPv1 exception values, and convert these exception values into SNMPv1
error codes. error codes.
The type of exception that can be returned when accessing MIB data The type of exception that can be returned when accessing MIB data
and the action taken depends on the type of SNMP request. and the action taken depends on the type of SNMP request.
- For a GetRequest, a noSuchObject or noSuchInstance exception - For a GetRequest, a noSuchObject or noSuchInstance exception
may be returned. may be returned.
- For a GetNextRequest, an endOfMibView exception may be - For a GetNextRequest, an endOfMibView exception may be
returned. returned.
- No exceptions will be returned for a SetRequest, and a - No exceptions will be returned for a SetRequest, and a
GetBulkRequest should only be received in an SNMPv2c or SNMPv3 GetBulkRequest should only be received in an SNMPv2c or SNMPv3
message, so these request types may be ignored when mapping message, so these request types may be ignored when mapping
exceptions. exceptions.
Note that when a response contains multiple exceptions, it is an Note that when a response contains multiple exceptions, it is an
implementation choice as to which variable binding the error-index implementation choice as to which variable binding the error-index
should reference. should reference.
4.1.2.2.1. Mapping noSuchObject and noSuchInstance 4.1.2.2.1. Mapping noSuchObject and noSuchInstance
A noSuchObject or noSuchInstance exception generated by an SNMPv2 A noSuchObject or noSuchInstance exception generated by an SNMPv2
access to MIB data indicates that the requested object instance can access to MIB data indicates that the requested object instance can
not be returned. The SNMPv1 error code for this condition is not be returned. The SNMPv1 error code for this condition is
skipping to change at page 21, line 42 skipping to change at page 18, line 13
original request SHALL be returned with the response PDU. original request SHALL be returned with the response PDU.
4.1.2.3. Processing An SNMPv1 GetRequest 4.1.2.3. Processing An SNMPv1 GetRequest
When processing an SNMPv1 GetRequest, the following procedures MUST When processing an SNMPv1 GetRequest, the following procedures MUST
be followed when using an SNMPv2 access to MIB data. be followed when using an SNMPv2 access to MIB data.
When such an access to MIB data returns response data using SNMPv2 When such an access to MIB data returns response data using SNMPv2
syntax and error-status values, then: syntax and error-status values, then:
(1) If the error-status is anything other than noError, (1) If the error-status is anything other than noError,
- The error status SHALL be translated to an SNMPv1 error-status - The error status SHALL be translated to an SNMPv1 error-status
using the table in section 4.3, "Error Status Mappings". using the table in section 4.3, "Error Status Mappings".
- The error-index SHALL be set to the position (in the original - The error-index SHALL be set to the position (in the original
request) of the variable binding that caused the error-status. request) of the variable binding that caused the error-status.
- The variable binding list of the response PDU SHALL be made - The variable binding list of the response PDU SHALL be made
exactly the same as the variable binding list that was exactly the same as the variable binding list that was received
received in the original request. in the original request.
(2) If the error-status is noError, the variable bindings SHALL be (2) If the error-status is noError, the variable bindings SHALL be
checked for any SNMPv2 exception (noSuchObject or noSuchInstance) checked for any SNMPv2 exception (noSuchObject or
or an SNMPv2 syntax that is unknown to SNMPv1 (Counter64). If noSuchInstance) or an SNMPv2 syntax that is unknown to SNMPv1
there are any such variable bindings, one of those variable (Counter64). If there are any such variable bindings, one of
bindings SHALL be selected (it is an implementation choice as to those variable bindings SHALL be selected (it is an
which is selected), and: implementation choice as to which is selected), and:
- The error-status SHALL be set to noSuchName, - The error-status SHALL be set to noSuchName,
- The error-index SHALL be set to the position (in the variable - The error-index SHALL be set to the position (in the variable
binding list of the original request) of the selected variable binding list of the original request) of the selected variable
binding, and binding, and
- The variable binding list of the response PDU SHALL be exactly - The variable binding list of the response PDU SHALL be exactly
the same as the variable binding list that was received in the the same as the variable binding list that was received in the
original request. original request.
(3) If there are no such variable bindings, then: (3) If there are no such variable bindings, then:
- The error-status SHALL be set to noError, - The error-status SHALL be set to noError,
- The error-index SHALL be set to zero, and - The error-index SHALL be set to zero, and
- The variable binding list of the response SHALL be composed - The variable binding list of the response SHALL be composed
from the data as it is returned by the access to MIB data. from the data as it is returned by the access to MIB data.
4.1.2.4. Processing An SNMPv1 GetNextRequest 4.1.2.4. Processing An SNMPv1 GetNextRequest
When processing an SNMPv1 GetNextRequest, the following procedures When processing an SNMPv1 GetNextRequest, the following procedures
MUST be followed when an SNMPv2 access to MIB data is called as part MUST be followed when an SNMPv2 access to MIB data is called as part
of processing the request. There may be repetitive accesses to MIB of processing the request. There may be repetitive accesses to MIB
data to try to find the first object which lexicographically follows data to try to find the first object which lexicographically follows
each of the objects in the request. This is implementation specific. each of the objects in the request. This is implementation specific.
These procedures are followed only for data returned when using These procedures are followed only for data returned when using
SNMPv2 access to MIB data. Data returned using SNMPv1 access to MIB SNMPv2 access to MIB data. Data returned using SNMPv1 access to MIB
data may be treated in the normal manner for an SNMPv1 request. data may be treated in the normal manner for an SNMPv1 request.
First, if the access to MIB data returns an error-status of anything First, if the access to MIB data returns an error-status of anything
other than noError: other than noError:
(1) The error status SHALL be translated to an SNMPv1 error-status (1) The error status SHALL be translated to an SNMPv1 error-status
using the table in section 4.3, "Error Status Mappings". using the table in section 4.3, "Error Status Mappings".
(2) The error-index SHALL be set to the position (in the original (2) The error-index SHALL be set to the position (in the original
request) of the variable binding that caused the error-status. request) of the variable binding that caused the error-status.
(3) The variable binding list of the response PDU SHALL be exactly the (3) The variable binding list of the response PDU SHALL be exactly
same as the variable binding list that was received in the original the same as the variable binding list that was received in the
request. original request.
Otherwise, if the access to MIB data returns an error-status of Otherwise, if the access to MIB data returns an error-status of
noError: noError:
(1) Any variable bindings containing an SNMPv2 syntax of Counter64 (1) Any variable bindings containing an SNMPv2 syntax of Counter64
SHALL be considered to be not in view, and MIB data SHALL be 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 accessed as many times as is required until either a value other
than Counter64 is returned, or an error occurs. than Counter64 is returned, or an error occurs.
(2) If there is any variable binding that contains an SNMPv2 exception (2) If there is any variable binding that contains an SNMPv2
endOfMibView (there may be more than one, it is an implementation exception endOfMibView (there may be more than one, it is an
decision as to which is chosen): implementation decision as to which is chosen):
- The error-status SHALL be set to noSuchName, - The error-status SHALL be set to noSuchName,
- The error-index SHALL be set to the position (in the variable - The error-index SHALL be set to the position (in the variable
binding list of the original request) of the variable binding binding list of the original request) of the variable binding
that returned such an SNMPv2 exception, and that returned such an SNMPv2 exception, and
- The variable binding list of the response PDU SHALL be exactly - The variable binding list of the response PDU SHALL be exactly
the same as the variable binding list that was received in the the same as the variable binding list that was received in the
original request. original request.
(3) If there are no such variable bindings, then: (3) If there are no such variable bindings, then:
- The error-status SHALL be set to noError, - The error-status SHALL be set to noError,
- The error-index SHALL be set to zero, and - The error-index SHALL be set to zero, and
- The variable binding list of the response SHALL be composed - The variable binding list of the response SHALL be composed
from the data as it is returned by the access to MIB data. from the data as it is returned by the access to MIB data.
4.1.2.5. Processing An SNMPv1 SetRequest 4.1.2.5. Processing An SNMPv1 SetRequest
When processing an SNMPv1 SetRequest, the following procedures MUST When processing an SNMPv1 SetRequest, the following procedures MUST
be followed when calling SNMPv2 MIB access routines. be followed when calling SNMPv2 MIB access routines.
When such MIB access routines return response data using SNMPv2 When such MIB access routines return response data using SNMPv2
syntax and error-status values, and the error-status is anything syntax and error-status values, and the error-status is anything
other than noError, then: other than noError, then:
- The error status SHALL be translated to an SNMPv1 error-status - The error status SHALL be translated to an SNMPv1 error-status
using the table in section 4.3, "Error Status Mappings". using the table in section 4.3, "Error Status Mappings".
- The error-index SHALL be set to the position (in the original - The error-index SHALL be set to the position (in the original
request) of the variable binding that caused the error-status. request) of the variable binding that caused the error-status.
- The variable binding list of the response PDU SHALL be made - The variable binding list of the response PDU SHALL be made
exactly the same as the variable binding list that was exactly the same as the variable binding list that was received
received in the original request. in the original request.
4.1.3. Notification Originator 4.1.3. Notification Originator
A notification originator must be able to translate between SNMPv1 A notification originator must be able to translate between SNMPv1
notifications parameters and SNMPv2 notification parameters in order notifications parameters and SNMPv2 notification parameters in order
to send a notification using a particular SNMP message version. If a to send a notification using a particular SNMP message version. If a
notification is generated using SNMPv1 notification parameters, and notification is generated using SNMPv1 notification parameters, and
configuration information specifies that notifications be sent using configuration information specifies that notifications be sent using
SNMPv2c or SNMPv3, the notification parameters must be translated to SNMPv2c or SNMPv3, the notification parameters must be translated to
SNMPv2 notification parameters. Likewise, if a notification is SNMPv2 notification parameters. Likewise, if a notification is
skipping to change at page 25, line 34 skipping to change at page 21, line 39
4.2. Proxy Implementations 4.2. Proxy Implementations
A proxy implementation may be used to enable communication between A proxy implementation may be used to enable communication between
entities which support different SNMP message versions. This is entities which support different SNMP message versions. This is
accomplished in a proxy forwarder application by performing accomplished in a proxy forwarder application by performing
translations on PDUs. These translations depend on the PDU type, the translations on PDUs. These translations depend on the PDU type, the
SNMP version of the packet containing a received PDU, and the SNMP SNMP version of the packet containing a received PDU, and the SNMP
version to be used to forward a received PDU. The following sections version to be used to forward a received PDU. The following sections
describe these translations. In all cases other than those described describe these translations. In all cases other than those described
below, the proxy SHALL forward a received PDU without change, subject below, the proxy SHALL forward a received PDU without change, subject
to size contraints as defined in section 5.3 (Community MIB) of this to size constraints as defined in section 5.3 (Community MIB) of this
document. Note that in the following sections, the 'Upstream document. Note that in the following sections, the 'Upstream
Version' refers to the version used between the command generator and Version' refers to the version used between the command generator and
the proxy, and the 'Downstream Version' refers to the version used the proxy, and the 'Downstream Version' refers to the version used
between the proxy and the command responder, regardless of the PDU between the proxy and the command responder, regardless of the PDU
type or direction. type or direction.
4.2.1. Upstream Version Greater Than Downstream Version 4.2.1. Upstream Version Greater Than Downstream Version
- If a GetBulkRequest-PDU is received and must be forwarded - If a GetBulkRequest-PDU is received and must be forwarded using
using the SNMPv1 message version, the proxy forwarder SHALL the SNMPv1 message version, the proxy forwarder SHALL set the
set the non-repeaters and max-repetitions fields to 0, and non-repeaters and max-repetitions fields to 0, and SHALL set the
SHALL set the tag of the PDU to GetNextRequest-PDU. tag of the PDU to GetNextRequest-PDU.
- If a GetResponse-PDU is received whose error-status field has - If a GetResponse-PDU is received whose error-status field has a
a value of 'tooBig', the message will be forwarded using the value of 'tooBig', the message will be forwarded using the SNMPv2c
SNMPv2c or SNMPv3 message version, and the original request or SNMPv3 message version, and the original request received by
received by the proxy was not a GetBulkRequest-PDU, the proxy the proxy was not a GetBulkRequest-PDU, the proxy forwarder SHALL
forwarder SHALL remove the contents of the variable-bindings remove the contents of the variable-bindings field before
field before forwarding the response. forwarding the response.
- If a GetResponse-PDU is received whose error-status field has - If a GetResponse-PDU is received whose error-status field has a
a value of 'tooBig,' and the message will be forwarded using value of 'tooBig,' and the message will be forwarded using the
the SNMPv2c or SNMPv3 message version, and the original SNMPv2c or SNMPv3 message version, and the original request
request received by the proxy was a GetBulkRequest-PDU, the received by the proxy was a GetBulkRequest-PDU, the proxy
proxy forwarder SHALL re-send the forwarded request (which forwarder SHALL re-send the forwarded request (which would have
would have been altered to be a GetNextRequest-PDU) with all been altered to be a GetNextRequest-PDU) with all but the first
but the first variable-binding removed. The proxy forwarder variable-binding removed. The proxy forwarder SHALL only re-send
SHALL only re-send such a request a single time. If the such a request a single time. If the resulting GetResponse-PDU
resulting GetResponse-PDU also contains an error-status field also contains an error-status field with a value of 'tooBig,' then
with a value of 'tooBig,' then the proxy forwarder SHALL the proxy forwarder SHALL remove the contents of the variable-
remove the contents of the variable-bindings field, and change bindings field, and change the error-status field to 'noError'
the error-status field to 'noError' before forwarding the before forwarding the response. Note that if the original request
response. Note that if the original request only contained a only contained a single variable-binding, the proxy may skip re-
single variable-binding, the proxy may skip re-sending the sending the request and simply remove the variable-bindings and
request and simply remove the variable-bindings and change the change the error-status to 'noError.'
error-status to 'noError.'
- If a Trap-PDU is received, and will be forwarded using the - If a Trap-PDU is received, and will be forwarded using the SNMPv2c
SNMPv2c or SNMPv3 message version, the proxy SHALL apply the or SNMPv3 message version, the proxy SHALL apply the translation
translation rules described in section 3, and SHALL forward rules described in section 3, and SHALL forward the notification
the notification as an SNMPv2-Trap-PDU. as an SNMPv2-Trap-PDU.
Note that when an SNMPv1 agent generates a message containing Note that when an SNMPv1 agent generates a message containing a
a Trap-PDU which is subsequently forwarded by one or more Trap-PDU which is subsequently forwarded by one or more proxy
proxy forwarders using SNMP versions other than SNMPv1, the forwarders using SNMP versions other than SNMPv1, the community
community string and agent-addr fields from the original string and agent-addr fields from the original message generated
message generated by the SNMPv1 agent will be preserved by the SNMPv1 agent will be preserved through the use of the
through the use of the snmpTrapAddress and snmpTrapCommunity snmpTrapAddress and snmpTrapCommunity nobjects.
objects.
4.2.2. Upstream Version Less Than Downstream Version 4.2.2. Upstream Version Less Than Downstream Version
- If a GetResponse-PDU is received in response to a GetRequest- - If a GetResponse-PDU is received in response to a GetRequest-PDU
PDU (previously generated by the proxy) which contains (previously generated by the proxy) which contains variable-
variable-bindings of type Counter64 or which contain an SNMPv2 bindings of type Counter64 or which contain an SNMPv2 exception
exception code, and the message would be forwarded using the code, and the message would be forwarded using the SNMPv1 message
SNMPv1 message version, the proxy MUST generate an alternate version, the proxy MUST generate an alternate response PDU
response PDU consisting of the request-id and variable consisting of the request-id and variable bindings from the
bindings from the original SNMPv1 request, containing a original SNMPv1 request, containing a noSuchName error-status
noSuchName error-status value, and containing an error-index value, and containing an error-index value indicating the position
value indicating the position of the variable-binding of the variable-binding containing the Counter64 type or exception
containing the Counter64 type or exception code. code.
- If a GetResponse-PDU is received in response to a - If a GetResponse-PDU is received in response to a GetNextRequest-
GetNextRequest-PDU (previously generated by the proxy) which PDU (previously generated by the proxy) which contains variable-
contains variable-bindings that contain an SNMPv2 exception bindings that contain an SNMPv2 exception code, and the message
code, and the message would be forwarded using the SNMPv1 would be forwarded using the SNMPv1 message version, the proxy
message version, the proxy MUST generate an alternate response MUST generate an alternate response PDU consisting of the
PDU consisting of the request-id and variable bindings from request-id and variable bindings from the original SNMPv1 request,
the original SNMPv1 request, containing a noSuchName error- containing a noSuchName error-status value, and containing an
status value, and containing an error-index value indicating error-index value indicating the position of the variable-binding
the position of the variable-binding containing the exception containing the exception code.
code.
- If a GetResponse-PDU is received in response to a - If a GetResponse-PDU is received in response to a GetNextRequest-
GetNextRequest-PDU (previously generated by the proxy) which PDU (previously generated by the proxy) which contains variable-
contains variable-bindings of type Counter64, the proxy MUST bindings of type Counter64, the proxy MUST re-send the entire
re-send the entire GetNextRequest-PDU, with the following GetNextRequest-PDU, with the following modifications. For any
modifications. For any variable bindings in the received variable bindings in the received GetResponse which contained
GetResponse which contained Counter64 types, the proxy Counter64 types, the proxy substitutes the object names of these
substitutes the object names of these variable bindings for variable bindings for the corresponding object names in the
the corresponding object names in the previously-sent previously-sent GetNextRequest. The proxy MUST repeat this
GetNextRequest. The proxy MUST repeat this process until no process until no Counter64 objects are returned. Note that an
Counter64 objects are returned. Note that an implementation implementation may attempt to optimize this process of skipping
may attempt to optimize this process of skipping Counter64 Counter64 objects. One approach to such an optimization would be
objects. One approach to such an optimization would be to to replace the last sub-identifier of the object names of varbinds
replace the last sub-identifier of the object names of containing a Counter64 type with 65535 if that sub-identifier is
varbinds containing a Counter64 type with 65535 if that sub- less than 65535, or with 4294967295 if that sub-identifier is
identifier is less than 65535, or with 4294967295 if that greater than 65535. This approach should skip multiple instances
sub-identifier is greater than 65535. This approach should of the same Counter64 object, while maintaining compatibility with
skip multiple instances of the same Counter64 object, while some broken agent implementations (which only use 16-bit integers
maintaining compatibility with some broken agent for sub-identifiers).
implementations (which only use 16-bit integers for sub-
identifiers).
Deployment Hint: The process of repeated GetNext requests Deployment Hint: The process of repeated GetNext requests used by
used by a proxy when Counter64 types are returned can be a proxy when Counter64 types are returned can be expensive. When
expensive. When deploying a proxy, this can be avoided by deploying a proxy, this can be avoided by configuring the target
configuring the target agents to which the proxy forwards agents to which the proxy forwards requests in a manner such that
requests in a manner such that any objects of type Counter64 any objects of type Counter64 are in fact not-in-view for the
are in fact not-in-view for the principal that the proxy is principal that the proxy is using when communicating with these
using when communicating with these agents. agents.
- If a GetResponse-PDU is received which contains an SNMPv2 - If a GetResponse-PDU is received which contains an SNMPv2 error-
error-status value of wrongValue, wrongEncoding, wrongType, status value of wrongValue, wrongEncoding, wrongType, wrongLength,
wrongLength, inconsistentValue, noAccess, notWritable, inconsistentValue, noAccess, notWritable, noCreation,
noCreation, inconsistentName, resourceUnavailable, inconsistentName, resourceUnavailable, commitFailed, undoFailed,
commitFailed, undoFailed, or authorizationError, the error- or authorizationError, the error-status value is modified using
status value is modified using the mappings in section 4.3. the mappings in section 4.3.
- If an SNMPv2-Trap-PDU is received, and will be forwarded using - If an SNMPv2-Trap-PDU is received, and will be forwarded using the
the SNMPv1 message version, the proxy SHALL apply the SNMPv1 message version, the proxy SHALL apply the translation
translation rules described in section 3, and SHALL forward rules described in section 3, and SHALL forward the notification
the notification as a Trap-PDU. Note that if the translation as a Trap-PDU. Note that if the translation fails due to the
fails due to the existence of a Counter64 data-type in the existence of a Counter64 data-type in the received SNMPv2-Trap-
received SNMPv2-Trap-PDU, the trap cannot be forwarded using PDU, the trap cannot be forwarded using SNMPv1.
SNMPv1.
- If an InformRequest-PDU is received, any configuration - If an InformRequest-PDU is received, any configuration information
information indicating that it would be forwarded using the indicating that it would be forwarded using the SNMPv1 message
SNMPv1 message version SHALL be ignored. An InformRequest-PDU version SHALL be ignored. An InformRequest-PDU can only be
can only be forwarded using the SNMPv2c or SNMPv3 message forwarded using the SNMPv2c or SNMPv3 message version. The
version. The InformRequest-PDU may still be forwarded if InformRequest-PDU may still be forwarded if there is other
there is other configuration information indicating that it configuration information indicating that it should be forwarded
should be forwarded using SNMPv2c or SNMPv3. using SNMPv2c or SNMPv3.
4.3. Error Status Mappings 4.3. Error Status Mappings
The following tables shows the mappings of SNMPv1 error-status values The following tables shows the mappings of SNMPv1 error-status values
into SNMPv2 error-status values, and the mappings of SNMPv2 error- into SNMPv2 error-status values, and the mappings of SNMPv2 error-
status values into SNMPv1 error-status values. status values into SNMPv1 error-status values.
SNMPv1 error-status SNMPv2 error-status SNMPv1 error-status SNMPv2 error-status
=================== =================== =================== ===================
noError noError noError noError
tooBig tooBig tooBig tooBig
noSuchName noSuchName noSuchName noSuchName
badValue badValue badValue badValue
genErr genErr genErr genErr
SNMPv2 error-status SNMPv1 error-status SNMPv2 error-status SNMPv1 error-status
=================== =================== =================== ===================
noError noError noError noError
tooBig tooBig tooBig tooBig
genErr genErr genErr genErr
wrongValue badValue wrongValue badValue
wrongEncoding badValue wrongEncoding badValue
wrongType badValue wrongType badValue
wrongLength badValue wrongLength badValue
inconsistentValue badValue inconsistentValue badValue
noAccess noSuchName noAccess noSuchName
notWritable noSuchName notWritable noSuchName
noCreation noSuchName noCreation noSuchName
inconsistentName noSuchName inconsistentName noSuchName
resourceUnavailable genErr resourceUnavailable genErr
commitFailed genErr commitFailed genErr
undoFailed genErr undoFailed genErr
authorizationError noSuchName authorizationError noSuchName
Whenever the SNMPv2 error-status value of authorizationError is Whenever the SNMPv2 error-status value of authorizationError is
translated to an SNMPv1 error-status value of noSuchName, the value translated to an SNMPv1 error-status value of noSuchName, the value
of snmpInBadCommunityUses MUST be incremented. of snmpInBadCommunityUses MUST be incremented.
5. Message Processing Models and Security Models 5. Message Processing Models and Security Models
In order to adapt SNMPv1 (and SNMPv2c) into the SNMP architecture, In order to adapt SNMPv1 (and SNMPv2c) into the SNMP architecture,
the following models are defined in this document: the following models are defined in this document:
- The SNMPv1 Message Processing Model - The SNMPv1 Message Processing Model
- The SNMPv1 Community-Based Security Model - The SNMPv1 Community-Based Security Model
The following models are also described in this document: The following models are also described in this document:
- The SNMPv2c Message Processing Model - The SNMPv2c Message Processing Model
- The SNMPv2c Community-Based Security Model - The SNMPv2c Community-Based Security Model
In most respects, the SNMPv1 Message Processing Model and the In most respects, the SNMPv1 Message Processing Model and the
SNMPv2c Message Processing Model are identical, and so these SNMPv2c Message Processing Model are identical, and so these
are not discussed independently in this document. Differences are not discussed independently in this document. Differences
between the two models are described as required. between the two models are described as required.
Similarly, the SNMPv1 Community-Based Security Model and the Similarly, the SNMPv1 Community-Based Security Model and the
SNMPv2c Community-Based Security Model are nearly identical, SNMPv2c Community-Based Security Model are nearly identical,
and so are not discussed independently. Differences between and so are not discussed independently. Differences between
these two models are also described as required. these two models are also described as required.
5.1. Mappings 5.1. Mappings
The SNMPv1 (and SNMPv2c) Message Processing Model and Security Model The SNMPv1 (and SNMPv2c) Message Processing Model and Security Model
require mappings between parameters used in SNMPv1 (and SNMPv2c) require mappings between parameters used in SNMPv1 (and SNMPv2c)
messages, and the version independent parameters used in the SNMP messages, and the version independent parameters used in the SNMP
architecture [16]. The parameters which MUST be mapped consist of the architecture [16]. The parameters which MUST be mapped consist of
SNMPv1 (and SNMPv2c) community name, and the SNMP securityName and the SNMPv1 (and SNMPv2c) community name, and the SNMP securityName
contextEngineID/contextName pair. A MIB module (the SNMP-COMMUNITY-MIB) and contextEngineID/contextName pair. A MIB module (the SNMP-
is provided in this document in order to perform these mappings. This COMMUNITY-MIB) is provided in this document in order to perform these
MIB provides mappings in both directions, that is, a community name may mappings. This MIB provides mappings in both directions, that is, a
be mapped to a securityName, contextEngineID, and contextName, or the community name may be mapped to a securityName, contextEngineID, and
combination of securityName, contextEngineID, and contextName may be contextName, or the combination of securityName, contextEngineID, and
mapped to a community name. contextName may be mapped to a community name.
5.2. The SNMPv1 MP Model and SNMPv1 Community-based Security Model 5.2. The SNMPv1 MP Model and SNMPv1 Community-based Security Model
The SNMPv1 Message Processing Model handles processing of SNMPv1 The SNMPv1 Message Processing Model handles processing of SNMPv1
messages. The processing of messages is handled generally in the messages. The processing of messages is handled generally in the
same manner as described in RFC1157 [2], with differences and same manner as described in RFC1157 [2], with differences and
clarifications as described in the following sections. The clarifications as described in the following sections. The
SnmpMessageProcessingModel value for SNMPv1 is 0 (the value for SnmpMessageProcessingModel value for SNMPv1 is 0 (the value for
SNMPv2c is 1). SNMPv2c is 1).
5.2.1. Processing An Incoming Request 5.2.1. Processing An Incoming Request
In RFC1157 [2], section 4.1, item (3) for an entity which receives a In RFC1157 [2], section 4.1, item (3) for an entity which receives a
message, states that various parameters are passed to the 'desired message, states that various parameters are passed to the 'desired
authentication scheme.' The desired authentication scheme in this authentication scheme.' The desired authentication scheme in this
case is the SNMPv1 Community-Based Security Model, which will be case is the SNMPv1 Community-Based Security Model, which will be
called using the processIncomingMsg ASI. The parameters passed to called using the processIncomingMsg ASI. The parameters passed to
this ASI are: this ASI are:
- The messageProcessingModel, which will be 0 (or 1 for - The messageProcessingModel, which will be 0 (or 1 for SNMPv2c).
SNMPv2c).
- The maxMessageSize, which should be the maximum size of a - The maxMessageSize, which should be the maximum size of a
message that the receiving entity can generate (since there is message that the receiving entity can generate (since there is
no such value in the received message). no such value in the received message).
- The securityParameters, which consist of the community string - The securityParameters, which consist of the community string
and the message's source and destination transport domains and and the message's source and destination transport domains and
addresses. addresses.
- The securityModel, which will be 1 (or 2 for SNMPv2c). - The securityModel, which will be 1 (or 2 for SNMPv2c).
- The securityLevel, which will be noAuthNoPriv. - The securityLevel, which will be noAuthNoPriv.
- The wholeMsg and wholeMsgLength. - The wholeMsg and wholeMsgLength.
The Community-Based Security Model will attempt to select a row in The Community-Based Security Model will attempt to select a row in
the snmpCommunityTable. This is done by performing a search through the snmpCommunityTable. This is done by performing a search through
the snmpCommunityTable in lexicographic order. The first entry for the snmpCommunityTable in lexicographic order. The first entry for
which the following matching criteria are satisfied will be selected: which the following matching criteria are satisfied will be selected:
- The community string is equal to the snmpCommunityName value. - The community string is equal to the snmpCommunityName value.
- If the snmpCommunityTransportTag is an empty string, it is - If the snmpCommunityTransportTag is an empty string, it is
ignored for the purpose of matching. If the ignored for the purpose of matching. If the
snmpCommunityTransportTag is not an empty string, the snmpCommunityTransportTag is not an empty string, the
transportDomain and transportAddress from which the message transportDomain and transportAddress from which the message was
was received must match one of the entries in the received must match one of the entries in the
snmpTargetAddrTable selected by the snmpCommunityTransportTag snmpTargetAddrTable selected by the snmpCommunityTransportTag
value. The snmpTargetAddrTMask object is used as described in value. The snmpTargetAddrTMask object is used as described in
section 5.3 when checking whether the transportDomain and section 5.3 when checking whether the transportDomain and
transportAddress matches a entry in the snmpTargetAddrTable. transportAddress matches a entry in the snmpTargetAddrTable.
If no such entry can be found, an authentication failure occurs as If no such entry can be found, an authentication failure occurs as
described in RFC1157 [2], and the snmpInBadCommunityNames counter is described in RFC1157 [2], and the snmpInBadCommunityNames counter is
incremented. incremented.
The parameters returned from the Community-Based Security Model are: The parameters returned from the Community-Based Security Model are:
- The securityEngineID, which will always be the local value of - The securityEngineID, which will always be the local value of
snmpEngineID.0. snmpEngineID.0.
- The securityName. - The securityName.
- The scopedPDU. Note that this parameter will actually consist - The scopedPDU. Note that this parameter will actually consist
of three values, the contextSnmpEngineID, the contextName, and of three values, the contextSnmpEngineID, the contextName, and
the PDU. These must be separate values, since the first two the PDU. These must be separate values, since the first two do
do not actually appear in the message. not actually appear in the message.
- The maxSizeResponseScopedPDU. - The maxSizeResponseScopedPDU.
- The securityStateReference. - The securityStateReference.
The appropriate SNMP application will then be called (depending on The appropriate SNMP application will then be called (depending on
the value of the contextEngineID and the request type in the PDU) the value of the contextEngineID and the request type in the PDU)
using the processPdu ASI. The parameters passed to this ASI are: using the processPdu ASI. The parameters passed to this ASI are:
- The messageProcessingModel, which will be 0 (or 1 for - The messageProcessingModel, which will be 0 (or 1 for SNMPv2c).
SNMPv2c).
- The securityModel, which will be 1 (or 2 for SNMPv2c). - The securityModel, which will be 1 (or 2 for SNMPv2c).
- The securityName, which was returned from the call to - The securityName, which was returned from the call to
processIncomingMsg. processIncomingMsg.
- The securityLevel, which is noAuthNoPriv. - The securityLevel, which is noAuthNoPriv.
- The contextEngineID, which was returned as part of the - The contextEngineID, which was returned as part of the
ScopedPDU from the call to processIncomingMsg. ScopedPDU from the call to processIncomingMsg.
- The contextName, which was returned as part of the ScopedPDU - The contextName, which was returned as part of the ScopedPDU
from the call to processIncomingMsg. from the call to processIncomingMsg.
- The pduVersion, which should indicate an SNMPv1 version PDU - The pduVersion, which should indicate an SNMPv1 version PDU (if
(if the message version was SNMPv2c, this would be an SNMPv2 the message version was SNMPv2c, this would be an SNMPv2
version PDU). version PDU).
- The PDU, which was returned as part of the ScopedPDU from the - The PDU, which was returned as part of the ScopedPDU from the
call to processIncomingMsg. call to processIncomingMsg.
- The maxSizeResponseScopedPDU which was returned from the call - The maxSizeResponseScopedPDU which was returned from the call
to processIncomingMsg. to processIncomingMsg.
- The stateReference which was returned from the call to - The stateReference which was returned from the call to
processIncomingMsg. processIncomingMsg.
The SNMP application should process the request as described The SNMP application should process the request as described
previously in this document. Note that access control is applied by previously in this document. Note that access control is applied by
an SNMPv3 command responder application as usual. The parameters as an SNMPv3 command responder application as usual. The parameters as
passed to the processPdu ASI will be used in calls to the passed to the processPdu ASI will be used in calls to the
isAccessAllowed ASI. isAccessAllowed ASI.
5.2.2. Generating An Outgoing Response 5.2.2. Generating An Outgoing Response
There is no special processing required for generating an outgoing There is no special processing required for generating an outgoing
skipping to change at page 33, line 37 skipping to change at page 28, line 40
In a multi-lingual SNMP entity, the parameters used for generating In a multi-lingual SNMP entity, the parameters used for generating
notifications will be obtained by examining the SNMP-TARGET-MIB and notifications will be obtained by examining the SNMP-TARGET-MIB and
SNMP-NOTIFICATION-MIB. These parameters will be passed to the SNMPv1 SNMP-NOTIFICATION-MIB. These parameters will be passed to the SNMPv1
Message Processing Model using the sendPdu ASI. The SNMPv1 Message Message Processing Model using the sendPdu ASI. The SNMPv1 Message
Processing Model will attempt to locate an appropriate community Processing Model will attempt to locate an appropriate community
string in the snmpCommunityTable based on the parameters passed to string in the snmpCommunityTable based on the parameters passed to
the sendPdu ASI. This is done by performing a search through the the sendPdu ASI. This is done by performing a search through the
snmpCommunityTable in lexicographic order. The first entry for which snmpCommunityTable in lexicographic order. The first entry for which
the following matching criteria are satisfied will be selected: the following matching criteria are satisfied will be selected:
- The securityName must be equal to the - The securityName must be equal to the snmpCommunitySecurityName
snmpCommunitySecurityName value. value.
- The contextEngineID must be equal to the - The contextEngineID must be equal to the
snmpCommunityContextEngineID value. snmpCommunityContextEngineID value.
- The contextName must be equal to the snmpCommunityContextName - The contextName must be equal to the snmpCommunityContextName
value. value.
- If the snmpCommunityTransportTag is an empty string, it is - If the snmpCommunityTransportTag is an empty string, it is
ignored for the purpose of matching. If the ignored for the purpose of matching. If the
snmpCommunityTransportTag is not an empty string, the snmpCommunityTransportTag is not an empty string, the
transportDomain and transportAddress must match one of the transportDomain and transportAddress must match one of the
entries in the snmpTargetAddrTable selected by the entries in the snmpTargetAddrTable selected by the
snmpCommunityTransportTag value. snmpCommunityTransportTag value.
If no such entry can be found, the notification is not sent. If no such entry can be found, the notification is not sent.
Otherwise, the community string used in the outgoing notification Otherwise, the community string used in the outgoing notification
will be the value of the snmpCommunityName column of the selected will be the value of the snmpCommunityName column of the selected
row. row.
5.3. The SNMP Community MIB Module 5.3. The SNMP Community MIB Module
The SNMP-COMMUNITY-MIB contains objects for mapping between community The SNMP-COMMUNITY-MIB contains objects for mapping between community
strings and version-independent SNMP message parameters. In strings and version-independent SNMP message parameters. In
skipping to change at page 35, line 20 skipping to change at page 30, line 15
snmpTargetAddrTMask value (i.e., bits equal to 1), the corresponding snmpTargetAddrTMask value (i.e., bits equal to 1), the corresponding
bits in the snmpTargetAddrTAddress value must match the bits in a bits in the snmpTargetAddrTAddress value must match the bits in a
transport address. If all such bits match, the transport address is transport address. If all such bits match, the transport address is
matched by that snmpTargetAddrTable entry. Otherwise, the transport matched by that snmpTargetAddrTable entry. Otherwise, the transport
address is not matched. address is not matched.
The maximum message size value, snmpTargetAddrMMS, is used to The maximum message size value, snmpTargetAddrMMS, is used to
determine the maximum message size acceptable to another SNMP entity determine the maximum message size acceptable to another SNMP entity
when the value cannot be determined from the protocol. when the value cannot be determined from the protocol.
SNMP-COMMUNITY-MIB DEFINITIONS ::= BEGIN SNMP-COMMUNITY-MIB DEFINITIONS ::= BEGIN
IMPORTS IMPORTS
IpAddress, IpAddress,
MODULE-IDENTITY, MODULE-IDENTITY,
OBJECT-TYPE, OBJECT-TYPE,
Integer32, Integer32,
snmpModules snmpModules
FROM SNMPv2-SMI FROM SNMPv2-SMI
RowStatus, RowStatus,
StorageType StorageType
FROM SNMPv2-TC FROM SNMPv2-TC
SnmpAdminString, SnmpAdminString,
SnmpEngineID SnmpEngineID
FROM SNMP-FRAMEWORK-MIB FROM SNMP-FRAMEWORK-MIB
SnmpTagValue, SnmpTagValue,
snmpTargetAddrEntry snmpTargetAddrEntry
FROM SNMP-TARGET-MIB FROM SNMP-TARGET-MIB
MODULE-COMPLIANCE, MODULE-COMPLIANCE,
OBJECT-GROUP OBJECT-GROUP
FROM SNMPv2-CONF; FROM SNMPv2-CONF;
snmpCommunityMIB MODULE-IDENTITY snmpCommunityMIB MODULE-IDENTITY
LAST-UPDATED "199910050000Z" -- 5 Oct 1999, midnight LAST-UPDATED "200003060000Z" -- 6 Mar 2000, midnight
ORGANIZATION "SNMPv3 Working Group" ORGANIZATION "SNMPv3 Working Group"
CONTACT-INFO "WG-email: snmpv3@lists.tislabs.com CONTACT-INFO "WG-email: snmpv3@lists.tislabs.com
Subscribe: majordomo@lists.tislabs.com Subscribe: majordomo@lists.tislabs.com
In msg body: subscribe snmpv3 In msg body: subscribe snmpv3
Chair: Russ Mundy Chair: Russ Mundy
TIS Labs at Network Associates TIS Labs at Network Associates
Postal: 3060 Washington Rd
Glenwood MD 21738
USA
Email: mundy@tislabs.com
Phone: +1-301-854-6889
Co-editor: Rob Frye
CoSine Communications
Postal: 1200 Bridge Parkway
Redwood City, CA 94065
USA
E-mail: rfrye@cosinecom.com
Phone: +1 703 725 1130
Postal: 3060 Washington Rd Co-editor: David B. Levi
Glenwood MD 21738 Nortel Networks
USA Postal: 3505 Kesterwood Drive
Email: mundy@tislabs.com Knoxville, TN 37918
Phone: +1-301-854-6889 E-mail: dlevi@nortelnetworks.com
Phone: +1 423 686 0432
Co-editor: Rob Frye Co-editor: Shawn A. Routhier
CoSine Communications Integrated Systems Inc.
Postal: 1200 Bridge Parkway Postal: 333 North Ave 4th Floor
Redwood City, CA 94065 Wakefield, MA 01880
USA E-mail: sar@epilogue.com
E-mail: rfrye@cosinecom.com Phone: +1 781 245 0804
Phone: +1 650 637 4777
Co-editor: David B. Levi Co-editor: Bert Wijnen
Nortel Networks Lucent Technologies
Postal: 3505 Kesterwood Drive Postal: Schagen 33
Knoxville, TN 37918 3461 GL Linschoten
E-mail: dlevi@nortelnetworks.com Netherlands
Phone: +1 423 686 0432 Email: bwijnen@lucent.com
Phone: +31-348-407-775
"
Co-editor: Shawn A. Routhier DESCRIPTION
Integrated Systems Inc. "This MIB module defines objects to help support coexistence
Postal: 333 North Ave 4th Floor between SNMPv1, SNMPv2c, and SNMPv3."
Wakefield, MA 01880 REVISION "200003060000Z" -- 6 Mar 2000
E-mail: sar@epilogue.com DESCRIPTION "This version published as RFC 2576."
Phone: +1 781 245 0804 REVISION "199905130000Z" -- 13 May 1999
DESCRIPTION "The Initial Revision"
::= { snmpModules 18 }
Co-editor: Bert Wijnen -- Administrative assignments ****************************************
IBM T. J. Watson Research
Postal: Schagen 33
3461 GL Linschoten
Netherlands
Email: wijnen@vnet.ibm.com
Phone: +31-348-432-794
"
DESCRIPTION snmpCommunityMIBObjects OBJECT IDENTIFIER ::= { snmpCommunityMIB 1 }
"This MIB module defines objects to help support coexistence snmpCommunityMIBConformance OBJECT IDENTIFIER ::= { snmpCommunityMIB 2 }
between SNMPv1, SNMPv2c, and SNMPv3."
REVISION "199905130000Z" -- 13 May 1999
DESCRIPTION "The Initial Revision"
REVISION "199910050000Z" -- 5 Oct 1999 (same as LAST-UPDATED)
DESCRIPTION "This version published as RFC xxxx"
-- RFC-editor assigns xxxx
::= { snmpModules 18 }
-- Administrative assignments **************************************** --
-- The snmpCommunityTable contains a database of community strings.
-- This table provides mappings between community strings, and the
-- parameters required for View-based Access Control.
--
snmpCommunityMIBObjects OBJECT IDENTIFIER ::= { snmpCommunityMIB 1 } snmpCommunityTable OBJECT-TYPE
snmpCommunityMIBConformance OBJECT IDENTIFIER ::= { snmpCommunityMIB 2 } 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
-- The snmpCommunityTable contains a database of community strings. SYNTAX SnmpCommunityEntry
-- This table provides mappings between community strings, and the MAX-ACCESS not-accessible
-- parameters required for View-based Access Control. STATUS current
-- DESCRIPTION
"Information about a particular community string."
INDEX { IMPLIED snmpCommunityIndex }
::= { snmpCommunityTable 1 }
snmpCommunityTable OBJECT-TYPE SnmpCommunityEntry ::= SEQUENCE {
SYNTAX SEQUENCE OF SnmpCommunityEntry snmpCommunityIndex SnmpAdminString,
MAX-ACCESS not-accessible snmpCommunityName OCTET STRING,
STATUS current snmpCommunitySecurityName SnmpAdminString,
DESCRIPTION snmpCommunityContextEngineID SnmpEngineID,
"The table of community strings configured in the SNMP snmpCommunityContextName SnmpAdminString,
engine's Local Configuration Datastore (LCD)." snmpCommunityTransportTag SnmpTagValue,
::= { snmpCommunityMIBObjects 1 } snmpCommunityStorageType StorageType,
snmpCommunityStatus RowStatus
}
snmpCommunityEntry OBJECT-TYPE snmpCommunityIndex OBJECT-TYPE
SYNTAX SnmpCommunityEntry SYNTAX SnmpAdminString (SIZE(1..32))
MAX-ACCESS not-accessible MAX-ACCESS not-accessible
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"Information about a particular community string." "The unique index value of a row in this table."
INDEX { IMPLIED snmpCommunityIndex } ::= { snmpCommunityEntry 1 }
::= { snmpCommunityTable 1 }
SnmpCommunityEntry ::= SEQUENCE { snmpCommunityName OBJECT-TYPE
snmpCommunityIndex SnmpAdminString, SYNTAX OCTET STRING
snmpCommunityName OCTET STRING, MAX-ACCESS read-create
snmpCommunitySecurityName SnmpAdminString, STATUS current
snmpCommunityContextEngineID SnmpEngineID, DESCRIPTION
snmpCommunityContextName SnmpAdminString, "The community string for which a row in this table
snmpCommunityTransportTag SnmpTagValue, represents a configuration."
snmpCommunityStorageType StorageType, ::= { snmpCommunityEntry 2 }
snmpCommunityStatus RowStatus
}
snmpCommunityIndex OBJECT-TYPE snmpCommunitySecurityName OBJECT-TYPE
SYNTAX SnmpAdminString (SIZE(1..32)) SYNTAX SnmpAdminString (SIZE(1..32))
MAX-ACCESS not-accessible MAX-ACCESS read-create
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The unique index value of a row in this table." "A human readable string representing the corresponding
::= { snmpCommunityEntry 1 } value of snmpCommunityName in a Security Model
independent format."
::= { snmpCommunityEntry 3 }
snmpCommunityName OBJECT-TYPE snmpCommunityContextEngineID OBJECT-TYPE
SYNTAX OCTET STRING SYNTAX SnmpEngineID
MAX-ACCESS read-create MAX-ACCESS read-create
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The community string for which a row in this table "The contextEngineID indicating the location of the
represents a configuration." context in which management information is accessed
::= { snmpCommunityEntry 2 } when using the community string specified by the
corresponding instance of snmpCommunityName.
snmpCommunitySecurityName OBJECT-TYPE The default value is the snmpEngineID of the entity in
SYNTAX SnmpAdminString (SIZE(1..32)) which this object is instantiated."
MAX-ACCESS read-create ::= { snmpCommunityEntry 4 }
STATUS current
DESCRIPTION
"A human readable string representing the corresponding
value of snmpCommunityName in a Security Model
independent format."
::= { snmpCommunityEntry 3 }
snmpCommunityContextEngineID OBJECT-TYPE snmpCommunityContextName OBJECT-TYPE
SYNTAX SnmpEngineID SYNTAX SnmpAdminString (SIZE(0..32))
MAX-ACCESS read-create MAX-ACCESS read-create
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The contextEngineID indicating the location of the "The context in which management information is accessed
context in which management information is accessed when using the community string specified by the corresponding
when using the community string specified by the instance of snmpCommunityName."
corresponding instance of snmpCommunityName. DEFVAL { ''H } -- the empty string
::= { snmpCommunityEntry 5 }
The default value is the snmpEngineID of the entity in snmpCommunityTransportTag OBJECT-TYPE
which this object is instantiated." SYNTAX SnmpTagValue
::= { snmpCommunityEntry 4 } MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This object specifies a set of transport endpoints
from which a command responder application will accept
management requests. If a management request containing
this community is received on a transport endpoint other
than the transport endpoints identified by this object,
the request is deemed unauthentic.
snmpCommunityContextName OBJECT-TYPE The transports identified by this object are specified
SYNTAX SnmpAdminString (SIZE(0..32)) in the snmpTargetAddrTable. Entries in that table
MAX-ACCESS read-create whose snmpTargetAddrTagList contains this tag value
STATUS current are identified.
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 If the value of this object has zero-length, transport
SYNTAX SnmpTagValue endpoints are not checked when authenticating messages
MAX-ACCESS read-create containing this community string."
STATUS current DEFVAL { ''H } -- the empty string
DESCRIPTION ::= { snmpCommunityEntry 6 }
"This object specifies a set of transport endpoints
from which a command responder application will accept
management requests. If a management request containing
this community is received on a transport endpoint other
than the transport endpoints identified by this object,
the request is deemed unauthentic.
The transports identified by this object are specified snmpCommunityStorageType OBJECT-TYPE
in the snmpTargetAddrTable. Entries in that table SYNTAX StorageType
whose snmpTargetAddrTagList contains this tag value MAX-ACCESS read-create
are identified. 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 }
If the value of this object has zero-length, transport snmpCommunityStatus OBJECT-TYPE
endpoints are not checked when authenticating messages SYNTAX RowStatus
containing this community string." MAX-ACCESS read-create
DEFVAL { ''H } -- the empty string STATUS current
::= { snmpCommunityEntry 6 } DESCRIPTION
"The status of this conceptual row in the snmpCommunityTable.
snmpCommunityStorageType OBJECT-TYPE An entry in this table is not qualified for activation
SYNTAX StorageType until instances of all corresponding columns have been
MAX-ACCESS read-create initialized, either through default values, or through
STATUS current Set operations. The snmpCommunityName and
DESCRIPTION snmpCommunitySecurityName objects must be explicitly set.
"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 There is no restriction on setting columns in this table
SYNTAX RowStatus when the value of snmpCommunityStatus is active(1)."
MAX-ACCESS read-create ::= { snmpCommunityEntry 8 }
STATUS current
DESCRIPTION
"The status of this conceptual row in the snmpCommunityTable.
An entry in this table is not qualified for activation --
until instances of all corresponding columns have been -- The snmpTargetAddrExtTable
initialized, either through default values, or through --
Set operations. The snmpCommunityName and
snmpCommunitySecurityName objects must be explicitly set.
There is no restriction on setting columns in this table snmpTargetAddrExtTable OBJECT-TYPE
when the value of snmpCommunityStatus is active(1)." SYNTAX SEQUENCE OF SnmpTargetAddrExtEntry
::= { snmpCommunityEntry 8 } MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The table of mask and mms values associated with the
snmpTargetAddrTable.
-- The snmpTargetAddrExtTable augments the
-- The snmpTargetAddrExtTable 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 }
snmpTargetAddrExtTable OBJECT-TYPE snmpTargetAddrExtEntry OBJECT-TYPE
SYNTAX SEQUENCE OF SnmpTargetAddrExtEntry SYNTAX SnmpTargetAddrExtEntry
MAX-ACCESS not-accessible MAX-ACCESS not-accessible
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The table of mask and mms values associated with the "Information about a particular mask and mms value."
snmpTargetAddrTable. AUGMENTS { snmpTargetAddrEntry }
::= { snmpTargetAddrExtTable 1 }
The snmpTargetAddrExtTable augments the SnmpTargetAddrExtEntry ::= SEQUENCE {
snmpTargetAddrTable with a transport address mask value snmpTargetAddrTMask OCTET STRING,
and a maximum message size value. The transport address snmpTargetAddrMMS Integer32
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 snmpTargetAddrTMask OBJECT-TYPE
SYNTAX SnmpTargetAddrExtEntry SYNTAX OCTET STRING (SIZE (0..255))
MAX-ACCESS not-accessible MAX-ACCESS read-create
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"Information about a particular mask and mms value." "The mask value associated with an entry in the
AUGMENTS { snmpTargetAddrEntry } snmpTargetAddrTable. The value of this object must
::= { snmpTargetAddrExtTable 1 } 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.
SnmpTargetAddrExtEntry ::= SEQUENCE { The value of this object allows an entry in the
snmpTargetAddrTMask OCTET STRING, snmpTargetAddrTable to specify multiple addresses.
snmpTargetAddrMMS Integer32 The mask value is used to select which bits of
} a transport address must match bits of the corresponding
instance of snmpTargetAddrTAddress, in order for the
transport address to match a particular entry in the
snmpTargetAddrTable. Bits which are 1 in the mask
value indicate bits in the transport address which
must match bits in the snmpTargetAddrTAddress value.
snmpTargetAddrTMask OBJECT-TYPE Bits which are 0 in the mask indicate bits in the
SYNTAX OCTET STRING (SIZE (0..255)) transport address which need not match. If the
MAX-ACCESS read-create length of the mask is 0, the mask should be treated
STATUS current as if all its bits were 1 and its length were equal
DESCRIPTION to the length of the corresponding value of
"The mask value associated with an entry in the snmpTargetAddrTable.
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.
The value of this object allows an entry in the This object may not be modified while the value of the
snmpTargetAddrTable to specify multiple addresses. corresponding instance of snmpTargetAddrRowStatus is
The mask value is used to select which bits of active(1). An attempt to set this object in this case
a transport address must match bits of the corresponding will result in an inconsistentValue error."
instance of snmpTargetAddrTAddress, in order for the DEFVAL { ''H }
transport address to match a particular entry in the ::= { snmpTargetAddrExtEntry 1 }
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.
This object may not be modified while the value of the snmpTargetAddrMMS OBJECT-TYPE
corresponding instance of snmpTargetAddrRowStatus is SYNTAX Integer32 (0|484..2147483647)
active(1). An attempt to set this object in this case MAX-ACCESS read-create
will result in an inconsistentValue error." STATUS current
DEFVAL { ''H } DESCRIPTION
::= { snmpTargetAddrExtEntry 1 } "The maximum message size value associated with an entry
in the snmpTargetAddrTable."
DEFVAL { 484 }
::= { snmpTargetAddrExtEntry 2 }
snmpTargetAddrMMS OBJECT-TYPE --
SYNTAX Integer32 (0|484..2147483647) -- The snmpTrapAddress and snmpTrapCommunity objects are included
MAX-ACCESS read-create -- in notifications that are forwarded by a proxy, which were
STATUS current -- originally received as SNMPv1 Trap messages.
DESCRIPTION --
"The maximum message size value associated with an entry
in the snmpTargetAddrTable."
DEFVAL { 484 }
::= { snmpTargetAddrExtEntry 2 }
-- snmpTrapAddress OBJECT-TYPE
-- The snmpTrapAddress and snmpTrapCommunity objects are included SYNTAX IpAddress
-- in notifications that are forwarded by a proxy, which were MAX-ACCESS accessible-for-notify
-- originally received as SNMPv1 Trap messages. 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 snmpTrapCommunity OBJECT-TYPE
SYNTAX IpAddress SYNTAX OCTET STRING
MAX-ACCESS accessible-for-notify MAX-ACCESS accessible-for-notify
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The value of the agent-addr field of a Trap PDU which "The value of the community string field of an SNMPv1
is forwarded by a proxy forwarder application using message containing a Trap PDU which is forwarded by a
an SNMP version other than SNMPv1. The value of this a proxy forwarder application using an SNMP version
object SHOULD contain the value of the agent-addr field other than SNMPv1. The value of this object SHOULD
from the original Trap PDU as generated by an SNMPv1 contain the value of the community string field from
agent." the original SNMPv1 message containing a Trap PDU as
::= { snmpCommunityMIBObjects 3 } generated by an SNMPv1 agent."
::= { snmpCommunityMIBObjects 4 }
snmpTrapCommunity OBJECT-TYPE -- Conformance Information *******************************************
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."
::= { snmpCommunityMIBObjects 4 }
-- Conformance Information ******************************************* snmpCommunityMIBCompliances OBJECT IDENTIFIER
::= { snmpCommunityMIBConformance 1 }
snmpCommunityMIBGroups OBJECT IDENTIFIER
::= { snmpCommunityMIBConformance 2 }
snmpCommunityMIBCompliances OBJECT IDENTIFIER -- Compliance statements
::= { 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 MODULE -- this module
STATUS current MANDATORY-GROUPS { snmpCommunityGroup }
DESCRIPTION
"The compliance statement for SNMP engines which
implement the SNMP-COMMUNITY-MIB."
MODULE -- this module OBJECT snmpCommunityName
MANDATORY-GROUPS { snmpCommunityGroup } MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
OBJECT snmpCommunityName OBJECT snmpCommunitySecurityName
MIN-ACCESS read-only MIN-ACCESS read-only
DESCRIPTION "Write access is not required." DESCRIPTION "Write access is not required."
OBJECT snmpCommunitySecurityName OBJECT snmpCommunityContextEngineID
MIN-ACCESS read-only MIN-ACCESS read-only
DESCRIPTION "Write access is not required." DESCRIPTION "Write access is not required."
OBJECT snmpCommunityContextEngineID
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
OBJECT snmpCommunityContextName OBJECT snmpCommunityContextName
MIN-ACCESS read-only MIN-ACCESS read-only
DESCRIPTION "Write access is not required." DESCRIPTION "Write access is not required."
OBJECT snmpCommunityTransportTag OBJECT snmpCommunityTransportTag
MIN-ACCESS read-only MIN-ACCESS read-only
DESCRIPTION "Write access is not required." DESCRIPTION "Write access is not required."
OBJECT snmpCommunityStorageType OBJECT snmpCommunityStorageType
MIN-ACCESS read-only MIN-ACCESS read-only
DESCRIPTION "Write access is not required." DESCRIPTION "Write access is not required."
OBJECT snmpCommunityStatus OBJECT snmpCommunityStatus
MIN-ACCESS read-only MIN-ACCESS read-only
DESCRIPTION "Write access is not required." DESCRIPTION "Write access is not required."
::= { snmpCommunityMIBCompliances 1 } ::= { snmpCommunityMIBCompliances 1 }
snmpProxyTrapForwardCompliance MODULE-COMPLIANCE snmpProxyTrapForwardCompliance MODULE-COMPLIANCE
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The compliance statement for SNMP engines which "The compliance statement for SNMP engines which
contain a proxy forwarding application which is contain a proxy forwarding application which is
capable of forwarding SNMPv1 traps using SNMPv2c capable of forwarding SNMPv1 traps using SNMPv2c
or SNMPv3." or SNMPv3."
MODULE -- this module MODULE -- this module
MANDATORY-GROUPS { snmpProxyTrapForwardGroup } MANDATORY-GROUPS { snmpProxyTrapForwardGroup }
::= { snmpCommunityMIBCompliances 2 } ::= { snmpCommunityMIBCompliances 2 }
snmpCommunityGroup OBJECT-GROUP snmpCommunityGroup OBJECT-GROUP
OBJECTS { OBJECTS {
snmpCommunityName, snmpCommunityName,
snmpCommunitySecurityName, snmpCommunitySecurityName,
snmpCommunityContextEngineID, snmpCommunityContextEngineID,
snmpCommunityContextName, snmpCommunityContextName,
snmpCommunityTransportTag, snmpCommunityTransportTag,
snmpCommunityStorageType, snmpCommunityStorageType,
snmpCommunityStatus, snmpCommunityStatus,
snmpTargetAddrTMask, snmpTargetAddrTMask,
snmpTargetAddrMMS snmpTargetAddrMMS
} }
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"A collection of objects providing for configuration "A collection of objects providing for configuration
of community strings for SNMPv1 (and SNMPv2c) usage." of community strings for SNMPv1 (and SNMPv2c) usage."
::= { snmpCommunityMIBGroups 1 } ::= { snmpCommunityMIBGroups 1 }
snmpProxyTrapForwardGroup OBJECT-GROUP snmpProxyTrapForwardGroup OBJECT-GROUP
OBJECTS { OBJECTS {
snmpTrapAddress, snmpTrapAddress,
snmpTrapCommunity snmpTrapCommunity
} }
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"Objects which are used by proxy forwarding applications "Objects which are used by proxy forwarding applications
when translating traps between SNMP versions. These are when translating traps between SNMP versions. These are
used to preserve SNMPv1-specific information when used to preserve SNMPv1-specific information when
translating to SNMPv2c or SNMPv3." translating to SNMPv2c or SNMPv3."
::= { snmpCommunityMIBGroups 3 } ::= { snmpCommunityMIBGroups 3 }
END END
6. Intellectual Property 6. Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to intellectual property or other rights that might be claimed to pertain
pertain to the implementation or use of the technology described in to the implementation or use of the technology described in this
this document or the extent to which any license under such rights document or the extent to which any license under such rights might or
might or might not be available; neither does it represent that it might not be available; neither does it represent that it has made any
has made any effort to identify any such rights. Information on the effort to identify any such rights. Information on the IETF's
IETF's procedures with respect to rights in standards-track and procedures with respect to rights in standards-track and standards-
standards-related documentation can be found in BCP-11. Copies of related documentation can be found in BCP-11. Copies of claims of
claims of rights made available for publication and any assurances of rights made available for publication and any assurances of licenses to
licenses to be made available, or the result of an attempt made to be made available, or the result of an attempt made to obtain a general
obtain a general license or permission for the use of such license or permission for the use of such proprietary rights by
proprietary rights by implementors or users of this specification can implementors or users of this specification can be obtained from the
be obtained from the IETF Secretariat. IETF Secretariat.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary rights
rights which may cover technology that may be required to practice which may cover technology that may be required to practice this
this standard. Please address the information to the IETF Executive standard. Please address the information to the IETF Executive
Director. Director.
7. Acknowledgments 7. Acknowledgments
This document is the result of the efforts of the SNMPv3 Working This document is the result of the efforts of the SNMPv3 Working Group.
Group. The design of the SNMP-COMMUNITY-MIB incorporates work done The design of the SNMP-COMMUNITY-MIB incorporates work done by the
by the authors of SNMPv2*: authors of SNMPv2*:
Jeff Case (SNMP Research, Inc.) Jeff Case (SNMP Research, Inc.)
David Harrington (Cabletron Systems Inc.) David Harrington (Cabletron Systems Inc.)
David Levi (SNMP Research, Inc.) David Levi (SNMP Research, Inc.)
Brian O'Keefe (Hewlett Packard) Brian O'Keefe (Hewlett Packard)
Jon Saperia (IronBridge Networks, Inc.) Jon Saperia (IronBridge Networks, Inc.)
Steve Waldbusser (International Network Services) Steve Waldbusser (International Network Services)
8. Security Considerations 8. Security Considerations
Although SNMPv1 and SNMPv2 do not provide any security, allowing Although SNMPv1 and SNMPv2 do not provide any security, allowing
community names to be mapped into securityName/contextName provides community names to be mapped into securityName/contextName provides
the ability to use view-based access control to limit the access of the ability to use view-based access control to limit the access of
unsecured SNMPv1 and SNMPv2 operations. In fact, it is important for unsecured SNMPv1 and SNMPv2 operations. In fact, it is important for
network administrators to make use of this capability in order to network administrators to make use of this capability in order to
avoid unauthorized access to MIB data that would otherwise be secure. avoid unauthorized access to MIB data that would otherwise be secure.
skipping to change at page 48, line 7 skipping to change at page 40, line 31
When a proxy implementation translates messages between SNMPv1 (or When a proxy implementation translates messages between SNMPv1 (or
SNMPv2c) and SNMPv3, there may be a loss of security. For example, SNMPv2c) and SNMPv3, there may be a loss of security. For example,
an SNMPv3 message received using authentication and privacy which is an SNMPv3 message received using authentication and privacy which is
subsequently forwarded using SNMPv1 will lose the security benefits subsequently forwarded using SNMPv1 will lose the security benefits
of using authentication and privacy. Careful configuration of of using authentication and privacy. Careful configuration of
proxies is required to address such situations. One approach to deal proxies is required to address such situations. One approach to deal
with such situations might be to use an encrypted tunnel. with such situations might be to use an encrypted tunnel.
9. References 9. References
[1] Rose, M. and K. McCloghrie, "Structure and Identification of [1] Rose, M. and K. McCloghrie, "Structure and Identification of
Management Information for TCP/IP-based internets"", STD16, RFC Management Information for TCP/IP-based internets", STD 16, RFC
1155, May 1990. 1155, May 1990.
[2] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network [2] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple
Management Protocol", STD15, RFC 1157, SNMP Research, Performance Network Management Protocol", STD 15, RFC 1157, May 1990.
Systems International, Performance Systems International, MIT
Laboratory for Computer Science, May 1990.
[3] McCloghrie, K., and M. Rose, Editors, "Concise MIB Definitions", [3] McCloghrie, K. and M. Rose, Editors, "Concise MIB Definitions",
STD 16, RFC 1212, Hughes LAN Systems, Performance Systems STD 16, RFC 1212, March 1991.
International, March 1991.
[4] Rose, M. T., "A Convention for Defining Traps for use with the [4] Rose, M., "A Convention for Defining Traps for use with the
SNMP", RFC 1215, March 1991. SNMP", RFC 1215, March 1991.
[5] McCloghrie, K., and M. Rose, "A Convention for Describing SNMP- [5] McCloghrie, K. and M. Rose, "A Convention for Describing SNMP-
based Agents", RFC 1303, Hughes LAN Systems, Dover Beach based Agents", RFC 1303, February 1992.
Consulting, Inc., February 1992.
[6] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. [6] Case, J., McCloghrie, K., Rose, M. and S.Waldbusser,
Waldbusser, "Introduction to Community-based SNMPv2", RFC1901, SNMP "Introduction to Community-based SNMPv2", RFC 1901, January
Research,Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., 1996.
International Network Services, January 1996.
[7] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., [7] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose,
and S. Waldbusser, "Structure of Management Information Version 2 M. and S. Waldbusser, "Structure of Management Information
(SMIv2)", RFC 2578, STD 58, Cisco Systems, SNMPinfo, TU Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
Braunschweig, SNMP Research, First Virtual Holdings, International
Network Services, April 1999.
[8] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., [8] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose,
and S. Waldbusser, "Textual Conventions for SMIv2", RFC 2579, STD M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58,
58, Cisco Systems, SNMPinfo, TU Braunschweig, SNMP Research, First RFC 2579, April 1999.
Virtual Holdings, International Network Services, April 1999.
[9] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., [9] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose,
and S. Waldbusser, "Conformance Statements for SMIv2", RFC 2580, M. and S. Waldbusser, "Conformance Statements for SMIv2", STD
STD 58, Cisco Systems, SNMPinfo, TU Braunschweig, SNMP Research, 58, RFC 2580, April 1999.
First Virtual Holdings, International Network Services, April 1999.
[10] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. [10] Case, J., McCloghrie, K., Rose, M. and S.Waldbusser, "Protocol
Waldbusser, "Protocol Operations for Version 2 of the Simple Operations for Version 2 of the Simple Network Management
Network Management Protocol (SNMPv2)", RFC1905, SNMP Research,Inc., Protocol (SNMPv2)", RFC 1905, January 1996.
Cisco Systems, Inc., Dover Beach Consulting, Inc., International
Network Services, January 1996.
[11] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Transport [11] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Transport
Mappings for Version 2 of the Simple Network Management Protocol Mappings for Version 2 of the Simple Network Management Protocol
(SNMPv2)", RFC 1906, January 1996. (SNMPv2)", RFC 1906, January 1996.
[12] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. [12] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser,
Waldbusser, "Management Information Base for Version 2 of the "Management Information Base for Version 2 of the Simple Network
Simple Network Management Protocol (SNMPv2)", RFC1907, SNMP Management Protocol (SNMPv2)", RFC 1907, January 1996.
Research,Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc.,
International Network Services, January 1996.
[13] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. [13] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser,
Waldbusser, "Coexistence between Version 1 and Version 2 of the "Coexistence between Version 1 and Version 2 of the Internet-
Internet-standard Network Management Framework", RFC1908, SNMP standard Network Management Framework", RFC 1908, January 1996.
Research,Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc.,
International Network Services, January 1996.
[14] Levi, D., Wijnen, B., "Mapping SNMPv2 onto SNMPv1 within a bi- [14] Levi, D. and B. Wijnen, "Mapping SNMPv2 onto SNMPv1 within a
lingual SNMP agent", RFC2089, SNMP Research, Inc., IBM, January bi-lingual SNMP agent", RFC 2089, January 1997.
1997.
[15] Bradner, S., "Key words for use in RFCs to Indicate Requirement [15] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[16] The SNMPv3 Working Group, Harrington, D., Wijnen, B., "An [16] Harrington, D. and B. Wijnen, "An Architecture for Describing
Architecture for Describing SNMP Management Frameworks", RFC 2571, SNMP Management Frameworks", RFC 2571, May 1999.
May 1999.
[17] The SNMPv3 Working Group, Case, J., Harrington, D., Wijnen, B., [17] Case, J., Harrington, D. and B. Wijnen, "Message Processing and
"Message Processing and Dispatching for the Simple Network Dispatching for the Simple Network Management Protocol (SNMP)",
Management Protocol (SNMP)", RFC 2572, May 1999. RFC 2572, May 1999.
[18] The SNMPv3 Working Group, Levi, D., Meyer, P., Stewart, B., "SNMP [18] Levi, D., Meyer, P. and B. Stewart, "SNMP Applications", RFC
Applications", RFC2573, May 1999. 2573, May 1999.
[19] The SNMPv3 Working Group, Blumenthal, U., Wijnen, B., "The User- [19] Blumenthal, U. and Wijnen, B., "The User-Based Security Model
Based Security Model for Version 3 of the Simple Network Management for Version 3 of the Simple Network Management Protocol (SNMP)",
Protocol (SNMP)", RFC 2574, May 1999. RFC 2574, May 1999.
[20] The SNMPv3 Working Group, Wijnen, B., Presuhn, R., McCloghrie, K., [20] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access
"View-based Access Control Model for the Simple Network Management Control Model for the Simple Network Management Protocol
Protocol (SNMP)", RFC 2575, May 1999. (SNMP)", RFC 2575, May 1999.
10. Editor's Addresses 10. Editor's Addresses
Rob Frye Rob Frye
MCI WorldCom CoSine Communications
2100 Reston Parkway, Suite 600 1200 Bridge Parkway
Reston, VA 20191 Redwood City, CA 94065
U.S.A. U.S.A.
Phone: +1 703 715 7225
EMail: Rob.Frye@wcom.com
David B. Levi Phone: +1 703 725 1130
Nortel Networks EMail: rfrye@cosinecom.com
3505 Kesterwood Drive
Knoxville, TN 37918
U.S.A.
Phone: +1 423 686 0432
EMail: dlevi@nortelnetworks.com
Shawn A. Routhier David B. Levi
Integrated Systems Inc. Nortel Networks
333 North Ave 4th Floor 3505 Kesterwood Drive
Wakefield MA 01880 Knoxville, TN 37918
U.S.A. U.S.A.
Phone: + 1 781 245 0804
EMail: sar@epilogue.com
Bert Wijnen Phone: +1 423 686 0432
IBM T. J. Watson Research EMail: dlevi@nortelnetworks.com
Schagen 33
3461 GL Linschoten
Netherlands
Phone: +31 348 432 794
EMail: wijnen@vnet.ibm.com
A. Full Copyright Statement Shawn A. Routhier
Integrated Systems Inc.
333 North Ave 4th Floor
Wakefield MA 01880
U.S.A.
Phone: + 1 781 245 0804
EMail: sar@epilogue.com
Bert Wijnen
Lucent Technologies
Schagen 33
3461 GL Linschoten
Netherlands
Phone: +31 348 407-775
EMail: wijnen@lucent.com
A. Changes From RFC1908
- Editorial changes to comply with current RFC requirements.
- 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.
- Added coexistence for/with SNMPv3.
- Added description for SNMPv1 and SNMPv2c Message Processing
Models and SNMPv1 and SNMPv2c Community-based Security
Models.
- Added snmpCommunityMIB so that SNMPv1 and SNMPv2 community
strings can be mapped into the SNMP Version Independent
paramaters which can then be used for access control using the
standard SNMPv3 View-based Access Control Model and the
snmpVacmMIB.
- 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.
- Included (and extended) from RFC2089 the SNMPv2 to SNMPv1
mapping within a multi-lingual SNMP Engine.
- Use keywords from RFC 2119 to describe requirements for
compliance.
- Changed/added some rules for converting a MIB module from
SMIv1 to SMIv2.
- Extended and improved the description of Proxy Forwarder
behaviour when multiple SNMP versions are involved.
Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than followed, or as required to translate it into languages other than
English. English.
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 273 change blocks. 
1167 lines changed or deleted 1183 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/