Skip to main content

Adopted Board Resolutions

Special Meeting of the ICANN Board of Directors
ICANN's Silicon Valley Office, Palo Alto, California, USA

  1. Waiver of Meeting Notice

    RESOLVED, (2010.11.05.01) the Board hereby confirms that it waives the notice for the meeting.

  2. New gTLDs - Cross-Ownership Issues for Registries and Registrars

    Whereas, at the ICANN meeting in Nairobi in March 2010, the Board passed a resolution indicating that as a default position that no co-ownership would be allowed in new gTLDs, but that if the GNSO were to develop a policy on the subject prior to the launch of new TLDs that the Board would consider using the new policy for the new gTLD program <>.

    Whereas, in May 2010, ICANN published version 4 of the Draft Applicant Guidebook, which included a note that the Board encouraged the GNSO to recommend policy on this issue, and that the Board would review this issue again if the GNSO did not make recommendations in time for launch of the new gTLD program <>.

    Whereas, the GNSO's Vertical Integration Working Group is divided on whether registrars should be allowed to operate registries (and consequentially whether registries should be allowed to operate registrars). The VI-WG's "Revised Initial Report on Vertical Integration Between Registrars and Registries" is posted at <> [PDF, 2.42 MB].

    Whereas, the GNSO VI working group's report includes a number of proposals to address vertical integration for the new gTLD program, but the VI-WG has not reached consensus as to which one to recommend <>.

    Whereas, on 23 September 2010, ICANN's Governmental Advisory Committee submitted its comments on v4 of the Applicant Guidebook, including comments on the issue of registry-registrar separation <> [PDF, 44 KB].

    Whereas, the Board has had over six months since Nairobi to consider the issue, including consideration of the GNSO VI working group's deliberations, and community comment including at the ICANN meeting in Brussels in June 2010.

    Whereas, the current set of agreements are not balanced in that while recent contracts prohibit registries from acquiring registrars, ICANN has never had a rule prohibiting registrars from applying for or operating TLDs.

    Whereas, while ICANN has individually negotiated contracts that recently have included restrictions on registry ownership of registrars, cross-ownership provisions have varied over time and no formal “policy” on this topic has ever been recommended by the GNSO or adopted by ICANN.

    Whereas, historical contract prohibitions on registries acquiring registrars do not provide a compelling basis for principled decision-making.

    Whereas, the Board is committed to making fact-based decisions, and has carefully considered available economic analysis, legal advice and advice from the community.

    Resolved, (2010.11.05.02), the Board directs the CEO to include the following principles relating to registry-registrar cross-ownership in the forthcoming version of the Applicant Guidebook.

    1. ICANN will not restrict cross-ownership between registries and registrars. Registry operators are defined as the registry operator and all other relevant parties relating to the registry services.

    2. Registry agreements will include requirements and restrictions on any inappropriate or abusive conduct arising out of registry-registrar cross ownership, including without limitations provisions protecting against:

      1. misuse of data; or

      2. violations of a registry code of conduct;

    3. These provisions may be enhanced by additional enforcement mechanisms such as the use of self-auditing requirements, and the use of graduated sanctions up to and including contractual termination and punitive damages.

    4. ICANN will permit existing registry operators to transition to the new form of registry agreement, except that additional conditions may be necessary and appropriate to address particular circumstances of established registries.

    5. ICANN will have the ability to refer issues to relevant competition authorities.

    6. ICANN will have the ability to address possible abuses that may arise out of registry-registrar cross-ownership through the consensus policy process.


Domain Name System
Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as"""" is not an IDN."