摘要

  • draft-brown-epp-deleg-03 在 9 月 29 日的修订中，为 <deleg:rem> 增加空元素 <deleg:all/>，表示移除该域名的全部 DELEG 记录。第 02 版只有逐项指定的移除方式。
  • 这仍是一份活跃的个人 Internet-Draft，不是 RFC，也没有证据表明注册局已部署该指令。“全部”限定在 DELEG 集合，不能扩写为注销域名或移除传统 NS。

对于一项变更，逐条列明对象本身就是一种可审查的证据。审核人可以检查清单上的记录是否正是要删除的记录。改成“全部”以后，客户端提交的文本不再给出最终条数；实际覆盖哪些 DELEG 记录，取决于服务器执行时看到的域名状态。第 03 版的新闻点在于这种授权对象的变化，而不是已经发生了一次清空事件。

草案第 5.2.2 节把两种移除方式放进同一类 EPP 域名更新：可以列出待移除的 deleg:deleg 记录，也可以在 <deleg:rem> 内置入 <deleg:all/>。文中的示例展示了只移除全部 DELEG、同时不新增记录的更新。第 02 版没有这个选项。它让一种可能的管理操作更简洁，也让原先可由记录清单限定的范围变成对整个集合的授权。

边界同样清楚。该元素属于 DELEG 扩展，不是 EPP 注销域名命令，也不指向 EPP 主机对象、全部 DNSSEC 数据或传统 NS。草案第 6 节本就考虑 DELEG 与传统 NS 并存。即使将来有服务器接受此类 EPP 更新，其响应也只能先说明配置入口接受了什么；权威 DNS 是否已发布相同状态、递归解析器是否仍持有缓存，仍须分开观察。把 EPP 的成功回执当成全球 DNS 已同步的证明，会跳过关键证据环节。

这次修订还有另一组文字变化：旧版 deleg:params 的属性式写法改为多个 deleg:param 元素，拟议 XML 命名空间由 deleg-0.01 变为 deleg-0.02，旧版架构里的 priority 与 target 字段不再出现。BTW 此前报道过第 02 版 EPP 与新版 RDAP 草案在这两个字段上的不一致。第 03 版缩小了那个具体的文本差距，但并未证明 EPP、DNS 与 RDAP 已形成可部署、可往返验证的数据链。本篇讨论的是新出现的整组移除权，不重复把旧差距说成现状。

草案的安全章节还提出：服务器拒绝未知参数名和无效值，客户端与服务器定期更新所知的注册键清单。这些约束可以限定拟议数据格式，却不能回答谁有权发出整组移除指令。DELEG 主草案第 11 版仍在请求 IANA 创建“Delegation Information”注册表；不能因为 EPP 草案引用了键名，就断言注册表已正式运行。

IETF Datatracker 对这份 EPP 文稿的状态是活跃个人 Internet-Draft，未列 RFC 流、负责的领域主管或电话审议，IESG 状态为 “I-D Exists”。9 月 29 日的公告证明新版已经公开，不等于工作组共识、标准批准、产品支持或事故发生。它要求的治理判断属于未来：允许自动化逐条维护记录的凭据，是否也应被允许一次清空整个集合？答案不能只从 XML 是否有效推出来。

来源