Review Comments for draft-galvin-regext-epp-variants-05
General Observation
The document presents an important and ambitious attempt to standardize
management of same-entity/variant domain sets in EPP. The architectural
principles are increasingly clear compared to earlier versions, especially the
distinction between conceptual set membership and allocated members. However,
several areas would benefit from tighter protocol semantics, clearer
interoperability expectations, and more precise operational behavior.
1. Clarify the Boundary Between “Conceptual Existence” and Registry State
The draft repeatedly states that all members of a Same Entity Set exist
“conceptually” once the Primary Domain is created, while only some members are
“allocated” in the repository.
This distinction is central to the protocol model, but its operational
consequences remain insufficiently specified.
For example:
* Does “conceptual existence” imply that uniqueness constraints are globally
reserved?* Are conceptual members queryable through `<info>`?* Can conceptual
members participate in DNSSEC policy calculations?* How should escrow providers
represent conceptual members?* Are conceptual members included in registry
reporting obligations?
It would help to define a formal state model for:
* conceptual member* allocatable member* allocated member* activated member*
blocked member* exempted member
A state transition diagram would significantly improve implementability and
interoperability.
2. The Definition of “Primary Domain” Appears Operationally Fragile
The draft defines the Primary Domain as the chronologically first allocated
member.
This may create ambiguity in operational edge cases:
* registry restore after catastrophic failure* escrow replay* migration between
backend providers* parallel create races across shared repositories* deletion
and later recreation scenarios
The document should clarify whether:
* the Primary Domain identity is immutable forever,* or whether it may be
reassigned,* and how consensus is maintained across multiple registries sharing
a repository.
Without stronger requirements, different implementations may derive
inconsistent Primary Domains.
3. `<delete>` Cascading Semantics Need Stronger Safety Analysis
The draft currently mandates cascading deletion behavior for deletion of the
Primary Domain.
This is operationally risky because EPP historically treats `<delete>` as a
single-object operation. Cascading deletion across potentially many domains may
surprise registrars and create significant recovery complexity.
The draft should discuss:
* atomicity guarantees,* rollback behavior,* partial failure handling,*
interaction with Redemption Grace Period (RFC3915),* registry notification
obligations,* and whether confirmation mechanisms are needed.
The open issue in Appendix A correctly identifies this concern. The current
text does not yet provide enough guidance for interoperable safe implementation.
4. Clarify Cross-Registry Consistency Requirements
The draft states that multiple registries may share a common repository and
policy.
However, it remains unclear:
* whether consistency is strongly required in real time,* whether eventual
consistency is acceptable,* what happens during temporary partition or
synchronization failure,* and which registry is authoritative during conflict
resolution.
This becomes particularly important because transfer semantics are defined to
affect all registries in the same entity set.
The draft would benefit from explicit consistency model terminology.
5. Security Considerations Are Currently Too Minimal
The Security Considerations section appears substantially underdeveloped
relative to the protocol impact.
The extension introduces new attack surfaces and operational risks, including:
* cross-registry privilege escalation,* accidental cascading operations,*
denial-of-service through set locking,* synchronization inconsistencies,*
registrar authorization confusion,* and variant-set hijacking risks.
The current text mainly discusses user confusion and impersonation.
The document should include analysis of:
* authorization boundaries,* replay protection,* race conditions,* distributed
consistency attacks,* and abuse scenarios involving linked transforms.
The draft itself acknowledges uncertainty in this section, and this deserves
more comprehensive treatment before standardization.
6. Result Code Namespace Needs Alignment with Existing EPP Conventions
The proposed result codes use placeholders such as “23x1”.
Before publication, the document should clarify:
* whether a dedicated EPP extension result code range is being requested,* how
collisions with existing extension result codes are avoided,* and whether these
errors should map to existing EPP policy or parameter error classes where
possible.
It may also help to define machine-readable error values in extension data
rather than relying exclusively on textual descriptions.
7. Backwards Compatibility Claims May Be Too Strong
The draft states that unsupported registrars can continue functioning safely
because responses remain “compatible”.
However, if transforms implicitly affect entire sets spanning multiple
registries, older clients may experience unexpected failures or side effects
that are difficult to interpret.
The document should more precisely define:
* what “fail-safe” means,* what guarantees are provided,* and which
user-visible behaviors may still differ from classic EPP semantics.
A dedicated interoperability subsection with concrete examples would help.
8. The Relationship Between Registry Policy and Protocol Semantics Needs
Sharper Separation
Several core behaviors are delegated to “registry policy”.
While flexibility is understandable, too much protocol behavior currently
appears policy-defined, including:
* equivalence determination,* option propagation,* allocation semantics,* and
linked behaviors.
The draft should more clearly distinguish:
* mandatory protocol invariants,* optional policy extensions,* and
implementation-specific behavior.
Otherwise, interoperable implementations may diverge significantly while still
claiming conformance.
9. Consider Adding Examples for Multi-Registry Scenarios
The document would benefit greatly from worked examples covering:
* shared repository operation,* transfer across registrars,* exempted domain
handling,* variant allocation,* and cascading updates.
Concrete XML examples would make the extension substantially easier to
implement correctly.
10. Editorial Notes
A few editorial observations:
* “sstandard” in Section 4.1 appears to be a typo.* Terminology capitalization
is occasionally inconsistent (“same entity set” vs “Same Entity Set”).* Some
normative statements could be shortened for readability.* The distinction
between “registered”, “allocated”, and “activated” should be harmonized
throughout the text.
Overall Assessment
The draft addresses a genuinely important operational problem, especially for
IDN variants and coordinated multi-registry environments. The architectural
direction is promising, but the current version still feels closer to an
architectural framework than a fully specified interoperable protocol extension.
In particular, the following areas appear most critical before standardization:
* formal state semantics,* distributed consistency behavior,* cascading
transform safety,* and significantly expanded security analysis.
regrade
Eng.Mo.H...
On Tuesday, May 12, 2026 at 12:28:21 PM GMT+4, Andy Newton <[email protected]>
wrote:
I support the working group adopting this draft and working on this problem.
-andy, as an individual
On 11-05-2026 10:31 AM, Antoin Verschuren via Datatracker wrote:
> This message starts a regext WG Call for Adoption of:
> draft-galvin-regext-epp-variants-05
>
> This Working Group Call for Adoption ends on 2026-05-25
>
> Abstract:
> This document defines an EPP extension allowing clients to learn
> about and manipulate a set of objects in a shared central repository
> that are necessarily tied to the same entity (typically domain
> objects whose names are equivalent in a registry-defined way and are
> tied to a single registrant). The extension supports multiple
> registries with a shared definition of equivalence using a shared
> central repository.
>
> Please reply to this message and indicate whether or not you support adoption
> of this Internet-Draft by the regext WG. Comments to explain your preference
> are greatly appreciated. Please reply to all recipients of this message and
> include this message in your response.
>
> Authors, and WG participants in general, are reminded of the Intellectual
> Property Rights (IPR) disclosure obligations described in BCP 79 [2].
> Appropriate IPR disclosures required for full conformance with the provisions
> of BCP 78 [1] and BCP 79 [2] must be filed, if you are aware of any.
> Sanctions available for application to violators of IETF IPR Policy can be
> found at [3].
>
> Thank you.
> [1] https://datatracker.ietf.org/doc/bcp78/
> [2] https://datatracker.ietf.org/doc/bcp79/
> [3] https://datatracker.ietf.org/doc/rfc6701/
>
> The IETF datatracker status page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-galvin-regext-epp-variants/
>
> There is also an HTML version available at:
> https://www.ietf.org/archive/id/draft-galvin-regext-epp-variants-05.html
>
> A diff from the previous version is available at:
> https://author-tools.ietf.org/iddiff?url2=draft-galvin-regext-epp-variants-05
>
> _______________________________________________
> regext mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
_______________________________________________
regext mailing list -- [email protected]
To unsubscribe send an email to [email protected]
_______________________________________________
regext mailing list -- [email protected]
To unsubscribe send an email to [email protected]
