摘要

  • 截至 2026 年 8 月 30 日，AFRINIC 官方数据库中有 3,790 个 RPSL 对象使用严格格式的 remarks: Geofeed HTTPS-URL；其中符合 RFC 9632 地址对象语境的 inetnum 与 inet6num 共 3,573 个。
  • 现有写法不是错误。RFC 9632 明确允许尚未实现 geofeed: 专用字段的注册数据库使用 remarks 兼容形式，并要求使用方在迁移完成前同时识别两种形式。
  • AFRINIC 在线地址对象模板仍只有可选的 remarks:，没有 geofeed:；公开 DBWG 记录显示工作项与影响评估请求曾被多次提出，但截至 2026 年 8 月未见后续公开处置。
  • 合理要求不是“立刻上线”，而是一份有限、可核验的迁移回执：状态、权限矩阵、语法与冲突规则、旧记录处理、WHOIS/RDAP 映射、隐私与认证边界、测试、回滚和最终结果。

先看那 217 条差额。

对 AFRINIC 2026 年 8 月 30 日官方数据库压缩包逐行搜索，会得到 3,790 条严格匹配：字段名是 remarks:，随后是区分大小写的 Geofeed，再跟一个 HTTPS 地址。这个数字没有错。但把 RPSL 对象按空行分组、识别对象类型以后，与地址注册直接相关的数量是 3,573：3,483 个 inetnum，90 个 inet6num。

剩余 217 条去了哪里？168 条在 route，41 条在 route6，5 条在 domain，2 条在 as-set，1 条在 organisation。

这不是一次“抓到 217 个故障”的审计。它说明的是更朴素的事实：备注没有类型边界。人可以在里面写 Geofeed，也可以写运维说明、证书、联系方式或任何其他文字。只要生产者和采集者共同约定识别某个前缀，备注就能承担机器接口的作用；但数据库本身并不知道那行文字是什么。

因此本文用 3,573 做标题。3,790 描述的是字符串在整个 RPSL 库里的出现位置，3,573 描述的是 RFC 9632 发现机制所围绕的地址对象。两者都是事实，却回答不同问题。把较大的数字直接称为“地址记录”会制造精确的错误；忽略较大的数字，又会错过通用备注向其他对象类型外溢的证据。

先承认兼容方案的价值

如果只因没有专用字段就把 AFRINIC 判为落后，结论会比数据库本身更粗糙。

RFC 9632 预设各 RIR 不会同时改造数据库。对于尚未实现 geofeed: 的系统，它规定了严格的 remarks 形式。只要仍有生产者没有完成迁移，采集者就必须能够读取 remarks 和专用字段两种形式。换言之，AFRINIC 当前做法不是标准之外的临时补丁，而是标准专门保留的兼容路径。

这条路径也确实承载业务。3,573 个地址对象指向 106 个不同的 HTTPS URL。对象状态包括 3,461 个 ASSIGNED PA、71 个 ALLOCATED PA、17 个 ALLOCATED-BY-RIR、13 个 ASSIGNED PI 和 11 个 SUB-ALLOCATED PA。多个对象共用同一个 feed 很正常：运营者可以在一份文件中维护多个前缀的位置声明。

这些数量不能证明 URL 都可访问，不能证明下游平台都采用，也不能证明某个城市或国家代码正确。它们证明的是采用规模：现有约定已经进入大量注册记录。任何迁移若把“字段更整洁”置于兼容性之上，都可能让运营者和数据采集者承担不必要的切换成本。

AFRINIC 谨慎也有正当理由。一个字段会同时触及网页更新、邮件更新、认证、批量库、WHOIS 客户端、RDAP、文档、客服流程和异常处理。若同一对象同时出现 remarks 与专用字段，系统必须决定谁优先；若旧 remarks 不符合严格语法，必须决定拒绝、保留、提示还是转换。看似一行模板的变化，实际可能是一项跨接口工程。

所以问题不是“为什么还没照抄别的 RIR”，而是“这项改动是否已经被评估、决定，并留下可验证状态”。

数据库可以校验指针，不能认证世界

专用字段的意义很具体。RFC 9632 指出，remarks 形式无法由 RIR 正式校验，因此每个对象最好只有一个 Geofeed 引用的建议也无法在字段层强制执行。专用 geofeed: 可以限定 HTTPS 语法、限制出现次数、发现冲突，并让输出系统把 URL 当作数据，而不是要求每个客户端重新解析文字。

当前库里有 3,592 个地址对象包含不区分大小写的 Geofeed 类备注，其中 106 行偏离严格形式：有的在 Geofeed 后加冒号，有的使用小写，有的仍是 HTTP。这并不等于所有变体都会被采集器拒绝。它只说明文字约定会漂移，而通用 remarks 不会主动阻止漂移。

字段能解决的是结构，不是真实性。至少有三层必须分开：

  1. 指针语法：数据库是否知道这是一条 Geofeed URL，格式与数量是否符合规则；
  2. 资源授权：发布文件的人是否有权代表相应 IP 地址空间；
  3. 位置内容：文件里的地点是否准确、及时，并且没有过度暴露用户位置。

HTTPS 保护客户端与指定站点之间的连接，认证的是端点，不是地址空间的权利。RFC 9632 因而提供可选的 RPKI 签名机制，用资源证书增强发布者授权证据。即使有 RPKI 签名，也不意味着每一条位置都天然准确，更不意味着细粒度位置不会产生隐私风险。

专用字段应当把第一层做清楚，并为第二层提供更稳定的入口；它不应借此宣称第三层已经被注册机构认证。把记账人变成地理真理裁判，既超出字段能力，也会把责任放错位置。

一项公开请求，需要一个公开终态

这项议题并非外部观察者凭空提出。它在 AFRINIC Database Working Group 的公开邮件列表里已经形成清楚的时间线。

2025 年 10 月 27 日，一位参与者提议加入 geofeed: 并允许资源持有人更新。邮件承认当前可用的是 remarks，同时描述了其 PI 资源体验：相关备注需要 hostmaster 协助。10 月 28 日，DBWG 联合主席启动两周讨论期，并请工作人员准备包含利弊的影响评估。

到了 11 月 14 日，联合主席表示讨论期内没有反对，请 AFRINIC 工作人员把它作为工作项，并说明实施方法与影响评估。2026 年 4 月 6 日，提议者追问进展；4 月 16 日，联合主席再次要求确认是否为有效工作项并更新评估；4 月 17 日，另一位参与者表示支持。

公开归档显示，2026 年 1、2、3、4、8 月有邮件月份，5、6、7 月没有归档目录；截至 8 月的主题索引中，4 月 17 日之后没有新的 Geofeed 主题记录。本文能证明的仅仅是：在检查到的公开 DBWG 记录里，没有找到更晚的公开回复或处置。

这句话不能被扩大为“AFRINIC 什么都没做”。内部可能已有工单、技术评估、法律讨论或私下沟通。邮件列表看不到它们。真正缺少的是公开请求的公开终态：已接受、延期、拒绝、被替代，还是等待某项依赖。

治理不要求所有提议都被实施。治理要求机构能够说清楚提议现在在哪里。

13 个 PI 对象只能支持有限判断

原始邮件关于 PI 更新的说法值得核验，也必须控制范围。一个人的经历不能代表所有持有人。冻结数据库提供了一个有限截面：13 个使用严格 Geofeed remarks 的 ASSIGNED PI 地址对象，全部在 mnt-by 中列有 AFRINIC-HM-MNT，同时在较低层维护字段中出现资源相关 maintainer。

这与提议者描述的控制结构相吻合，却不能告诉我们全部更新路径。mnt-by 说明对象保护关系，不能单独证明客服是否提供其他入口、哪些修改可由资源 maintainer 完成、是否存在自动审核，或每次请求的处理方式。

应当公开的问题不是笼统的“PI 能不能自己改”，而是一张权限矩阵：按对象类型、状态、mnt-by 与 mnt-lower 关系，分别说明谁能新增、修改、删除和纠错；使用什么认证；直接写入失败时走哪条支持路径；处理结果留下什么回执。

这张表既能保护数据库，也能保护运营者。没有权限边界的自助写入可能扩大滥用；没有可见纠错路径的集中控制则可能让过期信息长期存在。

RDAP 让隐含语义暴露出来

检查 160.115.0.0 的 AFRINIC RDAP 响应，可以看到一条严格形式的 Geofeed URL，但它位于通用 remarks description 里。响应声明 rdap_level_0、nro_rdap_profile_0 和 cidr0，没有声明 geofeed1，也没有标准化的 Geofeed link。

RFC 9877 定义了 rel: geofeed 链接关系和可选的 geofeed1 扩展。服务器可以提供这类链接；如果主动声明 geofeed1，在拥有且可以返回 URL 时就必须给出相应链接。AFRINIC 当前响应并未声明该扩展，因此不能据此指控它违反 RFC 9877。

但这个响应准确呈现了语义债务：数据已经在那里，机器却只能把它当作一段描述。人类和定制采集器可以读懂，通用 RDAP 客户端无法从 conformance 声明得知服务器支持结构化 Geofeed，也不能在不自行解析文字的情况下取得标准链接。

WHOIS 里的备注一旦跨到 RDAP，问题就从“模板是否漂亮”变成“每个客户端是否要重复猜测同一段文字”。

一份不预设结论的迁移回执

最小可用回执应包含十二项：

  1. 工作项编号、负责人、进入日期、当前状态和下次复核日期；
  2. 当前与目标 WHOIS schema 版本；
  3. 对更新接口、批量库、WHOIS、RDAP 和常见采集器的影响评估；
  4. 按对象类别、资源状态和 maintainer 关系划分的写入权限；
  5. HTTPS 语法、出现次数和错误返回规则；
  6. remarks 与专用字段并存或冲突时的优先级；
  7. 对严格形式、变体形式和跨对象类型记录的清点与迁移办法；
  8. 是否实现 RDAP geofeed1 及其输出规则；
  9. 明确区分字段语法、HTTPS 端点、RPKI 资源授权与位置准确性；
  10. 有关位置粒度和个人暴露的隐私提示；
  11. 测试对象、兼容结果、纠错通道和回滚条件；
  12. 最终上线或关闭回执，包括版本、日期、监测指标和未解决例外。

这份回执可以支持实施，也可以支持延期。AFRINIC 或许判断当前兼容方案足够成熟，短期不值得改；也可能先校验新 remarks，再逐步开放专用字段；还可能先完成 WHOIS，之后再考虑 RDAP。只要选择、理由、影响和验证条件公开，社区就不必从沉默中猜测进度。

注册数据库的权威不来自它对一切都作判断，而来自它对自己知道什么、不知道什么、谁能修改、如何纠错说得足够精确。Geofeed 专用字段不是宏大治理改革，只是一项有限的数据结构决定。正因为有限，它更应该能够被完整说明。