摘要

  • Draft 2 是 2018 年 11 月 20 日公布的提案文本，不是当年已获采纳或已经实施的规则；2026 年 2 月 4 日获追认的是后来形成的 Draft 7，两个生命周期事件不能倒推合并。
  • 与 Draft 1 相比，Draft 2 把规范性的初次验证与升级验证窗口从两个工作日加三个工作日改为十五天加十五天，并把最低周期从每三个月一次改为每六个月一次；但示例仍保留两天加三天，造成同一文本内部的时钟冲突。
  • Draft 2 新增的首要后果是限制账户访问，仅保留修改 abuse-c 或 abuse mailbox 的通道，成功重新验证后恢复；它又保留了与资源撤销有关的更彻底跟进。AFRINIC 员工认为这会封锁除邮箱修正以外的全部 MyAFRINIC 功能，包括在线投票，法律顾问则认为以失去投票权回应行政联系资料未更新并不相称。
  • 可达性验证有正当而狭窄的用途：降低受害者、同行网络和运营者找到责任窗口的成本。但 AFRINIC 只是私人技术记账员和唯一性协调者，能够核验地址、纠正登记记录，却无权裁判投诉真伪、强令特定处置、惩罚持有者或以登记系统的关口替代法院、监管者和执法机关。

L3——条文中的三十天，示例中的五天

这份提案最容易被一句“强制验证 abuse 联系方式”概括，也最容易因此被读错。Draft 2 真正独有的制度信息，不在于它再次主张公共数据库里应有一条可联系的 abuse-c，而在于它怎样改写了 Draft 1 的时间、裁量与后果。只有把两稿并排，才能看见一种不寻常的组合：程序表面变得更宽松，失效之后的第一击却变得更直接；检验频率降低了，登记机构干预会员账户的触点反而增加了。本文讨论的正是这条红线，不把它扩写成强制 abuse 联系人的一般历史，也不把后来版本的追认借来替 Draft 2 补上并不存在的实施事实。

先看基线。Draft 1 要求由 AFRINIC 分配的资源设置 abuse-c，相关邮箱应受到主动管理；子对象可以沿用父对象的联系人，也可以配置自己的联系人。它的规范性第 8.4 节把初次验证期限定为最多两个工作日；如果验证失败，程序升级至 LIR，再给最多三个工作日。第 8.5 节要求在创建或更新时验证，至少每三个月验证一次，并保留 AFRINIC 认为适当时启动验证的空间。继续不合规会进入相关政策和程序下更彻底的跟进，文本特别指向与资源撤销有关的程序。也就是说，Draft 1 已经存在一条较硬的尾部风险，但它没有在前端明确安插 Draft 2 那种账户访问封锁。

Draft 1 的日期本身还有一项不能悄悄抹平的来源差异。AFRINIC 现存页面的详情或当前版本列表指向 2018 年 8 月 12 日，而同一存续材料中的修订历史写的是 2018 年 3 月 12 日。现有证据不足以替两者裁决。这个分歧不影响本文的硬日期：Draft 2 于 2018 年 11 月 20 日公布；但它提醒读者，版本元数据并不总像政策叙事所暗示的那样整齐。认真分析制度文本，不能为了时间线好看就替来源消除矛盾。

Draft 2 对第一组时钟作了明显放宽。初次验证从最多两个工作日改为最多十五天；失败后向 LIR 升级的第二段期限，从最多三个工作日改为最多十五天。若只读规范条款，一个持有者从收到中性验证请求到第二阶段结束，面对的是“十五加十五”的两段窗口，而不是 Draft 1 的“二加三”。这三十天是验证流程的上限结构，不是解决底层 abuse 举报的三十日服务承诺。提案没有规定运营者必须在十五天或三十天内证明某宗投诉已被处置，更没有建立判断投诉是否属实、内容是否违法、回应是否充分的实体标准。把验证期限说成 abuse 处置 SLA，会把“邮箱能否收信”偷换成“登记机构能否审判行为”。

第二组变化是频率。Draft 1 的最低周期为至少每三个月一次，Draft 2 改成至少每六个月一次。创建或更新时验证的触发点继续存在，AFRINIC 认为适当时也可以验证。就例行负担而言，这相当于把最低频率减半：如果没有其他触发，运营者一年面对的最低定期测试由四次降为两次。这样的改动可以被合理理解为降低重复核验成本、给予组织处理人员变动和邮件系统异常的更长空间。它也说明 Draft 2 的作者并非单向追求更紧、更快的控制。

但 Draft 2 同时把时间裁量写得更明白。AFRINIC 可以修改初次期、升级期和周期频率，条件是向社群说明理由。文本还给出一种慢启动思路：第一年可能只进行一次验证，随后逐步提高频率。这里必须同时保留两个判断。其一，披露理由比无说明地改变节奏更可问责，慢启动也可能帮助系统、人员和成员适应新流程；其二，“说明理由”并不等于取得公共权力，文本中“AFRINIC 认为适当时”的触发仍会让私人机构掌握相当大的操作裁量。证据只证明提案这样写过，不证明 AFRINIC 曾针对某个会员选择性启动验证，也不支持从条款推断任何具体执法事件。

真正棘手的，是 Draft 2 没有把自己的示例程序同步更新。它的非规范性例子继续说：验证代码有效两个工作日，此后再给三个工作日，随后变成永久无效并重复测试。于是同一份 Draft 2 内同时出现两只钟：规范条文是十五天加十五天，示例却是两个工作日加三个工作日。不能挑一只喜欢的钟宣布它代表完整的 Draft 2，也不能把示例当成无害旧文字略过。成员面对自动邮件、内部转办、周末、节假日和跨时区团队时，五天与三十天的区别足以决定一次短暂故障究竟是正常恢复，还是被系统标记为失败。

这项不一致还会放大后果条款的不确定性。如果账户限制以规范窗口结束为触发，成员理论上拥有两段十五天；如果实施人员或自动化系统照搬示例，则实际容错可能收缩为两天加三天。现有资料不证明最终若实施会采用哪一套，也不证明 Draft 2 曾进入生产。恰当的结论不是替设计者选钟，而是承认：一项能影响账户功能的程序，不应让规范条文与操作示例在最基本的时间问题上相互冲突。清晰不是编辑偏好，而是程序可预见性的最低条件。

第三组变化最具制度重量。Draft 2 增加了一个明确的“第一后果”：初次不合规时，账户访问其资源的能力将被封锁，只允许进入用于修正 abuse-c 或 abuse mailbox 的部分；完成修正并成功重新验证后，访问恢复。单看这一步，它似乎构成一种带有自助修复出口的激励——缺陷在哪里，修复入口就保留在哪里。然而文本没有删除 Draft 1 的硬尾部。更彻底的跟进依然存在，并继续特别关联资源撤销相关政策或程序。因而 D2 的序列不是以账户封锁替代撤销风险，而是在撤销导向的后续之前新增一道即时限制。

第 8.6 节又把升级情境延伸到疑似规避验证，以及对 abuse 案件回应不正确或缺乏回应的情况。可采取的动作包括重新验证、AFRINIC 居间和可能运用相关程序。这一表述跨越了两个性质不同的问题：验证规避仍可围绕登记资料和客观可达性取证；“回应不正确”则需要有人判断一宗争议中的答复是否令人满意。提案没有给出实体 abuse 的裁判标准，也没有把投诉人意见转化为司法事实的正当程序。正因如此，不能把 D2 的十五天说成整改 abuse 行为的倒计时，更不能把第三方不满意自动等同于会员失格。

2019 年 4 月 20 日的 AFRINIC 员工与法律评估把这些文字的现实含义照得更亮。员工理解的账户封锁覆盖除更新 abuse mailbox 外的全部 MyAFRINIC 功能。他们特别警告：凡通过 MyAFRINIC 进行的 AGMM 或其他选举投票，也会因为该封锁而无法进行。员工还指出“访问其资源”措辞不清，建议明确究竟禁止哪些数据库编辑。这里的关键不是猜测某次选举真的有人被挡在外面——没有这项事实——而是提案设计本身把一项联系资料缺陷与组织成员的治理参与能力绑在了一起。

AFRINIC 法律顾问的意见进一步划出比例问题：因为未更新行政联系信息而丧失投票权，并不相称，应该重新审视；同时，顾问认为这在毛里求斯法律下并非违法。两句话必须一起保留。“并非违法”不是“制度合理”的同义词，也不是对 AFRINIC 主权权力的确认；“不相称”也不是一项法院判决或已经发生的违法认定。它是对提案后果与记录缺陷之间失衡的内部法律警告，恰好说明私法上的可操作性与治理上的正当界限并非一回事。

实施评估同样属于条件性材料。AFRINIC 员工估计需要约六个月的软件开发，并要修改 WHOIS，具体取决于最终获追认的方案。这是工作量预测，不是开工证明，更不是上线证明。提案文本、员工评估、政策采纳和技术部署是四个不同的证据节点。Draft 2 的公布只证明有这份提案；2019 年评估只证明工作人员怎样理解它及估算成本；后来获得追认的是 2021 年 5 月 17 日所列的 Draft 7，而 AFRINIC 把追认日期记为 2026 年 2 月 4 日。后来的 Draft 7 生命周期不能追溯性地把 2018 年的 Draft 2 变成已采纳规则，也不能证明任何现行验证功能的确切生产状态。

因此，D1→D2 的完整红线不能被简化为“期限放宽”。它包括七个同时存在的变化或延续：初次窗口由二日变十五日；升级窗口由三日变十五日；最低周期由三个月变六个月；带说明义务的时间调整裁量被明确写入；账户访问封锁成为新的第一后果；撤销导向的后续被保留；而两日加三日的旧示例没有随规范条文改变。正是最后三项，让一份看似更温和的程序在制度后果上反而变得更沉。