Structure of Management Information for version 2 of the Simple Network Management Protocol (SNMPv2)
obsoleted by
- rfc-1902 — Structure of Management Information for Version 2 of the Simple Network Management Protocol (SNMPv2)
Extracted elements (30)
Conceptual rows should contain no more than approximately 20 columnar objects, and should be organized along functional or usage lines (e.g., one row for statistics, another for parameters). This reflects the constraint that a single PDU must be able to carry a full row fetch, and avoids over-fragmentation that mimics OSI-style optional attributes.
Counter64 was introduced because high-speed interfaces can cause a Counter32 to wrap in under one hour, making it impossible to reliably track change rates. The SMI restricts Counter64 use to only these high-rate cases to avoid gratuitous 64-bit counters.
IpAddress and NsapAddress are tagged APPLICATION types 'for historical reasons'. The document notes that new MIB designs should represent network addresses using the TEXTUAL-CONVENTION macro rather than these tagged types, implying the tagging predates the cleaner textual convention mechanism.
When de-OSIfying MIB modules from other organizations, events should be mapped to NOTIFICATION-TYPE sparingly because SNMPv2 emphasizes trap-directed polling; few or no notifications typically need to be defined for any MIB module.
Although the SMI imposes no size limit on OCTET STRING, MIB designers should be aware that there may be implementation and interoperability limitations for sizes in excess of 255 octets.
The 'deprecated' STATUS value signals that an object or notification is obsolete but that implementors may wish to support it to foster interoperability with older implementations. It differs from 'obsolete', which carries no such recommendation.
All information modules must start with exactly one invocation of the MODULE-IDENTITY macro, which must appear immediately after any IMPORTS or EXPORTS statements.
An OBJECT IDENTIFIER instance may have at most 128 sub-identifiers, and each sub-identifier must not exceed 2^32-1 (4294967295). The final sub-identifier of any administratively assigned object name shall be positive; zero is reserved for future use.
For all descriptors in an information module, the descriptor shall be unique and mnemonic, and shall not exceed 64 characters in length. The set of descriptors defined in all 'standard' information modules shall be unique, and the hyphen is not allowed as a character in any descriptor within a standard module.
For newly-defined conceptual rows that allow creation and deletion of object instances, there should be exactly one columnar object with SYNTAX of RowStatus and MAX-ACCESS of read-create, termed the status column.
For notification definitions, only the REFERENCE clause may be added or updated without requiring a new OBJECT IDENTIFIER. Any other semantic change to a notification definition requires changing both its OID value and descriptor.
If any columnar object in a conceptual row has 'read-create' as its maximal access level, then no other columnar object in the same conceptual row may have 'read-write' as its maximal access. The ordering is: not-accessible < read-only < read-write < read-create.
The Counter64 type may be used only if the information being modeled would wrap in less than one hour if the Counter32 type were used instead. This applies specifically to 'standard' MIB modules.
The MAX-ACCESS clause for objects with a SYNTAX of Counter32 or Counter64 is always 'read-only'. Similarly, no DEFVAL clause is allowed for Counter32 or Counter64 objects because counters have no defined initial value.
The Opaque type shall not be used for newly-defined object types; it is provided solely for backward compatibility. Standard MIB modules must not define any object with a SYNTAX clause value of Opaque.
When extending an information module, if any non-editorial change is made to an object assignment or object definition beyond the explicitly permitted revisions (adding enumerations, deprecating status, adding DEFVAL/REFERENCE/UNITS, augmenting rows), then the OBJECT IDENTIFIER value and descriptor must also be changed.
The AUGMENTS clause is an alternative to the INDEX clause for conceptual row extensions. A row using AUGMENTS inherits the INDEX of the base conceptual row, and creation of a base row implies creation of all its augmentations.
The INDEX clause specifies how instance-identifiers for columnar objects are formed: integer-valued (1 sub-identifier), fixed/IMPLIED string (n sub-identifiers), variable-length string (n+1), OID-valued (n+1), IpAddress (4), and NsapAddress (n). The IMPLIED keyword may appear at most once, on the rightmost variable-length object.
The MODULE-IDENTITY macro provides contact and revision history for an information module, requiring LAST-UPDATED, ORGANIZATION, CONTACT-INFO, and DESCRIPTION clauses. Its value is an OBJECT IDENTIFIER that can be used to authoritatively reference the information module.
The OBJECT-IDENTITY macro defines information about an OBJECT IDENTIFIER assignment, requiring STATUS (current or obsolete) and DESCRIPTION clauses. Its expansion happens conceptually during implementation, not at run-time.
The OID naming hierarchy under the Internet root (1.3.6.1) allocates: mgmt(2) for standard objects, experimental(3) for IETF working group objects, private(4)/enterprises(1) for unilateral definitions, security(5), and snmpV2(6) containing snmpDomains, snmpProxys, and snmpModules.
The SMI is divided into three parts: module definitions (MODULE-IDENTITY macro), object definitions (OBJECT-TYPE macro), and notification definitions (NOTIFICATION-TYPE macro). These three macros form the complete vocabulary for writing SNMPv2 MIB modules in a subset of ASN.1.
Section 14 is titled 'Security Considerations' and appears on page 54 of the RFC. The SNMPv2 SMI document defers detailed security treatment to the SNMPv2 administrative framework; the SMI itself defines structure but does not specify authentication or authorization mechanisms.
Counter32 is APPLICATION 1, an IMPLICIT INTEGER ranging 0..4294967295, which monotonically increases until it wraps at 2^32-1 back to zero. It has no defined initial value; MAX-ACCESS must be read-only and no DEFVAL clause is permitted.
Counter64 is APPLICATION 6, an IMPLICIT INTEGER ranging 0..18446744073709551615, with the same wrap-and-restart semantics as Counter32 but for a 64-bit range. MAX-ACCESS must be read-only and no DEFVAL clause is permitted.
Gauge32 is APPLICATION 2, an IMPLICIT INTEGER ranging 0..4294967295, representing a value that may increase or decrease but is clamped at the maximum. Unlike Counter32, it does not wrap.
IpAddress is encoded as APPLICATION 0, an IMPLICIT OCTET STRING of SIZE 4, in network byte-order. It is a tagged type for historical reasons; new MIB designs should use TEXTUAL-CONVENTION instead.
NsapAddress is APPLICATION 5, an IMPLICIT OCTET STRING of SIZE (1 | 4..21). The first octet contains the NSAP length (0..20); a single zero-valued octet encodes the 'default NSAP'. It is a tagged type for historical reasons.
Opaque is APPLICATION 4, an IMPLICIT OCTET STRING encoding arbitrary ASN.1 values via BER double-wrapping. A conforming implementation need only accept and recognize opaquely-encoded data; it need not unwrap or interpret the contents.
TimeTicks is APPLICATION 3, an IMPLICIT INTEGER ranging 0..4294967295, representing hundredths of seconds modulo 2^32 between two epochs whose definitions must be provided in the object's DESCRIPTION clause.