摘要

  • ARIN在2024年6月表示，IETF共同标准一旦被接受，就会在RDAP、ARIN Online和Reg-RWS中支持geofeed；建议会保持Open，直至功能开发并部署。
  • RFC 9877于2025年10月成为Standards Track RFC，定义了geofeed1、rel=geofeed和application/geofeed+csv，并由IANA登记。
  • 截至2026年9月12日，ARIN的建议清单仍把2024.10列为Open；现场RDAP帮助响应没有geofeed1，一个选定的网络对象仍只在Registration Comments中放置geofeed URL。
  • 这些事实不能证明工程停滞，也不能代表整个数据库。它们说明ARIN需要一张有日期、可复核的部署凭证，逐项交代标准触发、产品状态、旧评论迁移、批量访问、隐私、测试与回滚。

三只时钟没有同时走到下一格

这项工作的公开记录里有三只时钟。第一只是社区流程时钟：一项建议什么时候被接受、实施、关闭。第二只是标准时钟：IETF何时把草案变成稳定的RFC。第三只是产品时钟：用户界面、自动化接口和公开查询何时真正呈现相同能力。

2024年6月3日提交的ACSP Suggestion 2024.10，要求ARIN在网络对象上加入可选geofeed字段。提议者指出，ARIN资源持有人当时只能在自由文本评论中写入Geofeed [URL]一类字符串，而消费者需要从句子里识别URL。一个有类型的字段，能够把“这段文字也许是一条指针”变成“这个属性明确承担发现功能”。

ARIN四天后的答复给出了比一般“已收到”更完整的路径。五个RIR正在IETF内合作制定RDAP扩展；标准被接受后，ARIN会修改RDAP，并为ARIN Online和Reg-RWS加入必要功能。答复还提到为批量RDAP下载建立跨RIR一致格式。建议则会保持Open，直到新功能完成开发和部署。

这段话没有发布日期，也没有定义“被接受”究竟指IESG批准、RFC刊发、RIR共同配置文件还是另一个里程碑。因此，不能把它当成逾期合同。但它确实把等待理由放在了一个可观察事件上。一旦事件发生，治理责任就从说明外部依赖，转向说明内部交接。

RFC 9877在2025年10月以Standards Track身份发布。第一只时钟仍显示Open；第二只已经跨过RFC；第三只在公开层面没有一张逐接口状态表。缺口由此产生。

geofeed1是一项声明，不是装饰

RFC 9877没有命令所有RDAP服务器都实施geofeed。它做的是定义一套可互操作的语义。rel=geofeed说明链接用途，application/geofeed+csv说明目标文件类型，geofeed1则让服务器声明自己托管IP网络对象的geofeed URL。IANA的RDAP Extensions注册表已经列出geofeed1并指向这份RFC。

三者中，geofeed1承担的是能力承诺。服务器若使用该扩展标识，就必须在帮助响应以及包含IP网络对象的查询或搜索响应的rdapConformance数组中写入它。对于服务器掌握且允许返回geofeed URL的对象，响应还必须给出相应链接。

这使“没有链接”获得上下文。客户端若先看到服务器声明扩展，便可以在规则允许的范围内理解某个对象为何没有链接。若服务器根本没有声明，缺少链接只能说明本次响应没有给出链接，不能被放大为系统性结论。

RFC还特意留下较弱的实施路径：服务器可以采用已经登记的geofeed关系和媒体类型，却不声明geofeed1。因此，探测帮助响应很有价值，但它不是对全库的搜查令。判断必须停在协议能证明的位置。

现场JSON只回答了两个窄问题

2026年9月12日抓取的ARIN RDAP帮助响应列出了基础RDAP、NRO配置文件、CIDR、origin-AS、RIR搜索等多个扩展。数组里没有geofeed1。这足以写成一个精确句子：该次现场帮助响应没有声明RFC 9877扩展。

它不能写成“ARIN没有做geofeed”。帮助端点看不到开发分支、内部测试或尚未公开的ARIN Online表单，也无法判断ARIN是否在等待另一个跨RIR配置文件。协议状态和工程活动不是同一类证据。

另一个现场响应展示了旧路径。154.54.100.0/22的网络对象在Registration Comments里包含Geofeed ai.net/geofeed.csv。其rdapConformance没有geofeed1，三条链接分别是self、alternate和up，没有rel=geofeed。

选择这个对象，是因为它清楚呈现社区提议所说的评论写法，而不是为了抽样统计。一个对象不能证明所有ARIN geofeed都仍藏在评论里，也不能证明其他对象没有标准链接。它甚至不能证明URL所指文件仍然正确。它只能证明：在RFC发布之后，至少有一个公开对象仍携带旧式发现线索。

这已经足以提出迁移问题。新字段上线时，旧线索如何处理？

2026年的会议措辞需要一条校正注

ARIN 57在2026年4月举行。会议第二天的工程更新提到geofeed和RPKI目录服务的RDAP增强，并称相关工作“正在通过IETF”。当时RFC 9877已发布约半年。

也许演讲者指的是另一份相关文本、NRO配置文件或后续协调；也许幻灯片沿用了旧句子；也许产品仍有未完成的标准依赖。公开记录无法在这些解释中选择。负责任的写法不是据此指控延误，而是要求ARIN对两种公开状态作一次对账。

一条简短校正就有价值：RFC 9877已经完成，当前实际依赖是某项配置、迁移、隐私审查或产品排期。机构最容易积累的技术债，往往不是代码，而是已经失效却仍在解释今天的旧前提。

从评论升级为字段，不能靠正则表达式完成

ARIN Online、Reg-RWS、RDAP和批量输出分别服务于人、自动化发布、公开查询和大规模消费者。它们可能在不同日期上线，也可能对同一URL应用不同校验。若只宣布“geofeed已部署”，用户仍不知道哪一条路径可写、哪一条可读、何时一致。

更困难的是旧评论。自由文本可能只有一个干净URL，也可能有两个链接、附带说明、过期地址，或者碰巧出现Geofeed一词。把所有匹配字符串自动提升为有类型的权威指针，会改变原文本的意义；完全不迁移，则会长期保留两套发现方式。

可审计的做法应先盘点，再迁移。把候选项分为格式清楚、含糊、多链接、不可达和不适用。涉及权限提升的项目应让资源持有人确认。若评论和新字段同时存在，要说明谁优先。若迁移规则错误，要能回滚到原始证据而不是覆盖它。

前缀层级也必须进入测试。更具体的网络对象可能提供自己的feed；宽泛对象的URL不能无条件向下覆盖。客户端需要从ARIN得到确定的结构，再按RFC 9632的选择规则处理，而不是猜测评论继承。

指针、授权与地理事实是三件事

RFC 9632说明如何通过RPSL发现geofeed，也定义了可选的RPKI认证方式。这里“可选”很重要。签名可以帮助消费者判断feed是否由相关资源的授权方提供，并约束覆盖前缀，但它不会到现场测量服务器位置。

一条完整链条至少有四个动作：资源持有人提供URL；ARIN发布指针；可选签名证明来源授权；消费者决定是否采纳文件中的地点声明。任何一步都不能替代下一步。注册局发布的链接不是物理位置证明，RPKI认证也不是地理真伪认证。

机器可读会放大优点，也会放大残留问题。批量消费者更容易发现数据，同时也更容易长时间缓存旧数据。删除何时生效？批量快照何时更新？更具体feed何时覆盖较宽feed？因隐私或监管原因省略链接时，客户端能作何种推断？这些都需要部署说明。

RFC 9632不建议把普通RDAP查询用作批量收集。ARIN在2024年答复中提到一致的批量格式，恰好承认了这一边界。若产品路线改变，也应说明替代方案，而不是让高频消费者自己决定如何抓取。

一张部署凭证应如何写

第一栏是触发条件。明确列出RFC 9877、相关勘误，以及ARIN认为仍具约束力的NRO或跨RIR配置文件。给出ARIN判定“标准已被接受”的日期。若还有依赖，就写出名字，不要继续用笼统的IETF状态代替。

第二栏是产品矩阵。ARIN Online、Reg-RWS、RDAP帮助、网络对象查询和批量输出分别处于设计、测试、可用、默认、弃用还是完成。每个状态只定义一次。列出预计出现的rdapConformance标识、链接关系和媒体类型，并提供不会泄露成员敏感信息的正例与反例。

第三栏是写入规则。谁有权增加、修改和删除URL？是否只允许HTTPS？格式化会不会改变URL？URL暂时不可达时，是阻止保存、提示风险，还是仍由持有人负责？系统不应把一次网络故障悄悄变成指针撤销。

第四栏是迁移记录。公布候选评论的数量与处置类别，不公布具体URL。说明哪些需要持有人确认，哪些保留原状，旧评论何时退出发现链，以及错误提升时如何恢复。

第五栏是多只时钟：变更获准时间、ARIN Online回读、Reg-RWS回读、RDAP可见、批量快照纳入。最终一致并不可怕，不可观察才可怕。给出可承诺的时间窗，比假装所有接口同一秒改变更可靠。

第六栏是测试与治理。至少覆盖有效链接、无链接、错误URL、更具体对象、多语言链接、受限返回和删除。记录上线与回滚日期。解释ARIN 57措辞。最后，按ARIN自己的完成标准更新ACSP 2024.10，并把状态链接到这张凭证。

凭证的价值，是阻止双方过度推断

没有公开交接记录，外界容易把缺少geofeed1解释成“什么都没做”，机构内部也容易把开发进展解释成“已经完成”。两种说法都把一种状态冒充成另一种。

凭证给ARIN一个有边界的陈述：截至某日，这些接口按这些规则支持这些协议元素。它也给用户一个有边界的测试。更重要的是，它保留不确定性：Open状态不等于工程停滞，一个对象不等于全库，URL不等于位置事实。

ARIN完全可能有合理答案。例如，RFC只是第一项前置条件，另一个共同配置文件尚未完成；或者部分界面已经上线，只是建议页没有同步。两种说明都比继续让人猜测更有用。

标准已经解决了命名问题。现在需要解决的是交接问题：外部条件何时改变，谁控制哪条接口，旧数据如何跨越边界，客户端最终可以相信什么。

来源