摘要

  • AFRINIC 对 AFPUB-2021-GEN-002-DRAFT03 的里程碑记录显示：2022 年 7 月 28 日宣布共识，PDWG 主席同日向董事会发送批准报告，作者也在同日撤回提案。页面没有日内时间，因此不能据此排列三项动作的先后，更不能编造它们之间的因果链。
  • 当时有效程序在 AFRINIC 页面上的表述允许作者通过通知 RPD 邮件列表撤回政策草案，却没有明文规定这项权利在会议粗略共识、Last Call、最终共识宣布或报告送交董事会之后终止。这个文本空缺造成的是程序托管问题，不是任何一方天然胜出的证明。
  • 共识形成了一项应被保存的集体程序记录，但它还不是可执行政策；向董事会发送报告只是交接，不等于董事会批准。现有公开记录没有董事会决议、实施日期、执行动作或由该草案引起的运营变化。
  • 允许作者在批准前撤回，有保护署名责任、阻止有缺陷文本继续前进的善意理由；但若共识之后仍可无条件单方撤回，它也可能成为对集体程序的私人否决。现有记录没有权威裁断这两种主张谁在本案中占优。
  • 合理的制度修复不是把作者、“社群”、主席、董事会或 AFRINIC 描写成互联网号码资源的所有者，而是建立逐阶段的程序托管转移：明确版本、状态、当前保管者、撤回性质、决定者、共识记录的处置、董事会回应、实施状态与纠错路径。

同一天不是同一瞬间

7 月 28 日看起来像一条紧凑的新闻线索：先有一个经过讨论和 Last Call 的政策草案，然后出现共识，接着又出现撤回。只要把正式页面上的三个日期标签顺手连成一句话，叙事就很容易获得戏剧性：作者究竟是在共识之前踩下刹车，还是在共识之后推翻了集体决定？董事会是否已经接住了提案？主席是否来得及处理撤回？然而，记录恰恰不允许回答这些问题。

AFRINIC 页面只把三项动作标在 2022 年 7 月 28 日：共识宣布；PDWG 主席向董事会发送批准报告；作者撤回。它没有列出时、分、秒，也没有附上作者的撤回通知。因而，“同日发生”是事实，“先后如此”不是事实。即使自然语言中的排列顺序会诱使读者把它当作时间顺序，也不能这样使用。页面同样没有说明撤回的原因，所以不能把 7 月 12 日邮件列表上对临时政策后果的实质性异议，推断成作者后来撤回的动机。那封邮件能证明 Last Call 期间仍有具体争论，不能代替完整异议台账，更不能替作者解释决定。

这种克制并非咬文嚼字。三个动作的日内顺序可能影响程序解释，但证据没有提供这个顺序。若共识宣布在撤回通知之前，问题是作者的单方权利是否跨过了集体决定记录的形成点；若撤回通知在共识宣布之前，问题可能变成主席为何仍记录共识；若报告发送与撤回的先后未知，则董事会收到的究竟是一项仍在进行的提案，还是一项状态已经发生争议的提案，也不能靠猜测补齐。把任一假设写成事实，都会让作者、主席或董事会承担记录没有证明的行动含义。

所以，这一事件的第一条制度教训并不是“谁赢了”，而是日期精度不足以承担程序状态转换。当规则把权利系于阶段，正式记录就必须提供足以辨认阶段的时间与收件状态。没有这种精度，归档页看似给出了完整结局，实际上只给出一组互相挤压的标签。

一条完整时间线，六种不同状态

这份提案的标识是 AFPUB-2021-GEN-002-DRAFT03，版本为 3.0，作者为 Jordi Palet Martinez。AFRINIC 的正式提案页记录，它在 2022 年 5 月 18 日提交，目标是修改当时综合政策手册的第 3.1、3.3 和 3.4 条。5 月 18 日至 6 月 1 日，它处于讨论阶段。6 月 1 日，AFRINIC-35 对其进行讨论，正式里程碑记录写下“粗略共识”。

此后，程序进入 Last Call。正式页面把这一阶段标为 6 月 23 日至 7 月 14 日。7 月 12 日的 RPD 存档保留了一项关于草案临时政策后果的实质性反对意见，说明最后征询并非纯粹等候期；但现有材料没有重建每一封邮件、每一个异议的答复以及主席怎样逐项衡量它们，因此不能把一封存档邮件夸大为共识是否成立的完整判决书。

7 月 28 日，正式页面同时记录共识宣布、主席向董事会发送批准报告、作者撤回。8 月 1 日，提案被归档。这条时间线必须完整保留，也必须按状态拆开理解：6 月 1 日的会议粗略共识不是 7 月 28 日的共识宣布；7 月 28 日的共识宣布不是批准；报告发送不是董事会表决；作者撤回不是一份公开可核验的裁决；8 月 1 日的归档也不是对前述冲突作出的法律或程序判决。

尤其重要的是，现有证据没有董事会批准这份草案的决议，没有董事会拒绝、接受撤回或将提案退回的文件，也没有实施日期、实施指令、调用记录或运营变更。围绕这一天的任何分析，都只能停留在“批准之前的程序冲突”上。说董事会已经批准，会把报告传输误写成公司决定；说撤回已在法律上消灭共识，会把状态标签误写成裁判；说共识自动战胜撤回，则会替没有明文截止点的规则补上一条并不存在的限制。

归档保存了结局标签，却没有裁断权利

8 月 1 日的归档很容易被读成最终答案。人们习惯把档案中的最后位置当成制度上的胜负：既然提案进入 archive，似乎就是撤回有效；既然共识先被记录，似乎归档又只是行政整理。但归档能够可靠证明的只有记录保管状态发生变化，即该提案被放入正式档案索引。它不能单凭自身证明谁有权决定晚期撤回，也不能证明董事会曾就冲突作出接受、拒绝、批准或退回。

档案的功能是保存，不是自动裁判。它可以显示版本、日期与最终标签，却不能在缺少理由和规则引用时生成制度正当性。把归档当作裁判，会使档案管理员或网站状态字段无意中获得超出其角色的权力：一个记录动作被误认为解决了权限争议。相反，成熟的记录应当同时保存相互冲突的历史状态——共识确曾被宣布，报告确曾发送，作者撤回也被登记——再另行说明哪一个具名主体依据哪一条规则决定下一步。

这也是为什么共识记录不应随着撤回而被抹去。即使最终决定停止推进，参与者已经投入的论证、异议和主席的分类仍是程序事实。保存它不等于把共识升级为主权命令，也不等于要求董事会必须批准；它只是拒绝让后来的状态变化重写先前发生过的程序。