Summary

  • RFC 1285 adapted ANSI FDDI Station Management objects for the Internet SMI and SNMP, changing names and some syntax while aiming to preserve each object's meaning.
  • RFC 1512 later says changes from ANSI SMT 6.2 to 7.3 were numerous enough to create a different MIB-tree branch; it explicitly rejects assuming compatibility with RFC 1285.

FDDI already had a management vocabulary outside the Internet SNMP framework. RFC 1285's challenge was translation: how could a network manager using SNMP see the station, MAC, path, port and attachment information defined through ANSI's FDDI Station Management work? The document says its definitions were, as far as possible, identical to the ANSI objects. It then recast them for the Internet Structure of Management Information (SMI) and MIB.

The authors described the bargain carefully. The meaning of a managed object should stay the same; its representation could change to fit SNMP. A Boolean could be expressed as an enumerated integer, a bit string as an octet string, and an object name could change to fit the Internet MIB tree. The point was not cosmetic uniformity. If two management schemes described the same instrumentation with shared definitions, implementations could reuse instrumentation and managers could translate information more easily. RFC 1285 stated that as an engineering goal, not as measured savings or proof that a vendor implemented it.

The model did not reduce a ring to one health light. RFC 1285 separated Station Management (SMT), MAC, PATH, PORT, ATTACHMENT and chipset groups. Each named a different management surface. An object identifier and its instance identified a particular item in a structured management namespace; they did not authenticate who reported a value, prove a physical cable path, or demonstrate that an application could communicate. A defined counter, state or action carried only the meaning assigned to that object.

The next revision exposes a boundary that the word “mapping” can obscure. RFC 1512, published in September 1993, revised the FDDI MIB against changes from ANSI SMT 6.2 to 7.3. It says those changes were so numerous that the objects had to occupy another branch of the MIB tree, and instructs readers not to assume compatibility with RFC 1285. Yet RFC 1512 repeats the ambition to preserve managed-object semantics while changing syntax for SNMP.

Semantic translation and version compatibility were separate questions: one standard could preserve meaning across two management schemes while a later source-standard revision still changed the manager-facing structure.

That distinction matters whenever a “same technology” label is treated as a compatibility test. A manager needed to know which MIB revision and object identifiers an agent implemented, whether the source model matched, and whether the expected variables were present. A path label or familiar object name was not enough. The standards document cannot tell us which products deployed either revision, whether a particular upgrade failed, or whether FDDI traffic reached a destination. It records the design boundary, not an implementation census.

The lasting lesson is modest but useful: interworking requires a defined semantic contract, and migrations require a separate compatibility contract. RFC 1285 documented the first. RFC 1512's warning makes clear that it did not silently guarantee the second.

Sources: RFC 1285; RFC 1512; RFC 1155; RFC 1212; RFC 1213.