摘要

  • RFC 5249 明确反对把既有 MIB RFC 当作新稿模板，因为 boilerplate 与其他必备元素会随时间变化；它把最新要求放进可维护的外部模板。
  • 本次取证时，三个具名旧地址均经跳转抵达同一通用模板目录。成功响应只能说明路由完成，不能说明终点就是原来点名的 MIB 专用工件或它的权威继任者。

三扇门通向同一个大厅

第一扇门写着 XML MIB 模板，里面应有给 XML2RFC 作者的注释。第二扇门写着“带说明文本”，第三扇门写着“纯文本”。三次请求都没有失败；浏览器最终都来到 IETF Authors 的 Templates and schemas 页面。

这个大厅是真实、有用而且由 IETF 提供的。它列出通用 RFCXML 模板、schema、Markdown 与 Asciidoc 资源，也提醒作者不要拿已经处理过的 XML RFC 直接当 Internet-Draft 模板，因为生成过程会把不适合继续编辑的数据固化进去。

问题不在终点是否权威，而在终点是否自称为起点所点名的东西。本次保存的页面没有出现 MIB 专用模板名称。因而，最小可证事实是：旧地址可达，跳转终点可达；XML、带说明文本、纯文本三个工件与该终点之间的继承关系，尚不能仅靠响应本身建立。

把这句话缩短成“模板还在线”，就把网络可达性升级成了文档权威。

RFC 5249 本来就是为了阻止这种捷径

2008 年发布的 BCP 139 处理的是一个看似保守的习惯：作者从已经出版的 MIB RFC 复制结构。旧 RFC 经过审查，格式也熟悉，拿来用似乎风险最低。但出版物冻结在某个时点；Internet-Draft boilerplate、IESG 要求、IANA 说明与安全指引却会继续变化。

RFC 5249 因而列出三种由 MIB Doctors 维护的模板。XML 版在注释里放入建议，文本版可以保留建议，也可以只留下干净骨架。标准还说明，建议里有不少 MUST，通常对应 IESG 的要求，MIB Doctors 很可能据此检查；模板会不时更新，以反映最新要求。

这是合理分工：RFC 固定“不要复制旧先例，应使用当前维护源”的规则，外部工件承载会变化的具体起点。可是，一旦把变化移到 RFC 外部，版本身份就成为合规链的一部分。

“遵守 RFC 5249”最多证明作者接受了这套分工。它没有告诉审查者，作者在哪一天拿到哪一份字节、当时看到了哪些注释、跳转去了哪里、后来是否发生变化。

URL 是定位意图，不是内容指纹

目前的 OPS 页面仍列出三种 MIB 模板，并写有“2013 年 6 月更新模板”。MIB boilerplate 页面则注明其内容最后更新于 2013 年 1 月、2022 年迁移。时间戳可以帮助调查，但不能自动生成版本链。

一个可复核的取件凭证至少要保存：起始 URL、每次跳转、最终 URL、取件时刻、HTTP 状态、内容类型、字节数与 SHA-256。若发生迁移，还要有权威来源明确说明新工件继承旧名称及用途。

没有最后一条时，系统应显示“可达，但身份未证”，而不是绿色“正常”。这不是吹毛求疵。XML 模板、带说明文本和纯文本可能渲染出相近结构，却给作者不同的决策提示。只看成品，无法倒推出当时存在的建议。

文档模板从来不是 MIB 模块本身

RFC 5249 还刻意把两件事拆开：它提供围绕 MIB 的文档模板，却不提供 MIB 模块模板。标准建议在正文之外独立开发模块，因为验证工具通常需要单独输入，再把经过处理的模块纳入文档。

因此，一次审查至少有四张收据：当前政策来自哪里；正文采用了哪份模板；独立模块经过什么工具验证；专家如何判断语义、安全与可实施性。

模板结构正确，不代表模块能编译。编译成功，不代表 DESCRIPTION 足以让不同实现者得到相同结果。存在 Security Considerations 标题，不代表作者列出了敏感可读对象与危险可写对象。没有残留占位符，也不代表风险分析发生过。

RFC 4181 要求使用最新批准的 MIB boilerplate 与安全模板，同时明确反对盲目复制。它把“某类对象没有风险”的明确判断与“根本没提到这类对象”区分开；后者应被视为遗漏。它也推荐语法工具，却提醒审查者从潜在实现者角度阅读模块。语法只是证据链的一段。

熟悉的外观最容易制造错误确信

RFC 7367 对 Harrington 模板作了致谢，说明这条模板谱系确实进入后续文档。RFC 9349 又表明，多年后仍有 MIB 文档出版。这些都是历史事实，却无法证明另一份稿件使用了哪版模板字节。

恰恰因为格式熟悉，旧文件才会被长期保留。团队成员相信“以前过审过”，把本地副本当作保险。随着网站与政策变化，本地副本越来越可复现，却越来越不一定当前。系统最终回到 RFC 5249 想解决的起点：把过去批准当成现在指令。

更合适的做法是把模板当成构建依赖。审查时固定内容地址；更新时比较差异；只重开受到影响的政策、结构或安全判断。面向人的“最新版”页面可以移动，进入审查记录的输入不能漂移。

把四层证明写成一份短清单

清单不必庞大。记录政策与 BCP 标识；模板名称、版本、发布者、URL、取件时间和 hash；跳转链与继任依据；独立 MIB 的 hash；验证器与版本；输出和例外；安全判断覆盖的具体对象；审查人、日期与结论。

这份清单不会让错误消失，但会让变更范围可算。政策变了，不必假装是模块语法问题。验证器变了，可以在相同字节上比较结果。模块变了，旧验证收据自然失效。安全指南变了，就重新打开人的判断，而不是只跑一次格式化。

Lu Heng 的现实层方法在这里很实用：名称、机构和流程不能替代具体可观测结果。模板负责协调写作，不拥有模块真相；验证器观察形式属性，不拥有部署真相；出版状态稳定文本，也不证明每个实现行为。每层只应获得自己那张收据能支持的权威。

Sources