摘要

  • IETF现行资料库通常在Internet-Draft发布185天后将其标为过期，除非正式处理状态阻止过期。这个标签描述活跃版本的生命周期，并没有指出哪个机构否决了提案。
  • 活跃Repository与Archive承担不同功能。版本会因更新、被替代、出版为RFC或到期而离开活跃资料库，历史版本仍可保存在Archive中。
  • 官方历史直接证明两者不可混写：draft-iab-protocol-maintenance-05过期后继续修订，最终成为RFC 9413；draft-ietf-netvc-testing多次过期，但真正有理由的终止记录是后来单独出现的IESG Dead状态。
  • 尽调需要一张“草案状态回执”：精确版本、发布日期与到期日、归档和替代链、工作组及文档流状态、采用与Last Call证据、明确处置、实现依赖及结论责任人。

把时钟写成裁决的清单

设想一家设备采购方正在评估一项新协议。分析员打开IETF Datatracker，看见最新Internet-Draft显示Expired，便在风险登记册中写下“IETF已否决”。产品团队据此撤下路线图项目，审计报告再引用这条结论。几个月后，同名草案出现新修订，登记册又把状态改成“IETF重新批准”。

两次判断都越过了证据。第一次把自动到期日变成机构决定，第二次把新文件变成认可。系统观测到的事实——过期与更新——都是真的；它虚构的则是两次授权性结论。

“否决”不是一个没有主语的状态。谁否决了什么？工作组没有采用？主席判断没有rough consensus？Area Director拒绝承接？IESG终止出版请求？作者只是没有在期限内提交新版本？原草案被另一名称替代？还是讨论仍在继续，文件恰好跨过自动时钟？

仅凭Expired无法回答。它最多说明一个生命周期条件发生了。治理记录必须另行寻找真正解释机构行为的事件，并保存决定者、权限范围、适用版本、日期与理由。

Repository、Archive与185天事件

IETF作者资源的现行说明把Internet-Draft Repository与Internet-Draft Archive明确分开。Repository保存活跃版本。出现更新版本、被另一草案替代、出版为RFC或者到期时，该版本不再活跃。Archive则保存各个版本及其渲染形式，只有极少数特殊情况才会移除。

现行规则通常让草案在进入Repository后185天到期。某些正式处理状态会阻止它到期，例如IETF文档流的IESG出版处理，或者Independent Submission Stream中的Independent Series Editor审查。这一点很重要：时钟本身也会读取流程状态，而不是一把对所有文件机械落下的六个月闸刀。

Archive保留文本，不等于把Internet-Draft变成正式档案出版物。同一份现行说明强调，草案仍是work in progress，引用时也不应赋予其他身份。保存回答的是“当时写了什么”，不是“IETF批准了什么”。

再看1996年的RFC 2026第2.2节，差异更清楚。BCP 9当时把Internet-Drafts目录描述为公开演进中文本、接受非正式审阅的工具。草案六个月不变且未获IESG建议出版，就会从目录移除；提交新版本会重新启动期限。RFC 2026还明确说，Internet-Draft没有正式地位，随时可能改变或移除。

基础设施已经演进：现在采用185天表述，也通过Archive长期保存历史版本。但治理边界没有倒转。草案仍不是RFC，资料库到期也仍不能替代可归责的流程决定。

一个标签装不下四种状态

可靠系统至少要把四层事实分开。

第一层是文档身份。draft-example-foo-04不是抽象的“Foo提案”，而是一份具有发布日期、具体字节与引用集合的修订。05版可能修复安全条件、改变消息格式或缩小适用范围。省略版本后缀的评估无法证明自己究竟读了哪份文本。

第二层是资料库生命周期。Active、updated、replaced、published和expired解释某一修订为何仍是活跃副本，或为何离开活跃视图。它们帮助读者寻找当前文件，却不单独表达技术质量或共识。

第三层是流程状态。个人提交、候选工作组采用、已采用的工作组文档、工作组Last Call，以及处于IESG评估中的出版请求，不是同一种机构位置。RFC 2418第7.2节把Internet-Drafts视为工作中的文档；第7.4节另行规定工作组Last Call；第7.5节又把推进文档所需的rough consensus与提交IESG写成独立步骤。

第四层才是处置。有权限的主体可以记录采用、替代、撤回、拒绝承接、批准、出版或终止，并可能留下理由和申诉路径。真正的不利结论应在这一层寻找，不能从生命周期层反推。

四层可以分别变化。工作组仍准备修改的文档可能到期；活跃的个人草案可能没有任何机构承接；已经有人实现的设计可能出版请求失败；过期修订也可能被同名新版本接续。单一红黄绿标签无法诚实承载这些组合。

过期后成为RFC 9413的草案

Maintaining Robust Protocols的官方历史给出了“过期等于否决”的直接反例。05版在2021年7月12日发布，系统于2022年1月13日记录到期。06版在2022年5月10日出现，随后还有07至12版。IAB把文档推进到Community Review和IAB Review，记录共识与批准，并于2023年2月送交RFC Editor。

最终文本在2023年6月出版为RFC 9413。早期到期事件是真实历史；把它写成IAB或IETF否决仍然是错误叙述。时钟既没有阻止后来修订，也没有提前预言审阅和出版结果。

这个案例不证明多数过期草案都会回来。它只证明一个必要而有限的命题：过期与否决在逻辑上不等价。如果数据模型只能先写“否决”，以后再覆盖成“批准”，它丢失的正是治理所需要的事件链。

正确记录会同时保留全部事实：2022年1月13日，05版因自动到期离开活跃状态；5月10日，06版发布；此后的条目分别说明审阅机构和决定；RFC 9413记录最终档案出版结果。每个事件都有自己的时间、主体与含义。

真正终止另有决定者与理由

Video Codec Testing and Quality Measurement的历史展示相反方向。05版在2017年9月过期，06版一个月后出现；06版在2018年5月过期，07版于7月提交并进入工作组Last Call。07版在2019年1月到期时，工作组状态仍记载为已经形成共识、等待write-up。08版随后进入出版程序和IETF Last Call。

真正具有治理意义的不利记录到2020年3月25日才出现。IESG状态改为Dead，Area Director同时写明：在多次尝试推动解决IESG评估意见之后，NETVC工作组仍缺乏完成文档所需的动力。系统在同年8月还记录了一次自动到期。

这时，分析员拥有可以引用的终止证据：日期、流程主体和理由都存在。理由是动力不足以及评估意见未解决，并不等于某个技术定理证明测试方法毫无价值。文档shepherd的记录甚至说明相关方法已被AV1实现者使用。实现依赖、出版处置与资料库到期是三个不同事实。

如果只把最后一次到期叫作“否决”，反而会丢掉最好证据：明确的IESG状态变化和说明。若把更早几次到期叫作否决，则与后续工作继续的事实直接冲突。

复活也不等于批准

这条界线是对称的。过期不能证明否决，新版本也不能证明接受。符合要求的个人可以提交Internet-Draft；新修订可能回应意见、恢复可见性、重启讨论，也可能只是作者保留继续工作的选择。正式地位仍须来自相应流程记录。

文件名也不能独立承担所有证明。draft-ietf-...通常反映工作组采用，但精确工作组状态和历史仍是依据；名称不证明工作组对每句话都存在当前rough consensus，更不证明IESG已批准。Last Call启动特定审阅，也不是最终出版。

running code同样不能伪造机构地位。实现证据对判断互操作性、实际价值与转换成本极其重要。Heng Lu关于Running-Code Primacy的论述正是对纸面权威的必要约束。但实现是部署事实的证据，不是共识记录。成熟做法是同时保存代码和流程，让二者互相检验，而不是互相冒充。

外部采用者也必须承担自己的决定。采购方为了在RFC出版前获得新能力，可以有意锁定某个草案版本。这并非天然不合理，但义务来自采购合同，而不是资料库徽标。合同应写明精确版本、变更规则、兼容测试与退出路径。

主张取消到期的草案仍只是草案

个人草案Removing Expiration Notices from Internet-Drafts主张，在草案已经长期归档的环境中，自动到期失去了原有作用。它指出，过期草案仍被引用，一些系统只是改变展示或搜索方式。这份文档可作为经验丰富的参与者对机制存在分歧的证据。

但它本身也是最新修订已经过期的Internet-Draft。这个巧合既不能用来嘲笑提案，也不能替提案制造权威。IETF没有把它采纳为现行规则。人们可以评价论点，却不能把文档的存在写成“IETF已同意取消到期”。

这恰好体现全文的纪律：草案可以包含很强的推理，却没有正式地位；流程标签可以准确，却不自动裁定技术价值。只有被授权的主体通过可追溯记录把两者连接起来，才形成治理意义上的决定。

草案状态回执

技术清单应保存足够证据，让未参加原讨论的人也能重建结论，而不用猜测某一天的徽标代表什么。

字段 能证明什么
精确名称与修订 评估的是具体文本，而非漂移中的提案名称
内容指纹 被审阅字节是否与保存版本相同
发布与到期日期 时钟事件及当时适用的规则版本
Repository状态 该修订是否仍活跃，以及为何离开活跃状态
Archive位置 历史文本和渲染结果在哪里保存
修订链 前后版本的关系，同时避免把它们视为相同文本
替代关系 是否由另一草案名称接续或取代
文档流、承接者与工作组 哪个机构如有，负责下一流程步骤
采用状态 工作组是否把它纳入工作，以及证据是什么
共识与Last Call 哪次审阅针对哪个版本，尚有哪些实质异议
IESG或其他文档流处置 真正的决定、主体、日期、状态与理由
出版结果 若成为RFC，其编号、文档流与类别
实现依赖 代码、测试、部署或外部引用在状态变化后是否仍相关
外部采用文书 哪份合同或政策选用了哪个版本，如何处理更新
责任人与复核日 状态、实现或引用改变后由谁纠正记录

这张回执阻止两种相反错误。把Active、adopted或Last Call写成“IETF批准”，属于权威膨胀；把Expired写成“IETF否决”，属于权威捏造。前者需要正面决定证据，后者需要不利决定证据。时钟都无法单独提供。

来源

结论

Expired是有用警告：活跃修订越过了新鲜度边界，继续依赖需要重新尽调。它不说明工作为何停止、是否有人判断技术方案，也不证明相关机构曾经作出决定。

可执行规则很简单：把到期当作时钟回执，把处置当作权威回执，两者都要保存。若提案被终止，就写明决定者、流程、版本、日期与理由；若它恢复修订，就记录新版本而不虚构批准；若实现者或采购方继续依赖，就以自身权限记录这项选择。日历可以让文档变旧，却不能替机构投票。