摘要

  • APNIC 62 的演示文稿称，在随机抽取的 20 万条可通过 Whois 发现的地理位置记录中，APNIC 占“成功 Geofeed 发布者”的 3.0%，ARIN 占 21.6%，RIPE NCC 占 75.5%。
  • 图表以不同 netname 归并发布者，并因技术原因排除 AFRINIC 与 LACNIC；它没有给出各区域合资格总体、快照时间、netname 数量或“成功”的判定流程。
  • 因此，3.0% 是三地成功样本内部的构成比例，而不是 APNIC 会员、资源持有者、前缀或网络的 Geofeed 采用率。
  • “一键发布”值得试验，但评估它需要一张可复核的采用回执，把资格、发现、验证、维护和下游使用接成同一条测量链。

先看脚注，再看柱子

图上的三根柱很容易产生竞赛感：APNIC 只有 3.0%，ARIN 为 21.6%，RIPE NCC 达到 75.5%。标题问的是成功发布者来自哪个 RIR，于是读者自然会把柱高理解为三个地区的采用表现。

脚注改变了计数对象。数据是 geolocatemuch.com 从 20 万条地理位置记录中随机取出的样本，前提是相应 Geofeed 能通过 Whois 被发现；随后再按“Network IDs（不同 netnames）”分组。AFRINIC 和 LACNIC 则因技术原因被有意排除。

这些限定并不会让图表失效，恰恰相反，它们规定了图表能够说什么。一行地理位置记录不是一名发布者。一份 CSV 可以包含许多前缀，多个资源对象也可能指向同一文件。netname 是注册数据里的标签，在不同注册局中未必代表同一种稳定组织身份。去重必须做，但以什么键去重，会决定哪些发布者被合并、哪些被保留。

三个百分比相加为 100.1%，这与保留一位小数后的普通舍入相符，不值得另作解读。真正缺失的是每根柱背后的不同 netname 数量，以及每个 RIR 内有多少具备发布条件的 netname、资源持有者、前缀或已路由网络。

样本构成不是总体普及程度

假设成功样本里有 1,000 个观察值，其中 30 个映射到 APNIC，APNIC 在这个集合中的占比就是 3.0%。若 APNIC 的合资格总体只有 60 个，这个数字与合资格总体为 60,000 个时代表的普及程度完全不同。同一个分子无法回答两个问题。

“构成”问的是：经过取样、发现、清洗和归类后留下的成功项，分别登记在哪些区域。“采用率”问的是：某一区域全部合资格对象中，有多少发布了当前可访问、范围正确且能被使用的 Geofeed。要把前者变成后者，必须为每个区域提供同一口径的分母。

APNIC Blog 的报道把来源称为样本，并说数据凸显了区域采用差异。这个方向性担忧可能完全成立：在被纳入的成功集合里，APNIC 标签确实很少。但就已公开的信息而言，它还无法测量 APNIC 运营者相较 RIPE NCC 运营者更少采用 Geofeed 的概率。

另外两个 RIR 的缺席进一步划清了边界。演示文稿披露了排除，这是好事；同时也意味着柱子描述的是三个被纳入的区域，而不是整个 RIR 体系。由此不能推断 AFRINIC 或 LACNIC 的情况，而技术上无法纳入本身也提示：不同注册数据之间的可比性需要单独说明。

“成功”应当是一组状态，而不是一个形容词

geolocatemuch.com 的公开页面说明，它通过 Whois 发现 Geofeed，并提供合并后的验证数据。页面也解释了关联为何复杂：一份文件可包含多个前缀，多个资源对象可指向同一文件，超出注册对象所涵盖地址范围的记录应被忽略。

APNIC 62 的图表没有定义“成功发布者”。它可能指链接被发现，也可能指 URL 可抓取、CSV 能解析、记录位于授权范围、发布权限得到验证、字段通过检查，或者某个下游服务实际采用了数据。这些并不是同一个状态。

RFC 8805规定了自发布 IP 地理位置数据的格式，同时保留消费者的判断权。消费者可以把它当作提示，可以选择别的数据，也要自行处理冲突。RFC 9632标准化发现方式与可选认证，能加强“资源持有者授权这份文件”的证据，却不能把声明自动变成测量所得的地理事实。

RFC 9877通过 geofeed1 链接关系和媒体类型把发现机制带入 RDAP。抓取与使用明确不在该 RFC 的范围内。它既没有要求注册局提供某种按钮，也没有定义采用率分母，更没有保证下游数据库会接收链接。

一键只能消除一种摩擦

Sid Mathur 的五页演示文稿建议 RIR 在控制面板里提供“一键”发布 Geofeed URL。这个建议值得实测。注册局已经负责账户认证和资源对象维护；引导式表单可以减少拼写错误、检查地址范围、展示隐私提醒，并把一个隐蔽机制放到运营者看得到的位置。

最有力的支持理由应被正面承认：运营者不该为了发布一个标准 URL 而学习偶然形成的命令语法。设计良好的表单可以降低支持成本，让正确路径成为容易的路径。

但是，按钮不会代为托管 CSV、决定位置字段表达什么、持续更新数据、证明位置准确，也不能迫使商业数据库摄取它。注册局一侧的状态可能在一次点击后完成，而所有下游状态仍然未知。

演示文稿还说，一次非正式 APNIC WhatsApp 社群投票把“不确定注册局能怎样帮助”列为第二大障碍。这是很好的调查线索，却不是一项区域优先级测量。文稿没有给出样本数、招募方式、题目、选项、日期或去重规则，也没有显示第一名是什么、两项差距多大、回答者是否代表尚未发布者。

给“采用”一张版本化回执

可复核的测量应从柱状图之前开始。回执需记录快照时间、源文件与代码版本、20 万行抽样方法、原始行数和唯一前缀数、Whois/RDAP 发现方法、RIR 映射规则以及每项技术排除。它还要明确定义成功状态，并展示从发现、抓取、解析、范围检查、权限验证、时效检查到消费的数量流失。

每个 RIR 都应在共同计数单位下同时公布分子和合资格分母。如果继续使用 netname，就要说明标准化方法及其跨注册局局限；若改用资源持有者、文件、前缀或路由源，也应明确标记口径变化。

产品试验还需要另一条链：控制面板版本、合资格账户数、尝试次数、成功发布数、验证失败原因、30 或 90 天后的维护情况，以及至少一个消费者成功发现该链接的证据。隐私安全的汇总数据已经足够，无需公开任何会员的精确位置或账户历史。

APNIC 62 大会报告证明“The case for RIRs”是一场 Cooperation SIG 演讲，并不能把演讲者建议变成 APNIC 政策。Blog 也说明作者观点未必代表 APNIC。把提案与机构承诺分开，既保护试验空间，也保留责任边界。

所以，3.0% 这根柱不应被丢弃。它的作用是启动调查；脚注则提醒人们不要过度声称。先公开什么进入样本、什么通过筛选、什么被排除，以及谁本可参加，下一张图才可能告诉我们：更简单的注册局界面究竟改变了采用行为，还是只改变了讲述方式。

来源

  1. APNIC Blog：APNIC 62 的 IP 地理位置讨论
  2. Sid Mathur：Self-published Geofeeds; the role of RIRs
  3. APNIC 62 大会报告
  4. Geolocate much?
  5. RFC 8805：自发布 IP 地理位置数据格式
  6. RFC 9632：Geofeed 数据的发现与使用
  7. RFC 9877：Geofeed 数据的 RDAP 扩展