Structure and identification of management information for TCP/IP-based internets
obsoleted by
- rfc-1155 — Structure and identification of management information for TCP/IP-based internets
Extracted elements (28)
MIB versioning preserves the 'tail' of object names (the portion after { mgmt version-number }) across versions, so multi-version implementations can share a common tail-space rather than maintaining entirely separate name trees. This design makes simultaneous support for multiple MIB versions vastly simpler.
New versions of the MIB may augment (but not remove or semantically alter) list object types by appending non-aggregate types, and may declare old types obsolete without deleting their names. This ensures backward-compatible extensibility.
Simplicity and extensibility were chosen as primary design goals because the authors believed the community's understanding of TCP/IP network management was incomplete. A minimal SMI imposes few constraints on future approaches while an extensible SMI maximizes the space of experiments.
The SMI deliberately restricts ASN.1 constructs (to four primitive types and specific SEQUENCE forms) solely for simplicity, not because the full ASN.1 generality is technically incorrect. Future editions may relax these restrictions as understanding matures.
A conforming implementation is only required to accept and recognize Opaque-encoded data; it need not unwrap and interpret the inner ASN.1 content. This makes Opaque useful for passing arbitrary data without requiring all agents to understand it.
SEQUENCE list definitions must not include DEFAULT or OPTIONAL clauses; all elements are always present. This constraint avoids ambiguity when mapping between management protocol versions and implementations.
The name returned by a management operation must be identical to the name requested; an agent may not substitute a renamed or versioned equivalent, preserving strict name-based referencing across protocol implementations.
Each management protocol must provide a mechanism for accessing simple (non-aggregate) object types and must specify whether aggregate object access is supported and which instances are returned when a type/instance pairing matches multiple instances.
Each OBJECT DESCRIPTOR for an Internet-standard MIB object type shall be a unique, mnemonic, printable string to enable a common human language for MIB discussion and simple table mappings in user interfaces.
If an enumerated INTEGER is used as an object type, a named-number with value 0 shall not be present in the enumeration list; use of value 0 in enumerations is prohibited.
New versions of the Internet-standard MIB may not change the semantics of any previously defined object without also changing the object's name. Object names (the tail following { mgmt version-number }) must remain stable across versions.
No object type in the Internet-Standard MIB shall use sub-identifier 0 in its OBJECT IDENTIFIER name; this value is reserved for future extensions.
Only ASN.1 primitive types INTEGER, OCTET STRING, OBJECT IDENTIFIER, and NULL are permitted in object type syntax definitions. The full generality of ASN.1 is explicitly excluded to ensure simplicity.
When a management agent returns an instance that is a superset of the expected object type (due to multi-version support), a manager should ignore additional information beyond the expected definition. However, control actions must fail if the instance syntax does not match the expected type.
When IpAddress is encoded using ASN.1 basic encoding rules, only the primitive encoding form shall be used (not the constructed form).
Aggregate types are formed using SEQUENCE (list) and SEQUENCE OF (table). A list is SEQUENCE of primitive types, always fully present (no DEFAULT or OPTIONAL). A table is SEQUENCE OF a list entry type.
Each managed object type is defined by five fields: OBJECT (textual OBJECT DESCRIPTOR plus OBJECT IDENTIFIER), Syntax (ASN.1 abstract data structure), Definition (textual semantics), Access (read-only, read-write, write-only, or not-accessible), and Status (mandatory, optional, or obsolete).
The OBJECT-TYPE ASN.1 macro formalizes object type definitions with SYNTAX (ObjectSyntax), ACCESS, and STATUS clauses, and a VALUE NOTATION binding to an ObjectName (OBJECT IDENTIFIER). This macro enables tool-based processing of MIB definitions.
The ObjectSyntax CHOICE encompasses SimpleSyntax (INTEGER, OCTET STRING, OBJECT IDENTIFIER, NULL) and ApplicationSyntax (NetworkAddress, Counter, Gauge, TimeTicks, Opaque). Application-wide types must resolve IMPLICITly to a primitive, list, table, or other application-wide type.
The experimental(3) subtree (1.3.6.1.3) is used for Internet experiments, with individual experimenter subtrees allocated by the Assigned Numbers authority. The private(4) subtree contains enterprises(1) (1.3.6.1.4.1) for vendor-specific MIB objects and product registration.
The Internet subtree of OBJECT IDENTIFIERs is rooted at { iso org(3) dod(6) 1 }, yielding prefix 1.3.6.1, administered by the IAB. Four child nodes are established: directory(1), mgmt(2), experimental(3), and private(4).
The mgmt(2) subtree (1.3.6.1.2) is reserved for IAB-approved MIB documents, with object identifiers assigned by the Assigned Numbers authority. The initial Internet-standard MIB is assigned { mgmt 1 } (1.3.6.1.2.1).
RFC 1065 contains no dedicated security considerations section, which was common for 1988 standards. Security for access to managed objects and authentication of management operations is deferred entirely to the companion protocol specification (SNMP, RFC 1067), not addressed by the SMI itself.
Counter is tagged APPLICATION 1, encoded as IMPLICIT INTEGER in the range 0..4294967295 (2^32-1). It monotonically increases until wrap-around to zero; it never decreases.
Gauge is tagged APPLICATION 2, encoded as IMPLICIT INTEGER in the range 0..4294967295. Unlike Counter, it may increase or decrease but latches at the maximum value rather than wrapping.
IpAddress is tagged APPLICATION 0 and encoded as an IMPLICIT OCTET STRING of exactly 4 octets in network byte order. Only the primitive encoding form of BER shall be used.
Opaque is tagged APPLICATION 4, encoded as an IMPLICIT OCTET STRING that double-wraps an arbitrary ASN.1 value encoded using BER. Non-ASN.1 encodings are also permitted via the ASN.1 EXTERNAL type inside the wrapper.
TimeTicks is tagged APPLICATION 3, encoded as IMPLICIT INTEGER counting hundredths of a second since an epoch defined per object type. The reference epoch must be stated in each object type's definition.