摘要

  • 在 RFC 2020 中，配置写入只表达意图；训练过程隔在“希望采用的模式”和“链路最终采用的模式”之间。
  • 这不是抽象区别：当前帧格式决定 MTU 是 1500 还是 4464 字节，只有训练状态达到 opened，ifOperStatus 才能成为 up。

写入成功只是起点

RFC 2020 把 dot12DesiredFramingType 与 dot12CurrentFramingType 并列设置，却不让它们互相冒充。前者为下一次训练选择兼容 IEEE 802.3、兼容 IEEE 802.5，或两者皆可；后者回答接口眼下实际使用哪一种。即使期望值允许二选一，当前值仍必须落到一个具体格式上。

这个区别会直接改变 ifMtu。当前采用 802.3 兼容帧时，MTU 是 1500；采用 802.5 兼容帧时，是 4464。改变期望帧格式，可能在下一次训练后改变 MTU。因此，SET 被接受只能证明请求存在，不能证明格式已经切换，更不能把新 MTU 当成既成事实。

帧的外观也不能替访问协议作证。IEEE 802.12 能使用 Ethernet 或 Token Ring 的帧格式，却运行自己的 Demand Priority Access Method。RFC 2020 因而明确：不能只因帧格式相似，就给它套用 Ethernet-like 或 Token Ring MAC MIB。只有在 Token Ring 帧格式之外还真正支持源路由时，RFC 1749 才是那个更窄的例外。

训练把偏好变成可核验结果

训练帧只用于链路初始化。链路下端的从设备发起，上端的主设备回应。RFC 2020 要求连续收到 24 个无差错训练帧才完成训练，并说明这项要求是为了让边缘质量的链路无法轻易过关。

dot12Status 区分关闭、正在打开、已打开、打开失败和链路失败。ifOperStatus 只有在已打开时才是 up；其余几种状态都是 down。打开、复位、改变期望帧格式、改变期望混杂状态或改变控制模式，都可能触发训练，但触发动作本身不是训练结果。

混杂模式把这条界线写得更直白。dot12DesiredPromiscStatus 是下一次训练包中提出的请求，主设备未必批准。写入 ifPromiscuousMode 会更新期望值并触发重训；训练结束后，这个对象却必须反映实际启用的模式，而不是刚才请求的模式。dot12LastTrainingConfig 留下最近一次无差错训练帧中的配置位，提供了另一份结果证据。

“主设备”也只是协议角色。它决定何时批准请求节点发送；终端节点和被动交换设备通常是从设备。这个称谓不证明设备归谁所有，不构成组织权力，也不保证任何数据已经送达。

能算出来，不等于能证明结果

RFC 2020 没有另设普通优先级发送计数，因为它可以用接口总量减去高优先级总量推导。接收侧却因错误帧和不可读字节而需要额外计数。这里的公式定义了观测值之间的关系，但无法证明目的端收包、应用完成任务或服务履约。

安全边界同样明确：RFC 的安全考虑一节只说本文未讨论安全问题。接口已打开、训练配置已接受、流量能够计数，都不是认证、机密性、完整性或安全运行的证据。

两套文档生命周期并不冲突

截至 2026 年 9 月 11 日，RFC Editor 与 IETF 的当前记录仍把 RFC 2020 列为 Proposed Standard，没有列出取代它的 RFC；RFC Editor 勘误检索显示没有匹配记录。这只是当日数据库结果，不是永远不会出现勘误的保证。

IEEE 的当前记录描述另一份文档：IEEE 802.12-1995 被标为 Inactive-Withdrawn，撤回日期为 2001 年 1 月 15 日；IEEE 802 也把 Demand Priority 工作组列入已解散清单。这些后来的行政事实不衡量部署量、市场成败或性能。把文档标签写成运行事实，恰好会重犯 RFC 2020 努力避免的错误。

来源