I appreciate the opportunity to provide comments on the updated Specification 14 (Variant TLDs) of the Draft 2026 gTLD Registry Agreement (RA). The proposed updates appropriately align with the IDN EPDP Phase 1 Recommendations 7.4 and 7.5, and represent meaningful progress toward enabling variant TLDs, strengthening the multilingual Internet, and advancing Universal Acceptance (UA) globally.

Given the critical role of Internationalized Domain Names (IDNs), Email Address Internationalization (EAI), and Variant TLD management in addressing the digital divide and supporting global linguistic diversity, these updates are timely and important. The following feedback aims to support ICANN’s efforts while also identifying areas where further clarity or policy enhancements would help ensure long-term adoption and operational success for variant TLDs.

I strongly support ICANN’s incorporation of Recommendations 7.4 and 7.5 into Specification 14. The updated fee model in Section 2.13 of the revised draft  is consistent with the policy intent to avoid financial barriers for communities adopting Variant TLDs. Applying Registry-Level Fixed Fees and RPM Access Fees once per TLD Set, rather than per TLD, is fair, predictable, and removes a key disincentive for registries considering variant applications.

This is a constructive step toward equitable access to the DNS, particularly for linguistic communities operating in scripts with inherent variant behavior (e.g., Arabic, Chinese, Indic scripts).

3.1 Section 2.13 – Fees (Support with Recommendations) :

I support the new fee structure as drafted in Section 2.13, which provides:

A single Registry-Level Fixed Fee for the entire TLD Set

Cumulative calculation of transaction thresholds across all TLDs in the set

A single RPM Access Fee satisfying obligations for all variants

These changes reduce administrative overhead and better reflect the operational reality that variant TLDs are not distinct commercial products but linguistic companions of the primary TLD.

Recommendation:

To further enhance predictability, ICANN could publish a clear fee-calculation example in implementation materials, demonstrating how cumulative transaction thresholds are applied when multiple variant TLDs generate differing levels of registrations. This will reduce ambiguity for future applicants.

3.2 Section 2.14 – Reservations for Registry Operations (Support)

The clarification that Registry Operator operational reservations under Specification 5 Section 3.2 are capped at 500 names cumulatively per TLD Set is a positive development. It prevents unnecessary expansion of reserved-name inventories and encourages consistent operational behavior across all variants.

Recommendation:

ICANN may consider adding language to emphasize that operators should apply consistent naming conventions and UA-compatible practices when selecting reserved registry operational names across variants.

3.3 Section 2.16 – Amendments & Waivers (Strong Support)

Requiring Variant TLD Registry Operator Approval before changes affecting the express terms of Specification 14 is a crucial safeguard. It ensures that policy or contractual changes impacting variant operations receive approval from those most directly affected.

The provision that each TLD Set receives one vote for the purpose of Section 7.6(j)(ii) is also fair and functionally appropriate.

Recommendation:

ICANN should consider including periodic reporting or structured engagement channels with Variant TLD Registry Operators to ensure policy changes reflect operational realities and emerging UA challenges.

4. Enhancing Universal Acceptance (UA) and EAI Alignment

Although Specification 14 is focused on Variant TLD mechanics, the following enhancements would ensure the 2026 round fully supports global UA goals.

4.1 Include an Explicit UA Readiness Requirement

Many challenges faced by IDN and Variant TLD operators stem from inconsistent application support. ICANN could significantly advance UA adoption by adding language requiring:

UA-readiness testing of registry systems

Registrar integration guidance on UA and EAI compliance

Affirmation that all variant TLDs must operate according to UA best practices

Such language can be included in Specification 14 or cross-linked to Specification 6 or Specification 11.

4.2 Promote Baseline EAI Support

Since many IDN applicants seek to enable local-language email identities, it is important that Registry Operators supporting Variant TLDs also commit to:

EAI-compatible WHOIS/RDAP systems

EAI-ready customer-facing portals

Encouraging registrars to support EAI mailbox provisioning

This aligns with the purpose of IDNs—enabling inclusive digital access—not just variant symmetry.

5. Need for Clear Implementation Guidance

Given the complexity of Variant TLD operations and the RZ-LGR framework, ICANN should publish:

Operational checklists for Variant TLD Set management

Guidance on cross-variant second-level allocation policies, as required under Section 2.15

Recommended processes for handling unintended cross-script confusion cases

Examples illustrating emergency-transition behavior when variants fail (Section 2.8)

Such documentation will help applicants, especially from developing regions, navigate the application and operational phases more effectively.

6. Support for Stronger Capacity Building and Outreach

The Variant TLD program will be new to many communities. ICANN should invest in:

Training for new applicants, especially in IDN-heavy regions

Registrar education programs about variant requirements

Universal Acceptance Day alignment with Variant TLD deployment timelines

EAI testing labs and open tools for registry-registrar interoperability

This investment is essential to ensure meaningful adoption of Variant TLDs and to prevent fragmentation caused by inconsistent operational policies.

I support the proposed updates to Specification 14 (Variant TLDs) of the Draft 2026 gTLD Registry Agreement, particularly the incorporation of IDN EPDP Phase 1 Recommendations 7.4 and 7.5, which introduce a fairer and more efficient fee model for Variant TLD Sets. The clarified approach—applying fixed fees and RPM Access Fees once per TLD Set and calculating transaction thresholds cumulatively—removes unnecessary financial and operational barriers for communities adopting IDN variants.

I also support the updates to Section 2.14, clarifying that reserved names for registry operations apply cumulatively across the TLD Set, and Section 2.16, which strengthens governance protections by requiring Variant TLD Registry Operator Approval for amendments affecting Specification 14. These changes ensure predictability, equitable treatment, and consistent operations across variant TLDs.

To further strengthen the framework, I recommend that ICANN incorporate explicit Universal Acceptance (UA) and Email Address Internationalization (EAI) readiness expectations into the RA, as these are essential for realizing the full value of IDNs and Variant TLDs. Additional implementation guidance, capacity-building programs, and technical resources would greatly assist applicants—especially those from developing linguistic communities—in successfully deploying Variant TLDs.

Overall, the proposed updates represent substantial progress in supporting a multilingual and inclusive Internet. With the addition of UA- and EAI-focused guidance, the 2026 round can meaningfully enhance global digital participation and strengthen the operational foundation for IDN and Variant TLD adoption.