Summary

  • draft-ietf-regext-epp-same-entity-01 lets a registry define which domains belong to one entity and how options apply to them, while placing both the policy and the method of agreeing it with registrars outside the protocol specification.
  • The boundary has hard consequences: transfer of one allocated member can transfer the whole set, deletion of the Primary Domain can delete all allocated members atomically, and a shared repository can extend that effect across registries.
  • Because the set is implicit and can be too large to enumerate, accountable operation needs an equivalence-policy receipt: the exact policy and LGR version, parties, Primary Domain, membership proof, exceptions, repository scope, command blast radius and result evidence.

The consequential part of an EPP command is normally expected to be in the command. A domain name appears in the request; a result code and transaction identifiers appear in the response. That record can be retained and compared. The Same Entity Set draft introduces a more difficult object. One named domain can stand for an entire policy-defined family, including names that have never been registered and cannot feasibly be returned in a list.

The draft's motivating case is internationalised domain variants, but the abstraction is broader. A registry identifies characteristics that make domain objects equivalent for one registrant. The first registered member creates the set and becomes its Primary Domain for that registry. Later names can be allocated only under the same registrar, and the registrar is responsible for keeping the registrant the same. The repository can withhold unallocated members for that entity.

This is not merely a convenient grouping label. The set changes the unit on which commands operate. A transfer request against any allocated member applies to all allocated members. A delete against the Primary Domain applies to every allocated member; if one cannot be deleted, the whole operation fails and leaves the set intact. Where several registries share an equivalence policy and a central repository, the transfer boundary can cross registry lines.

Yet the document says the policy defining the characteristics and options is outside the specification. So is the method by which the registry shares that policy with registrars and secures agreement. The wire protocol can execute an atomic rule without carrying the complete authority that made the rule valid.

An implicit set is still a control surface

The draft makes an important distinction between existence and allocation. A name belongs to the Same Entity Set because the equivalence rule puts it there, not because somebody has created the object. The response can enumerate allocated members. It cannot necessarily enumerate the set itself. One use case describes a realistic universe of 10^15 possible names.

That scale defeats a familiar audit habit: ask the server for the list, save the list and compare it later. There may be no complete list to save. Membership instead depends on a function—perhaps an IDN Label Generation Ruleset and additional registry policy—applied to a Primary Domain. An auditor who records only the allocated members captures the output sample, not the rule that determined the universe.

The Primary Domain therefore carries unusual authority. It is the first registered member, defines membership and determines how options apply. The draft describes Prescribed, Settable and Linked behaviours as examples. A prescribed value follows registry policy. A settable value can be chosen and then applied according to the set rules. A linked value binds behaviour across members. These classes are useful vocabulary, but the draft does not require them or exhaust the policies a registry might create.

The practical governance question is not whether the XML is valid. It is which version of which external policy the server applied at the moment of decision. If the LGR changes, a previously impossible member can become allocatable or a new conflict can appear. If registries sharing a repository harmonise their tables differently, membership may cease to be symmetric. The same command bytes can then imply a different blast radius without a change to the command.

Atomicity converts classification into consequence

Atomic deletion is a strong protection when the set boundary is correct. It prevents a half-deleted family in which some variants disappear while others remain allocated, perhaps opening confusion or impersonation opportunities. Failure of one member causes the whole Primary Domain delete to fail. The repository preserves the prior state rather than leaving a partial outcome.

But atomicity does not validate classification. It faithfully applies whatever set the repository believes exists. If the policy version is wrong, if a member was exempted but not represented correctly, or if two registries disagree about symmetry, the transaction can be perfectly atomic and still affect the wrong names. Technical consistency and institutional correctness are separate properties.

Transfer widens the stakes. The draft requires a transfer of any allocated member to act on the entire set. In a shared central repository, the action can cover the corresponding sets in multiple registries. That creates an operational benefit: the identity relationship does not fracture because one visible name moved while its variants stayed behind. It also creates a concentration point. An error in membership, authorisation or policy agreement is no longer local to the object named in the request.

Backwards compatibility adds another tension. The draft says three principles must hold without exception: compatibility with unaware clients, same-entity management and set management. A client that does not understand the extension must receive a fail-safe rejection where its command would violate set semantics. That is safer than silently accepting a partial action. It can still be opaque to the registrar: the old client learns that its request failed, but may not possess the policy context needed to explain the hidden set.

Exceptions are evidence, not clutter

The status vocabulary exposes further governance state. Allocated means active in the registry, but it does not prove delegation in DNS. Allocatable means available only to the same entity. Blocked means unavailable to anyone. Exempted names are the awkward inheritance: existing registrations can have another registrant or registrar until defined conditions bring them into conformity.

An exception is tempting to treat as a temporary footnote. In practice it may be the most important item in the file. It shows where the ideal equivalence model meets pre-existing rights and contracts. A command that should be set-wide in the abstract may encounter an object the repository cannot transfer or delete. That is exactly where atomic failure needs an intelligible explanation.

The draft is candid about unfinished work. Its appendix still asks for actual numerical error codes, more security analysis and confirmation of DS-record behaviour for a variant. It also notes that a Unicode upgrade may turn a domain into an exempted case. The rendered IANA Considerations section is blank. The Datatracker currently displays no intended RFC status while the draft header says Standards Track. Those are reasons to follow the work, not reasons to present it as settled or deployed.

The missing artefact is a policy receipt

The durable operational answer is not to push the whole registry policy into every EPP request. It is to bind each consequential action to a compact, reproducible receipt. I would call it an equivalence-policy receipt. This is an editorial proposal, not a requirement in the draft.

The receipt starts with the policy identity: registry policy version, LGR version and effective time. It names the registry, registrar and central-repository operator that were parties to the rule. It identifies the Primary Domain and records how the member named in the command was proven to belong. For multi-registry operation, it names every registry covered and the repository state that made membership symmetric.

It then records the action boundary. Was this a transfer, delete or option change? Which allocated members were in scope at evaluation time? Which unallocated names remained allocatable or blocked? Which members were exempted, and under what transition rule? A digest of the input policy and membership evidence matters more than a prose label such as “variant bundle.”

Finally, the receipt binds result evidence: server and client transaction identifiers, outcome code, failed member where disclosure is permitted, and proof that an atomic failure preserved all prior allocations. A registrar need not receive sensitive data about names it cannot manage, but it must receive enough reason to distinguish policy enforcement from a transient server error.

This makes responsibility visible without pretending that the protocol owns the policy. The registry remains accountable for the equivalence definition. The registrar remains accountable for common registrant identity. The repository remains accountable for symmetric membership and atomic execution. The receipt connects those decisions to the command that exposed them.

Sources