摘要

  • IETF 工作组 grip（G & R for Security Incident Processing）由 Barbara Y. Fraser 和 Klaus-Peter Kossakowski 担任联席主席，于 1995 年 2 月启动，2001 年 12 月结束，隶属运营与管理领域，并与安全领域共同拥有章程。[^1]
  • 该工作组产出 RFC 2350《对计算机安全事件响应的期望》（BCP 21），作者为 Nevil Brownlee（奥克兰大学）与 Erik Guttman（Sun Microsystems），1998 年 6 月 1 日发布，源自 draft-ietf-grip-framework-irt 系列草案。[^4]
  • BCP 21 目前仍恰好只包含这一份 RFC：没有任何文件废止或取代 RFC 2350，但它带有勘误（errata）。[^5]
  • 撰写机构已于 2001 年 12 月停止运作，而标准仍是当前最佳实践——这份指导文件的验证与修复路径如今完全依赖 RFC Editor 与 IETF Datatracker 的公开记录，而非任何存续的工作组。[^3]

一份标准的生命周期长于其撰写者

要理解这个问题的分量，需要先回到 1990 年代中期的背景。当时，计算机安全事件响应团队（CSIRT）正在各机构内快速成立，但组织在向这些团队求助时，对双方的权利与义务并没有公认的框架。IETF 为此组建了 grip 工作组，全称 Guidelines and Recommendations for Security Incident Processing，由运营与管理领域（Operations and Management Area）与安全领域共同拥有章程。[^1]

Datatracker 的已结束工作组列表显示，grip 启动于 1995 年 2 月，结束于 2001 年 12 月。[^2] 六年多的工作中，该工作组的核心产出就是 1998 年 6 月 1 日发布的 RFC 2350。这份文件由当时在奥克兰大学的 Nevil Brownlee 与 Sun Microsystems 的 Erik Guttman 撰写，从 1995 年 9 月的 -00 号草案到 1997 年 9 月的 -07 号草案，历经七个版本才形成最终标准。[^6]

RFC 2350 的核心贡献是一份期望框架：它定义了组织可以合理要求事件响应团队做什么——例如团队应公布其服务范围与联系方式，用户应了解报告事件后会发生什么——以及团队反过来可以对组织提出的要求。它被指定为 Internet 最佳当前实践，编号 BCP 21。[^4]

机构结束后，标准仍然生效

2001 年 12 月，grip 工作组正式结束。工作组不再开会，不再有活跃的邮件列表讨论，两位联席主席也不再以工作组主席的身份承担任何职责。但 BCP 21 并未随之退役：RFC Editor 的 BCP 索引显示，BCP 21 至今恰好只包含一份文件——RFC 2350——没有任何后续文件取代它。[^5]

换句话说，一份定义安全事件响应期望的标准，仍然处在"当前有效"状态，而撰写它的机构已经消失了二十多年。Datatracker 上关于 RFC 2350 的元数据维护记录甚至晚至 2026 年 5 月 20 日——记录仍在被维护，但维护者不是原工作组，而是 IETF 的档案体系本身。[^7]

这正是本文要考察的责任问题。BCP 21 没有被废止，意味着任何引用它的组织、CSIRT 或政策文件，引用的都是一份没有存续所有权机构的现行标准。这不是失职的证据：IETF 的标准并非由永久机构持有，工作组的结束在 IETF 体系内是正常生命周期。但 "正常" 与 "可验证" 是两回事。

可验证性如今依赖什么

对于今天需要确认 BCP 21 状态的读者，验证路径完全通过公开档案，而非任何存续的群体：

第一，RFC Editor 的 RFC 2350 信息页与全文页确认其作者、发布日期（1998 年 6 月）与最佳当前实践状态，并列出已登记的勘误。[^3] 第二，BCP 21 索引页确认该 BCP 至今只包含这一份 RFC。[^5] 第三，IETF Datatracker 的已结束工作组列表与 grip 组页面确认工作组的起止时间与人员。[^1]

需要指出的是，这些记录本身带有明确的边界。Datatracker 在已结束工作组列表上警告说 "已结束工作组的数据偶尔不正确"；[^2] 同时，grip 组页面在 Name 字段显示的 "G & R for Security Incident Processing" 与章程中的全称 "Guidelines and Recommendations for Security Incident Processing" 不一致。[^1] 这些是小型但具体的提醒：即便是最基础的机构记录，也需要交叉核对。

责任归谁的两种读法

一种读法认为，这是 IETF 体系正常运作的体现：标准一旦发布即为社群共有，不需要常设的 "所有者"；RFC 2350 二十八年未经修订恰恰说明其框架足够稳定，没有引发需要接手修订的争议。

另一种读法强调，"无人拥有" 与 "人人共有" 并不等同。BCP 21 带有勘误，而勘误的累积从未升级为一次修订；事件响应领域在此期间发生了根本变化——自动化检测、云环境、供应链事件——而这份期望框架从未被系统性地重新审视。当一个标准的修订机制取决于有人愿意组建新工作组，而二十八年没有人组建，那么 "仍然现行" 更多是一个档案事实，而非治理结论。

本文的立场是第二种读法更符合证据：RFC 2350 之所以仍然有效，是因为无人废止它，而不是因为有人验证并重申了它。对依赖它的机构而言，这意味着引用 BCP 21 时应当意识到，其解释权没有任何存续的机构性来源。

[^1]: IETF Datatracker, grip 工作组页面 — https://datatracker.ietf.org/wg/grip/about/ [^2]: IETF Datatracker, 已结束工作组列表 — https://datatracker.ietf.org/group/concluded/ [^3]: RFC Editor, RFC 2350 信息页 — https://www.rfc-editor.org/info/rfc2350/ [^4]: IETF Datatracker, RFC 2350 文档页 — https://datatracker.ietf.org/doc/rfc2350/ [^5]: RFC Editor, BCP 21 索引 — https://www.rfc-editor.org/info/bcp21/ [^6]: IETF Datatracker, RFC 2350 历史页 — https://datatracker.ietf.org/doc/rfc2350/history/ [^7]: RFC Editor, RFC 2350 全文 — https://www.rfc-editor.org/rfc/rfc2350.html [^8]: IETF Datatracker, API group 1007 — https://datatracker.ietf.org/api/v1/group/group/1007/