Summary

  • The GAC asked for a timeline after describing the desired result as collection and public availability of legal-person registration data. ICANN's 24 August reply said Phase 2A implementation may begin in FY2027.
  • The same reply drew a substantive boundary: existing policy permits but does not require legal-versus-natural differentiation, best practices create no contractual obligation, and technical fields do not themselves authorize publication.

One correspondence chain now carries two different meanings of the word “implementation.”

In its 11 May 2026 letter, the Governmental Advisory Committee said work to enable the collection and publication of legal entities' domain-name registration data had not progressed since the ICANN Board adopted the EPDP Phase 2A recommendations in March 2022. The GAC repeated its position that contracted parties should collect and make legal-person data publicly available. It asked ICANN to confirm a timetable and offered to join an Implementation Review Team.

On 24 August, Board Chair Tripti Sinha supplied a timing answer: subject to completion of existing projects using the same implementation resources, ICANN org anticipated being able to begin Phase 2A work in FY2027. The answer was published on 25 August.

But the letter did something more important than name a fiscal year. It stated that the Phase 2A team had decided not to modify existing Consensus Policy requirements on differentiation between legal and natural persons. It said the current Registration Data Policy permits, but does not require, registries and registrars to consider whether data concerns a legal person or contains personal data when applying RDDS redaction rules. It also said the best practices to be produced under Phase 2A will not create contractual obligations.

The disagreement visible in the record is therefore not only about a queue. The GAC's preferred policy outcome and the package waiting for implementation are not identical objects.

What the Board adopted

The Board adopted four Phase 2A recommendations on 10 March 2022. Their verbs matter.

First, one or more fields must be created to facilitate differentiation between legal- and natural-person registration data and/or between personal and non-personal data. Contracted parties that differentiate may use the field. Second, parties that choose to differentiate should follow the report's guidance. Third, if a GDPR Code of Conduct is developed within ICANN, relevant controllers and processors should consider the guidance. Fourth, parties that choose to publish a registrant-based or registration-based email address should evaluate the legal guidance obtained by the EPDP team.

That is a real implementation mandate for ICANN org. The Board directed the President and CEO, or designees, to develop and execute an implementation plan. A required technical deliverable should not be dismissed merely because use by contracted parties remains optional.

Nor, however, should the requirement to create a field be enlarged into a requirement to populate it, differentiate every record or publish the underlying data. The Board's 2022 rationale was explicit: the recommendations created no new obligations for contracted parties. It also said guidance and best practices sit outside the Registry Agreement, Registrar Accreditation Agreement and Consensus Policies, leaving ICANN Contractual Compliance without contractual authority to enforce them as obligations.

The 24 August response preserves that distinction. Recommendations 1, 2 and 4 contribute to a best-practices document for contracted parties. Recommendations 1 and 3 also require work directed at ICANN org. Recommendation 1 appears in both groups because it combines guidance with technical coordination. That overlap does not merge their legal force.

The current policy has its own publication logic

The Registration Data Policy already separates collection, transfer, escrow, publication, redaction, consent and lawful disclosure. Those actions are related, but they are not synonyms.

For public RDDS output, section 9.2.1 requires the redaction rules where redaction of personal data is necessary to comply with applicable law. It also permits those rules in specified additional circumstances. When deciding whether to apply them, a registry operator or registrar may consider whether the registration data pertains to a legal person or contains personal data. The policy says that consideration is not required.

The distinction is practical because a record associated with a company can still contain information about identifiable people. A corporate registration may name an employee, founder, external counsel or administrative contact. “Legal person” describes one characteristic of the registrant or record; it is not a machine-readable conclusion that every value in the record is non-personal.

The Registrant Organization field illustrates the existing control. A registrar must offer the registered name holder an opportunity to provide the value and must collect it if supplied. The holder must be informed that the organization value will be published if the holder agrees and that the organization will be considered the registered name holder. If publication is agreed, the registrar must publish the value. If it is not, the registrar may redact it under the policy.

That sequence is not a universal answer to every legal-person record, but it shows why the operative question cannot be reduced to classification. The system must retain which value is at issue, whether it contains personal data, which policy clause applies, whether consent is relevant, what applicable law requires and which accountable party made the publication decision.

A technical field can carry a decision; it cannot supply one

The Board response divides the technical task between Extensible Provisioning Protocol and the Registration Data Access Protocol. ICANN expects coordination with the technical community over differentiation fields in EPP and an updated gTLD RDAP Profile.

That work matters. A common field can prevent one system from encoding “legal person” as free text, another as an undocumented Boolean and a third as an inference no downstream party can inspect. It can define permitted values, absence states, update behaviour and a stable representation across registration and public-data systems.

Yet a field has no independent mandate. Its syntax does not decide who must populate it. A value does not establish the evidence used to classify the registrant. Transport through EPP does not determine what an RDAP response may reveal. Publication in an RDAP profile does not displace the Registration Data Policy, applicable law or the controller's accountable decision.

This is the line that implementation documents need to preserve. A technical standard can make an authorized distinction interoperable. It cannot turn a desired policy outcome into an adopted contractual obligation.

The missing artifact is a scope concordance

ICANN can make the boundary visible without choosing between the GAC's public-policy objective and contracted parties' legal concerns. It can publish a compact concordance alongside the implementation plan.

Layer Public instrument Force at the evidence cutoff Deliverable or decision
Public-policy position GAC letters and communiqués Advice and stated policy preference A request for collection and public availability of legal-person data
Adopted Phase 2A package GNSO recommendations and 2022 Board resolutions Direction to ICANN org; no new contracted-party obligations Best-practice guidance and technical field work
Contractual rule Registration Data Policy and applicable agreements Enforceable within their defined scope Collection, redaction, publication, consent and disclosure controls
Technical representation EPP extension and gTLD RDAP Profile work Interoperability specification once completed and adopted Defined values and carriage across systems
Record-level decision Contracted party applying policy and law Case-specific responsibility Whether a value is collected, classified, redacted, published or disclosed

Each row should link to the exact version, responsible actor, implementation state and change path. If the GAC seeks a mandatory result beyond the adopted package, the map should identify the policy process or other lawful authority capable of creating it. If ICANN org is implementing the current package, the map should prevent readers from mistaking completion of a field for completion of the broader GAC objective.

Such a concordance would not settle the substantive privacy debate. It would settle what is being built under which authority. That is a necessary precondition for honest progress reporting.

FY2027 is a start forecast, not a mandate change

The 24 August letter says ICANN anticipates being able to begin implementation in FY2027, subject to completion of existing projects that use dedicated implementation resources. It also points the GAC toward the FY2028 planning cycle and promises community updates.

“Begin” is the operative word. The letter supplies no completion date, no final field design, no published best-practices text and no evidence of adoption by contracted parties. Nor does the passage of time convert a recommendation's optional elements into mandatory ones.

The implementation record can still be judged. ICANN can be asked whether work started, which dependency cleared, what artifact was produced and why the sequence changed. The GAC can continue to argue for a different policy outcome. Contracted parties can explain implementation and legal constraints. Technical experts can define a clean data model.

What none of those roles should do is collapse the layers. Advisory participation is not contract amendment. A Board direction to implement is not a new obligation on every registrar. A field is not a disclosure authorization. A status update is not policy.

ICANN's response makes that boundary unusually clear. The next accountability test is whether the implementation programme keeps it clear when guidance, data models and public expectations begin to move together.

Sources

  1. ICANN correspondence index
  2. Tripti Sinha to Nicolas Caballero, 24 August 2026
  3. Nicolas Caballero to Tripti Sinha, 11 May 2026
  4. ICANN Board action on EPDP Phase 2A, 10 March 2022
  5. EPDP Phase 2A Final Report
  6. Phase 2A recommendations for Board consideration
  7. ICANN Registration Data Policy
  8. ICANN Registration Data Access Protocol resources