摘要

  • APNIC 的公开 NIR API 文档给出了 POST /nir-delegations/asn，任务完成后可以显示 SUCCESSFUL；但教程把操作描述为从 NIR 的池委派资源，而产品路线图说的是通过 MyAPNIC 与 NIR API 向 NIR 账户持有人直接委派 ASN。这两段文字不能在没有版本和发布日期的情况下被视为同一语义。
  • 2024 年 9 月的执行委员会材料称核心注册系统和 NIR API 更新正在进行，12 月材料把“NIR ASN 直接分配”列为最终 QA；当前路线图把项目列在 2025 年，却让目标日期和 changelog 保持为空。现有证据没有证明项目失败，也没有证明某一公开端点就是后来那次发布。
  • APNIC 可以发布一张小型、可签名或可按哈希寻址的“发布与保证凭据”：绑定路线图编号、API 与数据结构版本、生产切换时间、参与 NIR、迁移批次、委派语义，以及匿名汇总的 Whois/RDAP 一致性检查。

SUCCESSFUL 是一个有用但很窄的回答。自动化客户端需要知道是否继续等待、是否重试、是否出现错误；任务状态正是为此而设。它并不天然携带制度含义。完成的可能是旧的池内委派，也可能是新的直接写入路径；可能只完成核心数据库变更，也可能已经完成所有公开投影。若没有发布版本，观察者无法从同一个状态词分辨这些情形。

这不是挑剔命名。ASN 是全球路由系统中的唯一标识，获得它意味着一家组织可以用自己的策略交换可达性信息。一次分配同时牵动资格审查、资源来源、账户关系、联系信息、费用处理以及公共注册记录。接口让动作更快，却不会自动让责任边界更清楚。

APNIC 的公开记录现在提供了三种各自可信的材料。路线图讲要解决的问题和拟采用的方案；执行委员会材料记录项目到了哪个阶段；API 教程展示客户可以怎样提交请求。困难在于三者没有共享一个不可变的发布标识。读者只能凭相似的项目名称和时间顺序推断它们属于同一代系统。

推断或许正确，却不等于可审计的证据。接口路径可以在内部语义变化时保持不变，文档也可能覆盖测试环境、生产环境或两个环境共用的调用形状。项目通过最终 QA，并不自动给出生产切换日期。路线图上的年度归属，更不等于每家 NIR 在同一日采用了同一模型。

公开时间线在最终 QA 后失去连接

2019 年，APNIC 曾公开解释一次与 NIR 数据结构有关的长期迁移。文章称，IPv4 资源在较早的联盟式安排之后，自 2004 年起逐步从共同的区域池直接进行分配与指派，并写入 APNIC 注册系统。旧有地址块并未凭一句“直接”就消失，后续的数据核对还需要纠正日期、持有人和遗漏的转移记录。

这段历史不能用来证明 ASN 项目采用了同样的实现。它的价值在于提醒人们：资源从哪里来、由谁服务成员、最终写入哪里，以及旧记录如何迁移，是四个可以分别改变的问题。一个系统从间接变为直接时，名称最容易先变得简单，现实却往往要经过多个批次。

2024 年 9 月的 APNIC 执行委员会材料把“NIR ASN 直接分配”置于正在推进的核心注册系统和 NIR API 更新中。它确认了工作面：不仅是网页说明，而是涉及登记核心与对外接口的产品变化。材料没有给出完成日期，也没有列出采用者。

同年 12 月的材料更进一步。项目目的被表述为通过直接向 NIR 账户持有人委派 ASN，改善数据的一致性与有效性；状态则进入最终 QA 测试。最终 QA 是重要的交付信号，因为它表明工作已经越过构想阶段。但 QA 仍是一道发布前控制，不是生产发布凭据。

2025 年 2 月的执行委员会与年度报告材料仍把该项目列在进行中的路线图工作里。当前路线图数据则将它放在 2025 年，指明 Registry 团队以及 ARMS、MyAPNIC，并重复希望通过 MyAPNIC 与 NIR API 直接完成 ASN 委派。可是该条目的 target 为空，changelog 也为空。

空白不等于取消。它也不能证明 APNIC 没有内部发布记录或没有把功能部署到生产环境。准确的结论更窄：公众无法在这张路线图卡片上找到预定或实际切换时间，也无法沿着变更记录到达某个版本、迁移说明和结果检查。

APNIC 的 2025 年年度报告表示，季度产品路线图目标已经达成，并明确列举了更新的 Whois 授权、RPKI Signed Checklist 对象以及 RDAP 新架构原型。已捕获的报告全文没有点名“NIR ASN 直接分配”。这种沉默同样不是失败证据；它只说明年度汇总无法承担这一具体项目的发布收据功能。

于是公开时间线停在一个尴尬位置。人们看到工作开始、最终 QA 和年度目标完成，却看不到能把它们锚定到生产版本的那一行。制度透明度缺失的不是更多叙述，而是一个可引用的连接键。

端点证明能力，不证明后来那一版语义

公开 NIR API 文档说明，NIR 可以用接口管理其子账户的注册信息。ASN 教程展示 POST /nir-delegations/asn 请求，包含将在 Whois 与 RDAP 中使用的联系信息，并返回异步任务的位置。通用说明要求客户端查看任务状态，并提供 Idempotency-Key 来避免同一请求被意外重复执行。

这些都是实质性证据。它们证明存在一条支持 ASN 操作的公开调用形状，证明处理不是必然同步完成，也证明接口设计者考虑了重复提交。但教程同时把动作写成从“NIR 的池委派”资源。路线图后来使用的是向 NIR 账户持有人“直接委派”的语言。若没有发行说明，不能悄悄抹平这两个短语之间的差异。

可能性不止一种。文档端点也许后来获得了新的后台语义而路径不变；教程也许描述兼容模式；不同 NIR 也许分批迁移；测试域上的说明也许先于生产切换；路线图项目也可能只改变账户和核心登记方式，而没有改变客户可见的请求结构。公开材料没有让其中任何一种解释成为确定事实。

因此，端点是“系统能接受何种请求”的证据，不是“哪一语义何时在何处生效”的证据。把两者混为一谈，会让一个技术接口背负它从未承诺提供的审计结论。

Idempotency-Key 也有相同边界。它控制同一意图被重复提交时的执行次数，不能证明意图采用了正确的规则版本。一个请求可以按照旧模型恰好执行一次；两个 NIR 可以各自在不同迁移阶段恰好执行一次；一次成功写入也可能需要随后修复公共投影。幂等性降低重复风险，却不记录权限来源。

异步任务的 SUCCESSFUL 状态则属于事务真相。它告诉调用者本次处理已完成，但没有说明“完成”包含哪些下游效果。若核心注册表已更新而 RDAP 缓存尚未一致，状态仍可能依据任务定义而成功。若 NIR 的批准在请求之前发生，任务本身也不会证明批准材料。任务状态必须被保留，却不应被扩展解读。

直接写入没有取消 NIR 的制度职责

APNIC 的 NIR 运作政策解释了这层关系。NIR 的价值包括以本地语言、在本地制度环境中提供服务；它们必须遵守区域与全球资源管理政策，也可以设置不与上位规则冲突的本地要求。APNIC 同时需要保留直接会员资格的可能。

一个组织可以同时与 NIR 和 APNIC 存在会员关系，但资源服务在同一时间应来自一个来源。由此可见，“直接写入 APNIC 核心注册系统”不必然意味着 NIR 不再判断申请。NIR 仍可能是成员的服务窗口、证据检查者和关系持有人，只是批准结果不再经过第二次人工录入才进入区域登记核心。

这样的设计有明显收益。减少重复录入，可以降低号码、日期、联系人和账户归属在两套系统之间漂移的机会；统一接口也能让错误处理和重试更一致。路线图将改善数据一致性与有效性作为目标，符合这个操作逻辑。

但“直接”的对象必须被说清。它可能指 ASN 直接来自 APNIC 管理的区域池，而非一个预先分给 NIR 的池；也可能指 NIR 的批准直接写入核心登记；还可能只指系统之间的传输不再依赖人工。资源来源、审批权和写入路径并非同义词。

旧记录又增加一层问题。既有 ASN 是否被迁移到新的子账户模型？不同年代的记录是否保留旧的资源池归属？NIR 若分批接入，系统如何表明一笔交易采用哪条路径？这些问题都不需要公开申请人的证件或内部备注，却需要公开版本与迁移边界。

APNIC 的现行号码资源政策规定，申请人可以向 APNIC 或相关 NIR 请求 ASN，所有已分配 ASN 都必须在 APNIC 或相关 NIR 的 Whois 数据库公开登记。政策给出了可接受的制度结果，却没有替代实现记录。相同的公共登记结果，可以由不同版本、不同批准链和不同迁移路径产生。

这正是为什么观察最终 Whois 或 RDAP 记录还不够。公共状态能回答“现在记录了什么”，不能单独回答“哪个软件版本和哪项授权把它变成这样”。对运营者而言，状态、事务与发布是三个不同层级的事实。

现有公开审查使用了另一个分母

APNIC 还运行资源委派审查计划。公开说明包括数据分析、遵规抽查、程序评估、账户记录准确性、对 NIR 的支持，以及未来对协议的复核。2026 年第二季度更新称，JPNIC、TWNIC 和 KRNIC 的工作已经完成，其他 NIR 的分析仍在继续。

这套公开审查是重要的问责设施，但它公开定义的主要范围是十年的 IPv4 委派与转移。它没有把 ASN 直接分配项目列为结果分母，也没有公布通过新路径处理的 ASN 数量、采用的 NIR 集合或请求与最终公共记录之间的差异率。

因此，不能拿这项审查的完成情况来证明 ASN 新路径的质量。同样也不能反向声称 APNIC 内部不存在 ASN 控制。可验证的表述只有：目前引用的公开审查项目采用 IPv4 范围，无法作为这次 ASN 发布的独立结果度量。

分母决定指标能回答什么。若审查十年 IPv4 委派，它能揭示历史地址数据的问题，却不能说明某个 2025 年 ASN 接口版本的成功率。若任务日志只统计 API 调用，它能描述事务，却不能说明 Whois 与 RDAP 是否最终一致。若路线图只记录完成状态，它能描述管理进度，却不能说明迁移覆盖率。

把这些分母连接起来，才会形成完整证据链。发布记录定义适用版本和范围；事务汇总描述该版本处理了什么；公共状态核对验证结果最终出现在哪里。缺少第一步，后两步很难被正确归因。

一张最小发布与保证凭据已经足够

APNIC 不需要公开成员申请、身份证明、NIR 商业条款或内部支持对话。它只需要为重大 NIR 注册工作流变化发布一份紧凑、稳定、可验证的收据。

第一组字段应固定发布身份：路线图项目编号、不可变发布编号、生产切换时间、部署范围、回滚状态，以及对应的 API 和数据结构版本。还要明确旧语义和新语义，尤其说明 ASN 是从 NIR 池委派，还是直接从 APNIC 管理的区域池产生。

第二组字段应记录采用与迁移：哪些 NIR 已接入，是否分阶段开启，旧路径是否仍可用，以及哪些既有 ASN 被回填到新账户结构。无需披露单个成员，只需给出制度和技术边界。

第三组字段应提供限定期间的汇总检查：尝试、成功、拒绝、撤销、修正与核对的数量；核心登记与 Whois、RDAP 投影是否一致；有多少重复被幂等机制吸收；还有哪些例外尚未解决。每个数字都应带时间窗、定义和版本。

最后，凭据需要链接回路线图、发行说明、API 文档和后续保证结果。若文档可以签名或按内容哈希寻址，未来修订就不会覆盖过去曾经有效的边界。更正可以追加，而不是重写历史。

这种凭据把三种事实明确分开。发布事实说明哪套语义已经部署；事务事实说明某个请求发生了什么；注册状态事实说明公众现在能查到什么。三者彼此关联，却不能互相代替。

对 NIR 工程师，这会减少在支持工单、会议记录和代码行为之间重建版本的时间。对 APNIC 会员，它说明哪一机构在何时承担何种控制。对研究者和未来审计者，它提供可重复的边界，而不是要求他们从空白 changelog 推测项目历史。

最重要的是，这种记录不会削弱 APNIC 修复系统的空间。相反，版本化凭据允许组织承认某批次需要修正，同时保留其他批次的准确历史。没有版本，修复容易看成悄然改变；有版本，修复可以成为可解释的治理动作。

问题从来不是 APNIC 是否拥有一个 ASN 端点。公开教程已经证明了某种端点能力。问题也不是项目是否失败；现有材料不支持这种断言。真正的问题是，公众没有一条共同标识，能够把计划、最终 QA、生产语义、NIR 采用和登记结果连接成同一次发布。

当下一次 SUCCESSFUL 出现时，机器仍然只需要一个简短状态。人类需要的则是它背后的版本、授权和结果。让发布拥有一份可引用的记忆，才能使成功不仅可执行，也可核验。

来源