摘要

  • AFPUB-2026-ASN-001-DRAFT02 将要求 AFRINIC 新创建的 AS-SET 使用层级名称，同时保护现有平面对象及其编辑。
  • 保留、编辑、恢复已删除对象和创建新对象是不同操作，证据边界不能混用。
  • AFRINIC 工作人员警告恢复可能留下操作侧门；BTW 建议逐案决策回执，并进行不含敏感信息的汇总报告。

该提案是面向未来的规则，不是对现有平面名称集合的清理。它针对在 AFRINIC WHOIS 数据库中创建 AS-SET 的行为。RFC 2622 第 5 节将层级集合名称描述为由冒号分隔的组件，并允许以 ASN 开头。按照其命名空间控制规则，只有父对象的维护者才能创建其下的子名称。

提案有意保留已经安装的历史状态。现有非层级 AS-SET 不得重命名，可以继续使用，也可以在不改名的情况下编辑。提案给出的理由是，大规模重命名会造成大量数据不一致，而且没有可靠的程序化方法判断每个现有 AFRINIC AS-SET 对应哪个 ASN。这一安排也保留了已经存在的路由策略引用。

四种操作并不等价。保留意味着身份不变；编辑是在不改变名称的情况下改变允许的内容；创建意味着按照拟议规则建立新记录；恢复则是在对象被删除后，试图重新带回一个已经安装过的身份。因此，恢复必须回答对象原来是什么、如何被删除以及为何仍需连续性。

提案的强制性示例是恢复一个误删的非层级 AS-SET。工作人员提出的措辞是：在必要时可以批准例外，且 AFRINIC 应记录理由。工作人员另行警告，召回已删除的平面对象可能形成操作漏洞，削弱政策效果。AFRINIC 37 会议记录把它描述为留下侧门，并记录删除需要对维护者进行认证。

现有证据没有规定如何证明误删、恢复期限多长、谁负责批准、记录包含哪些字段、是否允许重复恢复，或是否报告例外总量。证据也没有证明发生过任何恢复。

AFRINIC 的公开 IRR 指南记录了门户和 WHOIS-web 创建流程以及维护者保护。证据包没有测试这些生产路径，也没有表明拟议限制已经启用。提案列出 WHOIS 和 MyAFRINIC/IRR 为受影响系统，并要求在服务器端以及公开表单或 API 中进行验证。工作人员表示会在 MyAFRINIC v2 之后优先实施；这是一项有条件的计划，而不是实施证据。

**BTW 分析：**恢复回执应包括原对象身份和哈希、删除时间及经过认证的执行者、误删证据、受影响的路由策略引用、考虑过的替代方案、批准审阅人、决策时间、到期或迁移条件，以及关闭记录。这样可以把连续性与无限期重新开放平面状态区分开。

另一项 BTW 分析 是按汇总方式报告例外数量和处置结果，不披露维护者秘密或敏感路由配置。这不是现有 AFRINIC 产品，也不是已采纳的要求。

发布说明：“发布”是计划中的编辑日期，即 2026 年 9 月 7 日（Asia/Shanghai）。实际服务器发布时间尚未设置。

来源

  1. https://www.afrinic.net/policy-proposals.html
  2. https://www.afrinic.net/afpub-2026-asn-001-draft02
  3. https://www.afrinic.net/ppm-afrinic-37.html
  4. https://www.rfc-editor.org/rfc/rfc2622.html
  5. https://afrinic.net/irr-guide