Summary

  • RFC 1065 made an object type a declaration with a name, syntax, encoding and access category; it did not make the declaration a current reading from a particular machine.
  • Its identifier tree delegated durable names and its type vocabulary disciplined representation, while MIB definitions and management protocols still had to say what existed, how an instance was located and what a response meant.

A catalogue was not an instrument panel

Early TCP/IP management faced a deceptively ordinary problem. A manager, an agent and a MIB needed to agree on the label of a thing before they could disagree about its value. Without a common structure, one implementation's “interface errors” might be another's private number, represented in a different form and sent over a different wire convention. Yet a common label could invite a larger mistake: treating the catalogue as if it already contained the network's state.

RFC 1065, published in August 1988, separated those jobs. It defined common structures and an identification scheme for management information in TCP/IP-based internets, using ASN.1. Its Structure of Management Information was deliberately a foundation. It supplied an information model, but said that it did not define the actual managed objects available in a particular system, nor the protocol-specific machinery used to refer to an object instance. Those were companion responsibilities, not omissions to be filled by wishful reading.

The distinction is easiest to see in the document's use of object type. A type says how a class of managed information is named, what syntax its values use, how those values are encoded and what access category applies. RFC 1065 calls that declaration declarative. An object instance, by contrast, is a type bound to a value at a time. The type can tell a manager how to read an answer if one arrives. It cannot itself report the answer, prove which device supplied it, establish when it was sampled or show that the value still describes the running system.

The tree named responsibility before it named a value

The object identifier was the visible spine of that discipline. RFC 1065 used a hierarchy of OBJECT IDENTIFIER arcs and placed Internet management under the iso.org.dod.internet branch. A numerical path allowed independently administered subtrees to coexist without a central flat list for every possible variable.

That hierarchy is often easy to overread. An object identifier is not a serial number for a physical device, a database primary key for every occurrence, a promise that an implementation exports the object, or a measurement. It is a structured name whose administration can be delegated. The document's tree gives a way to refer to the definition of a type. A management protocol still needs rules for appending or otherwise carrying instance information, and a MIB still needs to define the type in the first place.

This modesty mattered. A name that survives across tools can make comparison possible; it does not dissolve the circumstances of comparison. Two responses bearing the same type can come from different agents. The same agent can respond at different times. A missing response can mean many things other than a non-existent type. RFC 1065 built the grammar that keeps those later questions expressible rather than silently answering them.

Syntax made a value legible, not necessarily true

The RFC also supplied application-wide data types such as Counter, Gauge, TimeTicks and Opaque, in addition to ASN.1's basic vocabulary. These choices were not cosmetic. A recipient that knows a value's syntax and encoding can parse the bytes without guessing whether it has received an integer, an object identifier or an octet string.

But representation is not provenance. A well-formed Counter does not say where counting began, a TimeTicks value does not identify the clock's broader history, and an Opaque value is not made intelligible merely because the enclosing field can be carried safely. Later MIBs and protocols could give individual types more precise operational meaning. RFC 1065's contribution was narrower: it prevented every management exchange from inventing its basic notation anew.

The same limit applies to the access field. read-only, read-write, write-only and not-accessible classify an object type's expected management access. They are not credentials, an authentication outcome, a policy decision for a named operator or evidence that a requested modification has succeeded. Calling a type read-write does not appoint every manager with permission; it tells a protocol and MIB reader that both reading and writing are part of the declared surface, subject to the system that actually enforces a request.

The boundary kept a protocol from impersonating a database

The SMI's restraint became more valuable as management systems accumulated tables, counters and configuration controls. A MIB could define the managed objects. A protocol could form an instance reference, carry a request and return a response. An agent could apply local state and access policy. A manager could then decide how much confidence to put in a result. RFC 1065 made none of those actors disappear behind a friendly object name.

RFC 1155 later obsoleted RFC 1065 while explicitly re-releasing its technical content unchanged, apart from its status and minor typographical corrections. RFC 1212 offered later conventions for concise MIB definitions, and RFC 2578 records the evolved SMIv2 form. They show a lineage, not permission to project later mechanisms back into 1988.

Sources and limits

RFC 1065 establishes the early SMI's scope, object-type declaration, identifier hierarchy, value syntax and access categories. RFC 1155 establishes the technically unchanged re-release. RFC 1212 and RFC 2578 provide later comparison. These texts do not establish current deployment, a vendor's MIB contents, the identity of a responding device, authorization in a specific session, data-plane effect, or the factual truth and freshness of an individual value. The argument that a durable declaration is deliberately narrower than a live observation is an interpretation of that documented separation.