Structure of Management Information for Version 2 of the Simple Network Management Protocol (SNMPv2)
obsoleted by
- rfc-2578 — Structure of Management Information Version 2 (SMIv2)
obsoletes
- rfc-1442 — Structure of Management Information for version 2 of the Simple Network Management Protocol (SNMPv2)
Extracted elements (31)
Conceptual rows should contain no more than approximately 20 columnar objects, grouped along functional lines (e.g., statistics versus configuration parameters, or commonly accessed versus rarely accessed), so that typical management operations on a row fit within a single PDU. Splitting rows into many tables solely to achieve optionality is explicitly discouraged.
Counters have no defined initial value by design: a single sampled value carries no information content; meaningful data requires a delta between two samples at known times. This is why Counter32/Counter64 objects prohibit DEFVAL clauses and require companion TimeStamp objects when discontinuities can occur outside re-initialization.
IpAddress is defined as APPLICATION 0 rather than a plain OCTET STRING because the tagged type was inherited from SNMPv1 for historical compatibility. New address types should use textual conventions instead, since IpAddress is permanently limited to 32-bit IPv4 and cannot represent IPv6 or other address families.
All descriptors within an information module must be unique, must not exceed 64 characters, must begin with a lower-case letter, and must consist only of letters or digits — hyphens are explicitly prohibited to avoid ambiguity with the minus sign in programming languages. The set of descriptors across all standard information modules must also be globally unique.
Counter64 may appear in standard MIB modules only if the modeled information would wrap in less than one hour were Counter32 used instead. This restricts Counter64 to high-rate quantities such as high-speed interface octet counts.
Every information module must contain exactly one MODULE-IDENTITY invocation with mandatory LAST-UPDATED, ORGANIZATION, CONTACT-INFO, and DESCRIPTION clauses. This invocation must appear immediately after any IMPORTS statements. The ASN.1 EXPORTS statement is not allowed; all items are automatically exported.
Every OBJECT-TYPE must include a MAX-ACCESS clause. For objects with SYNTAX Counter32 or Counter64, MAX-ACCESS must be either 'read-only' or 'accessible-for-notify'. A DEFVAL clause must not be present for Counter32 or Counter64 objects.
If any non-editorial change is made to a managed object definition beyond the specific allowed revisions (adding enumerations, deprecating status, adding DEFVAL/REFERENCE/UNITS, augmenting rows, or adding new objects), the OBJECT IDENTIFIER value and descriptor for that object must both be changed.
Newly-defined conceptual rows that allow instance creation or deletion should include exactly one columnar object with SYNTAX RowStatus and MAX-ACCESS read-create as the status column. If any columnar object has MAX-ACCESS read-create, no other columnar object of the same row may have MAX-ACCESS read-write.
OBJECT IDENTIFIER values must contain at most 128 sub-identifiers, and each sub-identifier must not exceed 2^32-1 (4294967295). All OBJECT IDENTIFIER values must have at least two sub-identifiers, and the final sub-identifier of any administratively assigned object name must be positive (zero is reserved).
Standard MIB modules must not define any object with SYNTAX Opaque. The Opaque type must not be used for any newly-defined object types; it exists solely to preserve backward compatibility with existing SNMPv1 MIBs.
Syntax refinement via the SYNTAX clause must not change the object's primitive or application type. Permitted refinements are: narrowing integer or size ranges, removing named-value enumerations (INTEGER or BITS), and reducing OCTET STRING character repertoire. No other refinements are allowed.
The next-to-last sub-identifier in the OBJECT IDENTIFIER name of any newly-defined notification must have the value zero. This maintains compatibility with procedures employed by SNMPv1/v2 proxy agents.
When Counter32 or Counter64 discontinuities can occur at times other than management-system re-initialization (e.g., at object-instance creation), a companion object with SYNTAX TimeStamp should be defined to record the time of the last discontinuity.
Conceptual tables are defined using OBJECT-TYPE with SYNTAX 'SEQUENCE OF EntryType' for the table object and 'EntryType' for the row object; both have MAX-ACCESS 'not-accessible'. Each columnar object is accessed individually via instance identifiers formed from the INDEX or AUGMENTS clause of the row.
The AUGMENTS clause is an alternative to INDEX for conceptual rows with a strict one-to-one correspondence to a base row. A row using AUGMENTS inherits the base row's INDEX, cannot itself be augmented, and its column instances exist co-extensively with the base row's instances; creating a base row implicitly creates all augmenting rows.
The MODULE-IDENTITY macro identifies an information module, providing LAST-UPDATED, ORGANIZATION, CONTACT-INFO, DESCRIPTION, and zero or more REVISION/DESCRIPTION pairs in reverse chronological order. It must appear exactly once per module, immediately after any IMPORTS statements; its value is an OBJECT IDENTIFIER that authoritatively identifies the module.
The NOTIFICATION-TYPE macro defines the information carried in an unsolicited SNMPv2-Trap-PDU or InformRequest-PDU, listing an ordered sequence of MIB objects via an optional OBJECTS clause plus mandatory STATUS and DESCRIPTION. No OBJECTS-listed object may have MAX-ACCESS of 'not-accessible'.
The OBJECT-IDENTITY macro documents administrative OBJECT IDENTIFIER assignments, particularly type identification values. Its clauses include mandatory STATUS (current, deprecated, or obsolete) and DESCRIPTION, plus optional REFERENCE; its value is an OBJECT IDENTIFIER.
The OBJECT-TYPE macro defines a managed object, specifying SYNTAX, optional UNITS, MAX-ACCESS, STATUS, DESCRIPTION, and optionally REFERENCE, INDEX or AUGMENTS, and DEFVAL clauses. Its value is an administratively assigned OBJECT IDENTIFIER; leaf non-columnar instances are identified by appending a zero sub-identifier.
The SNMPv2 OID naming hierarchy roots at internet (1.3.6.1), with sub-trees: mgmt(2)/mib-2(2.1) for standard objects, experimental(3) for IETF working-group objects, private(4)/enterprises(4.1) for vendor objects, security(5), and snmpV2(6) with arcs for snmpDomains, snmpProxys, and snmpModules.
RFC 1902 formally defines and registers the SNMPv2-SMI OID subtree: internet (1.3.6.1), mgmt (1.3.6.1.2), mib-2 (1.3.6.1.2.1), transmission (1.3.6.1.2.1.10), experimental (1.3.6.1.3), private (1.3.6.1.4), enterprises (1.3.6.1.4.1), security (1.3.6.1.5), snmpV2 (1.3.6.1.6), snmpDomains (1.3.6.1.6.1), snmpProxys (1.3.6.1.6.2), and snmpModules (1.3.6.1.6.3).
RFC 1902 explicitly states that security issues are not discussed in this memo. The SMI defines structure and syntax for management information but defers authentication, authorization, access control, and privacy to the SNMPv2 administrative framework defined in companion documents.
Counter32 is [APPLICATION 1] IMPLICIT INTEGER in [0..4294967295] and wraps to zero after reaching its maximum. Counter64 is [APPLICATION 6] IMPLICIT INTEGER in [0..18446744073709551615] with identical wrap-around behavior. Neither type has a defined initial value, so a single sample carries no information.
Gauge32 is [APPLICATION 2] IMPLICIT INTEGER in [0..4294967295]; it may increase or decrease but clamps at its maximum rather than wrapping. Unsigned32 is defined identically (APPLICATION 2) and is indistinguishable from Gauge32 on the wire.
INDEX clause instance encoding: integer-valued indexes use one sub-identifier; fixed-length or IMPLIED variable-length strings use n sub-identifiers (one per octet); variable-length strings without IMPLIED use n+1 (length then octets); OIDs without IMPLIED use n+1 (count then sub-ids); IpAddress uses 4 sub-identifiers. IMPLIED may only appear on the last index component and not on potentially zero-length strings.
Integer32 is ASN.1 [UNIVERSAL 2] IMPLICIT INTEGER in range -2147483648 to 2147483647; it is indistinguishable from the base INTEGER type. INTEGER may additionally represent named-number enumerations, in which case only the enumerated values are valid.
IpAddress is [APPLICATION 0] IMPLICIT OCTET STRING of exactly 4 octets in network byte order, representing a 32-bit IPv4 address. It is a tagged type for historical reasons; new address representations should use textual conventions rather than this type.
Opaque is [APPLICATION 4] IMPLICIT OCTET STRING carrying arbitrary ASN.1 BER-encoded data double-wrapped as an OCTET STRING. A conforming implementation need only accept and recognize opaquely-encoded data; it need not unwrap or interpret the inner encoding.
The BITS construct encodes a named-bit enumeration as an OCTET STRING; bit positions are assigned contiguous non-negative values starting at zero, and only enumerated bits may appear in a value. MIB designers should avoid exceeding 128 bits due to implementation and interoperability limitations.
TimeTicks is [APPLICATION 3] IMPLICIT INTEGER in [0..4294967295], representing time in hundredths of a second modulo 2^32 between two epochs defined in the object's DESCRIPTION. TimeTicks may not be sub-typed.