Denis Walker 与 RIPE 数据库的 reclaim 删除权

Summary

Denis Walker 在 2013 年说明，RIPE 数据库增加了 reclaim 功能：对 RIPE NCC 签发的地址资源，系统可接受上级资源的维护者授权，删除符合条件的下级运营记录。
这把钥匙只管删除，不管修改。适用范围包括更具体的地址记录、路由记录和反向解析委派；上级资源本身、自治系统号以及人物资料不在其中。

一条旧记录，挡住一条新路

运营者要换一条路由记录，却发现相同前缀的旧 route 对象还在。旧对象的 mnt-by 指向另一个维护者，现任地址持有人无法删除；新对象也无法按原计划建立。纸面上，这段地址由持有人负责。操作到关键一步，权限却留在过期的记录里。过去，往往要请 RIPE NCC 人工越过认证门槛。

Denis Walker 在 2013 年 4 月解释了新的办法。RIPE 数据库的 reclaim 功能，在删除下级对象时，把 RIPE NCC 签发的上级地址资源所列 mnt-by、mnt-lower 维护者纳入可接受的授权来源。操作者仍提交普通更新，在对象中写入 delete: reason。没有神秘命令，改变的是系统判断“谁有资格按下删除键”的规则。

这种困局并不需要坏人登场。两个团队共享 mnt-by，其中一方就可能移除另一方；一次交接没收好尾，旧维护者便继续看管某条记录。一条精确匹配的旧路由对象又可能挡住新对象。于是，资源持有人背负管理责任，却必须排队向注册机构请求例外。Walker 把重复的人工救援，变成了有边界的自助操作。

边界写得很细。更具体的 inetnum、inet6num 对象，匹配或更具体前缀的 route、route6 对象，以及 in-addr.arpa、ip6.arpa 下的反向委派域对象，都在覆盖范围内。上级分配或指派记录本身不在范围内，aut-num、ENUM 域，以及 person、role 等次级对象也不在。reclaim 只能删除，不能原地修改内容或换掉认证信息。拿到一个下级子分配的人，也不会因此自动拥有顶层删除权；授权根源是 RIPE NCC 签发给资源持有人的那条上级记录。

删掉数据库中的路由对象，不等于瞬间改写互联网路由器。但它确实撤掉一道注册层的门闩，让持有人能建立可用的新记录。登记系统最容易被忽略的权力，往往就藏在这种“做不了下一步”的瞬间。

RIPE NCC 的 2013 年年报将 reclaim 列为当年数据库新功能。Walker 本人的说明交代了它能删什么、不能删什么。一枚删除键的故事，归根结底是一个责任问题：既然资源由持有人管理，谁能让挡路的记录离开？