Summary
- RFC 2366 placed
marsMIBbelow{ snmpModules 17 }; RFC 2417, published two months later, says a clerical assignment error required correction and places it below{ mib-2 57 }. - Expanding those symbolic paths yields different numeric roots:
1.3.6.1.6.3.17and1.3.6.1.2.1.57. Objects named beneath the MIB inherit the changed prefix. - The MIB describes management objects for MARS clients, servers and multicast servers. A change to their names is not a report that agents, managers, group membership, virtual circuits or packet forwarding changed.
A branch correction with a long tail
An object identifier is a path, not a label pasted onto an otherwise fixed number. Each arc names a child beneath its parent. In July 1998, RFC 2366 defined the MARS management module as marsMIB ::= { snmpModules 17 }. In September, RFC 2417 obsoleted that memo. Its IANA note calls the earlier assignment a clerical error; its revision note says to “reroot this MIB from snmpModules to mib-2,” and its module identity is marsMIB ::= { mib-2 57 }.
The arithmetic makes the scale of the correction visible. RFC 1902 places snmpModules under snmpV2, itself beneath internet; MIB-II, RFC 1213 places mib-2 under mgmt and internet. The old root therefore expands to 1.3.6.1.6.3.17; the corrected one to 1.3.6.1.2.1.57. The module’s descendants are defined relative to marsMIB, so their numeric paths inherit the new prefix too.
That is a real identity change in the management namespace. It is not, by itself, a change to what MARS does. RFC 2022 describes MARS as the mechanism by which endpoints on ATM networks register or query multicast-group membership, then use virtual-circuit meshes or a multicast server to distribute traffic. RFC 2417’s tables expose views of clients, servers, groups, mappings, virtual circuits, state, timers and statistics. They describe what an agent may report; they do not execute membership distribution or prove which circuit carries a packet.
The distinction matters because the same sentence—“the MIB changed”—can refer to several different layers: a standards document, a symbolic OID, the numeric name compiled into an agent, what a manager polls, and the network behavior an operator observes. RFC 2417 establishes the first two. It does not identify a vendor, upgraded agent, converted monitoring system, compatibility bridge, outage or completed fleet migration. Its status as the successor memo tells us which assignment the standards record adopts, not how quickly running equipment followed it.
The current IANA SMI Numbers registry lists mib-2 arc 57 as marsMIB, citing RFC 2417, and marks the earlier snmpModules arc 17 entry obsolete. That is a useful present-day receipt for the registry’s intended naming. It cannot be read backward as a deployment census. RFC 2417 also says the module is used with the ATM-MIB in RFC 1695, MIB-II in RFC 1213, and optionally the IF-MIB in RFC 1573—dependencies among management models, not proof that any particular agent exported them.
The evidence boundary is the story
It is tempting to imagine an operator watching every MARS object disappear from one branch and reappear under another. The documents do not show that scene. A manager configured with the former numeric subtree could need a revised view; an agent compiled to export the corrected subtree could answer a different query. Those are plausible consequences of the name change, not reported historical events. Whether a particular system accepted both names, changed configuration, or saw polling failures requires implementation or operational evidence absent here.
Heng Lu’s notes on Running-Code Primacy and Reality Layers offer a useful analytical lens: a symbolic assignment, an implementation, a manager’s interpretation and an observed service are different claims. That lens does not supply evidence about 1998 deployments.
So the narrow lesson is more durable than a migration anecdote we cannot substantiate: a registry correction can change the identity by which management software locates information, and every descendant name can move with it, while the network action being observed remains a separate question. The paper tree moved. The RFCs do not say that MARS itself did.
Sources
- IETF Datatracker — RFC 2417 publication record
- IETF Internetworking Over NBMA Working Group
- RFC 2366 — Definitions of Managed Objects for Multicast over UNI 3.0/3.1 Based ATM Networks
- RFC 2417 — Definitions of Managed Objects for Multicast over UNI 3.0/3.1 Based ATM Networks
- RFC 1155 — Structure and Identification of Management Information
- RFC 1213 — Management Information Base for Network Management of TCP/IP-based internets: MIB-II
- RFC 1573 — Evolution of the Interfaces Group of MIB-II
- RFC 1695 — Definitions of Managed Objects for ATM Management
- RFC 1902 — Structure of Management Information for Version 2 of the Simple Network Management Protocol
- RFC 2022 — Support for Multicast over UNI 3.0/3.1 Based ATM Networks
- IANA SMI Numbers registry
- Heng Lu — Running-Code Primacy
- Heng Lu — On Reality Layers
- Heng Lu — Minimum Initial Specification and Localized Future Decision
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
