摘要

  • RFC 9592 终止把 Tao of the IETF 作为一份由 IETF 维护的独立长文，因为不同主题的变化节奏、参与方式和新人需求无法继续被一次整体审阅捆在一起。
  • 分拆为专题网页和多种媒介，解决的是更新成本；它不会自动证明谁批准了某次重要改动、旧文是什么、某名读者当时看到哪一版，以及现实操作是否与说明一致。

Tao 的谱系很清楚。1993 年的 RFC 1391 开始为新人解释 IETF，此后十七年又发布四个 RFC 版本，2006 年的 RFC 4677 是最后一个。2012 年，RFC 6722 把 Tao 改为网页，目标正是“更容易更新”。然而 RFC 9592 记录：再往后的十一年，也只发布了四个新版本。

媒介已经可变，工作单元仍然是一个庞大整体。这才是关键故障。

不同速度的内容，被绑在同一只钟上

会议安排、远程参与、Hackathon、工作组习惯、工具和流程说明不会同步老化。修改其中一个主题，却要重新阅读、审核并发布整个长文。编辑成本增加，读者负担上升，新内容还可能被埋在旧结构里。随着远程参与变得重要，仍以线下会议为中心的说明更容易失真。

RFC 9592 选择把内容迁移到专题指南、短文、视频、播客、博客、Datatracker 等渠道。今天的 IETF “Getting started” 页面更像路由器：它把读者导向 IETF 简介、RFC 说明、工作组指南、新工作提交流程、会议指南、新人项目、邮件列表和会议录像。每个模块可以根据自己的需要变化。

这让内容更容易维护，但“可以更快改”不等于“已经留下可复核的改动凭证”。

旧网页制度明确保留了哪些回执

RFC 6722 不只是要求“把 Tao 放上网”。IESG 指定编辑；建议在明确的邮件列表讨论；编辑整理拟议修订；IESG 保留批准权；每个版本要显示时间戳；已发布版本放进带日期的归档地址，并提供修订列表。

这些手续没有把 Tao 变成正式流程文件。RFC 9592 明确称它是社区编写和维护的非正式介绍。但它们至少回答三个审计问题：是哪一版、何时出现、由谁承担编辑责任。

RFC 9592 没有为所有后继网页、视频、博客和渠道制定一套统一的同等制度。这个结论必须保持克制：它不能证明 IETF 现有系统没有代码仓库、备份、内部审阅或历史记录。它只说明，旧制度退役后，新表面不会因“官方”二字自动继承公开的时间戳、归档和批准回执。

官方、当前、历史、所见与执行是五件事

官方地址证明当前发布者。当前页面证明此刻公开的说明。日期归档证明过去发布过什么。读者保存的副本证明他实际看见什么。正式流程文件说明什么具有规范地位。运行中的行为和系统结果，才说明现实发生了什么。

一份当前网页可以更准确，却无法单独证明去年的读者收到什么。旧归档可以完全真实，却不保证内容正确或被采纳。机构可以正式发布解释，但不会因此获得对外部网络的主权。IETF 现有简介仍保留这条边界：标准是自愿采用的，IETF 不运行、控制或巡逻互联网。

因此，答案不是重建另一个 Tao，而是给每个重要模块建立最小出处账本。涉及参与资格、申诉、知识产权、共识程序、安全或重大工程决定时，应保留内容所有者、范围、正式来源、公开地址、发布时间、内容哈希或快照、重大改动说明、审阅凭证、被替代版本和下次复核触发条件。

依赖指南作决定的团队也要留痕：使用了哪个地址和版本、何时取得、若说明与正式文件冲突以谁为准、谁作了解释、何时重新验证。否则，动态页面很容易在事后被当成一条从未改变的硬规则。

完整链条应当是：需求、责任人、来源、拟议修改、审阅、发布、版本、归档、读者所见、本地决定、运行结果。模块化能缩短中间环节，不能把两端抹掉。

“运行代码优先”在这里不是反文档口号。指南的价值在于帮助真实参与者完成真实工作，机构标签不能替代结果。“最小初始规范”要求公共部分足够协调，同时把后续本地判断和责任清楚地留在本地。“现实层级”则防止把“官方页面”“获批流程”“参与者相信的内容”和“实际发生的结果”压成一个绿色状态。

来源