摘要

  • RFC 1285 将 ANSI FDDI 站点管理对象改写为互联网 SMI 与 SNMP 可用的形式：对象名称和部分语法可以变化，但目标是保留其含义。
  • RFC 1512 指出，ANSI SMT 从 6.2 到 7.3 的变化足以让对象转到 MIB 树的另一分支，并明确要求不要假设它与 RFC 1285 兼容。

FDDI 原本就有一套不属于互联网 SNMP 框架的管理词汇。RFC 1285 面对的是映射问题：使用 SNMP 的网络管理器，如何读取 ANSI FDDI 站点管理工作所定义的站点、MAC、路径、端口和连接信息？文件称其定义尽可能与 ANSI 对象一致，再将其改写到互联网的 SMI 和 MIB 体系中。

作者对这项约定说得很清楚：被管理对象的含义应保持不变，但表示方式可以为了 SNMP 而改变。布尔值可以改成枚举整数，位串可以改成八位组串，对象名称也可以为纳入互联网 MIB 树而调整。这不只是格式整齐。共同定义的目标，是让不同管理体系复用同一套仪表化数据，并让管理信息更容易在体系间转换。RFC 1285 提出的是工程目标，并没有证明厂商实际实现，也没有测量成本节省。

这套模型没有把一个环简化为单一的“正常/故障”灯。RFC 1285 分别设有 SMT、MAC、PATH、PORT、ATTACHMENT 与芯片组分组，每一组覆盖不同的管理面。对象标识符及其实例，只是在结构化管理命名空间中指定某个对象；它不会验证报告者身份，不会证明物理电缆路径，也不能证明应用成功通信。计数器、状态或动作，只具有该对象定义所赋予的含义。

后续修订显出了“映射”一词容易掩盖的边界。RFC 1512 于 1993 年 9 月发布，针对 ANSI SMT 从 6.2 到 7.3 的变化重做 FDDI MIB。它说变化多到对象必须放在 MIB 树的另一分支，并要求不得假设与 RFC 1285 兼容。与此同时，它仍然强调在为 SNMP 改写语法时保留管理对象的语义。语义转换与版本兼容是两件事：一种管理体系可以忠实承载另一体系的含义，却不保证源模型变化后，管理器看到的结构保持不变。

当“支持 FDDI MIB”被当成兼容性证明时，这个区别就很实际。管理器需要知道代理实现的 MIB 版本和对象标识符，核对其源模型版本，并确认预期变量确实存在。熟悉的对象名称还不够。RFC 文本并未说明哪些产品部署了两个版本、某次升级是否失败，也没有证明 FDDI 流量到达目的地。它记录的是设计边界，不是实现普查。

可以保留下来的教训并不夸张：互操作需要明确的语义契约；迁移还需要另一份兼容性契约。RFC 1285 记录了前者。RFC 1512 的警告说明，前者不会自动保证后者。

来源：RFC 1285；RFC 1512；RFC 1155；RFC 1212；RFC 1213。