Summary

  • The Latin Script Diacritics PDP final report proposes a common operator and linked transition arrangements for eligible ASCII/diacritic gTLD sets.
  • Changing a provider, removing a suffix and making that suffix available to another entity are different actions, with different proposed conditions.
  • The report is before the GNSO Council. The Board’s forthcoming workshop discussion is not policy adoption, and no implementation round is established.

The migration unit would be the set

Imagine a registry operator wanting to move the DNS service for one of its related suffixes to a new provider. Under the proposed Latin Script Diacritics framework, the relevant question would not be whether that suffix was ready on its own. The corresponding allocated and delegated members of its set would have to move to the same provider for that function at the same time.

That requirement appears in Recommendation 22 of the final report dated 31 August. It turns a proposal about writing names correctly into a consequential choice about how a registry can reorganize its operations.

The proposal addresses a particular gap: an ASCII gTLD and its Latin-diacritic counterpart can look confusingly similar without being variants under the root-zone rules. The working group would permit qualifying strings to operate as a set under one registry operator. This is neither permission for every accented string nor a merger with the separate variant-TLD framework. Eligibility still depends on the prescribed character criteria and root-zone rules.

The current GNSO document index links the final report. Its 57 outputs have working-group consensus, not completed policy approval. In her 2 September workshop preview, the Board chair says the 4–6 September meeting will examine the recommendations before they formally reach the Board. The report has been submitted to the Council. ICANN’s implementation framework separates policy development, Board adoption and subsequent implementation.

One operating group, not necessarily one supplier

The proposed attachment is durable. Recommendation 18 calls for one Registry Agreement and common service-level and operational requirements. Recommendations 23 and 25 would keep the relevant allocated and delegated strings together during a registry transition or change of control, and during emergency transfer to an Emergency Back-End Registry Operator.

The provider requirement needs care. It applies across the set for each critical function; it does not insist that one supplier perform every function. The report explicitly allows multiple DNS service providers, provided they are the same across the set. A registry could therefore retain supplier diversity while losing the option to move just one member independently for a given function.

There is a sensible protective purpose. If names that users may confuse acquire incompatible control or operating arrangements, the exception that allowed them to coexist could become harder to justify. A shared transition can preserve that alignment.

But alignment has a cost. A supplier change must be prepared across the relevant group, even if one member would otherwise be ready earlier. That is an inference from the proposed coupling, not evidence of an actual delay or a quantified increase in cost. Buyers should price the migration unit they would actually have to move.

Removing a suffix is a different exit

The report does not impose a ten-year ban on changing providers. Its long restriction concerns reassignment after removal from the root zone.

If the ASCII member is removed, the proposed set would dissolve, although the operator could retain a single internationalized gTLD. Voluntarily removing a diacritic member need not remove the others. Recommendations 37 and 38 would prevent the removed strings from going to another entity, other than the specified remaining holder, for at least ten years. An emergency transition that keeps the set intact is not such a removal.

The distinction matters for customers. Moving a functioning namespace and retiring one do not preserve the same thing. Guidance 39 calls for a transition plan where a string proposed for removal contains existing second-level registrations. Recommendation 40 separately addresses removal resulting from a Registry Agreement breach; it does not make every breach an automatic deletion.

Nor would the scheme simply sweep up old arrangements. Pre-existing independently operated gTLDs have an exemption, with limits on further applications. Existing second-level names that fail the same-registrant and same-registrar test are also protected from retroactive changes to their contractual or allocation status. For non-exempt allocated members of a second-level set, however, the proposed inter-registrar transfer would be collective too.

Portability belongs in the safety case

Lu Heng’s Note 64 argues that shared coordination rules should identify the safety property they preserve while keeping exit and portability workable. Used here, that is a test of proportionality, not a claim that his design pattern overrides gTLD contracts.

The policy question is consequently sharper than “more accents or fewer”. Which shared obligations are necessary to prevent confusion, and can an operator still replace its suppliers without an impracticable transition? A credible answer should protect the relationship between names without making the incumbent service arrangement indispensable.

The report does not put these rules into the current 2026 application guidebook or establish a particular future round. There is time to examine the operating consequences before treating the exception as a product ready to buy.

Sources

  1. Latin Script Diacritics PDP final report
  2. GNSO drafts and working documents
  3. September Board workshop preview
  4. Policy implementation at ICANN
  5. Lu Heng: minimum specification and voluntary adoption