摘要

  • RFC Final Review原名AUTH48，发生在某个RFC出版文档流批准Internet-Draft之后。作者要检查完整内容、标记和各类输出，并同意出版；这是真实的完整性控制，却不是IETF的第二轮投票。
  • 文档进入出版队列后，RFC Production Center接管出版副本的变更控制。编辑性修正可在这段保管期内完成；新增、删除或技术变更若超出编辑范围，须由原文档流批准。
  • 2025至2026年的kramdown-rfc与GitHub试点把边界公开展示。2026年8月27日，RFC-to-be 10025仍有Final Review状态页和公开仓库，但RFC 10025的信息页尚返回404。
  • 可靠的“最终审阅回执”应保存获批版本、文档流决定、RPC修改集合、问题和变更分类、作者及文档流确认、最终输出哈希和出版公告。实现与部署必须另找证据。

那个被看成第二次表决的pull request

误判往往不是从伪造材料开始，而是从压缩真实材料开始。

风控人员打开一座公开仓库，看见RPC-edits分支、若干issues、一项pull request，以及尚未全部完成的作者确认名单。若系统只允许“通过”或“未通过”两个状态，就会自然地把开放事项写成争议，把缺少确认写成否决，把GitHub参与者写成新的投票人。

Final Review实际位于两个不同事件之间。上游是某个RFC文档流批准一份Internet-Draft出版；下游是RPC发布确定的HTML、PDF、TXT和XML文件，并通过公告确认RFC已经出现。中间阶段要证明：编辑后的文字仍忠实表达获批内容，各种格式也没有破坏代码、图表、引用或规范含义。

这不是无足轻重的排版。一个丢失的条件、错误的IANA指令、损坏的ABNF、模糊的规范词，出版后都可能长期影响实现者。但重要性并不会自动扩大职权。RPC有权停下来问，作者有责任认真核，文档流仍掌握实质内容的批准权。

GitHub试点的制度价值就在于把这些动作分开。它能让后来者看到获批起点、RPC提出的修改、提出问题的人、回答者，以及某项变更是否需要更高一级确认。透明并不意味着每个可见参与者都成为授权主体；透明的意义恰恰是让授权主体不再被隐藏。

批准发生在进入队列之前

现行RFC出版说明把起点写得很清楚：Internet-Draft先由IETF、IAB、IRTF、Independent或Editorial五个文档流之一批准，然后才进入出版队列。每个文档流有自己的决定程序。RPC收到的不是一篇等待它判断技术取舍的投稿，而是一份已有出版决定的文稿。

这个顺序决定了比较基线。进入队列后，RPC控制出版副本。作者若想修改，必须通过RPC提出；若改动新增或删除内容、改变技术含义，或者从性质上看已经超出编辑，RPC就要把它送回原文档流取得批准。

RFC 9920进一步划清责任：各文档流批准机构对本流内容负责，RFC Editor职能承担生产与分发。RPC编辑文档，保存修改和与作者对话的记录，识别可能带来技术影响的改动，寻求澄清，确认出版准备状态，再发布最终成品。

技术决定和编辑保管缺一不可。文档流不能只说“我们批准了”却不保证最终文件可可靠阅读；RPC也不能因为持有工作副本就重新设计协议；作者不能借最后一次校对绕过已经完成的集体程序。尽调记录首先要写清精确获批版本和哈希，其次写清批准它的文档流与机构。

作者究竟确认什么

Final Review不是对一张diff随手点同意。作者要处理RPC提出的问题，审阅共同作者的改动，重读完整内容，核对版权文字和语义标记，还要检查HTML、PDF与文本输出。它可能需要多轮讨论，也可能需要寻找更准确的表达。

kramdown-rfc试点说明在该路径中设置两次确认。第一次表示markdown内容已经稳定，可以转换成RFCXML；第二次确认最终内容和全部格式。原因很实际：源文件正确，不代表输出一定正确。代码块、艺术图、表格、引用、缩进和语义结构都可能在转换后出问题。

因此，作者确认更像一份完整性声明：以本人责任范围判断，这组最终文件忠实、完整并可出版。它并不赋予作者在文档流决定之后任意加入新技术政策的权限。

“作者失联”规则显示这种权利不是不可替代的个人主权。现行说明允许把失联者移至致谢或贡献者，也允许文档流负责人代为确认。后者通常用于对方贡献重大、不宜简单删除署名的情况。系统同时保存贡献、连续性与权限边界，不让一个不可达邮箱永久锁住公共记录。

失联当然不能被轻率处理。那位作者可能最清楚某个细节是否被编辑歪曲。回执应记录联系状态、选择了哪条路径、谁代替确认以及理由。区别在于：问题有明确程序，而不是被翻译成没有出口的“作者否决权”。

GitHub merge不能越过的线

RPC在2025年9月1日启动kramdown-rfc试点。目标是使用越来越多作者熟悉的格式，并让diff更集中反映内容变化。初期计划每月接收至少五项请求，在实践中完善方法后再扩大使用。

到2026年，公开说明已用Final Review替代AUTH48。新名称去掉了一个误导性的数字；48从来不是可靠的两天期限。GitHub则把保管结构做成可见的物件：RPC修改放在单独分支，问题进入issues，方案进入pull requests，对话进入公开档案。

RFC-to-be 10025的仓库是一个正在发生的样本。README说明，最初的markdown是获准出版的Internet-Draft副本；RPC改动在自己的分支中；作者确认内容和格式；超出编辑范围的变更由Area Director批准；工作组chairs与document shepherd也在审阅界面中。参与者如不适合GitHub，还可回到电子邮件方式。

截至2026年8月27日，Final Review状态页和公开仓库均可访问，而RFC 10025信息页返回404。仓库当时显示十五项issues和一项pull request。这些数字不能被解释成十五个技术错误、十五项反对或十五个阻塞决定；它们只证明公开工作项存在。

状态随后可能变化，所以观察必须带日期。RFC编号出现、临时输出可查看、仓库开放，都不等于已经出版。最终RFC页面和出版公告才是另一个事件的证据。

RFC 9991：需要Area Director确认的规范词

抽象边界在一封公开邮件中变得具体。

成为RFC 9991的文档处于Final Review时，作者提出新增一个BCP 14关键词。大写规范词可能改变技术义务，不是普通标点。公开审阅通信显示，RPC要求Area Director审阅并批准这项新增；AD明确回复批准。

这条记录最重要的是动作顺序。作者提出，RPC识别并转交，AD批准，RPC之后才出版。任何一个动词都不能代替另一个。

如果系统只保存最终文本，就无法证明迟来的规范变更凭什么进入；只保存AD邮件，又无法证明获批文字确实进入每种最终格式；只保存RFC编号，则整条责任链都消失了。

转交也不证明编辑者试图扩权。相反，它证明RPC识别了编辑权限的终点，并把实质决定交还给正确的批准者。

48为什么从来不是期限

AUTH48看起来像一项48小时服务承诺。RFC 8963研究了2018年出版的一组RFC，把RPC编辑、AUTH48和最终出版等待分开计算。样本中的AUTH48平均超过一个月，而且差异很大。报告把它描述为最终核验：作者同意编辑版本，或者要求最后修正。

RFC 8700记载了“48天”“48周”的长期玩笑，也保存了更重要的制度经验：技术变更需要相关Area Director或文档流负责人批准。

审阅时间长并不能自动说明谁有错。多个时区的作者协调、失联、IANA动作、规范性引用依赖、Stream Hold或工具故障，都会形成不同原因。时长是启动调查的指标，不是调查结论。

改称Final Review修正了错误的时钟隐喻。新的记录不应再用“第二次表决”制造错误的政治隐喻。它是一段受约束的最终定稿过程。

最终审阅回执

字段 应保存的证据 作用
获批源稿 draft名称、版本、字节和哈希 固定文档流批准的基线
文档流决定 文档流、机构、日期和链接 指明出版批准者
交给RPC 入队时间和当前状态 区分决定与生产保管
修改集合 分支、diff和哈希 展示批准后发生了什么
审阅事项 问题、责任人、回答和档案 让不确定性可归属
变更性质 编辑、格式、技术或超出编辑 决定需要何种权限
作者确认 身份、范围和时间 把确认绑定到输出
文档流确认 AD或负责人回执 防止生产保管变成内容权力
外部等待 IANA、引用集群、文档流或工具 找到真正阻塞方
最终成品 HTML、PDF、TXT、XML哈希 证明确认对象
出版 公告、RFC URL和时间 证明RFC-to-be已经成为RFC
采用 实现、测试和部署 防止文档状态冒充运行现实

这张回执不会替代人的判断，却会保存判断者及其范围。于是记录可以准确写成“等待某作者核对输出”“技术新增等待AD批准”或“IANA动作尚未完成”，而不是发明否决、重投票或出版。

来源

RFC-to-be 10025的状态仅指2026年8月27日快照。本文不把issues数量当作缺陷数量，也不预测出版结果。