摘要

  • AFRINIC 在 2026 年 6 月的公开会议纪要中，把 AS0 ROA 的完整实施、号码资源转移的技术系统，以及滥用联系人政策的内部技术实施，都放到了 MyAFRINIC v2 的依赖或后续优先序列中；另一个处于 Last Call 的 AS-SET 提案也采用了相同的软件排期边界。
  • 四条路径不能合并成一个“功能清单”。它们分别触及 RPKI、跨 RIR 程序、内部验证流程、WHOIS 和 IRR，而且三项已经批准，一项尚未批准，所需的权威、测试对象和完成标准都不同。
  • 一个门户可以上线，一项政策仍可能只是部分实施；一个界面可以存在，一条跨机构流程仍可能没有完成端到端验收。需要建立逐政策的依赖与验收台账，把门户版本、政策版本、测试结果、激活时间、例外和纠正记录连在一起。
  • 共用平台本身并非问题。统一身份、权限、记录和通知可能比继续修补遗留系统更可靠。风险在于：如果只发布一个平台状态，四项政策的真实状态就会被一个易于传播的日期覆盖。

软件项目喜欢一个日期。日期可以放进路线图，可以写进公告，也可以成为所有进度讨论的共同坐标。但政策实施不是一次剪彩。它是由文本权威、系统行为、工作人员程序、用户权限、测试结果、通知、激活和纠正共同构成的一条证据链。

MyAFRINIC v2 正处在这两种逻辑的交界处。

AFRINIC 的公开资料显示，至少四条政策路径被放在这个会员门户的重建项目之后或部分依赖于它。第一条是为未分配、未指派地址空间签发 AS0 ROA；第二条是号码资源转移；第三条是滥用联系人更新；第四条是新建 AS-SET 必须使用层级名称的提案。它们在技术上都可能碰到会员门户或与门户相连的工作流，但除此之外，相同之处很少。

三项政策已经批准，一项仍在 Last Call。一个涉及 RPKI 发布，一个需要与其他 RIR 对接程序，一个要在内部系统中建立验证和纠正路径，一个要控制 WHOIS 和 MyAFRINIC 的 IRR 创建入口。把它们统称为“MyAFRINIC v2 之后的政策工作”可以说明排期，却不能说明任何一项已经完成。

因此，本文不判断门户是否会按期上线，也不推测某个功能是否被删减。现有证据不支持这些结论。更窄也更有用的问题是：当一个共同发布里程碑承载四项不同的制度结果时，AFRINIC 需要公开什么，才能证明每一只政策时钟分别走到了终点？

同一个项目，两个日期表述

AFRINIC-37 会议纪要记录，这次公共政策会议于 2026 年 6 月 24 日举行。纪要称 MyAFRINIC v2 的开发始于 2020 年，随后经历多年预算和其他资源限制，后来重新启动；当时的目标是到 2026 年底上线。为满足这一期限，项目需要限制范围，避免 scope creep。

“限制范围”不等于“项目失败”。对于连接会员身份、号码资源记录和多种操作权限的门户，保护一个可测试、可回退的发布范围，可能比一次塞入全部需求更稳妥。共享基础设施也可能减少多套遗留逻辑之间的冲突。但会议纪要没有列出被延后的具体功能，所以不能据此声称 AS0、转移、滥用联系人或 AS-SET 中的任何一项被移出发布。

AFRINIC 随后的 AfPIF 2026 页面提供了另一种进度标记。页面把 MyAFRINIC v2 描述为会员自助门户的全面重建，并称在用户验收测试和 live beta 之前，正在征集社区反馈。它邀请会员加入 UAT 和 beta，也希望通过简短访谈了解资源申请、联系人更新、账单管理和日常查询等流程。

这能证明测试准备和招募，不能证明测试已经结束，更不能证明生产环境已经开放。UAT 邀请、UAT 完成、beta 开始、beta 结束、受限生产和全面生产是六种不同状态。一个严谨的实施记录不应让前一个状态自动继承后一个状态的含义。

另一个精确日期出现在 AS-SET Draft 2 的员工评估中。该页称，当时资源都集中到 MyAFRINIC v2 项目，预计门户于 2026 年 11 月 15 日上线；如果 AS-SET 提案推进，其实施将在门户完成后优先安排。这个日期比会议纪要的“年底”更精确，却只属于该员工评估的实施计划。把 11 月 15 日扩展成四项政策共同的交付承诺，会超过来源。

截至本文证据冻结日，11 月 15 日尚未到来。现有资料既不能证明门户已经上线，也不能证明它错过期限。日期的意义在于揭示共同依赖，而不是提供一则尚未发生的成败新闻。

AS0：先定义“部分”，再谈“完整”

当前政策台账把 AFPUB-2019-GEN-006-DRAFT03——未分配和未指派 AFRINIC 地址空间的 RPKI ROA 政策——列为已批准，并标注 Awaiting Implementation。AFRINIC-37 纪要则给出更细的状态：使用演进后的 KRILL 软件进行内部测试；预计当月月底发布 beta，并明确称为 partly implemented；按照政策文本完整实施，则依赖 MyAFRINIC v2。

这段记录值得保留原有层次。已批准、内部测试、部分实施、按文本完整实施，是四个不同判断。它们不能被“RPKI 功能已经有了”取代。

AS0 的验收对象也不能只是一个按钮或一个设置页。至少需要说明覆盖哪些未分配、未指派资源，什么对象被发布，哪些例外仍未包含，系统如何处理失败或错误发布，以及从“部分”进入“完整”的判据是什么。本文的来源没有给出这一整套答案，因此不能自行填补；恰恰因为边界尚不清楚，公开的部分/完整定义才成为首要证据。

内部测试可以验证规则和软件，但不能自动证明所有运行条件。会员门户可能承担权限、可见性、通知或纠正入口；RPKI 发布系统则承担另一类状态。只有当政策版本、门户版本、KRILL 运行状态、覆盖范围和纠正流程能够被同一条验收记录连接起来时，“完整实施”才是可复核的结论。

转移：界面之外还有另一家注册机构

AFRINIC 的已批准政策概览把号码资源转移政策 AFPUB-2020-GEN-006-DRAFT03 的批准日期记为 2026 年 2 月 4 日。AFRINIC-37 纪要称，该政策覆盖区内和跨 RIR 转移；截至 2026 年 4 月，与其他四个 RIR 的互惠性已经确认。实施正在进行，Member Services 正与其他 RIR 的对应团队映射必要程序，技术系统实施则将在 MyAFRINIC v2 部署后优先处理。

转移路径说明了为什么一个门户日期不够。区内转移和跨 RIR 转移不是同一条流程；与每个对手机构之间也可能存在不同的状态交换、证据要求和失败处理。会员看到一个申请入口，只能证明入口存在。要证明一条转移路径可用，还需要从合格请求、材料验证、对方确认、双方状态同步，到最终注册记录和通知的端到端结果。

反过来，工作人员也可能在门户全面开放之前拥有可执行的程序。若只用“门户未上线”判断“政策完全没有实施”，同样会抹掉真实进展。逐政策台账的价值正在于允许中间状态：程序已映射但技术入口未激活；某类转移可处理而另一类仍待对接；测试通过但尚未面向所有会员开放。这样的限定比简单的“完成/未完成”更诚实，也更便于下一步决策。

本文不讨论转移政策中资源分类或跨区域限制的实体正当性，那已有独立文章处理。这里唯一关心的是实施证据：什么能够证明每一条合格路径在程序和技术上都可用，并且在拒绝、中止或纠正时保留完整历史。

滥用联系人：字段、邮件和后果不是一个状态

同一份政策概览把 AFPUB-2018-GEN-001-DRAFT07 的批准日期也记为 2026 年 2 月 4 日。AFRINIC-37 纪要称，滥用联系人更新的内部系统技术实施将在 MyAFRINIC v2 部署完成后优先处理。

这条路径的最低验收对象并不是数据库里出现了 abuse-c，也不是系统发送了一封测试邮件。完整工作流至少要区分：控制文本是哪一个版本；被验证的是哪个联系人记录；验证何时发起；怎样认定送达、回复或失败；会员如何收到通知并改正；例外如何处理；以及任何后果从什么事件、什么时间开始。

这些问题不能从早期 Draft 2 的设计机械推导到最终批准的 Draft 7。旧草案能说明历史讨论，不能替代现行控制文本。实现时如果没有显式绑定政策编号和版本，旧逻辑、工作人员理解和最终批准规则之间可能出现难以追溯的差异。现有资料没有证明这种差异已经发生；它只说明为什么验收记录必须防止这种情况。

滥用联系人也显示了“部分实施”可以有多种含义。系统可能已能验证新申请人的邮箱，却尚未覆盖既有资源；可能已能发出通知，却没有可复核的纠正状态；也可能内部流程已经准备好，但会员界面尚未开放。不能从其中任何一项推断全部。验收台账需要逐项写出包含和排除范围。

AS-SET：实施计划不能替代政策权威

AFPUB-2026-ASN-001-DRAFT02 的位置与前三项根本不同。当前台账把它列为 Last Call 提案，核实资料没有显示批准。员工评估称，为限制新建非层级 AS-SET，WHOIS 所有创建入口和 MyAFRINIC 的 IRR 界面都需要软件修改；既有 AS-SET 不会被重新命名。实施计划随后把工作排在 MyAFRINIC v2 之后。

在政策讨论期间评估技术影响是合理的。没有评估，参与者就无法判断提案是否可执行、影响哪些系统、需要多少资源。但“可实施”和“有权实施”必须分开。只要提案尚未批准，它的状态就是准备和评估，而不是已采用规则的上线。

如果未来批准，验收的第一项证据应是最终控制文本及生效时间。随后要证明所有创建入口执行同一规则：直接 WHOIS 路径、MyAFRINIC 的 IRR 界面，以及任何受到政策约束的其他入口。还要证明“只约束新建对象”和“不重命名既有对象”的边界没有被实现过程破坏。一个入口拒绝非层级名称，不能证明其他入口没有绕过；一个新对象通过测试，也不能证明旧对象保持原状态。

因此，把 AS-SET 与三个已批准政策放在同一张依赖表中是有价值的，但它们不能共用一个状态词。前三项可以讨论批准后实施；AS-SET 首先要等待政策权威。台账必须容纳这种不对称。

政策路径 核实资料中的状态 与 MyAFRINIC v2 的关系 尚需公开的验收证据
AS0 ROA 已批准；台账为 Awaiting Implementation；纪要记录内部测试及计划中的 partly implemented beta 按文本完整实施依赖门户 对象与覆盖范围、部分/完整定义、测试和纠错案例、激活及持续发布证据
号码资源转移 2026 年 2 月 4 日批准；程序映射进行中 技术系统在门户后优先实施 各类合格路径的程序与技术端到端测试、对方状态、通知、注册结果和纠正路径
滥用联系人更新 2026 年 2 月 4 日批准 内部技术实施在门户部署完成后优先安排 Draft 7 绑定、验证/通知/纠正测试、后果边界、例外及生效记录
层级式 AS-SET 名称 Last Call 提案，未证实批准 评估涉及 WHOIS 和门户，排在门户后；评估页写 11 月 15 日期望 后续批准、最终文本、所有创建入口覆盖、既有对象保护和纠正测试

一张足够小、又足够严格的台账

公众不需要查看内部工单、源代码、会员材料或安全配置。AFRINIC 可以发布一张紧凑的依赖与验收台账，每条政策一行，每次状态变化增加事件，而不是覆盖旧状态。

第一组字段负责权威：政策标题、编号、版本、当前状态和生效依据。它能防止实现引用错误草案，也能保证 AS-SET 在批准之前保持“提案评估”而非“政策实施”。

第二组字段负责技术基线：精确的 MyAFRINIC v2 发布版本或带日期的基线、依赖类别、必要系统或程序变化。MyAFRINIC v2 是项目名称，不是可复现的软件状态。必须知道某项验收针对哪个发布基线，也必须把门户界面、WHOIS/IRR 规则、RPKI 发布、内部工作流、数据迁移和跨 RIR 程序分开。

第三组字段负责责任和测试：前置条件、责任团队、测试用例、验收标准、UAT 或 beta 的参与范围及结果。责任归属不是指责，而是明确谁有能力证明条件已满足。内部测试、会员 UAT 和 live beta 回答的问题也不同，不能互相替代。

第四组字段负责状态语义：什么叫部分实施，什么叫完整实施，哪些内容明确不在本次范围，下一次状态变化需要什么事件。如果不预先定义，partly implemented 可能变成没有退出条件的永久标签，launched 也可能成为四项政策共同的模糊终点。

最后一组字段负责时间和修复：通知时间、激活时间、例外、回滚、纠正路径、上线后观察窗口、未决依赖和下一决策。平台可用率只能说明平台健康，不能证明政策结果。每项政策都需要自己的运行信号：AS0 的覆盖和纠正、转移路径的完成状态、滥用联系人的验证与改正、AS-SET 创建入口的一致约束。

这种台账不会消除延期、缺陷或争议。它做的是让这些状态可识别，使一个合理的分阶段发布不被误写成失败，也使一个笼统的上线公告不被误写成四次成功。

资料没有证明什么

官方页面都是时间截面。6 月的年底预期不能证明 8 月底的实际状态；8 月页面上的测试邀请也不能证明测试已经完成。证据没有显示门户当前已生产上线，没有显示 UAT 或 beta 已结束，没有显示 AS-SET 已批准，也没有显示 AS0、转移系统或滥用联系人系统已经完整实施。

同样，资料没有证明任何事故：没有停机、失败测试、被拒绝转移、无效联系人、AS-SET 冲突或 RPKI 路由后果。本文也没有识别因共同依赖而受损的会员。把这些未知变成故事，会破坏这篇分析最重要的纪律。

真正可审计的不是一个假定失败，而是 AFRINIC 是否建立了足够精确的报告结构，使未来的成功也不会被夸大。它已经公开区分了 Awaiting Implementation、内部测试、partly implemented、程序映射、门户后优先处理和 Last Call。下一步，是给这些状态加上逐政策的证据对象。

如果这一步完成，MyAFRINIC v2 可以继续作为共同基础，而不会变成共同解释。门户上线只是一个事件；其后仍有四次验收。

来源