Skip to main content
Resources

Work Stream 2 – Recommendations to Improve Staff Accountability

Recommendation 7.1 calls for improved visibility and understanding of ICANN org's existing accountability processes.

Recommendation 7.2 suggests that ICANN org enhance existing staff accountability mechanisms to include better overall performance assessment and appropriate accountability to relevant stakeholders.

Recommendation 7.3 calls for ICANN to work with the community to develop service-level agreement targets and guidelines that clearly define the services provided by ICANN to the community.

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

Rec Description Implementation Status
7.1.1

The ICANN organization should improve visibility and transparency of the organization's existing accountability mechanisms, by posting on icann.org in one dedicated area the following:

7.1.1.1 Description of the organization's performance management system and process.

7.1.1.2 Description of how departmental goals map to ICANN's strategic goals and objectives.

7.1.1.3 Description of the Complaints Office and how it relates to the Ombuds Office.

7.1.1.4 Organization policies shared with the CCWG-Accountability during the course of the WS2 work.

7.1.1.5 ICANN Organization Delegations document.

7.1.1.6 The roles descriptions included in this overall report.

7.1.1.7 Expectations and guidelines regarding the development of staff reports for Public Comments, or staff response to Community correspondence.

Complete. Completed in Q2 2022. See implementation documentation.

7.1.2

The ICANN organization should also evaluate what other communication mechanisms should be utilized to further increase awareness and understanding of these existing and new accountability mechanisms.

Complete. Completed in Q4 2022. See implementation documentation.

7.2.1

The ICANN organization should enhance existing accountability mechanisms to include:

7.2.1.1 A regular information acquisition mechanism (which might include surveys, focus groups, reports from the Complaints Office) to allow the ICANN organization to better ascertain its overall performance and accountability to relevant stakeholders.

7.2.1.1.1 The group notes that several new mechanisms are now established, but have not yet been exercised enough to determine effectiveness or potential adjustments. The evaluation mechanism proposed here would be helpful in determining effectiveness of these recent mechanisms before creating yet more mechanisms that may turn out to be duplicative or confusing for the organization and community.

7.2.1.2 Results of these evaluations should be made available to the Community.

Complete. Completed in Q3 2022. See implementation documentation.

7.2.2

Consistent with common best practices in services organizations, standardize and publish guidelines for appropriate timeframes for acknowledging requests made by the community, and for responding with a resolution or updated timeframe for when a full response can be delivered. The ICANN organization should include language in the performance management guidelines for managers that recommends people managers of community-facing staff seek input from the appropriate community members during the organization's performance reviews. Identification of appropriate community members, frequency of outreach to solicit input, and how to incorporate positive and constructive feedback into the overall performance review should be at the discretion and judgement of the personnel manager, with appropriate guidance from HR as necessary. Such a feedback mechanism should be supplemental to the existing mechanisms available to the community to provide input on ICANN staff performance, including direct communication to specific staff member, their personnel managers, senior executive staff, Board Directors, and the Complaints Officer.

Complete. Completed in Q4 2022. See implementation documentation.

7.3

The ICANN Organization should work with the community to develop and publish service level targets and guidelines (similar to the Service Level Agreement for the IANA Numbering Services) that clearly define the services provided by ICANN to the community as well as the service level target for each service. In this context:

7.3.1 ICANN should work with the community to identify and prioritize the classes of services for which service level targets and guidelines will be implemented, and to define how service level targets and guidelines will be defined.

7.3.2 Develop clear and reasonable guidelines for expected behavior between the ICANN organization and the community for those newly identified activities.

7.3.3 Develop and publish the resulting service levels, targets, and guidelines in a single area on icann.org. These targets and guidelines should also inform any regular information acquisition mechanism described in Recommendation 2 of this report.

Complete. Completed in Q4 2022. See implementation documentation.

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