VPN 出口地址登记册究竟应当记录什么？

出口登记册听起来像清单，而清单并不是难点。难点在于确定每条记录主张什么、谁可以发布它，以及当这一主张不再成立时会发生什么。这些提案把三种不同的地址角色混为一谈，而把它们混在一起的登记册无法可靠地回答任何问题。把一条记录从发布追踪到撤回，设计要求便会自行显现。

从记录开始，而不是从清单开始

第一个问题不是收录多少个地址，而是一行到底意味着什么。它描述的是客户端在哪里接入、目的地能看到哪个来源，还是谁在登记册中持有某项分配？这是三种主张，各有三个归属方和三种失效方式。不说明自己记录哪一种的登记册，既无法校验，也无法更正或到期。把含义弄对才是设计工作，清单只是输出。

在编写任何模式之前，先写出行定义。如果这个定义需要用到「和」，那它大概是两条假装成一条的记录。

三种看起来相似的地址角色

这些角色容易混淆，因为一次部署可以同时用到三者，而且往往确实如此。一项服务可以在一个地址上终止连接，并从另一个地址转发流量，而登记册记录的完全是第三种事实。

一个托管网段可能同时存在 VPN 出口与无关工作负载，因此登记册中的匹配并不能说明某个地址在某一时刻做什么。不写明角色的记录，不能作为任何具体事实的证据。正是写明角色才使记录可被证伪。还要说明地址族，因为一个悄悄只覆盖 IPv4 的登记册会误导所有假定相反情况的人。

把一条记录从发布追踪到撤回

取一个假想的出口并追踪它。运营方在声明的生效时间发布前缀及其角色，使用者获取它，之后该地址不再作为出口服务。每一步都需要规则：谁可以发布、前缀实际覆盖什么、记录何时生效，以及如何撤回。没有撤回途径的数据源会积累无人能与当前主张区分开的陈旧主张。

把发布权限与标签的准确性分开。把组织与资源关联起来的登记册记录证明的是分配，而不是当前用途，二者是不同的主张，需要不同的证据。使用者需要知道自己信任的是哪一种。

也要定义更正。被重新分配给客户的地址，或因错误标签而被牵连的无关服务，需要一条有据可查的修复路径，而不是在工单队列里争论。撤回触发条件应与发布规则写在同一份文件中。

已发布的数据源能支持什么、不能支持什么

已发布的前缀属性是一种成熟做法，现有示例描述的是地理或归属，而不是行为。VPN 数据源需要有自己的语义、自己的证据规则和自己的审核流程，而给一份国家清单改名并不能提供其中任何一项。ARIN 登记册指南说明了分配记录主张什么、不主张什么，新数据源必须就其自身主张赢得同样的清晰度。这是规范工作，不是重新贴标签的工作。

这样的数据源所能支持的，是关于网络来源的分类判断。它做不到的是识别共享地址背后的个人、证明来自该地址的全部流量都经过隧道，或判定某个具体请求是否属于滥用。这是三个彼此独立的问题，各有独立的证据要求。

把法律问题留在规范之外

技术规范无法裁定一项拟议的登记要求是否合法、相称或明智。这种评估需要实际的立法文本、受影响的权利、管辖范围，以及数据格式无法提供的法律分析。一种格式可以设计得很好，却仍然支持糟糕的政策。

规范能做的是让讨论具体化。先定义拟议的数据、其边界和失效方式，这样政策争论针对的是真实机制，而不是每个参与者各自想象的、未经定义的清单。这就是技术文件能对法律问题作出的最大贡献。