摘要

  • AFPUB-2019-V4-003-DRAFT02是2020年8月13日提交的《资源转移政策》草案二；2021年10月8日属于另一个编号AFPUB-2020-GEN-006-DRAFT02，两条沿革不得合并。
  • 草案二要求来源方遵守接收RIR的政策，并让转让方从接收RIR发起请求。ARIN、APNIC、RIPE NCC与LACNIC的反馈表明，这两项安排无法与各自当时的规则或程序可靠接合。
  • 草案二曾被提出、讨论、评估，经历条件性粗略共识与最后征求意见，后来归档；这些状态都不等于写入CPM、获董事会批准或投入运行。
  • AFRINIC能够做的是核验自己掌握的记录、与兼容的对端协调一次权威变更，并维护WHOIS/RDAP、反向DNS、RPKI及日志等依赖；它无权替另一个私人注册机构豁免其规则。
  • 真正可执行的可移转权需要一份绑定确切文本、方向、资源类型、验证责任、请求起点、对端政策版本、原子切换与回滚办法的兼容性证书，而不是逐笔交易中的管理裁量。

L3 — 四条无法接合的接收轨道

先看那张外部兼容性评估表。它所检验的并不是抽象意义上的“RIR是否赞成转移”，而是一个更窄、更难回避的问题：如果严格按照AFPUB-2019-V4-003-DRAFT02的文字办理，一笔跨RIR转移能否在两个独立登记系统之间完成同一项权威变更？四个对端给出的答案虽各有理由，却落在同一个结论上——AFRINIC页面上看似已经铺开的线路，到达交接处时没有与对端的制度接头对准。

ARIN针对的是来源方义务。草案二写道，来源方应当是目前在任何RIR登记的IPv4资源权利持有人，并遵守接收RIR的政策。问题不只是句子读起来别扭。来源方的身份、控制权与资源状态首先存在于来源RIR的记录和关系中；若接收RIR的政策并不以同样方式约束这个与它没有关系的来源方，AFRINIC的文字就不能自行制造那层关系。外部评估记录的ARIN意见因此把这句话视为与其跨RIR政策不兼容。

APNIC也聚焦于相同的来源方遵从句。评估表明确把意见绑定到草案二，并指出草案二与随后版本在相关文字上相同；就本篇所讨论的草案二而言，关键事实是APNIC认为要求来源方遵守接收RIR政策的设计不兼容。这不是APNIC对所有可移转性的永久否定，也不是对未来任何文本的预判，而是对一个特定版本、特定句子的定时检验。

RIPE NCC发现的则是程序起点错位。草案二让转让方向接收RIR提交请求，使用标准模板与正式转移协议；接收RIR批准后，再通知转出RIR、来源方和接收方，继而完成资源转移。RIPE NCC当时的程序从资源现登记所在的RIR开始。于是，草案二把第一把钥匙交给了尚未掌握来源记录的一端，而对端程序却要求先由掌握该记录的一端启动。RIPE NCC据此认为第5.7.5节不兼容且不可实施。

LACNIC的回答尤其能阻止一种过度简化：问题并不只叫“互惠”。评估记录显示，LACNIC本身不要求互惠，但它仍认为，让来源方遵守另一个RIR的政策意义不明，而且由接收RIR起步的流程与其他跨RIR安排不一致。也就是说，即使先移除“双方必须有对称政策”这一门槛，身份核验与工作流的接合问题仍然存在。没有互惠要求，不等于任何一方写出的程序都能被另一方执行。

四份回应合在一起，形成了一个很具体的现场：一个来源记录只能由掌握它的登记方可靠核验；一个接收方只能按照自身合法、已公布的接收条件审查接收者；而一次跨库变更必须让两边都知道何时承诺、何时更新、何时通知，以及失败时如何回到单一权威状态。若任何一环的责任主体在两套规则中不一致，“批准”这个词并不会自动把断口焊起来。

这里首先要校正证据坐标。本文唯一讨论的草案是AFPUB-2019-V4-003-DRAFT02，版本2.0，提交日期为2020年8月13日，拟修改CPM第5.7节。某条选题记录把它与2021年10月8日配在一起，但后一个日期属于不同编号AFPUB-2020-GEN-006-DRAFT02。编号、日期、条款与后续状态必须各自留在所属沿革中。2026年2月4日后来获批准的是该另一沿革的AFPUB-2020-GEN-006-DRAFT03；那一事件既不能倒推为本文草案二获准，也不能证明它曾经投入生产。

草案二要解决的缺口真实存在。它指出既有政策没有支持双向跨RIR转移的机制，拟让资源能够在AFRINIC服务区域内、移入该区域以及移出该区域。问题陈述同时提到IPv4地址和自治系统号码。它取消原有十二个月等待约束；在转让方与接收方达成协议且遵守现行政策的前提下，不为转移、分配或指派数量设上限。对于从另一个RIR转入AFRINIC的IPv4资源，草案仍保留需求评估，要求AFRINIC按照当时有效的政策核准接收方的IPv4需求。对于从AFRINIC转往另一个RIR的情形，文本又明确要求转移遵循接收RIR的政策。

这些选择勾勒出一种有吸引力的目标：稀缺资源不应因为最初登记地区而永久被困住，真实交易也不应受武断数量天花板阻碍；与此同时，接收侧仍可进行其政策规定的资格或需求审查。然而，目标合理不代表句法已经可执行。草案一方面把接收方写成任何与转让方达成转移协议的主体，另一方面在AFRINIC区域内又涉及会员身份与需求评估。工作人员据此指出第5.7.4.1与第5.7.4.2之间存在冲突：所谓“任何一方”到底是否还必须成为AFRINIC会员并通过需求审核，不能靠办事人员在个案中猜测。

来源方条款暴露的是更深一层的控制问题。若一项资源当前登记在另一RIR，AFRINIC或接收RIR不能仅凭申请者自述完成来源持有人核验。工作人员直接追问：为什么来源方应遵守一个与其没有关系的接收RIR的政策？如果来源方不向自己的RIR提交，而是直接找接收RIR，来源持有人验证又如何完成？这两个问题不是对便利性的挑剔。它们决定一项请求是否由能够核验权利与状态的主体受理，也决定两个登记库最终能否避免同时承认相互冲突的状态。

所谓“标准模板”同样不能凭命名自动成为共同标准。工作人员询问，该模板是否已得到全球接受。若四个对端并未同意字段、证据、签署方式和消息含义，五份看起来相似的表格仍可能表达五套不同承诺。草案还没有为争议资源给出处理指引；若来源权利受到异议，继续切换可能产生双重主张，贸然终止又可能损害真实接收方。工作人员也提醒重复分配风险：只有把原记录、承诺点与后续更新锁进一个可回滚的顺序，才能防止旧状态未撤、新状态已建的重叠。

资源类型的边界也不够清楚。问题摘要提到ASN，操作性条款却围绕IPv4展开。ASN是否适用相同资格、相同起点、相同状态处理与相同依赖服务，不能从一段目标陈述中推定。类似地，草案规定转移后的IPv4历史资源不再被视为历史资源。这会改变状态标签及其后续处理，因此必须获得两端对同一语义的确认；不能让一端认为“历史”属性已经消失，另一端仍按原状态保存。

程序写法可以被拆成一串动作：转让方与接收方达成协议；转让方向接收RIR提交标准模板和正式转移协议；接收RIR审查并批准；接收RIR通知转出RIR、来源方和接收方；资源随后转移。每个动词都隐藏着接口问题。谁证明转让方确为当前持有人？谁确认资源没有争议？“批准”是否只是接收资格通过，还是两端都已准备提交？通知是什么格式，接收方怎样验证它来自正确对端？若一方更新成功、另一方失败，谁发出撤销指令？草案二并未把这些问题变成共同、版本化的执行约定。

工作人员列出的改动范围说明，这不是一张数据库表里换个名字。MyAFRINIC的转移工具可能需要修改；反向DNS委派需要与新的权威状态一致；RPKI ROA不能在旧控制关系与新登记之间悬空；转移日志要留下可复核的顺序；工单系统要把申请、核验、条件、通知与完成状态连起来。除此之外，还要审查内部流程，与具有兼容政策的RIR协调，并投入额外会员服务人员和软件工程工作。任何一项没有同步，都可能让账面转移与路由安全、域名反向解析或成员服务视图出现时间差。

这些是操作依赖，不是已经发生的事故记录。现有材料没有证明草案二完成过一笔转移，也没有证明某笔交易因它被拒、某个网络因此中断、某位客户蒙受损失，或市场价格出现可量化变化。LARUS从运营者角度提醒，RIR治理决定可能通过登记、路由授权与业务连续性传导风险；在这里，它帮助我们解释为什么可预测的交接很重要，却不能被拿来填补一个没有记录的生产事件。审慎的分析必须把“存在暴露面”与“已经发生损害”分开。

状态边界同样不能含糊。草案二于2020年9月17日在AFRINIC-32与其他转移提案一同介绍。9月21日，共同主席摘要宣布条件性粗略共识和最后征求意见，并指出与ARIN有关的互惠担忧、要求修改。这只是私人政策制定程序中的一个阶段。它不等于文本已写入CPM，不等于董事会批准，不等于软件与人员已经完成改造，更不等于四个对端已经接受同一执行流程。草案后来被标为归档；“归档”说明记录状态，不是“曾实施后退役”的同义词。

因此，四个不匹配接头给出的第一个结论并非“跨RIR转移不可能”，而是“不能从一端的提议文字直接推导出双端可执行性”。ARIN和APNIC卡在来源方被错误置于接收方规则之下；RIPE NCC卡在请求从错误的一端开始；LACNIC即使不要求互惠，仍在这两个位置看到错位。各方意见来自一个特定时期，绑定草案二的确切文本。它们不能自动覆盖草案三、草案四或另一个2021年提案，也不能被无限期当成任何未来制度的否决票。

真正需要保留的是检验方法：把政策目标放到每一个实际交接点上，看两边是否为同一动作指定了同一责任人、同一前置条件和同一状态含义。只有这样，“这条路原则上开放”才会变成“这条路在指定日期、指定版本和指定方向上能够通行”。