Skip to main content

Board Governance Committee: Code of Conduct Guidelines

The following are suggested guidelines when dealing with adherence to and breaches or apparent breaches of the Code of Conduct. These guidelines are a work in progress and shall be amended, supplemented or enhanced from time to time as appropriate. Further, these are guidelines only, and shall not inhibit the Board's need to take action as required.

  1. Confidentiality.

  2. The Code of Conduct ("Code") states as follows:

    Board members should maintain the confidentiality of information entrusted to them by ICANN and any other confidential information about ICANN, its business, customers or suppliers, which comes to them, from whatever source, except when disclosure is authorized or legally mandated. For purposes of this Code, "confidential information" includes all non-public information relating to ICANN, its business, customers or suppliers.

    1. Training: As part of the Board member Induction Program, all Board members will receive training on the Code, including information relating to the requirement for confidentiality as set out in the Code. In addition to initial training, there should be refresher training periodically.

    2. Specific Handling of Confidential Information:

      1. Any document that is submitted to a Board mailing list or in BoardVantage shall be considered confidential, and for ICANN Board and staff only, until it is published on the ICANN website or the Board is otherwise informed that the document should no longer be considered confidential.

      2. Any staff matters shall be considered confidential until either a responsible ICANN staff member has made a public announcement or the information has been posted on the ICANN website.

      3. Where a Director or Liaison is providing a public briefing on a particular topic or has been asked by a member of the community for specific information - the Board member should refer the party or parties to the relevant publicly available material, and may assist with providing context for that material. Providing context does not include detailing the individual views of Board members on a particular topic, or revealing otherwise confidential information, but could involve explaining related activities at ICANN (such as position papers from other parties, etc.) that have been considered when making a particular decision.

      4. Where specific information being sought by a community member is not publicly available (e.g. the location for the next ICANN meeting), the Director or Liaison should check with relevant staff to determine if the material can be shared, and generally encourage the relevant ICANN staff function to make the material public before the Director or Liaison should make further comment. In some cases, information may be able to be shared on a limited "non-public" basis - e.g. with members of SSAC if related to a security issue, with members of the GAC if it relates to the location for a Board/GAC meeting, etc., but that information should not be disclosed before consulting with relevant staff.

    3. Response to Disclosure of Confidential Information.

      1. Board Discussion: If it is discovered that Confidential Information has been disclosed outside of the Board or the staff, that matter should be addressed at the next Board meeting. This discussion shall be used as an opportunity to remind Directors and Liaisons of their responsibility to maintain confidentiality and duty to abide by the Code of Conduct.

      2. Board Governance Committee Discussion with Discloser: If the Board becomes aware that a particular Director or Liaison disclosed the Confidential Information, the BGC shall address the matter with the discloser as it deems appropriate in accordance with Section II.D. of its Charter.

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."