Summary

  • RFC 1442 made every SMIv2 information module carry one stable MODULE-IDENTITY, with ownership, contact details, a last-update value and a revision trail. Those fields establish the lineage of the specification artifact.
  • The RFC explicitly placed expansion of that macro at implementation time rather than runtime. A module revision therefore does not prove that a reachable device ships it, exposes all its objects, grants access to them or behaves as the text prescribes.
  • RFC 1902 and then RFC 2578 preserved the identity discipline while tightening revision rules: compatible edits stay under the same module name, incompatible semantics require a new descriptor and object identifier, and obsolete definitions remain reserved rather than disappearing.

A date that looked fresher than the machine

Imagine an operations screen with two adjacent facts. One says that a router answered an SNMP request this morning. The other says that a familiar MIB module was last updated years later than the firmware build recorded for that router. The second date looks authoritative: it is written in the module, has a formal timestamp syntax and belongs to an IETF-defined construct. A hurried analyst may conclude that the device must support the newer revision.

The dates do not conflict. They refer to different objects.

The module date belongs to a definition file used by a compiler, manager, agent developer or documentation system. The response time belongs to a particular exchange with a running endpoint. A current library on the monitoring server can decode an older agent. A vendor can import a newer module while implementing only a subset of its objects. An access view can hide objects that exist in the agent. A proxy can answer on behalf of something else. Even a perfectly decoded value does not reveal which revision of source text governed the code path.

RFC 1442 matters because it made the first kind of evidence much better without pretending to supply the second. Its achievement was durable schema provenance. Its limit was runtime attestation.

SMIv2 needed a name for the document itself

The 1993 Structure of Management Information divided its work into three broad kinds of definition. MODULE-IDENTITY described the information module. OBJECT-TYPE described managed objects. NOTIFICATION-TYPE described unsolicited reports. This distinction put the container under management instead of treating a MIB as anonymous syntax surrounding a list of object identifiers.

Every module was to contain exactly one MODULE-IDENTITY invocation, positioned after any imports or exports. It identified the organization responsible for the module, supplied contact information, recorded when the module was last edited and listed revisions with descriptions. A module could now answer editorial questions about itself: who maintains this namespace, how has its definition changed, and which record is the newest?

That was a substantial improvement over a file whose provenance survived only in a filename, a mailing-list message or an implementer's memory. Stable module identity enabled tools to import definitions predictably. It made review histories inspectable. It also gave later editors a place to record change without renaming the whole module for every compatible correction.

But the macro was not a management object. RFC 1442 said its expansion conceptually occurs during implementation, not at runtime. The statement is easy to skip because the construct resembles data: it contains dates, descriptions and an object identifier. Yet its operational category is different. It tells builders and readers how a module is declared. It does not require an agent to expose a live register containing that declaration.

LAST-UPDATED was an edit clock

The label LAST-UPDATED invites overreach. It can be read as if it meant last firmware update, last installation, last process start, last configuration change or last successful observation. In the SMI it meant none of those things. It recorded the last time the information module was edited.

Likewise, each REVISION clause paired a timestamp with a description of a module revision. RFC 1442 asked for entries in reverse chronological order, although revision clauses were still optional in that first version. The history was about the specification's lineage. It was not an automatically collected deployment log.

That difference is not merely semantic housekeeping. A monitoring platform often merges three clocks: the date embedded in the schema it loaded, the software version reported by a device and the time at which the platform observed a value. Once merged, the newest-looking timestamp tends to dominate. The result is an evidence inversion. The strongest fact—“this schema file says it was edited then”—is turned into a weaker and unsupported claim—“this device ran that revision now.”

A defensible record keeps the clocks separate. Schema provenance can explain how an object identifier was decoded. Package or firmware provenance can explain what code a supplier says was installed. Observation provenance can establish what endpoint returned which bytes under which credentials. Behavioral verification can test whether the supposed object semantics held. No one clock subsumes the others.

Stable names were designed to absorb compatible change

The module name was not meant to tick upward with every revision. Keeping it stable protected imports: other modules referred to descriptors from the named module, and gratuitous renaming would break an ecosystem of definitions even where wire behavior remained compatible.

RFC 1442 therefore permitted a bounded set of edits beneath an existing name. Descriptions could be clarified. References could be added or corrected. Some status and access properties could move in safe directions. A table could gain columns under rules intended to preserve old implementations. These were forms of evolution that a receiver should be able to tolerate without an over-the-wire surprise.

The boundary was semantic compatibility. If an object changed in a way outside the permitted list, the editor was to assign a different descriptor and a new object identifier. The old definition could not be silently repurposed. Identity was doing double duty: the module name gave a stable home to compatible history, while individual descriptors and OIDs prevented incompatible meanings from borrowing an old address.

This is a subtle governance mechanism. Stability did not mean immutability. It meant that changes were classified, recorded and constrained. The name survived because editors accepted obligations about what could continue beneath it.

Two successors retained the boundary

RFC 1902 replaced RFC 1442 in 1996. It preserved the same three-part structure, the single module identity and the implementation-time—not runtime—character of the macro. The replacement demonstrates that an obsolete specification can leave a living design rule. The document number changed; the conceptual separation did not.

RFC 2578 replaced RFC 1902 in 1999 and became the Internet Standard SMIv2 reference. It made the change discipline sharper. A module could have different versions while keeping the same module name. Revisions were expected not to cause interoperability problems over the wire. Any change required corresponding revision information in MODULE-IDENTITY. Definitions were not to migrate casually between modules.

Most importantly, obsolete definitions were not to be deleted and their object identifiers were never to be reassigned. The namespace retained its negative space. A retired meaning remained part of the record precisely so that a later meaning could not occupy the same coordinate and deceive old implementations.

The status values current, deprecated and obsolete belong to this schema-governance layer. They communicate whether a definition is recommended for new use. They do not report whether a device implements it. An obsolete object may remain reachable in a large installed base; a current object may be absent from a specific product; a deprecated object may be present but hidden by policy. Standards status and runtime presence are independent variables.

What a module record can—and cannot—prove

A good evidence system should use MODULE-IDENTITY aggressively, but only for claims it can support. It can anchor the module's OID, organization, contact point and editorial revision history. Together with a cryptographic hash and acquisition record, it can identify the exact schema artifact a tool used. It can explain why the tool applied a particular syntax, display hint or textual convention to an observed value.

It cannot, alone, establish five other propositions. It cannot prove that the agent contains the module. It cannot prove that every object in the module is instrumented. It cannot prove that the requesting principal can see those objects. It cannot prove that the code follows the documented semantics. It cannot prove that a successful operation changed an external device state or persisted across restart.

Those propositions need separate observations. Runtime presence may require probing selected objects and preserving responses, including noSuchObject and access failures. Coverage may require comparing discovered instances with a declared conformance group. Authorization needs the identity, context and view used for the request. Semantic behavior needs controlled tests and independent state evidence. Persistence needs a later observation after the relevant lifecycle event.

The most useful inventory is consequently not “device X runs MIB revision Y.” It is a chain: schema artifact Y was loaded by collector C; C decoded response R from endpoint E at time T; principal P used context V; object O returned value Z; independent observation B did or did not corroborate the expected effect. Each link has its own provenance and uncertainty.

The historical lesson is about disciplined modesty

RFC 1442 belongs to a moment when Internet management needed definitions that could evolve without dissolving their identity. Its module macro helped make that possible. The module acquired an owner, a stable coordinate and a memory. Later SMI revisions strengthened the obligations around that memory.

The achievement becomes distorted when provenance is promoted into attestation. A registry entry can describe what a specification says. A compiler can prove which input it consumed. A packet can show what crossed an interface. None of those facts, by itself, creates the others. The symbolic layer becomes trustworthy only when its claims remain attached to the reality they actually observed.

That is why the fixed nameplate in this history should be valued, not distrusted. It is an excellent label for a continuing lineage. The error is asking the label to testify about the machine behind the glass.

Sources