摘要

  • draft-moonesamy-authorship-ietf-00 于 2026 年 9 月 9 日发布，是一份活跃的个人 Internet-Draft，不是 IETF 已采纳工作、正式政策或社区决定。
  • 草案询问：生成式 AI 参与 RFC 写作时，IETF 是否应形成程序指南；它还建议用快速的现场问答，让工作组感知“人的因素”。
  • 即席交锋可以检验某人是否掌握方案，却不能证明文字出处、列名同意、知识产权核验、工具使用范围或每次修订的长期责任。
  • 我主张为每次实质修订保留一份作者责任记录，把这些命题分开。这是 Daniel Kade 的治理建议，不是两份活跃草案中的既定要求。

新消息是一道被正式摆上台面的题

Datatracker 显示，Reflections on IETF Authorship 的 00 版在 9 月 9 日 11:19 UTC 进入仓库。它处于 Active 与 I-D Exists 状态，却没有 RFC stream、负责的 Area Director 或 IESG 处理流程。IETF 对 Internet-Draft 的说明很清楚：任何人都可以提交，个人草案不会因为完成入库就取得机构立场。

这项身份限定必须放在报道开头。草案回顾了作者、编辑、贡献者与致谢之间长期存在的分歧，也提到 RFC 把真实姓名与功劳、问责放在一起，而 IETF stream 的文档又声称代表更广泛的社区共识。它随后把生成式 AI 放进这套旧问题：社区是否应接受或实现由此类工具写成的规范？是否应该制定作者与编辑程序，而不是完全交给个人裁量？

00 版提出问题，没有给出制度答案。它没有规定必须披露什么、何时披露、由谁检查、如何申诉，也没有设计作者资格测试。草案把 2026 年 -00 文件增多部分解释为生成工具降低了写作门槛；这只能作为作者的判断引用，不能升级成 IETF 已证实的因果结论，更不能等同于质量或滥用判断。

文本最具体的设想，是让工作组同作者进行一种快速、来回的即席讨论，从而感受文档背后是否存在真实的“人”。这可以是审阅方法，却还不是作者规则。

能答出追问，只证明当下能答出追问

现场讨论有无可替代的价值。参与者必须把假设连起来，区分反例与范围变化，承认未知，并说明某项设计为何没有被另一种选择取代。工作组因此能判断对方是否真正理解协议，也能及时发现文字遮住的分歧。

但这种证据很窄。一个人完全可能深入理解由他人起草的文档；主要作者也可能不擅长即时表达。某位贡献者可能只负责一个章节，却比首页的编辑更熟悉那一部分。语言、时区、残障与会议媒介还会影响回答速度，却不会自动改变技术贡献和责任。

更关键的是，口头表现无法重建文本保管链。它回答不了哪一段来自作者、哪一段沿用旧 RFC、哪一段由工具生成、哪一段是在审阅后改写。它也无法证明所有列名者都同意、借用材料已经注明、提交者有依据作出 BCP 78 与 BCP 79 声明，或下一版仍保持相同的分工。

所以，现场问答所能支持的命题应当写得很克制：“此人在这个时点能够解释和捍卫方案。”作者记录所要支持的命题则跨越整个修订过程：“这些人提供、核验并接受了与其角色相符的责任。”把前者当作后者的证明，会让有效的讨论工具变成证据捷径。

现有制度本来就没有把所有权力交给作者名册

2021 年仍有效的 IESG 作者声明提供了一个硬边界：未经同意和实质贡献，不得把人列为作者或贡献者。用知名姓名制造支持感既误导也不合伦理，还会破坏提交者对 BCP 78、BCP 79 合规性的声明基础。

RFC 7322 则把作者和编辑名册的决定权交给相应 stream。首页一般不超过五人；更长名单需要 stream 的批准机构判断，是否应由少数编辑承担主要责任，并把其他人列入贡献或致谢。首页列名者还要在 AUTH48 阶段确认文本，并在出版后面对勘误等查询。2024 年的 IESG 声明又按贡献程度区分作者、贡献者和致谢。

但列名不产生共识。RFC 8789 把 IETF stream 文档的权威基础放在 rough consensus。写稿、列名、工作组接受、stream 批准与最终实现可能由相互重叠的人完成，却是五种不同事件。

另一份活跃个人草案也必须纳入事实边界。Principles and Guidelines for Assignment of RFC Authorship 的 06 版写明，作者与编辑仍对内容和知识产权负责，AI 工具不能被列为作者。对于“实质内容由 AI 生成时是否应披露”，该版仍明确标注为开放问题。它说明政策工作正在进行，而不是证明 IETF 已经作出最终裁决。

缺少的不是测谎器，而是逐版责任单

解决办法不是把每次会议变成考试，而是让每种记录只承担它能证明的事情。现场讨论记录理解与审阅；版本历史记录文字变化；明确同意记录姓名与角色的接受；权利文件记录贡献声明；议题、会议纪要和表决记录工作组或 stream 如何接纳文本。

一份轻量的逐版作者责任单，可以保留六组信息：负责的作者和编辑及其明确同意；重要的人类贡献和复用文字；按章节或变更集申报的软件协助范围；完成过的人类核验与仍未解决的不确定性；接纳文本的程序决定；以及进入 stream 审阅和 AUTH48 时的最终责任确认。

这不是 AI 检测器。它不从文风推断欺骗，也不把拼写检查、翻译帮助与整段技术生成视为同一件事。它记录参与者能够确认的行动，同时保留各 RFC stream 决定作者名册与程序的权力。

这种设计反而能保护正当使用。仅做语法或翻译辅助，可以如实说明有限范围；生成实质技术内容，则记录生成、核查与承担责任的路径。工具无需被虚构为作者，社区也不必从口头表现或句式猜测文档的生产史。

来源