摘要

  • draft-ietf-procon-2418bis-04 于 2026 年 8 月 17 日发布，新增一句：工作组可以把 Internet-Draft 恢复为未采纳状态，例如因为关注度下降。紧邻的 -03 版本没有这句话。
  • -04 当前仍是 WG Document，IESG 状态仅为 I-D Exists，并非已经生效的 IETF 最佳现行实践，也没有取代 RFC 2418。
  • 采纳的实质是选择一份工作底稿并把修改控制权交给工作组，不是确认全文已有共识，更不保证最终成为 RFC。因此，取消采纳改变的是机构托管关系，不会自动判定技术方案错误。
  • 可靠的退出凭证应串联原始采纳、工作组控制的最后版本、退出讨论与理由、共识判断、目标状态、编辑权移交、后继文本及外部依赖，并明确未采纳、搁置、放弃、到期和停止部署彼此不同。

补齐“进入”之后的那句话

第 4 版草案第 8.2 节先界定采纳：工作组可以正式采纳一份 Internet-Draft，把它作为某项工作的基础。紧接着，文本限制了这个动作的含义——采纳不代表文档内容已经形成共识；编辑的任务，是把工作组后续讨论的结果写进文档。该段最后新增一条退出路径：工作组也可以把草案恢复为未采纳状态，并以关注度下降为例。

第 3 版已经强调“采纳不等于同意全文”，但到编辑职责为止，没有写出反向转换。-04 的变更记录又明确列出“修改草案采纳文本”。因此，这不是从笼统的制度改革中推测出来的新意，而是可以在连续两个版本之间核验的文字变化。

这句话没有建立完整程序。它没有规定通知期限、人数门槛、申诉步骤，也没有说明“关注度下降”如何量化；更没有声称某个工作组已经据此撤回一份具体草案。它的意义在于承认一种最基本的制度事实：集体可以接手一项工作，也必须能够诚实地结束接手状态。

这种状态影响外部判断。产品团队会据此安排原型，其他标准文本会建立引用关系，供应商可能把 draft-ietf 名称当作路线信号。退出时，登记系统必须回答究竟是什么停止了：是工作组不再投入，还是方案被技术性否决，抑或运行网络已经弃用。三个问题需要三套证据。

它仍是现行草案，不是新规则

PROCON 文档页把 draft-ietf-procon-2418bis-04 列为 2026 年 8 月 17 日发布的新 WG Document。独立记录页显示，其预期状态为 Best Current Practice；若日后获批，它计划废止 RFC 2418 与 RFC 3934，并更新数份后续 RFC。

截至 8 月 27 日，实际程序位置还很靠前：IESG 状态是 I-D Exists，没有 document shepherd、负责的 Area Director 或 telechat 日期；若不更新或推进，草案将在 2027 年 2 月 18 日到期。同一列表中的 2026bis-11 已进入 Working Group Last Call，2418bis-04 没有。相邻两行并不共享程序状态。

PROCON 章程确实授权工作组整合长期分散的程序文件，并允许就工作组采纳草案的指导原则作非编辑性修改。章程证明议题在授权范围内，却不等于批准本版措辞。

在正式程序产生替代文本之前，RFC 2418仍是已发布的 BCP 25 基线。一份严谨的制度清单应同时保留“当前规则”和“拟议替代文本”，分别标注日期与状态。把 -04 当作随口建议会低估其制度背景；把它写成已经实施的新规则虚构了尚未发生的决定。

采纳移交托管权，不授予真理证书

RFC 7221对工作组采纳的常见做法给出清楚解释。原始持有人会被提醒，文档的修改控制权将交给 IETF；主席检查知识产权披露、判断工作组 rough consensus、选择编辑、安排 draft-ietf 版本，并确保个人草案与替代它的工作组草案相互链接。

判断标准是：这份文本是否足以成为继续工作的合适平台。RFC 7221 用两个短语划界——“初始，而非最终”；“采纳，而非批准”。文本不必已经完整，采纳也不保证发布为 RFC。工作组接手后，可以在章程和 IETF 程序范围内改变内容；除非另有明确约定，采纳不表示同意原稿的每一部分。

这是一项真实的权力变化。原作者不能再把个人偏好说成工作组决定，编辑也必须依据集体结论落笔。与此同时，工作组承担持续评审、版本治理和保存决定记录的责任。采纳更像把一个案件列入集体案卷，而不是给现有方案盖上永久合格章。

所以，反向转换也应在同一层次理解。恢复为未采纳，意味着工作组不再承诺以这份文档作为工作项目基础，或不再承担其修改控制。它没有逻辑能力抹掉此前支持采纳的理由，也不会自动解决后来出现的每个技术争议。

旧状态模型早已留有侧门

-04 把退出直接写进拟议继任文本，但 IETF 的既有文档并非只允许单向前进。RFC 6174定义了工作组 Internet-Draft 状态模型。Call for Adoption by WG Issued 表示正在考虑、尚未选中；若最终没有采纳，草案回到没有特定流状态的位置，但历史日志仍保存这次征求。Adopted by a WG 记录从个人草案到 draft-ietf 首版之间的过渡，WG Document 则表示已采纳且正积极开发。

模型还区分了旁支状态。Parked WG Document 可用于缺少作者或编辑、等待另一份文档或评审、暂时无法推进的工作，并可注明重新启动的条件。Dead WG Document 表示已放弃，但 RFC 特别说明 Dead 并非永远不可恢复；未到期文档还可以在得到必要同意后转入其他工作组。状态图没有画出某条箭头，也不代表相应转换必然被禁止。

这些词回答不同问题：

  • WG Document 表示工作组持有并积极开发；
  • Parked 表示托管仍在，但推进暂停且有原因；
  • Dead 表示本工作组的开发已经放弃，历史和可能的恢复仍保留；
  • Non-adopted 表示它不再是工作项目基础，后续控制者必须另行说明；
  • Expired 只表示资料库时钟到点，不能替代集体处置决定。

2418bis-04 尚未完整解释新措辞如何映射到 Datatracker 的每一种状态。这是需要后续文本或工具落实的开放问题，不应靠媒体自行合并概念。

RFC 7221 还说明，工作组没有义务永远保留已采纳草案。工作组放下文档后，任何人都可以在遵守版权限制的前提下，作为 Individual Submission 或 Independent Submission 继续推进。离开工作组可能是权威和场所的变化，而非技术对象消失。

“未采纳”不是技术判决书

所谓关注度下降，背后可能是完全不同的原因：问题紧迫性降低、找不到编辑、评审能力不足、另一份文档吸收了有效方案、外部依赖迟迟没有解决、实现方向已经转移，或者存在尚未克服的技术反对意见。这些情况都可能支持重新分配工作资源，却不能产生同一种技术结论。

RFC 7282强调，rough consensus 不是支持人数的简单统计；反对理由的内容以及是否得到回应更重要。退出也应如此。邮件数量下降不是自证理由，主席宣布状态变化也不应省略提出的问题、讨论期和共识判断依据。

文档状态更不能直接控制实际网络。一份被放下的草案可能已经进入代码或实验；一份活跃 WG Document 也可能尚无生产部署。机构状态回答“谁以什么权威维护文本”，实现证据回答“哪些系统实际做了什么”。

Heng Lu 关于最小初始规范、未来决定本地化与自愿采纳的论述，为这一区分提供了编辑框架：协调文本可以确立共同参照，却不会仅凭发布就命令所有外部主体实施。这个框架不是 IETF 程序证据；它提醒读者，采纳不等于部署命令，取消采纳也不是远程关机按钮。

最稳妥的公开表述应保持狭窄：“工作组在某日基于已记录的理由，把某版草案恢复为未采纳状态。”若要说技术被否决、RFC 被撤回或服务停止，必须另找直接证据。

一次干净退出应保留什么

第一层是身份链。应记录被考虑的个人草案、替代它的 draft-ietf 文档、关键版本和内容哈希，并链接原始采纳征求与主席的共识公告。缺少这些链接，后续个人版本可能被误判为无关重复，也可能被错误包装成工作组的正式延续。

第二层是退出决定。谁提出恢复未采纳，讨论持续多久，继续与停止各有哪些理由，哪些反对意见未解决，主席如何判断 rough consensus，都应可追溯。“关注度下降”最好由找不到编辑、无人回应评审征求、已有替代工作等具体事实支撑，而非作为无需证明的万能标签。

第三层是目标状态与控制权。文档究竟回到无特定流状态、搁置、放弃、被替代、转组、到期，还是转为个人提交？工作组编辑权在哪个时间点结束？最后一份可代表工作组的版本是哪一版？这些问题不能只靠文件名猜测。

最后，技术账本应与处置账本分开保存。开放问题、安全分析、实验结果和未解决反对意见，对接手者仍有价值。停止未来投入，并不授权删除过去形成的知识。

退出凭证

一份紧凑凭证应包括：采纳链上的名称、版本和哈希；采纳征求、决定、日期与理由；工作组控制的最后版本；退出提案和讨论；主席的共识判断；准确的目标状态；编辑权与修改控制的终止；替代、转移或继续提交的链接；保留的技术问题；已知实现、部署和文档依赖；对章程、里程碑或 Area Director 的影响；以及明确的非结论声明。

只记录进入，会让已经结束的机构授权继续附着在文本上；退出时删除进入记录，则会改写历史。双向记录让托管可以结束，让证据不会消失。

来源