Structure and identification of management information for TCP/IP-based internets
obsoletes
- rfc-1065 — Structure and identification of management information for TCP/IP-based internets
also
- std-16
Extracted elements (30)
MIB versioning rules keep the 'tail' of object OIDs (the portion following { mgmt version-number }) constant across versions so that implementations supporting multiple versions can be vastly simplified by sharing a common tail-space.
The Opaque type enables passing arbitrary ASN.1 syntax without requiring implementations to interpret it; conforming implementations need only accept and recognize opaquely-encoded data, supporting extensibility without mandatory decoding complexity.
The SMI deliberately restricts ASN.1 constructs to INTEGER, OCTET STRING, OBJECT IDENTIFIER, NULL, and limited SEQUENCE forms solely for simplicity, not because more general ASN.1 constructs are technically unavailable.
The SMI's primary goals are simplicity and extensibility, motivated by the authors' belief that understanding of TCP/IP management was incomplete. A simple SMI minimizes constraints on future approaches; an extensible SMI maximizes experimental options.
Following the robustness principle, if a management agent returns an instance corresponding to a superset of the expected object type, the manager should ignore additional information beyond the expected definition.
If an object instance returned by an agent does not have the same syntax as its expected object type, control actions based on that instance must fail. The name of a returned object must be identical to the name requested.
Each management protocol adhering to the SMI must define the mechanism by which object instances are referenced; this mechanism is protocol-specific and is not defined in the SMI itself.
Each management protocol must provide a mechanism for accessing simple (non-aggregate) object types and must specify whether it supports access to aggregate object types.
Each OBJECT DESCRIPTOR in the Internet-Standard MIB shall be a unique, mnemonic, printable string to promote a common human language for discussing the MIB and facilitate user-interface table mappings.
Every Internet-standard MIB document obsoletes all previous versions. New versions may declare old object types obsolete (but not delete their names), augment list definitions by appending non-aggregate types, or define new object types.
If an enumerated INTEGER is listed as an object type, a named-number having the value 0 shall not be present in the list of enumerations. Use of the value 0 is prohibited.
New versions of the Internet-standard MIB may not change the semantics of any previously defined object without changing the name of that object.
No object type in the Internet-Standard MIB shall use a sub-identifier value of 0 in its name; this value is reserved for future extensions.
Only the ASN.1 primitive types INTEGER, OCTET STRING, OBJECT IDENTIFIER, and NULL are permitted as syntax for object types. This restriction is made solely for simplicity.
SEQUENCE constructor types used for lists must not include DEFAULT or OPTIONAL clauses; all component types are always present.
An object type definition consists of five fields: OBJECT (textual descriptor plus OID), Syntax (ASN.1 type resolving to ObjectSyntax), Definition (semantic description), Access (read-only, read-write, write-only, not-accessible), and Status (mandatory, optional, obsolete).
Counter (APPLICATION 1) is a non-negative integer that monotonically increases until it reaches 2^32-1 (4294967295), then wraps to zero. It never decreases except by wrap-around.
Each managed object type has a globally unique name represented as an OBJECT IDENTIFIER (a sequence of integers traversing a global administrative tree), a syntax defined in ASN.1, and an encoding per ASN.1 BER.
Gauge (APPLICATION 2) is a non-negative integer that may increase or decrease but latches at the maximum value of 2^32-1 (4294967295) and does not wrap.
NetworkAddress is a CHOICE type representing an address from one of possibly several protocol families; currently only the Internet family (IpAddress) is defined.
Opaque (APPLICATION 4) passes arbitrary ASN.1 syntax by encoding a value with ASN.1 BER into an octet string, then encoding that as an OCTET STRING—effectively double-wrapping. A conforming implementation need only accept and recognize opaque data, not interpret it.
The OBJECT-TYPE ASN.1 macro formalizes object type definitions with fields SYNTAX (type ObjectSyntax), ACCESS (read-only | read-write | write-only | not-accessible), and STATUS (mandatory | optional | obsolete), with VALUE NOTATION mapping to an ObjectName OID.
TimeTicks (APPLICATION 3) counts time in hundredths of a second since a reference epoch. The MIB object type definition must identify the specific reference epoch.
The experimental(3) subtree (1.3.6.1.3) is for objects used in Internet experiments, administered by IANA. Assigned experimenters receive a numbered sub-node such as { experimental 17 } (1.3.6.1.3.17).
The Internet subtree of OBJECT IDENTIFIERs is rooted at { iso org(3) dod(6) 1 }, i.e., prefix 1.3.6.1, administered by the IAB. Four initial nodes are defined: directory(1), mgmt(2), experimental(3), and private(4).
The mgmt(2) subtree (1.3.6.1.2) is used for objects defined in IAB-approved documents; administration is delegated to the Internet Assigned Numbers Authority. Each approved Internet-standard MIB RFC is assigned a sequential number under this subtree.
The private(4) subtree (1.3.6.1.4) is for unilaterally defined objects. It contains enterprises(1) (1.3.6.1.4.1), under which vendors may register product models and define private MIB objects.
Security issues are not discussed in this memo.
All object instances are encoded using the ASN.1 Basic Encoding Rules (BER, ISO 8825) applied to the object's defined syntax. This is the sole wire encoding scheme specified by the SMI.
IpAddress (APPLICATION 0) represents a 32-bit internet address encoded as an IMPLICIT OCTET STRING of length 4 in network byte-order. Only the primitive ASN.1 encoding form shall be used.