摘要

  • draft-sayre-gendispatch-derivative-06 是活跃的个人 Internet-Draft。它提议把非衍生机制限于标准流程所用的 RFC 与 Internet-Draft；它不是 RFC、既定规则或 IETF 共识。
  • RFC 5378 把范围较广的 IETF Contribution 与范围较窄的 IETF Document 分开。现行 IESG 声明说明不合规提示的政策效力；IETF 126 的记录则把后续讨论和法律审查留在未来。
  • Daniel Kade 建议采用“贡献状态凭证”，分别记录原始提交、分类、适用规则、负责角色、行动和复核路径。这是治理建议，不是法律意见或 IETF 强制要求。

一行脚注不是权力链

标准工作由很多不完美但有价值的文本组成：部署经验、问题、反对意见、会议记录、上诉和正式草案。邮件进入 IETF 渠道，不等于它已经成为可供工作组采用和演进的标准文档；邮件携带公司系统自动附加的提示，也不等于该系统因此获得决定整个流程的权力。

RFC 5378 先把对象分开。Contribution 不只是为了发布为 Internet-Draft 或 RFC 而提交的材料，也包括 IETF 活动情境中的陈述，例如面向工作组、邮件列表、BOF、全体会议、IESG 或 IAB 的书面和电子通信。IETF Document 则是用于 IETF 标准流程的 RFC 与 Internet-Draft。参与渠道和文档身份并非同义词。

这个区别并不降低来信的分量。某条消息可以揭示一个关键的互操作性风险，同时仍不是一份可以被正式采纳的规范；归档系统可以完整保存它，却不能因保存字节而变成权利裁判者；作者可以提出保留意见，却不会因此取得让其他人停止技术讨论的授权。

RFC 5378 说明，IETF 为发展和发布文档需要一定权利，同时也描述了狭窄例外，例如专有技术、其他标准机构作品的再发布，以及尚未被接受进入开发的文档。这些例外要求精确判断对象，不能被扩展成每封邮件的通用格式。

新工作稿提出边界，不结束个案

-06 版更新于 2026 年 8 月 13 日。Datatracker 将它列为活跃个人 Internet-Draft：没有 RFC stream，共识说明为未知，IESG 状态为 I-D Exists。它的提议非常窄：非衍生机制只适用于属于标准流程所用 RFC 或 Internet-Draft 的 Contributions，RFC 5378 中其他权利不受影响。

这不等于 RFC 5378 今天已经被修改。它不裁定任何具体邮件，不证明有消息丢失、被删改、被审查或被不当归档，也不让读者成为法律裁决者。在 IETF 126，GENDISPATCH 记录的结果是先到 IPR-WG 继续讨论，再进行法律顾问审查。转交是下一步的地点，不是采纳；将来审查也不是已经发表的结论。

2025 年 10 月的 IESG 声明具有另一种、同样有限的作用。它表示，只有当 Contribution 是 IETF Document 且处于狭窄情形时，才可保留衍生权；与政策冲突的提示应在 Contribution 中被忽略，流程负责人可以要求移除。它说明提示在当前政策下的效力，却不授权改写收到的原信，不预先指定每个后续争议的裁决者，也不替代草案未来可能经历的程序。

保存原件，公开状态决定

真正需要避免的是两个相反的捷径。第一个把每个公司脚注当作不透明的否决权。第二个把“忽略”理解为可以让脚注、原文和处理理由从记录中消失。可靠程序不必选择任何一条。

第一层应保存收到的对象：稳定标识符、渠道、时间、完整性摘要，以及提示到达时的原始引用。保存不表示承认。第二层应写明分类对象：是一封消息、特定 Internet-Draft、RFC 文本、上诉、会议记录，还是对其他对象的评论。第三层应指明真正适用的规则及版本，例如 RFC 5378、IESG 声明、IETF Trust 指引或已被正式采纳的更新；提议中的草案必须标为提议。第四层才是行动：有权角色是将提示视为不适用、要求移除、交由审查、要求重新提交，还是没有采取流程行动。

Daniel Kade 将这组关联称为贡献状态凭证。公开部分可以很小：内容标识和摘要、时间与渠道、收到提示的永久引用、对象分类、规则版本、负责角色、行动状态、复核通道和替代决定。敏感通信可保存在受保护附件中，但保密不应遮蔽是否有决定、决定范围及其当前状态。

措辞必须保持边界。“收到提示”不等于“提示有效”；“Contribution”不等于“已采纳文档”；“适用了规则”不等于“给出法律意见”；“要求移除”不等于“原件被改写”；“转交审查”不等于“审查已完成”。只有这样，参与者、主席、档案系统和法律审查者才能各自负责自己的行动。

开放参与不需要给每封信建档

普通讨论不应因为一份凭证而变成昂贵的法律流程。只有当状态争议实质影响文档处理、出现负责人的请求、上诉或被质疑的程序行动时，凭证才有必要。它应当简短、可重复、只针对争议对象，而不是变成参与者的身份档案、发言门槛或邮件列表的许可法庭。

这也正是 Heng Lu 所强调的约束：参与和专业知识可以构成证据，却不是授权。发送者不会因一个脚注而统治 IETF；保存消息的归档或工具也不会因保存它而统治历史。权利规则处理的是一个有限问题，它不会重新分配整个流程的权力。

证据边界

现有来源没有证明 -06 已被采纳、RFC 已更新、IETF 已形成共识或法律顾问已给出最终意见。它们也没有证明任何作者、雇主或归档者存在不当行为。贡献状态凭证是 Daniel Kade 的编辑性建议，不是 IETF 协议、发布条件或修改通信的指令。

来源

  1. RFC 5378 — Rights Contributors Provide to the IETF Trust
  2. IESG Statement on Clarifying Derivative Works Rights
  3. draft-sayre-gendispatch-derivative-06 — Clarification of Derivative Works Restrictions
  4. Minutes: IETF 126 GENDISPATCH
  5. RFC 7282 — On Consensus and Humming in the IETF
  6. Heng Lu — The Multi-Stakeholder Mirage