PointQuébec’s public comment

Proposed Next Round Base gTLD Registry Agreement –

SPEC 14 (Variants TLDs)

Introduction

The Latin Diacritics PDP, opened for Public Comment, has consciously kept its Recommendations to mirror those of the IDN Variant EPDP, adapting those Recommendations were needed only to fit the definition and specificity of Latin Diacritics.

Furthermore, it recommends that the implementation of the PDP mirror that of the IDN Variant PDP, to ensure limited operational and technical differences between the 2 policies with the specific aim to ensure that operators be able to run both Variant and Latin Diacritics if they are able to run either.

Following this logic we respectfully ask that the attached text be included to the base agreement, to be made available to prospective Registry Operators as soon as the Latin Diacritics PDP Recommendations are approved and implemented.

These mirrors the Variant-specific items in the Base Registry Agreement, to add Latin Diacritics-specific elements - an article 2.23 to mirror 2.22 and a Specification 15 to mirror Specification 14.

We have witnessed wide community support for the earliest possible adoption of Latin Diacritics TLDs, as long as it does not disrupt the April 2026 next Round of g TLDs.

We believe that preemptively adopting these changes pending implementation would allow applicants to such TLDs to participate in the April 2026 round, albeit with the understanding that approval of their TLDs will require prior implementation of the policy.

Missing the opportunity to preemptively include our proposed text into the Base Agreement at this stage would exclude any prospective Latin Diacritic applicant to enter into a Registry Agreement with ICANN, regardless of progress on all other elements of the application review process, which we are confident will be implemented concurrently with next year's application review timelines.

We therefore respectfully invite you to consider these as friendly additions/amendments and include them to the Base Registry Agreement, to be available as soon as the policy Implementation is achieved, rather than waiting for the following Round of TLDs which could be years away.

REGISTRY AGREEMENT

2.23 [Note: For ASCII/Latin diacritc set TLDs. Registry Operator shall operate the Base ASCII TLD and the ASCII/Latin diacritic Set. in compliance with the requirements of Specification 15 attached hereto (“Specification 15”).]

[Note: For ASCII / Latin Diacritic set TLDs Only]

[SPECIFICATION 15

ASCII/Latin diacritc set TLDS

1.             Definitions.

1.1.        “Applicable ASCII/Latin diacritic set TLD Registry Agreements” means this Agreement and all other registry agreements that contain this Specification 15 between ICANN and the Applicable ASCII/Latin diacritic set TLD Registry Operators.

1.2.        “Applicable ASCII/Latin diacritic set TLD Registry Operators” means, collectively, the registry operators of top-level domains party to a registry agreement that contains this Specification 15, including Registry Operator.

1.3.        “Base TLD” is the top-level domain identified in Section 1 1.1 of the agreement

1.4.        “Root Zone Label Generation Rules” or “RZ-LGR” are the set of rules that determine valid internationalized top-level domain names and their variant names published at https://icann.org/rz-lgr, as may be updated by ICANN from time to time to add new characters. However, existing characters in active usage may never be revoked. 

(identical to Specification 14)

1.5      “TLD Set”  includes the Base ASCII TLD and all associated Latin       Diacritic TLDs.

1.6.        “ASCII/Latin diacritic set TLD Registry Operator Approval”

(TBD)

1.7.        “ASCII/Latin diacritic set TLDs” are the following top-level domain:

(1)         [include ASCII/Latin diacritic set TLDs here]

2.             Requirements for TLDs Set.

Maintenance of the Base ASCII TLD and the ASCII/Latin diacritic Set. The ASCII Base TLD must remain the Base TLD and 1.1.        the designation of the Base TLD cannot be changed. Each reference to “TLD” in the Agreement shall refer to each of the Base TLD and the Latin Diacritic TLD individually and this Agreement shall apply in full force and effect to the ASCII Base TLD and Latin Diacritic TLD(s) as though each individually had its own registry agreement.

2.2.     Critical Functions and Material Subcontracting Arrangements. The same entity shall perform the same Critical Function(s) (as identified in Section 6 of Specification 10) for each TLD within the TLD Set.

(identical to Specification 14)

2.3.        Change of Control ; Assignment and Changes to Material Subcontracting Arrangements. In the event of an assignment, a direct or indirect change of control or a Material Subcontracting Arrangement pursuant to Section 7.5 of the Agreement such assignment, change of control or Material Subcontracting Arrangement, as applicable, shall apply to all TLDs in the TLD Set.

(identical to Specification 14)

2.4.        Registry Services. Unless otherwise mutually agreed to, all Registry Services shall be offered for all TLDs in the TLD Set, and in the same manner for each TLD.

(identical to Specification 14)

2.5.        Delegation of the TLD Set. Registry Operator shall complete all testing and procedures for delegation for all the TLDs in the TLD Set within the time frame specified in Section 4.3(b) of the Agreement; provided however that, if Registry Operator fails to complete all testing and procedures for (i) for the Latin Diacritic TLD, then such Latin Diacritic TLD shall be removed from the TLD Set or (ii) for the Base ASCII TLD, then such Base ASCII TLD within the TLD Set shall be removed. In the case of a removed ASCII Base TLD from the set, the provisions of this Specification 15 shall thereafter no longer have any effect. ICANN may terminate the Agreement pursuant to Section 4.3(b) of the Agreement

2.6.        Data Escrow. Registry Operator shall engage with the same Escrow Agent for all TLDs in the TLD Set in accordance with Specification 2.

(identical to Specification 14)

2.7.        Zone File Access. Zone file data provided by the Registry Operator pursuant to Section 2 of Specification 4 shall include a separate zone file for each TLD in the TLD Set.

(identical to Specification 14)

2.8.        Emergency Thresholds. If any one of the events set forth in (i) through (iii) of Section 2.13 of the Agreement has occurred such that an emergency transition is required for any TLD in the TLD Set, then each TLD within the TLD Set shall be deemed to require the same emergency transition and shall be subject to Section 2.13 of the Agreement.

(identical to Specification 14)

2.9.        Renewal. If any one of the events set forth in Section 4.2(a) of the Agreement has occurred such that the Agreement shall, upon notice to Registry Operator, terminate at the expiration of the then-current Term for any TLD in the TLD Set, then each TLD within the TLD Set shall be deemed to have reached the same non-renewal threshold.

(identical to Specification 14)

2.10.        Termination. If any one of the events for termination set forth in Section 4.3 of the Agreement has occurred such that ICANN may exercise its right to terminate the Agreement for any TLD in the TLD Set, then each TLD within the TLD Set shall be deemed to have reached the same termination event.

(identical to Specification 14)

 2.11.        Transition of Registry upon Termination of Agreement. In the event that this Agreement is terminated and any TLD in the TLD Set is removed from the root zone pursuant to Section 4.5 of the Agreement, then each TLD within the TLD Set shall also be removed and in the event any TLD in the TLD Set is transitioned to a successor registry operator, then each TLD within the TLD Set shall be transitioned to the same such successor registry operator.

(identical to Specification 14)

----- to be continued in summary of Attachment ------

2.12 Voluntary Removal and Revocation of Base ASCII TLD and/or the ASCII/Latin diacritic Set. Registry Operator may request to remove either the Base TLD or the Latin Diacritic TLD from the TLD Set. In the event that domain name registrations exist at the second-level under either the delegated ASCII Base TLD(s) or the Latin Diacritic TLD, such request must include a transition plan for the existing domain name registrations under the remove ASCII Base TLD or the Latin Diacritic TLD to be submitted to ICANN for its review and approval. If an amendment to this Agreement removes a Latin Diacritic TLD, the remaining TLD(s) in the TLD Set shall remain delegated. If the Base ASCII TLD is removed, the TLD Set is dissolved and one Latin Diacritic TLD may be retained while the others are also removed. The provisions of this Specification 15 shall thereafter no longer have any effect.

 2.13.        [Fees.][1]

(identical to Specification 14)

 2.14.        Allocation of Variant Second-Level Names. Section 7 of Specification 6 shall apply across all TLDs in the TLD Set such that all second-level domain names under the TLD Set are either allocated to the same registrant, or else withheld for possible allocation only to that registrant.

(identical to Specification 14)

2.15.        Sections 7.6 and 7.7 of the Agreement, if any amendment contemplated by Section 7.6 or 7.7 of the Agreement (other than bilateral amendments between ICANN and Registry Operator and Board Amendments) would, if effective, amend the express

terms of this Specification 15, such amendment shall not amend the express terms of this Specification 15 unless such amendment also receives Base TLD or the Latin Diacritic TLD Operator Approval. For the avoidance of doubt, (i) nothing in this Section 2.15 of this Specification 15 shall restrict ICANN and Registry Operator from entering into bilateral amendments and modifications to this Specification 15 or any other provision of the Agreement, (ii)

-- see next --

the requirements of this Section 2.15 of this Specification 15 shall not apply to any Board Amendment or otherwise restrict the adoption of Board Amendments pursuant to Section 7.6 of the Agreement, and (iii) if any amendment does not receive the required Registry Operator Approval under Section 7.6 or 7.7 of the Agreement, as applicable, the terms of this Specification 15 shall not be amended by such amendment even if such amendment receives Variant TLD Registry Operator Approval.

2.16 [Note: For .Brand TLDs Only: The following provisions shall apply if this Agreement includes Specification 13:

(1)         If any TLD in the TLD Set ceases to qualify as a .Brand TLD pursuant to Section 1 or Section 2 of Specification 13, then concurrent therewith

(i) this TLD within the TLD Set shall cease to be a .Brand TLD, (ii) the Registry Operator shall immediately comply with the provisions of the Agreement no longer modified by Specification 13 (other than Sections 2 and 4.3 of Specification 13) and (iii) the provisions of Specification 13 (other than Sections 2 and 4.3 of Specification 13) shall thereafter no longer have any effect.

(2)         For the avoidance of doubt, each reference to “TLD” in Specification 13, including any reference to “.Brand TLD,” shall refer to each of the Base TLD and Latin Diacritic TLD(s) individually and Specification 13 shall apply in full force and effect to each Base TLD or the Latin Diacritic as though each individually had its own Specification 13.

(3)         Notwithstanding the last sentence of Section 9.4 of Specification 13, Registry Operator shall have one vote for each Base TLD operated by such Registry Operator pursuant to an Applicable Brand Registry Agreement.]]

Submitted 26 January 2026