Summary
- RFC 1239 reassigned five MIB roots from
1.3.6.1.3experimental arcs to the standardmib-2andtransmissionbranches. - Its policy rationale was operational: late renumbering forced vendor revisions even when definitions probably had not changed substantively, risked field problems and discouraged early implementation.
- The reassignment proves which codes the standards process selected. It does not prove when any agent, manager, poller or stored time series adopted them.
A two-page memo identified a deployed dependency
RFC 1239 is unusually short. It contains a policy diagnosis, five old codes and five replacements. The diagnosis gives the table its historical weight. Early MIBs had received object-identifier arcs under the experimental prefix. A standard arc arrived only when a MIB reached Full Standard. Advancing the document could therefore require vendors to revise implementations even when, as the memo put it, there was probably no substantive technical change in the definitions.
The number was not a margin note. In the SMI defined by RFC 1155, an object identifier is the administratively assigned name that locates an object type. Managers query it, agents expose it, schemas store it and tools bind it to labels. Moving a root changes every descendant address even if the object descriptions remain familiar.
RFC 1239 named two consequences. Renumbering late could create operational problems in the field. Waiting for a stable number could also discourage implementation until Full Standard, depriving the standards process of the experience that implementation was meant to supply. Its preferred rule was therefore to assign standard-MIB arcs at the earliest stage and preserve them as the standard progressed.
The RFC Editor metadata and Datatracker record now describe the memo as Historic and Legacy. That current classification is a record about the document. It neither erases the 1991 mapping nor says which code any device used then or uses now.
Five subjects received new administrative addresses
The first mapping concerned the Generic Interface Extensions. RFC 1229 had rooted them at 1.3.6.1.3.6, written as { experimental 6 }. RFC 1239 moved the root to 1.3.6.1.2.1.12, or { mib-2 12 }.
Four media-specific MIBs moved beneath the standard transmission branch. RFC 1230 had placed IEEE 802.4 Token Bus at experimental 7; its new suffix became transmission 8. RFC 1231 had placed IEEE 802.5 Token Ring at experimental 4; its new suffix became transmission 9. RFC 1232 rooted DS1 at experimental 2; the replacement was transmission 18. RFC 1233 rooted DS3 at experimental 15; the replacement was transmission 30.
These are mappings between names, not measurements of migration. RFC 1239 did not specify a deadline, an alias, dual registration, capability negotiation, collector conversion or a rule for historical databases. It said which code assignments changed and why the assignment policy should change in future. The path from that decision to a working fleet remained local.
A registry can settle authority without settling observation
The current IANA SMI registry preserves the standard structure. It lists GenericIF at mib-2.12 and the transmission values 8, 9, 18 and 30. Some rows now cite later RFCs because the object definitions continued to evolve. That is exactly why a present registry view and a 1991 transition record answer different questions.
The registry can establish the authoritative number now. RFC 1239 can establish the reassignment decision then. Neither record alone establishes that a particular agent stopped answering an experimental OID, that a management station began asking the standard one, or that two observations under different roots came from equivalent code and state.
This matters most in negative claims. A failed query under the new OID may mean the device never migrated, the object is unsupported, access is denied, the agent is unreachable or the query was malformed. A successful query under the old OID proves an answer at that observation point; it does not prove the standard assignment was ignored everywhere. Absence from one namespace is not presence or absence in the other.
Continuity requires more than replacing a prefix
A collector that changed only its query might split a time series. A parser might retain the same human label while the stored numeric key changed. A dashboard could join old and new data as if they were identical even though the agent version, object semantics or collection interval also changed. Conversely, refusing to join them could manufacture a discontinuity that existed only in the namespace.
RFC 1239 supplies no evidence that any of those outcomes occurred. It supplies the reason to preserve the evidence needed to decide. A defensible migration record would name the old and new OIDs, agent and manager versions, configuration change, observation times, response values, access context and the rule used to join or separate historical series. If dual support was observed, each response would still need its own capture; it should not be inferred from the mapping table.
The larger standards lesson is restraint. Stable identifiers reduce needless implementation churn, but they do not freeze meaning. Later specifications can revise status, syntax, access or interpretation while keeping a root. Identifier continuity and semantic continuity are different claims. RFC 1239 protected the first because the Internet had learned that even an administrative address could become an installed interface.
Sources
- RFC 1239 — Reassignment of Experimental MIBs to Standard MIBs
- RFC Editor information record for RFC 1239
- IETF Datatracker record for RFC 1239
- RFC 1229 — Extensions to the Generic-Interface MIB
- RFC 1230 — IEEE 802.4 Token Bus MIB
- RFC 1231 — IEEE 802.5 Token Ring MIB
- RFC 1232 — Definitions of Managed Objects for the DS1 Interface Type
- RFC 1233 — Definitions of Managed Objects for the DS3 Interface Type
- RFC 1155 — Structure and Identification of Management Information
- IANA — Structure of Management Information Numbers
Member Briefing
Deeper Profile Context
Sign in with the right membership level to unlock the full briefing and source notes.
Only for Strategic Circle
Strategic Circle
Open to all readers. Unlock profile briefings after joining and signing in.
Join Strategic CircleOnly for Leadership Alliance
Leadership Alliance
For qualified IP-asset owners and management; sign in to unlock alliance briefings.
Join Leadership Alliance
