Concise MIB definitions
also
- std-16
Extracted elements (23)
Actions from OSI MIBs are modeled in SNMP as read-write INTEGER objects: writing a particular distinguished value triggers the action, and reading returns a different distinguished value indicating idle state. This avoids introducing a separate action PDU type.
As a rule of thumb, a conceptual row should contain no more than approximately 20 objects so that all columnar objects fit in a single PDU. Objects should be grouped by access pattern (statistics vs. parameters, common vs. rare) rather than splitting a managed object class across many tables to emulate OSI optional-object flexibility.
Groups within a MIB module are 'units of conformance': all objects in a group are mandatory and implementations must implement either an entire group or none of it. This avoids the per-object optionality complexity common in OSI MIBs.
RFC 1212 was produced because experience with the SMI experimental subtree showed that MIB descriptions contained redundant information: a textual OBJECT section and an ASN.1 OBJECT-TYPE macro section covered the same ground. The concise format merges both into a single OBJECT-TYPE macro invocation, reducing editing errors and improving clarity.
The tabular structure of MIB conceptual tables is intentionally not a matter of protocol. A Get-Next-PDU on the last columnar object of a row returns the next column of the first row (or the first object after the table) rather than an error, increasing information density per PDU exchange. Row boundaries exist only at the management-application layer.
The REFERENCE clause provides a textual cross-reference to an equivalent object defined in another MIB module, and is particularly useful when de-osifying MIBs produced by organizations such as the IEEE, enabling traceability back to the source definition.
When de-osifying OSI or IEEE MIBs for SNMP use: BOOLEAN maps to INTEGER (true(1)/false(2)); ENUMERATED maps to INTEGER; BIT STRING with ≤32 bits maps to an INTEGER sum; BIT STRING with >32 bits maps to OCTET STRING with bits numbered left-to-right and trailing bits reserved for future use.
When placing an experimental MIB into Internet-standard space, optional objects must either be removed or placed in an optional group where all members must be implemented together. The document recommends defining a core MIB first with only essential objects and adding others later based on operational experience.
If an anonymous 'indextype' value (e.g., bare INTEGER rather than a named object like ifIndex) appears in the INDEX clause, a DESCRIPTION clause must be present explaining the semantics of that indextype.
If the MIB module does not contain a textual description of the object type elsewhere, the DESCRIPTION clause must be present. The clause must provide all semantic definitions necessary for implementation; its entire value must be enclosed in double quotation marks.
Management stations must be prepared to receive tabular information from agents that corresponds to entries not currently in use (invalidated rows). Proper interpretation requires examination of the relevant status columnar object, since agent removal of invalidated entries is implementation-specific.
The ACCESS clause must be present and defines the minimum level of support required for that object type. Valid values are read-only, read-write, write-only, and not-accessible. Implementations may locally support additional access modes beyond the declared minimum.
The INDEX clause may appear only if the object type corresponds to a conceptual row. If the MIB module contains no other textual description of how instance identification is derived for columnar objects, the INDEX clause must be present.
The STATUS clause must be present and defines the implementation support required. Valid values are mandatory, optional, obsolete, and deprecated.
The SYNTAX clause must be present in every OBJECT-TYPE invocation. It defines the abstract data structure for the object type using ASN.1, restricted to the constructs permitted by the SMI (ObjectSyntax).
The value of the DEFVAL clause must correspond to the SYNTAX clause for the object. If no acceptable default value exists for any columnar object in a row where instance creation is allowed, the INDEX objects must have ACCESS read-write so the management station can supply all required values.
Row addition via SNMP Set-PDU permits three fully conformant agent behaviors: (1) reject with noSuchName, (2) create new instances with supplied values returning badValue on type/value mismatch, or (3) create supplied instances and additionally create supplemental instances at agent discretion to complete a conceptual row.
Row deletion is modeled by defining an integer-valued columnar object per conceptual row; a management station writes the value 'invalid' (conventionally 2) to invalidate the row. Whether the agent physically removes the entry from the table is implementation-specific.
The DEFVAL clause specifies an acceptable default value the agent may use when creating a columnar object instance not supplied in the Set-PDU operands. This clause enables the third row-creation paradigm where the agent fills in unspecified columns.
The IndexSyntax type constrains valid INDEX components to five choices: INTEGER (0..MAX), OCTET STRING, OBJECT IDENTIFIER, NetworkAddress, and IpAddress. Only these types may appear as index objects.
The OBJECT-TYPE macro is an ASN.1 macro extension defining managed objects. Its TYPE NOTATION consists of mandatory SYNTAX, ACCESS, and STATUS clauses, plus optional DESCRIPTION, REFERENCE, INDEX, and DEFVAL clauses. The VALUE NOTATION yields an ObjectName (object identifier).
Security issues are not discussed in RFC 1212. The document focuses exclusively on the format for producing MIB modules and defers security considerations to other documents in the SNMP framework.
Instance identifiers for INDEX objects are encoded as OID sub-identifiers according to syntax: integer-valued uses one sub-identifier; fixed-length string uses n sub-identifiers; variable-length string uses n+1 (length prefix then octets); OBJECT IDENTIFIER uses n+1 (count prefix then sub-identifiers); IpAddress uses 4 sub-identifiers. For non-columnar objects without INDEX, a sub-identifier of zero is appended.