Skip to main content
Resources

Work Stream 2 – Recommendations for Improving the ICANN Office of the Ombuds

In building its recommendations on the ICANN Office of the Ombuds (IOO), the Cross-Community Working Group on Enhancing ICANN Accountability (CCWG-Accountability) was informed by an external review. Recommendations seek to clarify the Ombuds Office's roles and processes, and to strengthen its independence and transparency.

The implementation of this set of recommendations is owned by ICANN org.

Rec Description Implementation Status
5.1

The Ombuds Office should have a more strategic focus.

In progress. Targeted completion date: Q3 2022.

5.2

The Ombuds office should include procedures that:

5.2.1 Distinguish between different categories of complaints and explains how each will be handled.

5.2.2 Set out the kinds of matters where the Ombuds will usually not intervene – and where these matters are likely to be referred to another channel (with the complainant's permission)

5.2.3 Provides illustrative examples to deepen understanding of the Ombuds' approach.

Not started. Targeted completion date: Q1 2023.

5.3

Once ICANN has agreed to a revised configuration for the Office of the Ombuds, a plan should be developed for a soft relaunch of the function, which should incorporate action to emphasis the importance of the Ombuds function by all relevant parts of ICANN, including: Board, CEO, Community Groups, Complaints Officer.

Not started. Targeted completion date: Q1 2023.

5.4

All relevant parts of ICANN should be required (should include the corporation, the Board and committees, and anybody or group with democratic or delegated authority) to respond within 90 days (or 120 days with reason) to a formal request or report from the Office of the Ombudsman. The response should indicate the substantive response along with reasons. Should the responding party not be able to meet the 120-day limit due to exceptional circumstances, that party can apply to the IOO to seek an additional extension prior to the expiration of the original 90-day delay. The application should be in writing, stating the nature of the exception and the expected time required to respond. The IOO will respond to such requests within a week.

Not started. Targeted completion date: Q1 2023.

5.5

The ICANN Office of the Ombuds should establish timelines for its own handling of complaints and report against these on a quarterly and annual basis.

Not started. Targeted completion date: Q1 2023.

5.6

The Office of the Ombuds should be configured so that it has formal mediation training and experience within its capabilities.

Complete. Completion date: Q4 2018.

5.7

Ideally, the Office of the Ombuds should be configured so that it has gender and, if possible, other forms of diversity within its staff resources. (The primary objective of this recommendation is to ensure that the Community has choices as to whom in the IOO they can bring their complaints to and feel more comfortable doing so.)

Complete. Completion date: Q1 2019.

5.8 (Implementation Guidance)

ICANN should establish an Ombuds Advisory Panel:

5.8.1 Made up of five members to act as advisers, supporters, and wise counsel for the Ombuds and should be made up of a minimum of at least two members with Ombudsman experience and the remainder with extensive ICANN experience.

5.8.2 The Panel should be responsible for:

5.8.2.1 Contributing to the selection process for new Ombuds, which would meet the various requirements of the Board and Community, including diversity

5.8.2.2 Recommending candidates for the position of Ombuds to the Board.

5.8.2.3 Recommending terms of probation to the Board for new Ombuds.

5.8.2.4 Recommend to the Board firing an Ombuds for cause.

5.8.2.5 Contribute to an external evaluation of the IOO every five years.

5.8.2.6 Making recommendations regarding any potential involvement of the IOO in non-complaint work based on the criteria listed in Recommendation 11.

5.8.3 The Panel cannot be considered as being part of the Ombuds Office and cannot be considered additional Ombuds, but rather external advisors to the office.

5.8.4 Any such advisory panel would require the Ombuds to maintain its confidentiality engagements per the Bylaws.

CCWG-Accountability Implementation guidance: The Ombuds panel is not meant to be a decision-making body – it is only there to assist the Board or relevant Board Committee with the specific tasks enumerated in the recommendation. The Panel is specifically prohibited from getting involved in any matter before the Ombuds; the Ombuds shall not seek, even on anonymized terms, guidance from the Panel on any matter before the Ombuds. The Panel will only have the six specifically enumerated powers set out in the recommendation. In implementing the portion of the recommendation "recommend to the Board firing an Ombuds for cause" - because under the Bylaws only the Board has the power to fire the Ombuds, the CCWG advises that the Board should implement this recommendation by preparing and publishing information about the process any ICANN community participants can use to provide the Board with feedback about, or raise concerns regarding, the performance of the Ombuds. The Panel is welcome to offer feedback on the performance of the Ombuds but can only provide any feedback though this process (aside from the regular external evaluation). The CCWG suggests this clarification to preserve the right of the Panel to raise any concerns with the performance of the Ombuds function while not interfering with the Board's responsibilities in managing the engagement of the Ombuds and considering concerns raised in an appropriate way. In implementing the portion of the recommendation "Make recommendations regarding any potential involvement of the IOO in noncompliant work based on the criteria listed in recommendation 11", this should only occur at the request of the Board. Finally, a formal process to select the panel members should be created. This should ensure that candidates have extensive ICANN and/or ombuds experience, and also have complete independence from the SO/ACs. The selection process may be designed in any appropriate means to achieve independence, such as by selection by the Board, an independent recruitment firm, or other appropriate process. Regardless of the process which is selected the ICANN Board should post details regarding the process that will be utilized.

Not started. Targeted completion date: Q2 2023.

5.9

The Ombuds employment contracts should be revised to strengthen independence by allowing for a:

5.9.1 Five-year fixed term (including a 12-month probationary period) and permitting only one extension of up to three years (the extension should be subject to a community-based feedback mechanism to the Advisory Panel covering Ombuds performance over the previous years).

5.9.2 The Ombuds should only be able to be terminated with cause.

Not started. Targeted completion date: Q1 2023.

5.1 0

The Ombuds should have as part of their annual business plan, a communications plan – including the formal annual report – publishing reports on activity, collecting and publishing statistics and complaint trend information, collecting user satisfaction information, and publicizing systemic improvements arising from the Ombuds' work.

Not started. Targeted completion date: Q1 2023.

5.11

The following points should be considered and clarified publicly when looking at the Ombuds' involvement in any non-complaints work:

Whether there is unique value that the Ombuds can add through the proposed role or function?

Whether the proposed reporting/accountability arrangements may compromise perceived independence?

Whether the workload of the proposed role/function would limit the Ombuds ability to prioritize their complaints-related work?

Whether any Ombuds' involvement with the design of new or revised policy or process, meets the requirement of not, in any way, creating a "stamp of approval"?

Whether the proposed Ombuds input may be seen as a "short-cut" or substituting for full stakeholder consultation?

In progress. Targeted completion date: Q3 2022.

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