摘要

  • draft-ietf-regext-epp-same-entity-01 让注册局定义哪些域名属于同一实体、集合选项如何生效，却明确把政策本身以及注册局与注册商达成协议的方法留在规范之外。
  • 这条外部规则会产生刚性后果：任一已分配成员的转移可覆盖整组；删除主域名必须全部成功或全部不动；共享中央资料库还可能把范围扩展到多个注册局。
  • 需要一份“等价政策回执”，绑定政策与 LGR 版本、参与方、主域名、成员证明、例外、跨注册局范围、命令影响面和最终结果。

“集合”很容易让人想到数据库查询：服务器先存好若干对象，再把它们列出来。草案描述的顺序恰好相反。成员资格来自一条等价规则；名字即使尚未注册，也可能已经处在集合的逻辑边界内。首个注册名字成为该注册局的主域名，后续已分配成员必须归同一注册商，注册商还要确保注册人相同。

因此，返回已分配成员不等于返回全集。草案给出的现实用例可包含 10^15 个可能名字，协议不可能逐项枚举。审计若只保存响应列表，保存的是某一时刻的结果切片，而不是产生结果的规则。

规则由注册局制定并与注册商共享。其内容与双方怎样同意都不在规范内。Prescribed、Settable、Linked 只是选项行为示例，并非强制或穷尽分类。也就是说，XML 负责运输，外部政策负责决定运输命令到底触及谁。

原子执行不能证明集合划对了

删除主域名时，所有已分配成员必须一起删除；任何一个无法删除，整笔操作失败并保持原状。这能避免部分名字消失、部分名字遗留的危险状态，是重要的一致性保障。

但原子性只证明资料库完整执行了自己认定的集合。若使用了错误的政策版本、过期的 LGR，或漏记了历史豁免，操作仍可在技术上完美、在治理上错误。交易一致性与分类正当性不是同一项证据。

转移进一步放大影响。对任一成员发起转移，整组都要随之移动；若多个注册局共用政策和中央资料库，范围可以跨注册局。统一控制有助于防止变体分裂，却也让授权错误从一个显式域名扩散到整个隐式集合。

草案要求向后兼容、同一实体管理、集合管理三项原则始终成立。不了解扩展的旧客户端若会破坏集合语义，就应得到安全拒绝。拒绝比悄悄局部执行更好，但注册商如果看不到外部政策，就只能知道失败，难以说明为何失败。

豁免记录的是制度遗产

Allocated 表示在注册局内有效，不必然代表已进入 DNS 委派。Allocatable 表示仅同一实体可取得；Blocked 表示任何人都不能取得。Exempted 则容纳政策实施前已经存在、注册人或注册商可能不同的名字，直到满足规定的趋同条件。

豁免不是杂项。它标示新规则与既有权利、合同和技术状态的接缝，也往往是原子操作失败的真正原因。回执必须记录豁免依据、期限与退出条件，而不能只给出“策略冲突”。

目前文本仍有明显未决项：错误码尚待填入实际数字，安全分析与变体 DS 记录处理仍有问题，Unicode 升级还可能制造新的豁免。渲染版 IANA Considerations 为空；Datatracker 显示的预期 RFC 状态为空，而草案页眉写着 Standards Track。它是活跃草案，不是 RFC，更不证明已经生产部署。

让不可见政策留下可验证回执

本文提出的回执并非把整份政策塞入每条 EPP 命令，而是记录可复核的身份：政策版本、LGR 版本、生效时间、注册局、注册商和资料库运营者。它指出主域名，并保存请求中的名字为何属于该集合的证明。

随后记录命令影响面：操作类型、当时的已分配成员、涉及的注册局、可分配与阻止状态、所有豁免。最后把服务器与客户端交易标识、结果码以及失败后全量回滚的证据绑在一起。对无权查看的名字仍可做隐私保护，但不能把可解释性一并删掉。

责任边界由此清楚：注册局对等价规则负责，注册商对同一注册人负责，中央资料库对对称成员关系与原子执行负责。集合可以隐式存在，权力来源不能隐身。

来源