Speaking as a participant,
Moumien,
Thank you so much for your very thorough review and call out of
important questions. I want to take time with my co-author to carefully
consider all of them and will answer them. After one read I believe I
can answer most of the questions but you’ve highlighted some
interesting conditions that my co-author and I have not yet discussed so
there’s certainly discussion to be had in the working group.
Your general observation doesn’t say if you support adoption of the
document and thus are willing to have the working group work through
your questions as the specification evolves.
Would you please indicate if you support adoption of the work?
Thanks!
Jim
On 12 May 2026, at 4:46, moumien awad wrote:
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]
_______________________________________________
regext mailing list -- [email protected]
To unsubscribe send an email to [email protected]
