Network Working Group SNMPv2 Working Group Request for Comments: 1908 J. Case Obsoletes: 1452 SNMP Research, Inc. Category: Standards Track K. McCloghrie Cisco Systems, Inc. M. Rose Dover Beach Consulting, Inc. S. Waldbusser International Network Services January 1996
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
2. Management Information
2.1 Object Definitions
2.2 Trap Definitions
2.3 Compliance Statements
2.4 Capabilities Statements
3 Protocol Operations
3.1 Proxy Agent Behavior
3.1.1 SNMPv2 -> SNMPv1
3.1.2 SNMPv1 -> SNMPv2
3.2 Bi-lingual Manager Behavior
4. Security Considerations
5. Editor's Address
The purpose of this document is to describe coexistence between version 2 of the Internet-standard Network Management Framework [1- 6], termed the SNMP version 2 framework (SNMPv2), and the original Internet-standard Network Management Framework (SNMPv1), which consists of these three documents:
STD 16, RFC 1155  which defines the Structure of Management Information (SMI), the mechanisms used for describing and naming objects for the purpose of management.
STD 16, RFC 1212  which defines a more concise description mechanism, which is wholly consistent with the SMI.
STD 15, RFC 1157  which defines the Simple Network Management Protocol (SNMP), the protocol used for network access to managed objects.
The SNMPv2 approach towards describing collections of managed objects is nearly a proper superset of the approach defined in the Internet- standard Network Management Framework. For example, both approaches use ASN.1  as the basis for a formal descriptive notation. Indeed, one might note that the SNMPv2 approach largely codifies the existing practice for defining MIB modules, based on extensive experience with the current framework.
The SNMPv2 documents which deal with information modules are:
Structure of Management Information for SNMPv2 , which defines concise notations for describing information modules, managed objects and notifications;
Textual Conventions for SNMPv2 , which defines a concise notation for describing textual conventions, and also defines some initial conventions; and,
Conformance Statements for SNMPv2 , which defines concise notation for describing compliance and capabilities statements.
The following sections consider the three areas: MIB modules, compliance statements, and capabilities statements.
MIB modules defined using the current framework may continue to be used with the SNMPv2 protocol. However, for the MIB modules to conform to the SNMPv2 framework, the following changes are required:
In general, conversion of a MIB module does not require the deprecation of the objects contained therein. Only if the semantics of an object truly changes should deprecation be performed.
If a MIB module is changed to conform to the SNMPv2 framework, then each occurrence of the TRAP-TYPE macro must be changed to a corresponding invocation of the NOTIFICATION-TYPE macro:
(1) The IMPORTS statement must not reference RFC-1215.
(2) The ENTERPRISES clause must be removed.
(3) The VARIABLES clause must be renamed to the OBJECTS clause.
(4) The STATUS clause must be added.
(5) The value of an invocation of the NOTIFICATION-TYPE macro is an OBJECT IDENTIFIER, not an INTEGER, and must be changed accordingly. Specifically, if the value of the ENTERPRISE clause is not 'snmp' then the value of the invocation is the value of the ENTERPRISE clause extended with two sub-identifiers, the first of which has the value 0, and the second has the value of the invocation of the TRAP-TYPE.
For those information modules which are "standard", a corresponding invocation of the MODULE-COMPLIANCE macro must be included within the information module (or in a companion information module), and any commentary text in the information module which relates to compliance must be removed. Typically this editing can occur when the information module undergoes review.
In the current framework, the informational document  uses the MODULE-CONFORMANCE macro to describe an agent's capabilities with respect to one or more MIB modules. Converting such a description for use with the SNMPv2 framework requires these changes:
(1) Use the macro name AGENT-CAPABILITIES instead of MODULE- CONFORMANCE.
(2) The STATUS clause must be added.
(3) For all occurrences of the CREATION-REQUIRES clause, note the slight change in semantics, and omit this clause if appropriate.
In order to ease the coexistence between SNMPv1 and SNMPv2, object groups defined in an SNMPv1 MIB module may be referenced by the INCLUDES clause of an invocation of the AGENT-CAPABILITIES macro: upon encountering a reference to an OBJECT IDENTIFIER subtree defined in an SNMPv1 MIB module, all leaf objects which are subordinate to the subtree and have a STATUS clause value of mandatory are deemed to be INCLUDEd. (Note that this method is ambiguous when different revisions of a SNMPv1 MIB have different sets of mandatory objects under the same subtree; in such cases, the only solution is to rewrite the MIB using the SNMPv2 SMI in order to define the object groups unambiguously.)
The SNMPv2 documents which deal with protocol operations are:
Protocol Operations for SNMPv2 , which defines the syntax and semantics of the operations conveyed by the protocol; and,
Transport Mappings for SNMPv2 , which defines how the protocol operations are carried over different transport services.
The following section considers two areas: the proxy behavior between a SNMPv2 entity and a SNMPv1 agent; and, the behavior of "bi-lingual" protocol entities acting in a manager role.
To achieve coexistence at the protocol-level, a proxy mechanism may be used. A SNMPv2 entity acting in an agent role may be implemented and configured to act in the role of a proxy agent.
When converting requests from a SNMPv2 entity acting in a manager role into requests sent to a SNMPv1 entity acting in an agent role:
(1) If a GetRequest-PDU, GetNextRequest-PDU, or SetRequest-PDU is received, then it is passed unaltered by the proxy agent.
(2) If a GetBulkRequest-PDU is received, the proxy agent sets the non- repeaters and max-repetitions fields to zero, and sets the tag of the PDU to GetNextRequest-PDU.
When converting responses received from a SNMPv1 entity acting in an agent role into responses sent to a SNMPv2 entity acting in a manager role:
If a GetResponse-PDU is received with an error-status field having a value of `tooBig', the proxy agent will remove the contents of the variable-bindings field before propagating the response. Note that even though a SNMPv2 entity will never generate a `tooBig' in response to a GetBulkRequest-PDU, the proxy agent must propagate such a response.
To achieve coexistence at the protocol-level, a protocol entity acting in a manager role might support both SNMPv1 and SNMPv2. When a management application needs to contact a protocol entity acting in an agent role, the entity acting in a manager role consults a local database to select the correct management protocol to use.
In order to provide transparency to management applications, the entity acting in a manager role must map operations as if it were acting as a proxy agent.
Security issues are not discussed in this memo.
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134-1706
Phone: +1 408 526 5260
This document is the result of significant work by the four major contributors:
Jeffrey D. Case (SNMP Research, firstname.lastname@example.org)
Keith McCloghrie (Cisco Systems, email@example.com)
Marshall T. Rose (Dover Beach Consulting, firstname.lastname@example.org) Steven Waldbusser (International Network Services, email@example.com)
In addition, the contributions of the SNMPv2 Working Group are acknowledged. In particular, a special thanks is extended for the contributions of:
Alexander I. Alten (Novell)
Dave Arneson (Cabletron)
Uri Blumenthal (IBM)
Doug Book (Chipcom)
Kim Curran (Bell-Northern Research)
Jim Galvin (Trusted Information Systems)
Maria Greene (Ascom Timeplex)
Iain Hanson (Digital)
Dave Harrington (Cabletron)
Nguyen Hien (IBM)
Jeff Johnson (Cisco Systems)
Michael Kornegay (Object Quest)
Deirdre Kostick (AT&T Bell Labs)
David Levi (SNMP Research)
Daniel Mahoney (Cabletron)
Bob Natale (ACE*COMM)
Brian O'Keefe (Hewlett Packard)
Andrew Pearson (SNMP Research)
Dave Perkins (Peer Networks)
Randy Presuhn (Peer Networks)
Aleksey Romanov (Quality Quorum)
Shawn Routhier (Epilogue)
Jon Saperia (BGS Systems)
Bob Stewart (Cisco Systems, firstname.lastname@example.org), chair
Kaj Tesink (Bellcore)
Glenn Waters (Bell-Northern Research)
Bert Wijnen (IBM)