Summary

  • ICANN’s Board adopted the ccNSO’s IDN country-code domain policy on 22 October, except its Risk Treatment Appraisal route and the cross-references that depended on it.
  • The rejected route concerned strings found confusingly similar to certain existing or reserved names only in uppercase. The ccNSO can discuss the Board’s reasons; the rest of the policy still needs implementation.

Imagine an applicant choosing an internationalised country-code top-level domain. The proposed name passes one visual comparison but looks too much like an existing name when displayed in capitals. The ccNSO’s policy report had offered a further chance: propose safeguards and ask an independent panel to appraise the residual risk. That particular chance did not survive the Board’s vote. The applicant can consider another string under the parts the Board adopted, but cannot treat the rejected appraisal as an available policy path.

In its 22 October resolutions, the ICANN Board adopted the ccNSO recommendations in Part A of the ccPDP4 Board Report with an explicit exception. It withheld Section 7.8, the Risk Treatment Appraisal, and references to it in four other sections. It found those recommendations not in the best interests of ICANN or its community. That is a split decision, not a rejection of the whole IDN country-code framework.

The ccPDP4 Board Report shows why the exception is narrow. Its proposed appraisal follows a finding of confusing similarity only in uppercase to an existing ccTLD, gTLD, reserved name or two-character ASCII string. The requester would put forward a risk management method and mitigation measures for an independent panel to evaluate. It was never a general waiver for any similar domain. The Board has declined to adopt even this confined route.

The Board’s stated worry is not that an actual domain has caused harm. It says a mitigation package could depend on cooperation from a separate TLD manager and complex technical or administrative registration coordination. Such dependencies could create security and stability risks. The resolution also points to another option: a requester may propose an alternative IDN ccTLD string that avoids the similarity finding. It does not promise that an alternative will qualify.

The refusal leaves a governance step open. Under the process described in the resolution, the Board has prepared a statement of reasons for the ccNSO Council. The two bodies are to discuss whether a mutually acceptable solution is possible; the Council may affirm or modify its recommendation, or submit a supplemental one for Board consideration. No public record in this evidence package establishes that the Council has already chosen a response.

Meanwhile, the Board instructed ICANN’s CEO to implement the adopted recommendations subject to prioritisation and further practical review. Some provisions require Bylaws amendments that the Board cannot guarantee the Empowered Community will approve. For a potential requester, the useful distinction is therefore threefold: most of the policy was adopted, the uppercase-only appraisal was not, and an operational application path still depends on implementation. The separate GNSO plan for accented generic domains did not become part of this ccNSO decision.