Skip to main content

ICANN Expected Standards of Behavior

Those who take part in ICANN multi-stakeholder process including Board, staff and all those involved in Supporting Organization and Advisory Committee councils undertake to:

  • Act in accordance with ICANN's Bylaws. In particular, participants undertake to act within the mission of ICANN and in the spirit of the values contained in the Bylaws.
  • Adhere to the conflict of interest policy laid out in the Bylaws.
  • Treat all members of the ICANN community equally, irrespective of nationality, gender, racial or ethnic origin, religion or beliefs, disability, age, or sexual orientation; members of the ICANN community should treat each other with civility both face to face and online.
  • Act in a reasonable and informed manner when participating in policy development and decision-making processes. This includes regularly attending all scheduled meetings and exercising independent judgment based solely on what is in the overall best interest of Internet users and the stability and security of the Internet's system of unique identifiers, irrespective of personal interests and the interests of the entity to which an individual might owe their appointment.
  • Listen to the views of all stakeholders when considering policy issues. ICANN is a unique multi-stakeholder environment. Those who take part in the ICANN process must acknowledge the importance of all stakeholders and seek to understand their points of view.
  • Work to build consensus with other stakeholders in order to find solutions to the issues that fall within the areas of ICANN's responsibility. The ICANN model is based on a bottom-up, consensus driven approach to policy development. Those who take part in the ICANN process must take responsibility for ensuring the success of the model by trying to build consensus with other participants.
  • Act in accordance with ICANN policies.
  • Protect the organization's assets and ensure their efficient and effective use.
  • Act fairly and in good faith with other participants in the ICANN process.

ICANN Consultation Principles

ICANN is based on a multi-stakeholder model that develops policy through a bottom-up, consensus-driven process. ICANN's values contained in the Bylaws set out the importance of consultation in the ICANN process:

  1. Seeking and supporting broad, informed participation reflecting the functional, geographic, and cultural diversity of the Internet at all levels of policy development and decision-making.
  1. Employing open and transparent policy development mechanisms that (i) promote well-informed decisions based on expert advice, and (ii) ensure that those entities most affected can assist in the policy development process.

    (Article I, Section 2)

Furthermore, ICANN consults in other aspects of its operations beyond policy development, including strategic planning, operational planning, and budgeting.

The ICANN Bylaws set out clear frameworks for aspects of consultation, particularly those associated with policy development.

This document does not override or replace any of the Bylaws requirements. However, given the importance of consultation to the ICANN community, this document establishes a set of principles that guide consultation that takes place within the ICANN community.


In consulting with the ICANN community, ICANN seeks to uphold the following principles.

To maximize the ease of participation in any consultation, ICANN will:

  • Provide information on upcoming issues as far in advance as possible to give the community time to respond. Where issues are to be discussed publicly in a meeting, best efforts will be made to provide relevant information at least one week in advance of the meeting.
  • Maintain a calendar of current consultations and, where practicable, forthcoming consultations so that the ICANN community can be aware of times when their views will be sought on issues
  • Use online forums as the basic mechanism for conducting consultation
  • Provide sufficient context and background material to enable participants to understand the issues on which they are being asked to comment
  • Make clear the purpose of the consultation and the way in which comments will be used
  • Use developments in technology to enhance the consultation process
  • Follow the ICANN translation policy, with relevant documents and questions being translated and posted according to that policy
  • Except where Bylaws stipulate otherwise, ensure the minimum time for a comment period will be 21 days
  • Maintain a public participation site that encourages the community to discuss particular issues ahead of time and so clarify arguments and positions early on. If necessary, specific web pages, forums, and chat rooms can be quickly set up to cater to demand

To encourage active debate of issues, ICANN will:

  • Explore interactive approaches to comments that encourage discussion and resolution between members of the community
  • In the spirit of the values contained in the Bylaws, proactively seek comment from those entities most affected by an issue

To maximize transparency of the consultation process, ICANN will:

  • Make all comments visible to the community
  • Require that all comments be tagged with the sender's name and any relevant affiliation (where the individual is speaking on behalf of a group). Where the respondent is an ICANN Supporting Organization, Advisory Committee, or constituency group, some indication must be given of the process that was used to develop the comment and the parties who took part in that process
  • Post a summary of comments at the end of each comment period and in the same place as the comments
  • Post an analysis of the comments
  • Explain how the input will be used
  • Make clear wherever possible the impact of public comment on decisions
  • Request explicit discussion of that summary and analysis by the relevant body while discussing the topic under consideration

To maximize the effectiveness of the consultation process, ICANN will:

  • Conduct annual reviews of the consultation 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."