摘要

  • AFPUB-2026-GEN-001-DRAFT01 试图明确 AFRINIC 政策发展工作组的运作方式、共同主席职责以及共识和机构后续程序。
  • 2026 年 6 月 24 日 AFRINIC 37 会议上，作者表示草案尚未准备好寻求共识；会议记录显示它被送回邮件列表，目前仍列为“讨论中”。
  • 下一版最关键的设计，不是增加更多原则，而是让每次状态变化都绑定准确版本、决策者、意见、异议、期限、理由和复核路径。

没有寻求共识，本身也是程序发挥作用

AFRINIC 37 最值得注意的并不是通过了什么，而是作者没有要求会议对这份草案作出共识判断。他们选择解释概念并继续收集意见，明确承认议题复杂、文本尚未成熟。

这避免了一个常见混淆：在会议议程上介绍政策，不等于请求授权其进入下一阶段。现场时间有限、参与者已经投入成本，机构又希望尽快形成结果时，介绍很容易被叙述成决定。此次暂停保留了二者之间的边界。

时间线也必须保持清楚。官方页面把草案提交日记为 2026 年 5 月 20 日；共同主席在 5 月 25 日将其发送到 RPD 邮件列表征求意见；6 月 24 日会议只进行概念讨论；会议记录随后将它列入退回邮件列表的提案。到报道冻结时，官方索引仍称其为“讨论中”。

这些事实既不代表采纳，也不代表对内容作出终局否决，更不代表实施。它们描述的是一项仍在进行的政策工作。

把惯例写下来只是第一步

作者指出，现行 PDP 只给出了最低框架，工作组在实践中形成了多种没有写明的做法。支持某种做法的人会称它是长期惯例，反对者则可能认为它从未获得授权。通过文字明确角色和程序，可以减少这种冲突。

但书面规则仍可能不透明。条文可以说明“谁”作决定，却不记录他面对的是哪个版本；可以规定期限，却不记录期限从何时开始；可以使用“共识”一词，却不保存关键异议及其处理理由；也可以宣布批准，却不区分批准日期与真正生效日期。

因此，这项改革需要的不只是更新政策手册，还需要一套关于政策过程本身的决策账本。

每一次权力交接都应有凭据

提案触及的控制面很广：谁可以参与，如何选择和替换共同主席，工作组如何组织，谁判断粗略共识，共识无法形成时由谁接手，董事会如何批准，以及争议通过什么机制复核。

这些动作不能压成一个状态字段。收到提案时，应记录作者、时间和原始字节。发布时，应把公开页面绑定到确切版本。判断是否进入会议时，应记录适用截止时间和规则。判断共识时，应列出实质异议并说明为什么它们已经解决或仍然阻挡进程。如果工作组无法就共同主席人选形成共识，草案规定由 Number Council 任命临时共同主席；账本应记录触发条件、期限、获任人及理由。董事会批准应是独立行为。实施则应列出实际生效文本、系统变更和日期。

账本不需要公开私人数据，也不应把每封邮件变成投票。它只需要让一个没有参加现场的人能够沿着证据重建状态为何改变。

这样可以防止几种危险的继承关系：旧版本获得的支持不应自动归给新版本；会议介绍不应被当成共识征询；主席的判断不应被写成董事会批准；批准也不应在系统尚未改变时被说成已经实施。

参与资格必须衡量实际贡献

RPD 讨论中，一名参与者质疑用近期参加线下会议作为资格条件。他认为，在幅员辽阔且出行成本明显的地区，这种要求并不现实。他还反对通过共识任命共同主席，认为这会带来过强主观性，并主张董事会应能说明理由后拒绝批准。

这些是参与者意见，不是 AFRINIC 的事实认定。但它们提出了有效的目的测试。如果规则想衡量持续参与，就应考虑邮件列表贡献、远程参会、文本分析、问题整理和提案工作，而不只是出行。如果规则想确保可信管理，任命记录就应说明候选人、资格、利益冲突、选择方法和未解决异议。

一条表面中立的资格标准，如果实际衡量的是出行能力而非政策贡献，就会改变谁能够进入权力链条。

共识、批准和实施是不同控制点

粗略共识并不是支持邮件的计数。它需要判断重大异议是否已经得到回应。也正因为需要判断，结论必须绑定特定版本并说明理由。共同主席应公开他们考虑了哪些异议、文本如何变化，以及剩余分歧为什么阻碍或不阻碍提案前进。

董事会承担不同职责。法律、受托或运营问题可能不属于工作组讨论的范围。机构分工不应变成自动批准，也不应成为无声否决。拒绝或延迟需要理由、期限和返回路径。

实施又是第三层。员工需要记录依赖、计划和生效日期。只有到那时，运营商才能把机构决定与真正影响申请和登记的有效规则区分开。

下一版应在每一步回答七个问题：准确的文本是什么，谁有权决定，考虑了哪些证据和异议，适用哪条规则和期限，作出什么决定及其理由，接下来进入什么状态，以及谁能依据什么记录复核。

这份提案目前仍在讨论。它的价值不是已经解决 AFRINIC 治理，而是让仍需明确的权力交接显现出来。

来源