摘要

  • RIPE NCC 的迁移不是一次性的格式替换：2001 年 4 月 23 日开始切换，5 月 14 日让 auto-dbm 只接受 RPSL，直到 10 月 15 日才关闭 RIPE-181 自动转换。
  • 公开记录显示，Andrei Robachevsky 当时以 RIPE NCC Database Group Manager 身份参与沟通：他在 2000 年介绍 v3 查询行为，2001 年 4 月签署第一阶段完成的通知。
  • 把注册对象转换成新格式，只能说明数据库如何保存和接收记录；它本身不证明地址资源归谁所有、某个前缀目前是否在 BGP 中发布，或数据包实际经过哪里。

改变的是入口，也改变了维护责任

5 月 14 日的公告把迁移写成了三个不同入口的规则。auto-dbm 此后只接受 RPSL；auto-181 仍接收 RIPE-181，并在 10 月 15 日前将其转换成 RPSL；auto-rpsl 则继续接受 RPSL。测试数据库也采用相同区分。

因此，操作人员面对的并非一个抽象问题——“数据库迁移了吗？”——而是更具体的几个问题：当前脚本把更新发往哪个地址？它生成哪种语法？目标入口执行什么授权规则？临时兼容路径何时关闭？公开资料没有量化有多少脚本需要修改，也没有证明所有用户都遇到中断。但地址、格式和期限都被明确写出，用户可以据此检查自己的自动化程序。

4 月 23 日的消息称，新版 RIPE Database 已经运行，原有对象被自动转换为 RPSL 并加载。这个“已转换”并不意味着所有外围路径在同一时刻完成切换。第一阶段里，auto-dbm 仍允许受限制的 RIPE-181 更新：空属性、拼写错误属性会被拒绝，该路径不支持 PGP 认证，同时仍执行 RPSL 的授权规则；另一入口 auto-rpsl 接收新格式。实际变动因此包括数据结构、接口行为和谁能以什么方式更新记录。

查询语法也是证据边界

2000 年 8 月，时任 Database Group Manager 的 Robachevsky 介绍 v3 查询接口的变化，并向数据库工作组征求反馈。精确匹配与更宽范围查询回答的不是同一问题：前者寻找与输入地址范围完全相同的对象；后者返回能够覆盖输入范围的最小更大范围。-K 让响应只包含主键。来源查询列出数据库源及镜像信息、序列号范围；反向查询则可以按联系属性查找对象。

这些选项不会替一条记录背书，却会决定调用者看见什么。只返回主键，方便自动化处理，但同时减少上下文；找到包含输入范围的上级对象，也不等于找到了精确匹配。镜像信息说明数据库接口提供了哪些复制线索，不等于对全球路由的实时测量。接口变化因此可能让监控程序或维护脚本改变行为，即使一条记录表面上仍然相似。

RIPE 38 数据库工作组会议纪要把 Robachevsky 列为迁移议题的演讲者，并记下了关于受影响群体的讨论：查询用户、更新用户、脚本和近实时镜像，以及 RPSL、访问控制、数据库格式和镜像协议。该页面明确标为草稿，所以它证明的是草稿纪要如何记录会议议程和演讲，并不能单独证明后来所有步骤按期完成。4 月、5 月的正式通知和年度报告才支撑切换时间线。

兼容窗口让责任有了期限

RIPE NCC 的 2001 年年报将迁移概括为从 4 月 23 日开始、历时六个月并在 10 月 15 日结束。这个窗口把适配工作分给不同参与者：注册机构维护转换服务并发布规则；对象维护者需要检查更新生成器；镜像运营者需确认同步方式；查询客户端则要理解返回语义。档案没有统计每一方耗费的工时，也没有列出所有受影响软件，却清楚显示了机构能控制的开关：接受什么格式、如何执行授权、使用哪个入口，以及哪天关掉兼容桥。

一个共享注册系统的管理责任，不只是把对象从旧库搬到新库。用户需要知道如何提交、谁可以更新、查询返回何种范围、镜像怎样跟上，以及临时方案什么时候失效。这些是提供公共参考服务时应履行的责任。它们不会让服务运营方因此拥有数据库所记录的地址资源，也不会自动赋予其对所有使用者的政治权力。

RFC 2622 的作者名单可以帮助厘清另一个边界。该 RFC 定义 RPSL，用来描述路由策略，并说明 maintainer 对象如何参与更新授权；列出的作者是 Alaettinoglu、Villamizar、Gerich、Kessens、Meyer、Bates、Karrenberg 和 Terpstra，其中没有 Robachevsky。公开材料支持他负责沟通并参与数据库迁移，不支持把 RPSL 或 RFC 2622 的创制归给他。

注册对象不等于当前路由

RIPE Database 里的登记对象、Internet Routing Registry 中表达策略的对象、以及某个测量点观察到的 BGP 路由，是三类不同证据。转换后的记录说明数据库当时保存了什么；RPSL 策略对象表达提交者登记的意图；路由收集器则可能记录某个位置、某个时间是否看到了公告。一个不能替代另一个。登记记录本身证明不了今天的网络可达性、数据包路径、资源的法律所有权，或全部路由器都遵循那项策略。

如果一条记录过时，问题在数据质量和更新授权；如果某个前缀从路由视图消失，需要观察路由的证据；如果参与者争议谁有权登记资源，格式迁移也不会裁决这场争议。迁移的重要性应放在更窄、也更可靠的位置：它让公共注册服务的接口、期限和义务变得可见，同时提醒人们不要把登记系统与它所描述的资源或真实网络混为一谈。

证据支持到哪里

2000 年 8 月的工作组邮件由 Robachevsky 以 Database Group Manager 身份签署，内容涉及 v3 查询行为；2001 年 4 月的公告由他签署，说明新版数据库运行、对象自动转换和第一阶段完成。RIPE 38 草稿纪要也将他列为计划中的迁移演讲者。这些材料足以描述一名负责数据库工作的管理者如何解释迁移、询问用户意见，却不能证明他亲自编写转换软件、独自决定所有规则，或逐条检查所有对象。

在基础登记系统上拥有操作权，会带来清晰、可检查的服务义务：规则应能查到，转换应留痕，失败应有处置方式。操作记录系统本身却不等于拥有被记录的资源。现有证据最扎实地说明了切换时间、入口和格式规则；它没有给出每个用户的成本、全体用户的采用情况，也无法说明今天某条路由的状态。

来源