Structure of Management Information Version 2 (SMIv2)
obsoletes
- rfc-1902 — Structure of Management Information for Version 2 of the Simple Network Management Protocol (SNMPv2)
also
- std-58
Extracted elements (33)
Counter objects have no defined initial value; a single counter reading has no information content in general. Discontinuities at re-initialization or row creation must be tracked with a companion timestamp object (e.g., TimeStamp or DateAndTime).
IpAddress is defined as a tagged type ([APPLICATION 0]) for historical reasons. New MIB definitions should represent network addresses using the TEXTUAL-CONVENTION macro rather than IpAddress directly.
Unsigned32 shares the APPLICATION 2 tag with Gauge32, making them wire-indistinguishable. The distinction is purely semantic: Gauge32 clamps at its bounds, while Unsigned32 is a plain non-negative integer with no clamping behavior.
When adding new enumerations to a BITS object in an updated module, starting the new enumerations at the next multiple of eight bits avoids ambiguity between an old implementation that does not assert the new bits and a new one that explicitly clears them.
Although OCTET STRING allows up to 65535 octets, MIB designers should note that implementations may have interoperability limitations for sizes exceeding 255 octets. Similarly, BITS values exceeding 128 bits may encounter implementation constraints.
Hyphens are not permitted in SMIv2 ASN.1 identifiers or descriptors, except in information modules that were originally written to conform to SMIv1 and subsequently converted, since SMIv1 did allow hyphens.
Additional ASN.1 macros must not be defined in SMIv2 information modules, and SMIv1 macros must not be used in SMIv2 information modules. The ASN.1 EXPORTS statement is also not allowed.
All descriptors within an information module shall be unique, mnemonic, and shall not exceed 64 characters. The set of descriptors across all standard information modules shall also be unique. Descriptors must begin with a lower-case letter.
An OBJECT IDENTIFIER value may have at most 128 sub-identifiers, and each sub-identifier must not exceed 2^32-1 (4294967295 decimal). All OBJECT IDENTIFIER values must have at least two sub-identifiers.
Every information module must contain exactly one invocation of the MODULE-IDENTITY macro, which must appear immediately after any IMPORTS statements. It provides contact information and revision history to distinguish versions.
For newly-defined conceptual rows that allow creation or deletion of object instances, there should be one columnar object with a SYNTAX of RowStatus and a MAX-ACCESS of read-create, termed the status column.
If the semantics of any previously defined object change (any non-editorial change not explicitly permitted), the OBJECT IDENTIFIER value associated with that object must also be changed. Module names must not be changed when revising an information module.
In standard MIB modules, Counter64 may only be used if the information being modeled would wrap in less than one hour using Counter32 instead.
Objects with Counter32 or Counter64 syntax must not be specified in an INDEX clause, since a single Counter value has no information content. If a BITS object is used in an INDEX clause, it is treated as a variable-length string.
Once an OBJECT IDENTIFIER is registered, its associated semantics are not allowed to change and the OID cannot be used for any other registration. Obsolete definitions must not be removed from MIB modules since their OIDs must never be re-assigned.
The final sub-identifier of any administratively assigned object name shall be positive; a zero-valued final sub-identifier is reserved for future use. For conceptual tables, the row object is assigned sub-identifier 1 beneath the table.
The MAX-ACCESS clause for objects with Counter32 or Counter64 syntax must be either 'read-only' or 'accessible-for-notify'. A DEFVAL clause is not allowed for Counter32 or Counter64 objects.
The next-to-last sub-identifier in the name of any newly-defined notification must have the value zero, to achieve compatibility with SNMPv1 traps and multi-lingual proxy forwarding applications.
The Opaque type shall not be used for newly-defined object types; it is provided solely for backward-compatibility. Standard MIB modules must not contain any object with a SYNTAX clause value of Opaque.
Conceptual tables use SYNTAX 'SEQUENCE OF <EntryType>' with MAX-ACCESS not-accessible. The row object immediately beneath the table is assigned sub-identifier 1 and carries the INDEX or AUGMENTS clause defining instance identification.
The AUGMENTS clause is an alternative to INDEX for conceptual rows with a strict one-to-one correspondence to a base row. An augmentation row cannot itself be augmented, and creation of the base row implies creation of all its augmentations.
The BITS construct represents an enumeration of named bits assigned non-negative values starting at zero. Only those named bits so enumerated may appear in a value; new enumerations may be added when extending a module.
The INDEX clause encodes instance sub-identifiers as follows: integers map to one sub-id; fixed or IMPLIED variable strings encode n octets as n sub-ids; non-IMPLIED variable strings prepend a length sub-id; IpAddress uses 4 sub-ids; OBJECT IDENTIFIERs similarly use n or n+1 sub-ids.
The Internet SNMP naming hierarchy roots at internet OBJECT IDENTIFIER ::= { iso 3 6 1 } (prefix 1.3.6.1), with sub-trees mgmt(2), mib-2(2.1), experimental(3), private(4), enterprises(4.1), and snmpV2(6) for SNMP-specific assignments.
The OBJECT-TYPE macro requires SYNTAX, MAX-ACCESS, STATUS, and DESCRIPTION clauses. MAX-ACCESS values in ascending order are: not-accessible, accessible-for-notify, read-only, read-write, read-create.
RFC 2578 defines the SNMPv2-SMI module establishing the canonical OID tree for SNMP: internet (1.3.6.1), mgmt/mib-2 (1.3.6.1.2/2.1), experimental (1.3.6.1.3), enterprises (1.3.6.1.4.1), and snmpModules (1.3.6.1.6.3) along with zeroDotZero (0.0) as a null identifier.
SMIv2 defines a language for writing and reading descriptions of management information. The language itself has no security impact on the Internet.
Counter32 is encoded as [APPLICATION 1] IMPLICIT INTEGER (0..4294967295). It monotonically increases until reaching 2^32-1, then wraps to zero.
Counter64 encodes as [APPLICATION 6] IMPLICIT INTEGER (0..18446744073709551615), a 64-bit counter wrapping from 2^64-1 to zero.
ExtUTCTime is an OCTET STRING of SIZE(11|13) encoding timestamps as YYMMDDHHMMZ (years 1900–1999 only) or YYYYMMDDHHMMZ (any year), always suffixed with 'Z' to denote GMT. Years after 1999 must use the four-digit format.
Gauge32 and Unsigned32 both encode as [APPLICATION 2] IMPLICIT INTEGER (0..4294967295), making them wire-indistinguishable. TimeTicks uses [APPLICATION 3] IMPLICIT INTEGER (0..4294967295) representing hundredths of seconds between two epochs.
IpAddress is encoded as [APPLICATION 0] IMPLICIT OCTET STRING (SIZE(4)) in network byte-order, representing a 32-bit IPv4 address.
Opaque encodes as [APPLICATION 4] IMPLICIT OCTET STRING, double-wrapping arbitrary ASN.1 BER-encoded data inside an OCTET STRING.