Coexistence between version 1 and version 2 of the Internet-standard Network Management Framework
obsoleted by
- rfc-1908 — Coexistence between Version 1 and Version 2 of the Internet-standard Network Management Framework
Extracted elements (24)
Creation and deletion of conceptual rows is inconsistent using the SNMPv1 framework. The SNMPv2 framework corrects this. For MIB modules under early review that contain conceptual tables allowing row creation/deletion, it may be worthwhile to deprecate the old objects and replace them with SNMPv2-style objects.
The SNMPv2 approach towards describing collections of managed objects is nearly a proper superset of SNMPv1. Both use ASN.1 as the basis for a formal descriptive notation, and SNMPv2 largely codifies existing practice based on extensive experience with the current framework.
A SNMPv2 manager may receive SNMPv1-specific error-status values (noSuchName, badValue, readOnly) via a proxy agent. The SNMPv2 manager must be capable of correctly interpreting these values even though a native SNMPv2 entity would never generate them.
For enumerated INTEGER objects where a named-number enumeration has the value zero, the STATUS of that object must be changed to 'obsolete', as zero-valued enumerations are an error in the SNMPv1 MIB convention.
Hyphen characters must be removed from descriptor names and named-number enumeration labels when converting SNMPv1 MIB modules to SNMPv2, as SNMPv2 does not permit hyphens in these identifiers.
MIB modules defined using the SNMPv1 framework may continue to be used with the SNMPv2 protocol. However, for MIB modules to conform to the SNMPv2 framework, a defined set of changes is required.
A bi-lingual manager entity that supports both SNMPv1 and SNMPv2 must consult a local database to select the correct protocol when contacting an agent, and must map operations as if acting as a proxy agent to provide transparency to management applications.
Any object lacking a DESCRIPTION clause must have one added, and any conceptual row object without an INDEX clause must have either an INDEX or AUGMENTS clause defined.
For all objects, STATUS clause value 'mandatory' must be replaced with 'current', and STATUS value 'optional' must be replaced with 'obsolete'.
For all objects, the ACCESS clause must be replaced by a MAX-ACCESS clause. Objects whose instances can be explicitly created by a protocol set operation must have MAX-ACCESS of 'read-create'. Write-only ACCESS becomes 'read-write' with a note in the DESCRIPTION clause.
For any columnar object used solely for instance identification in a conceptual row, the MAX-ACCESS clause must be set to 'not-accessible', unless all columnar objects are used for identification, in which case at least one must have a value other than 'not-accessible'.
For any object with an INDEX clause that references an object with a syntax of NetworkAddress, the STATUS clause of both objects must be changed to 'obsolete'.
For any object with an unrestricted integer-valued SYNTAX clause, the value must be changed to Integer32. Counter SYNTAX must be changed to Counter32, and Gauge SYNTAX must be changed to Gauge32.
For SNMPv1 Trap-PDU conversion, if the generic-trap field is 'enterpriseSpecific', snmpTrapOID.0 is the concatenation of the enterprise field with sub-identifiers '0' and the specific-trap value; otherwise the corresponding well-known trap OID from the SNMPv2 MIB is used.
For standard information modules, a corresponding invocation of the MODULE-COMPLIANCE macro must be included within the module (or a companion module), and any commentary text relating to compliance must be removed.
If a GetResponse-PDU is received from a SNMPv1 agent with error-status 'tooBig', the proxy agent must remove the contents of the variable-bindings field before propagating the response to the SNMPv2 manager.
When a proxy agent receives a GetBulkRequest-PDU destined for a SNMPv1 agent, it must set the non-repeaters and max-repetitions fields to zero and change the PDU tag to GetNextRequest-PDU. GetRequest-PDU, GetNextRequest-PDU, and SetRequest-PDU are passed unaltered.
When a proxy agent receives a GetResponse-PDU from a SNMPv1 agent, it must pass it unaltered to the SNMPv2 manager, including any SNMPv1-only error-status values (noSuchName, badValue, readOnly) which must not be changed by the proxy.
When converting a MIB module to SNMPv2, the IMPORTS statement must reference SNMPv2-SMI instead of RFC1155-SMI and RFC-1212, and the MODULE-IDENTITY macro must be invoked immediately after any IMPORTS or EXPORTS statement.
When converting capabilities statements to SNMPv2, the macro name must change from MODULE-CONFORMANCE to AGENT-CAPABILITIES, a STATUS clause must be added, and occurrences of CREATION-REQUIRES must be reviewed for the slight semantic change.
When converting trap definitions to SNMPv2, each TRAP-TYPE macro must be replaced with a NOTIFICATION-TYPE macro. The ENTERPRISES clause must be removed, VARIABLES must be renamed to OBJECTS, a STATUS clause must be added, and the value must be an OBJECT IDENTIFIER rather than an INTEGER.
A proxy agent mechanism allows a SNMPv2 entity acting in an agent role to be implemented and configured to forward requests to and from SNMPv1 agents, achieving protocol-level coexistence between SNMPv1 and SNMPv2.
When a proxy agent receives a SNMPv1 Trap-PDU, it maps it into a SNMPv2-Trap-PDU by prepending two new variable bindings: sysUpTime.0 (from the timestamp field) and snmpTrapOID.0 (derived from the generic-trap and enterprise fields), then appending snmpTrapEnterpriseOID.0.
Security issues are not discussed in this memo.