Dear WG, Apologies for the delay, but the chairs had a difficult decision to make about this adoption request. The WG participants had many question that don’t seem related to the work that still needs to be done, but more on the process and the current state of the document. We have 3 clear in favour of adopting the work, 3 not opposing but with questions about the scope of the work, and 1 objection due to missing XML in the current incomplete document which is actually part of the WG work yet to come.
The verdict of the 2 chairs (Jorge and Antoin) is that there is appetite for this work that the current document may not yet fully cover. We therefor want to adopt this work with some advice and guidance below. With this message the chairs ask the authors to submit version 00 of a working group document, that is the same as the current document, using the following pre-approved draft name: draft-ietf-regext-epp-same-entity During this adoption request, no-one has volunteered yet to be a document shepherd for this document. The chairs want to ask the authors to search for a document shepherd, or if anyone still wants to volunteer to reach out to the authors. Work can begin as soon as the 00 is published. Looking at the amount of work, the milestone for this document will be September 2027. Then for some guidance: -First of all, the scope of this work is quite ambitious compared to what we normally do in this WG. It is not only about EPP commands for specific domains or variants, but on the general concept of provisioning multiple products under 1 service. This is a difficult provisioning concept for any product, not just domain names, and the chairs have some concern that we might not have that expertise in our working group. We would advise to seek the necessary expertise and address that issue first. Perhaps we need a specific document first on what same entity means, how it works and what processes need to be supported in addition to provisioning of single product services before we create any EPP extensions. -Adoption of work does not mean the document automatically makes it to WGLC. One outcome may be that we cannot reach consensus defining a same entity principle. -Only after we reach agreement that all aspects of a same entity principle are met, we can start thinking of what that means to definitions or XML schemas of how to handle all those aspects in EPP. It makes no sense to start inventing the solution before we created the problem statement or requirements. -Keep in mind that a generic solution should work for any provisioning of same entities, and not focus on domain variants as the primary goal which is policy. -We need to keep specific policy out of the technical discussion of how to provision same entity products, but it’s inevitable that there is some key guidance to local policy that may or may not work for a same entity principle. Think of processes that need to be defined and supported by a policy, or specific identifiers that need to follow specific uniqueness requirements that needs to be supported by a policy. The 2 chairs will carefully monitor that specific requirements or policy of specific registries do not influence the general applicability, definitions or descriptions of the same entity principle and its EPP processes. Kind regards, Your Co-chairs Jorge and Antoin. > Op 11 mei 2026, om 16:31 heeft Antoin Verschuren via Datatracker > <[email protected]> het volgende geschreven: > > 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]
