Skip to main content
Resources

Work Stream 2 – Recommendations for Guidelines for Standards of Conduct Presumed to Be in Good Faith Associated with Exercising Removal of Individual ICANN Board Directors

This set of recommendations concerns the establishment of guidelines to facilitate the ICANN Empowered Community's exercise of its power to remove individual ICANN Board Directors. The Empowered Community is the accountability mechanism through which ICANN's five Decisional Participants – consisting of the three Supporting Organizations (SOs), the At-Large Advisory Committee, and the Governmental Advisory Committee – exercise the specific rights and obligations that are defined in the ICANN Articles of Incorporation and Bylaws.

The Cross-Community Working Group on Enhancing ICANN Accountability (CCWG-Accountability) was tasked with creating a framework that would enable individuals to understand what is meant by "acting in good faith on behalf of their supporting organization or advisory committee" when participating in Board Director removal conversations. If individuals face legal challenges for their participation in those conversations, the ICANN Bylaws provide for indemnification – or paying for their defense – as long as the person's participation was in good faith.

The recommended guidelines are intended to apply to all Director removal conversations, regardless of the entity that selected the Director to the ICANN Board.

The CCWG-Accountability also proposed two stand-alone recommendations on Good Practices that suggest developing a standard framework for exercising the Empowered Community powers and potentially applying the recommended guidelines to Empowered Community discussions beyond the power to remove a Board Director.

All recommendations included in this topic are directed at and owned by the community, with ICANN org supporting the community's discussions and activities.

Rec Description Implementation Status
2.1

Recommendations for guidelines with respect to Petitions for removal:

2.1.1 May for any reason; and

2.1.2 Must:

2.1.2.1 Be believed by the Indemnified Party to be true.

2.1.2.2 Be in writing.

2.1.2.3 Contain sufficient detail to verify facts; if verifiable facts are asserted.

2.1.2.4 Supply supporting evidence if available/applicable.

2.1.2.5 Include references to applicable by-laws and/or procedures if the assertion is that a specific by-law or procedure has been breached.

2.1.2.6 Be respectful and professional in tone.

In progress.

2.2

Recommendations for guidelines with respect to procedures for consideration of board removal notices by SO/ACs to include:

2.2.1 Reasonable time frames for investigation by SO/AC councils or the equivalent decision-making structures if the SO/AC deems that an investigation is required.

2.2.2 Period of review by the entire membership of the SO/AC provided the SO/AC organizational structure customarily provides review for individual members; otherwise, period of review by those empowered to represent the SO/AC in decisions of this nature.

2.2.3 Consistent and transparent 40 voting method for accepting or rejecting a petition; such voting maybe be by the entire membership or those empowered to represent the SO/AC in decisions of this nature.

2.2.4 Documentation of the community process and how decisions are reached

In progress.

2.3

Standalone Recommendations In addition to the proposed guidelines which are intended to trigger the indemnity under ICANN Bylaws Article 20, Section 20.2, two other recommendations were developed that may be helpful to the community as standalone items

2.3.1 A standard framework be developed and used to raise the issue of Board removal to the respective body – either the specific SO/AC who appointed the member or the Decisional Participant in the case of a NomCom appointee. The framework would be in the context of developing a broader framework for implementing community powers and entering into the discussions contemplated by WS1. This framework could be developed by a new group specifically formed for that purpose.

2.3.2 Implement the guidelines as a community best practice to apply to all discussions even if not covered by the indemnities contemplated under Article 20. There may be discussions around rejecting a budget or rejecting a proposed standard Bylaw that would benefit from a good faith process. The guidelines for engaging discussions around Board removal could be adopted as a universal standard given that they are broad enough to encompass any discussion.

In progress.

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""icann.org"" is not an IDN."