摘要

  • 第201808.446号决议批准的是“IPv6政策与参考资料更新”AFPUB-2018-V6-001-DRAFT01，而不是另一个涉及IPv6子分配的V6-002提案。准确的编号不是文书洁癖，而是重建适用文本的第一步。
  • 2018年8月8日的表决完成了AFRINIC内部的公司批准，却没有让新条款在当天自动成为实际工作手册。行动事项201808.22要求董事长通知PDWG联合主席，行动事项201808.23另行要求员工实施；AFRINIC记录的实施日是11月23日，公开公告日是11月29日。
  • 从批准到实施相隔107个日历日，从实施到公告相隔六日。现有材料没有说明107日内每一项工程工作，也不支持指控不当拖延；它所能证明的是，批准、执行和发布在事实与制度上并非同一动作。
  • 这条可追溯的链条是合格的私人服务维护：有议程、有推荐、有编号决议、有投票记录、有责任分派、有版本化手册、有实施回执。它提高了账簿服务的可信度，却不会产生主权、立法、监管、警察、检控、处罚、没收或公法裁判权。

L3 — 一次投票留下的两项未完成工作

先把时钟拨回2018年8月8日的董事会会议。议程第9.1项摆在桌面上的，是PDWG联合主席转交的“IPv6政策与参考资料更新”提案。会议纪要把这项提案与邮件档案项目008500联系起来；第201808.446号决议则记载，提案已经走过PDP、达到被联合主席确认的共识，并由主席方向董事会推荐。SO提出决议，SI附议，全体一致通过。到这一刻，董事会完成了一项清楚、可编号、可回查的公司行为。

然而，纪要没有把这个表决写成终点。它马上列出两项尚未完成的工作：行动事项201808.22交给董事长，要求其告知PDWG联合主席；行动事项201808.23交给员工，要求其实施已经批准的政策。仅这一处安排就足以否定“8月8日投票即等于新条款当天生效”的叙述。如果实施已经随表决自动完成，就没有必要再把实施列为员工的后续任务；如果外部沟通已经完成，也没有必要另列通知责任。

8月21日的公告进一步把这种时态差异写得很明白。公告回顾董事会在8月8日批准V6-001，同时使用面向未来的安排：员工将继续实施，完成后再通知社群。这份公告能证明批准已经发生，也能证明实施当时仍被当作下一步；它不能反过来证明手册已于8月8日改变。这里最容易犯的错误，是把“获得实施授权”压缩成“已经实施”。两个说法只差几个字，却把公司决定和操作结果混成了同一件事。

后续记录给出了操作层面的日期。AFRINIC的实施经验报告以及AFRINIC-29会议记录，都把V6-001纳入《综合政策手册》1.3版的日期记为2018年11月23日，并说明该政策已经实施、处于有效状态。11月29日的公开实施公告再次确认，CPM 1.3包含这项IPv6政策与参考资料更新。于是，从8月8日批准到11月23日实施，共107个日历日；从11月23日实施到11月29日公开公告，又相隔六日。

这107日首先是一个算术事实，不是一项道德判决。现有公开记录没有逐日展示员工在其间做了哪些编辑、测试、审阅、发布或内部准备，也没有证明某位运营者因这个间隔遭遇具体损失。它同样没有显示是否存在早于11月23日的内部部署。因此，把107日说成拖延、隐瞒或失当，都会越过证据边界。更稳健的结论是：董事会的批准与手册的实施之间客观存在一段时间，而公开记录允许读者分别定位这两个动作。

这条时间线的起点还应再向前稍作定位，但不能把本文写成提案技术内容的复述。Jordi Palet Martinez在2018年3月11日提交了Draft 1，正确编号为AFPUB-2018-V6-001-DRAFT01。AFRINIC-28的记录显示，该提案于5月9日进入Last Call；工作人员当时表示，按文本实施不会影响AFRINIC自身运营。那是一项可实施性判断，不是11月已经完成实施的证明，更不是对所有运营者成本为零的普遍结论。Last Call也不是董事会批准：它位于程序链的前段，只能说明提案到达了一个过程节点。

编号问题值得单独强调。第201808.446号决议批准的是V6-001，不是V6-002。V6-002是另一个涉及IPv6子分配澄清的提案；在AFRINIC-28的同期记录中，它需要更多讨论。把二者混在一起，不只是把文件名抄错，还会把不同提案的议题、程序状态与后续命运接错。任何试图判断“哪段文字何时适用”的人，都必须先回答三个基本问题：是哪一个提案、由哪一个决议批准、进入哪一个版本。只要第一个答案错了，后面再精细的制度分析也会建立在另一份文本之上。

因此，这条链条可以拆成四个彼此衔接、又不能互相替代的动作。第一是推荐：PDWG联合主席把他们认为已达共识的提案交给董事会。推荐说明内部讨论程序达到了转交节点，却不是手册编辑动作。第二是批准：董事会通过编号决议，记录其公司层面的采纳。批准为AFRINIC自己的后续工作提供内部授权，却没有自动改写正在使用的CPM。第三是执行：员工把被批准的变化纳入实际手册，并处理相关的删除与重新编号。第四是发布：机构用一个可识别的版本和日期告诉使用者，哪份文本现在是工作依据。

四步之中，任何一步都不宜被浪漫化，也不宜被贬低。没有推荐，董事会难以证明自己是在接收已完成相应内部程序的项目；没有批准，员工的修改缺少一个可回查的采用动作；没有执行，决议仍然只是意向与授权；没有发布，外部使用者无法可靠辨认实际文本。它们共同组成一条服务变更链。链条的价值就在于每一环都有自己的证据功能，而不是所有环节被一个模糊的“政策通过了”所吞没。

从运营者或hostmaster的角度看，区别尤其实际。处理请求、准备材料、解释分配或利用条文时，人们面对的不是抽象的“共识气氛”，而是一份具体版本的工作手册。若8月8日到11月23日之间有人只看到董事会决议，他至多能知道改变已经获准、实施将到来；若他要判断当时工作的手册究竟是哪一版，仅靠决议仍不充分。11月23日的实施记录与CPM 1.3提供了更接近实际适用文本的回执，11月29日公告则把这一变化公开传达。

这种区分能防止一种常见的追溯性错觉：后来的人看到提案最终进入CPM，便把最终状态投射回批准日，仿佛中间不存在版本转换。如果这种写法成为机构习惯，员工与成员可能依据不同版本工作；提交者可能按新条文准备材料，处理者却仍按旧文本审核，或反过来。结果未必是巨大冲突，也可能只是往返解释、重做证据、延迟规划或调整编号。但这些交易成本正是版本管理应当消除的对象。

反过来说，一个可见的实施间隔本身并不可疑。技术手册需要准确落字、交叉引用、删除旧项、调整编号并生成可发布版本，普通的工程与文档工作都可能需要时间。现有材料没有告诉我们这些工作各花了多少时间，所以不能给107日编造原因；但制度上完全可以承认，批准与上线之间存在正常工作。真正重要的是，间隔不能被写没：批准日、实施日、公告日应各自留下明确记录，使任何人都不必靠机构记忆猜测生效点。

这也解释了为何一条残留的网页状态不能独自决定生命周期。提案存档页后来仍显示“讨论中”，但董事会决议、实施报告、AFRINIC-29记录和CPM 1.3公告共同展示了更完整的后续链条。一个孤立字段可能没有及时更新，也可能服务于与生命周期不同的页面逻辑；在没有额外证据时，不必推测原因。能够确定的是，单个状态标签的证明力低于彼此衔接的批准、实施和版本记录。严肃的档案判断应读取链条，而不是让一个网页标签覆盖所有后来的正式记录。

会议纪要本身也有一项应被保留的不确定性。2018年9月，第201809.450号决议批准了8月7日至8日的会议纪要，并注明有修订；现有材料没有展示修订文字，也没有证明修订改变了第201808.446号决议。负责任的写法既不能假定修订无关紧要，也不能暗示它推翻了已记录的表决。这里可说的只有：我们知道纪要后来经修订获批，却不知道修订具体涉及何处；在缺乏连接证据时，不应把未知内容变成新的事件。

于是，L3层面最扎实的观察并不复杂：一次一致表决留下了两项待办，随后才出现实施日期与公告日期。这个结构使批准与生效可以被分开证明。它既避免夸大董事会动作，也没有贬低董事会动作。第201808.446号决议确实完成了一项必要的内部批准；它之所以重要，正是因为它位于一条链上，而不是因为它能在一瞬间替代员工执行、版本发布和使用者通知。