摘要

  • 第 202201.673 号决议证明的核心事实很窄：AFRINIC 董事会在 2022 年 1 月批准了 AFPUB-2019-GEN-006-DRAFT03。它证明公司层面的接受，却不自动证明授权细节、实施、签名对象、验证器观察或路由处置。
  • 社群共识与董事会批准不是同一个动作。前者可以形成技术政策建议，后者才可能让 AFRINIC 自身的人员、预算、系统、密钥、存储库和风险承担进入一个可问责的公司决定。
  • 最有善意、也最有制度价值的理解是：董事会这道门不是为了否定共识，而是为了阻止“共识会自行执行”的错觉。问题不在于是否保留这道门，而在于门槛两侧的交接能否被重建和核验。
  • AS0 ROA 可以表达消极的路由起源意图，验证器也可能据此得出技术上的 Invalid 状态；但这个结果不是法院判决，更不是对所有网络下达的撤路命令。每个网络仍决定监测、降低优先级、拒绝或不改变路由。
  • 一份合比例的“批准回执”应说明准确版本、共识与申诉状态、交接、公司权限、法定人数、利益冲突、意见、表决、范围、受托执行者、预算、风险、有效条件、复核与纠错，同时明确保留运营商的路由裁量。

决议没有改写提案，却改变了承担者

第 202201.673 号决议值得关注，不是因为它给一项技术设想披上了庄严措辞，而是因为它把同一份提案带过了一个组织边界。AFRINIC 的官方董事会记录与政策登记资料共同指向一个可核验的动作：2022 年 1 月，董事会批准 AFPUB-2019-GEN-006-DRAFT03。该提案的名称是针对未分配和未指派 AFRINIC 地址空间的 RPKI ROA。批准前，提案已经作为明确版本存在；批准后，它仍是那个版本。变化不在字面，而在谁对下一步负责。

这一区别很容易被一句“社群通过了政策”抹平。政策讨论可以汇聚经验、暴露技术异议、测试参与者的支持程度，并形成应当采取某种共同规则的建议。然而，参与讨论的人并不能仅凭共识就支配 AFRINIC 的雇员，也不能替这家公司拨付预算、操作签名密钥、改变存储库、承担合同与运营风险。若政策要进入 AFRINIC 自己控制的系统，就必须有一个能够代表该公司接受责任的机关作出决定。董事会批准的合理功能，正是在这里出现。

因此，批准不是共识的同义词，也不是可以略去的礼仪。共识回答的是：参加这一自愿程序的人是否形成了足以推进的建议。董事会批准回答的是另一个问题：AFRINIC 这家私人机构是否接受在自身合法和合同边界内组织执行。前一个问题关乎讨论程序，后一个问题关乎公司承诺。二者可以相互衔接，却不能互相替代。

同样重要的是，董事会批准也没有把共识升级成公共法律。邮件列表不是立法机关，政策会议不是公共选举，社群参与也不是对地址资源的所有权证明。董事会可以约束 AFRINIC 内部如何行动，却不能凭一项公司决议获得主权、警察权、处罚权、没收权或公共法裁判权。第 202201.673 号决议的力量若要被准确理解，就必须与它的限度一起表述：它是公司承接，不是地区统治。

董事会面前究竟是什么

要理解这个公司承接的分量，需要说明提案机制，但不必把本文变成 Draft 3 的修订史。官方提案页显示，Draft 3 提议由 AFRINIC 针对其当时管理的未分配、未指派 IPv4 与 IPv6 地址空间创建 AS0 ROA。它还规定，在相关资源随后被分配之前，应先撤销并移除覆盖这些资源的 AFRINIC AS0 对象。文本保留了使用独立信任锚定位器的可能性，以支持选择性使用和分别测量；对于回收资源，则要求等回收程序结束后才纳入覆盖。

这些细节只是在界定董事会批准的对象。它们不能代替对批准动作本身的分析，也不能让我们抢先断言后来的实施计划、部署或现行运行状况。尤其不能因为提案写明一种预期技术行为，就说相应对象必定已经签出、进入存储库并被验证器读取。文本、批准和运行分别需要各自的证据。

AS0 机制的技术语义也有必要保持克制。AS0 ROA 表达的是一种消极路由起源意图：被覆盖的地址空间不应由普通自治系统作为起源进行通告。在相应条件满足时，路由起源验证可以把冲突的普通起源归为技术上的 Invalid。但 Invalid 是验证计算的状态，不是关于产权、合法性或行为善恶的司法结论。它更不自动等于丢弃路由。

验证器把所观察到的认证资料转换为结果，网络运营者再决定如何使用结果。有的网络可能只监测，有的可能降低优先级，有的可能拒绝，有的可能暂不改变本地策略。这种最后一公里的自主选择不是技术制度的瑕疵，而是权力边界的事实。AFRINIC 能管理自己的登记与认证服务，不能接管每个网络的路由器。董事会与路由器之间，至少还隔着执行、发布、观察和本地策略数道门。

一条不能压扁的证据链

最清楚的阅读方式，是把整个过程看作一串不能合并的状态。首先，提案人发布并修订文本；其次，政策程序记录讨论、共识以及任何申诉状态；然后，准确版本与程序记录被交给董事会；董事会另行决定公司是否批准；其后才可能是管理层获得限定授权、拟定实施安排、技术系统创建与维护签名对象、存储库对外发布、独立验证器观察，最后由每个网络决定依赖程度。

这条链上的每一环都改变不同的东西。提案发布让一个主张进入可讨论状态；共识让它获得程序上的推荐地位；批准让公司接受有限的组织责任；授权把责任交到具体管理者；实施把文字转换为系统动作；发布让外界可能观察；验证把资料转换成技术判断；运营商政策才可能改变一条路由如何被处理。前一环存在，不能证明后一环已经完成。

区分这些环节并非吹毛求疵。若共识记录有问题，需要检查的是参与、异议、判断和申诉；若董事会权限有问题，需要检查公司权力、法定人数、利益冲突与决定范围；若实施出错，需要检查版本控制、密钥、变更、撤销和纠错；若验证结果异常，需要检查存储库与验证器状态；若路由被不同网络区别对待，则要检查各自的本地策略。把所有问题统称为“政策失败”或“社群决定”，反而会隐藏真正有能力修复它的人。

第 202201.673 号决议位于这条链的中段。它不是起点，因为 Draft 3 和此前的共识阶段先于它；它也不是终点，因为管理委托、实施、发布、验证和运营商依赖均在其后。它的独特意义恰在这个不前不后的位置：公司终于明确承接，但技术世界还没有因此自动改变。