摘要

  • AFPUB-2026-GEN-001-DRAFT01拟要求PDWG联席主席在公共政策会议前阅读作者的演示稿，确认其内容与已提交提案一致。
  • 若两者有差异，作者必须向邮件列表提交更新版以通知工作组；但草案又明确，更新中的改动即使公开，也未必会被纳入考虑。
  • AFRINIC应为每次提案演示发布一张“演示稿—正文版本凭据”，绑定两份文件、差异、通知消息、程序状态以及最终有资格进入决定的文本。

真正需要固定的不是网页，而是“讨论对象”

互联网社群的政策记录通常不缺材料。网页上有提案，会议页有PDF，邮件列表有讨论，视频保存发言，会议纪要给出结论。问题在于，这些材料都能被找到，并不自动证明大家在同一时刻讨论的是同一段文字。

AFRINIC在现行提案列表中把AFPUB-2026-GEN-001-DRAFT01标为讨论中。提案页面记载，该稿于2026年5月20日提交，作者是Grégoire EHOUMI、Noah Maina与Adeola A. P. AINA。它试图为Policy Development Working Group补齐一整套工作规则，涉及联席主席职责、任命、共识、申诉、罢免与连续性。

草案第3.3.2.1(f)项把一个常被当成会务细节的问题写进职责：会议前，联席主席应阅读演示稿，熟悉细节，并确保演示稿与提案正文一致。如有差异，作者必须在邮件列表上提交更新后的提案，以通知工作组，即使这些改动不会被考虑。

这还不是已经生效的AFRINIC规则。它属于仍在讨论的草案，不能拿未来拟议义务反过来裁判已经举行的会议。不过，这句话准确抓住了政策过程的一个薄弱处：演示稿是解释工具，却很容易在记忆中变成另一份政策文本。

幻灯片必须删减。长条件被压成一句话，例外藏进备注，多个机构的共同责任被画成一根单向箭头。讲者为了回答问题，还会给出更直白的表述。多数时候，这些变化只是帮助理解；但“更容易懂”并不等于“已经按程序提交”。会场里最令人信服的一句话，也未必是社群事前有机会审阅和反对的那句话。

更新版可以用于通知，却尚未取得决定资格

草案最后半句是关键。如果发生差异，更新版必须公开；但其中改动可能不被考虑。也就是说，制度承认一种特殊状态：文本已经进入公共记录，却没有进入本轮决定范围。

同一份更新版可能依次承担三种作用。第一，记录作者在演示中展示了什么。第二，保存作者希望下一轮讨论的修订。第三，在完成通知、讨论期与明确准入之后，成为未来共识判断的对象。版本号升高，不能把这三个程序事件压成一个。

邮件列表消息能证明某个文件在某时到达，不能单独证明讨论期已经重启、旧反对意见仍然适用，或主席已经允许它参加共识判断。网页能证明公众可以打开文件，也不能单独证明文件拥有程序效力。公开性回答“能否看见”，准入回答“能否算数”。

如果记录没有状态，时间会替更新版制造一种未经证明的合法性。后来的文本修掉含混处，看起来更像作者“一直想表达”的内容；纪要只写提案标题，不写具体版本；几个月后，读者自然把整洁的新稿放回旧会议。没有人需要欺骗谁，版本洗白也可能发生。

解决办法并不复杂。每个版本都应拥有清楚状态：仅用于通知；自某日进入讨论；有资格在某次会议接受共识判断；仅对未来替代旧稿；已经撤回。关键不是多造标签，而是让文本跨越权限边界的时刻可见。

AFRINIC-37留下的是一次概念说明，不是共识决定

AFRINIC-37会议纪要为分析划出了事实边界。会议于2026年6月24日举行，AFPUB-2026-GEN-001-DRAFT01安排在10:15至11:05。纪要链接作者演示；演示资料索引列出对应的496 KB文件；20页PDF也使用同一个提案编号并列出作者。

更重要的是，纪要明确写道，邮件列表讨论仍在继续，作者尚未准备好寻求共识，只是要求更多时间介绍概念与政策细节。Alain Aina把这次发言描述为向社群解释想法、收集反馈的机会。会议收尾记录显示，这项提案被送回邮件列表。

因此，现有证据不能支持几个更戏剧化的说法：不能说演示稿与Draft01存在实质冲突，不能说某项差异改变了AFRINIC-37决定，不能说会议无效，也不能指控作者、主席或工作人员误导参与者。作者当时根本没有要求对这项提案作共识判断。本文分析的是草案为未来设置的版本边界，而不是重判那次演示。

5月25日的RPD邮件公告展示了一个简洁的“提案入场凭据”：联席主席说明收到新草案，写明编号与作者，链接正文，并邀请成员表达支持、反对、疑问和修改建议。读者可以确定是哪一份文本在何时进入讨论。演示稿也应接上这条链，而不是另开一条无状态的支线。

现行政策制定流程与Consolidated Policy Manual构成Draft01希望修改的制度底座。它们提醒读者区分“现行规则”和“拟议规则”：草案中写下的核对义务，不能被描述为今天已经约束AFRINIC的全部程序。

“一致”不是逐字相同，也不能只靠人工印象

两份文件是否一致，不能用一个简单的红绿灯回答。排版、缩写与顺序变化通常不影响规则；忠实的案例或流程图属于解释；改变主体、权限、期限、门槛、义务、例外与申诉权，则会改变制度含义。

真正有效的核对应按差异类型记录。编辑性差异可以略记；解释性差异要说明它对应哪段正文；实质性差异必须标出幻灯片页码与提案条款，并触发更新版通知。尤其需要留意动词：把“必须”改成“应当”，把“可以”画成自动流程，或省略一个前提，常常比新增一整页更有后果。

文件哈希不能判断语义是否相同，责任人仍需作判断。哈希解决的是更基础的问题：当时究竟比较了哪两个文件？提案正文与演示稿各自的SHA-256摘要一旦进入记录，即使后来同一URL下的文件被替换，原核对也不会错误地漂移到新文件上。

时间戳同样重要。AFRINIC应记录何时收到演示稿、何时完成核对、何时发现差异、更新版何时到达邮件列表。会后才发布的文本可以记录会场内容，却不能倒推为会场的正式对象；会前很晚才出现的文本即使人人可下载，也可能没有满足合理讨论期。

没有差异也应留下短结论：“已比较以下两组哈希，未发现实质差异。”沉默有三种解释：两者相符、没有核对、或差异被非正式修正。明确的否定性凭据，才能把“没有事件”变成有限但可用的证据。

一张足够轻量的版本凭据

凭据第一部分固定提案：编号、版本、规范URL、提交时间与内容哈希。第二部分固定演示稿：文件URL、收到或发布时间、页数与哈希。第三部分写明负责核对的联席主席与完成时间。

如有差异，表格按幻灯片页码与提案条款列出变动，区分编辑、解释和实质性内容。实质差异应链接邮件列表通知、更新版文件、各自时间与哈希。这里无需公开冗长的逐字diff，只要让人能定位权利、义务或程序效果发生了什么变化。

随后是整张凭据最重要的字段：程序状态。更新版究竟“仅通知”，还是已经从某日进入讨论？能否在下一次PPM中被考虑？讨论期是否重新计算？旧版是否仍是过去会议的准确对象，只是在未来被替代？这些问题不能靠Draft02这样的文件名让读者猜。

未来会议纪要与任何共识公告都应引用有资格参与决定的精确版本。更正文件不应覆盖参与者当时看见的证据，而应生成一条与旧记录相连的新状态。政策文本不是普通网页内容；它是社群把同意转化为机构权力的载体。

“演示稿—正文版本凭据”是Theo March的编辑建议，不是AFRINIC已经宣布的产品或制度。公开资料也不足以判断AFRINIC内部是否保留类似核对记录。建议只提出一个窄结论：既然草案把核对设为责任，又明确公开更新不代表采纳改动，那么责任是否履行、哪份文本可以算数，就应对社群可复核。

来源