摘要

  • ARIN 当前把 IRR 管理对象分为 simple 和 advanced 两类：前者来自 ARIN Online 或 XML REST，后者来自 RPSL REST 或旧 IRR-email 的迁移。对象的进入方式决定后续可用渠道。
  • 迁移对象可以在 Online 查看和删除，但不能在那里编辑；若先删除再用网页重建，新对象会进入另一种渠道类别，因此这不是原对象上的中性修改。
  • ARIN 两份当前文档对“网页创建对象能否使用 RPSL REST”给出了不同答案。本文没有测试真实账户，不能把文档矛盾擅自解释成生产行为。
  • 一份克制的转换凭证只需连接操作前哈希、类别、权限版本、授权角色、渠道、结果与后继哈希，不必公开 API 密钥、员工姓名或私有网络信息。

为什么删除按钮比编辑按钮更值得追问

ARIN 的 IRR 用户指南呈现了一种少见的权限组合。经 IRR-email 迁移的对象会出现在 ARIN Online 中，获授权的用户可以查看，也可以删除；唯独不能直接编辑。若要修改，指南把用户引向 REST。另一份实施说明则写明，想改由网页管理，需要删除旧对象并重新创建。ARIN IRR 用户指南

站在使用者角度，这可能只是一次“把错误字段改好”的任务。站在登记系统角度，却是两个独立事件：先撤下已有对象，再提交一个新对象。即使前缀、起源 ASN 和全部公开属性都被原样填回，新记录的出生方式已经不同，后续允许使用的写入路径也可能随之改变。

现有资料没有证明任何组织因此丢失对象，也没有显示路由泄漏、劫持、过滤错误或服务事故。本文未登录 ARIN 账户，未持有 API 密钥，未对真实对象执行 GET、PUT、DELETE 或 POST，更没有观测 NRTM 和 BGP。可以确认的是公开控制模型，而不是某个生产案例。

把这一点说窄很重要。登记操作的风险不等于路由事故，文档不一致也不等于代码失效。如果证据只能说明“ARIN 规定某类对象不能从网页编辑”，文章就不能把它扩写成“ARIN 使路由中断”。

同样，也不能把缺少编辑按钮简单归为落后的界面。旧对象可能含有网页表单无法无损表达的 RPSL 属性。若表单只能编辑部分字段，却在保存时重写或丢掉其他语义，拒绝编辑反而比假装兼容更可靠。真正需要审视的是：系统如何让使用者看懂这条边界，并在确实要转换渠道时保留前后两个状态的关系。

类别保存的是写入来历，不是路由真相

ARIN 当前 IRR 总览给出一张明确矩阵。simple 对象由 ARIN Online 或使用 XML 的 REST 创建；在这两个渠道中可创建、查看、编辑和删除，但按照表格，在 RPSL REST 中没有权限。advanced 对象由 RPSL REST 创建，或从 IRR-email 迁移而来；它们在 RPSL REST 中拥有四项操作，在 XML REST 中没有权限，在 Online 则只能查看和删除。ARIN IRR 总览

“simple”和“advanced”不能按日常含义理解成质量高低。advanced 对象并不因此更接近实时路由，simple 对象也不一定表达更简单的策略。它们是管理类别，描述对象如何进入系统、由哪一种载荷和校验路径维护。

总览还说明，无论对象属于哪一类，读者查询到的结果都是 RPSL。于是，公开输出与写入控制必须分开理解。查询者需要看到 route、route6、aut-num、as-set 或 route-set 声明了什么；没有必要知道维护者的 API 密钥，也不一定需要知道他使用网页还是 XML。但负责审计变更的人必须知道，哪条授权和哪个验证器产生了当前状态。

RFC 2622 定义了 Routing Policy Specification Language，也就是 IRR 对象采用的路由策略描述语言。它使策略声明可以被结构化记录和交换，却不是对当下 BGP 的测量。一个格式正确的 route 对象，不能证明相应前缀此刻正在公告；更不能证明每个网络都会接受、传播或用它生成过滤器。RFC 2622

因此，对象类别最适合回答的是“谁能通过什么渠道改动这条登记声明”。它不回答“包实际走向哪里”。把前者做得可审计，不需要把 IRR 抬高成互联网路由的最终裁判。

保留迁移身份是一种值得辩护的克制

ARIN 的实施说明把这套分类放在一次真实迁移中。旧 IRR-email 记录没有被不加区分地塞进新系统：与 ARIN 资源和验证条件相符的记录进入 ARIN 权威环境，其他记录被放入 ARIN-NONAUTH。ARIN 还说，迁移对象通过了新系统更严格的校验，界面会用说明标识它们。ARIN IRR Online 实施说明

这类标记保护了一段制度事实：对象虽然现在由新系统承载，却不是在新表单中出生。迁移工具不应因为成功解析了旧记录，就把旧来源追溯改写成网页创建。保留这一差异，能帮助运维者解释为什么同样看起来像 RPSL 的公开结果，拥有不同的修改渠道。

实施说明同时提出一条单向规则：组织一旦开始使用网页或 REST，旧 IRR-email 更新方式就会永久关闭。关闭双写渠道有合理性。若邮件、网页和 API 长期并存，每条路径可能使用不同凭据、校验器和并发规则，系统就难以回答哪次写入应当获胜。让现代渠道接管后停止旧写入，可以缩小控制面。

这正是为什么批评不能停留在“全部打开编辑权限”。如果网页无法完整表示 advanced 对象，强行允许在线编辑会用便利换取语义不确定。更好的要求是可预见转换：在删除前导出规范化前像，显示当前类别和不兼容原因，验证拟创建的后继对象，并把成功后的新状态明确链接回旧状态。

换句话说，保护来历与支持迁移并不冲突。冲突发生在系统用来历限制编辑，却在改变工具时让使用者抹掉来历。

删除再创建会多出哪些状态

原地修改可以被表示为：同一个持久身份从哈希 A 变为哈希 B，授权者、时间和验证结果随事件记录。删除再创建至少产生两个结果。旧对象可能已删除，而新对象尚未通过；新对象可能通过了校验，但公开观察尚未出现；重新输入的内容可能因校验或规范化与旧对象不同。

这些只是状态空间，不是本文发现的事故。公开资料没有给出迁移对象数量、转换频率、处理延迟或 NRTM 序列示例，因此不能估算暴露窗口，也不能说某个过滤系统实际看到了空档。诚实的结论是：DELETE 与随后的 POST 比一次 PUT 多了可失败的中间状态。

ARIN 的 IRR REST API 文档正好提供了这组动词。GET 读取，POST 创建，PUT 修改，DELETE 删除；支持的对象包括 route、route6、aut-num、as-set 和 route-set，载荷可以是 RPSL 或 XML，但仍受对象权限约束。ARIN IRR REST API

协议层面既然区分修改与替换，审计层也不应把它们压成一个模糊的“已更新”。若使用者复用对象键，后来的读者可能以为对象从未换过类别；若键也改变，则更需要一条后继关系。截图和支持工单可以帮助当事人，却不是未来维护者或自动化消费者都能验证的公共证据。

这并不要求 ARIN 保存并公开所有历史正文。前像和后像可以用规范化哈希表示；敏感身份可以只记录授权角色类别；密钥绝不能进入公开凭证。关键是让系统知道“这次删除是一次计划转换的前半步”，并让重建成功或失败都能延续同一事件链。

两份当前说明无法同时充当清晰合同

当前总览矩阵说，simple 对象在 RPSL REST 中没有权限。实施说明却写道，由 ARIN Online 创建的对象可以通过 REST 使用 RPSL 或 XML 进行查看、更新和删除；该页面列出的更新记录延续到 2025 年 1 月 17 日。

两种表述之间存在实质差异。它们可能适用于不同版本、对象类型或账户条件，也可能只是其中一页尚未同步。来源没有给出足够信息来选择。即便用一个真实账户测试一个 route 对象，也只能证明那个对象、那个时点和那组权限，不能自动覆盖所有 simple 对象。

2021 年 2 月的 ARIN 博文可以解释历史演进，当时文中描述了 REST 即将上线以及若干计划调整的限制。如今 ARIN 把它放在 Vault，并明确提醒 Vault 内容可能过时。它只能回答“当时怎样计划”，不能裁决当前生产权限。ARIN Vault：IRR REST API 历史

最小修复不是再写一篇散文说明，而是一张带版本和生效时间的统一矩阵：对象类别、对象类型、操作、渠道、载荷编码逐项交叉。运行代码仍然是具体案例的技术现实，公开矩阵则是可复核的支持承诺。两者出现差异时，应保存请求与结果，而不是让用户在两页文档之间猜测。

在 ARIN 统一说明或有范围明确的认证测试以前，本文只记录矛盾。它不声称 RPSL 实际可用，也不声称一定不可用。

转换凭证可以很薄

一份足够用的凭证不需要变成用户监控系统。它可以记录：公开对象类型与键、操作前类别和创建来源类别、采用的权限矩阵版本、规范化前像哈希、动作类型、授权角色类别、渠道和载荷编码、校验结果、操作后类别与哈希、删除与重建之间的接续标识，以及在可靠时记录公开观察或 NRTM 序列。纠错和撤回应当追加在链上，而不是覆盖旧事件。

API 密钥、个人姓名、内部组织关系和私有拓扑都没有必要公开。ARIN 只需证明它有权证明的内容：登记系统接受、拒绝或删除了什么，以及在什么控制路径下发生。它不能借这份凭证证明所有镜像已同步、所有过滤器已更新或 BGP 按该对象运行。

ARIN 用户指南还说明，Admin、Tech 和 Routing POC 可以管理 IRR，Resource POC 不可以。这是角色边界；对象类别是另一条边界。一个人即使具备组织层面的合法角色，也可能因为对象来源而不能从某渠道编辑。把两者分开记录，能避免把渠道拒绝误判为身份失败。

现有证据最终支持的是一种很窄的治理判断。ARIN 有理由保留迁移来历，有理由限制不能无损表达对象的界面。但当用户为了换渠道必须删除再创建时，登记系统也有责任保存转换的连续性。否则，来源既是权限依据，又会在遵循系统指引时消失。

来源

  1. ARIN：Internet Routing Registry 总览
  2. ARIN：IRR 用户指南
  3. ARIN：IRR Online 实施说明
  4. ARIN：IRR REST API
  5. ARIN Vault：IRR REST API 上线历史
  6. RFC 2622：Routing Policy Specification Language