Skip to main content
Resources

Work Stream 2 – Recommendations to Improve ICANN Transparency

The Cross-Community Working Group on Enhancing ICANN Accountability (CCWG-Accountability) produced recommendations on transparency in four areas:

  1. Improving ICANN's Documentary Information Disclosure Policy (DIDP)
  2. Documenting and Reporting on ICANN's Interactions with Governments
  3. Improving Transparency of Board Deliberations
  4. Improving ICANN's Anonymous Hotline (Whistleblower Protection)

Recommendations on the DIDP focus both on updating the DIDP with specific modifications, as well as procedural enhancements. They are intended to ensure that information contained in documents concerning ICANN's operational activities, and within ICANN's control, is made available to the public unless there is a compelling reason for confidentiality.

Recommendations on Documenting and Reporting on ICANN's Interaction with Governments and Improving Transparency of Board Deliberations are associated with CCWG-Accountability implementation guidance.

Recommendations on the Whistleblower Protection were informed by a third-party (NAVEX Global) review of ICANN's Anonymous Hotline.

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

Rec Description Implementation Status

8.1 Improving ICANN's Documentary Information Disclosure Policy (DIDP)

8.1.1

The caveat that the DIDP applies only to "operational activities" should be deleted.

Complete. Completed in Q1 2023. See implementation documentation.

8.1.2

The DIDP should include a documentation rule whereby, if significant elements of a decision-making process take place orally, or otherwise without a lasting papertrail, the participants in that decision-making process should be required to document the substance of the conversation, and include it alongside other documentation related to this decision-making process.

Complete. Completed in Q1 2023. See implementation documentation.

8.1.3

The DIDP should be expanded to include clearly defined procedures for lodging requests for information, including requirements that requesters should only have to provide the details necessary to identify and deliver the information.

Complete. Completed in Q1 2023. See implementation documentation.

8.1.4

The DIDP should impose clear guidelines on ICANN for how to process requests, including delegating a specific employee or employees with the responsibility of responding to DIDP requests, including a commitment to provide reasonable assistance to requesters who need it, particularly where they are disabled or unable to identify adequately the information they are seeking.

Complete. Completed in Q1 2023. See implementation documentation.

8.1.5

The DIDP should commit to complying with requesters' reasonable preferences regarding the form in which they wish to receive information under request (for example, if it is available as either a pdf or as a doc), if ICANN either already has that information available in the requested format, or can convert it to the requested format relatively easily.

Complete. Completed in Q1 2023. See implementation documentation.

8.1.6

The DIDP should specify that requests should receive a response "as soon as reasonably possible" and should cap timeline extensions to an additional 30 days.

Complete. Completed in Q1 2023. See implementation documentation.

8.1.7

The phrase "to the extent feasible, to reasonable requests" should be deleted from the provision on Responding to Information Requests.

Complete. Completed in Q1 2023. See implementation documentation.

8.1.8

In cases where information subject to request is already publicly available, ICANN staff should direct requesters, with as much specificity as possible, to where the information may be found. In other words, if the processing of a DIDP request reveals that the information has already been published, staff should include information about where this information may be found in their response to the requester.

Complete. Completed in Q1 2023. See implementation documentation.

8.1.9

The exception for information "that relates in any way to the security and stability of the Internet, including the operation of the L Root or any changes, modifications, or additions to the root zone" should be amended so that it only applies to information whose disclosure would be harmful to the security and stability of the Internet, including the operation of the L Root or any changes, modifications, or additions to the root zone.

Complete. Completed in Q1 2023. See implementation documentation.

8.1.10

The exception for "drafts of all correspondence, reports, documents, agreements, contracts, emails, or any other forms of communication" should be amended to clarify that this information should be disclosed unless it would be harmful to an ongoing deliberative or decision-making process.

Complete. Completed in Q1 2023. See implementation documentation.

8.1.11

The exceptions for "trade secrets and commercial and financial information not publicly disclosed by ICANN" and for "confidential business information and/or internal policies and procedures" should be replaced with an exception for "material whose disclosure would materially harm ICANN's financial or business interests or the commercial interests of its stake-holders who have those interests."

Complete. Completed in Q1 2023. See implementation documentation.

8.1.12

Where an exception is applied to protect a third party, the DIDP should include a mechanism for ICANN staff to contact this third party to assess whether they would consent to the disclosure.

Complete. Completed in Q1 2023. See implementation documentation.

8.1.13

The exception for information requests which are "not reasonable, excessive or overly burdensome, not feasible, abusive or vexatious or made by a vexatious or querulous individual" should be amended so that either the Ombudsman or the Complaints Officer automatically reviews any decision to use this exception.

Complete. Completed in Q1 2023. See implementation documentation.

8.1.14

The following sentence should be deleted: "Further, ICANN reserves the right to deny disclosure of information under conditions not designated above if ICANN determines that the harm in disclosing the information outweighs the public interest in disclosing the information."

Complete. Completed in Q1 2023. See implementation documentation.

8.1.15

ICANN should consider future processes to expand transparency at ICANN Legal, including through clarification of how attorney-client privilege is invoked.

Complete. Completed in Q1 2023. See implementation documentation.

8.1.16 (implementation guidance)

Wherever possible, ICANN's contracts should either be proactively disclosed or available for request under the DIDP. The DIDP should allow ICANN to withhold information subject to a non-disclosure agreement; however, such agreements should only be entered into where the contracting party satisfies ICANN that it has a legitimate commercial reason for requesting the NDA, or where information contained therein would be subject to other exceptions within the DIDP (such as, for example, where the contract contains information whose disclosure would be harmful to the security and stability of the Internet).

CCWG-Accountability's Implementation Guidance: As the recommendation starts with the language "wherever possible" we would recommend that ICANN publish a document clearly stating its position on the limited use of NDAs and documenting the information that will make available on its contracted relationships, as discussed below.

In the first year of implementation ICANN should publish a register of all suppliers (name of supplier, country or origin and actual annual amount) it pays 500,000$US or more per fiscal year broken down by categories (e.g., computer equipment, software, telecommunication services, contracting etc.). Starting in the second year of implementation ICANN should lower this threshold to 250,000$US. The Board should review this threshold amount on a regular basis to effectively ensure transparency.

In scoping ATRT4 or future ATRT reviews SO/ACs should consider if the information provided in the above Register meets their requirements. Should they feel the need for adjustments they should request the review consider this.

In progress. Targeted completion date: Q1 2024.

8.1.17

The DIDP should include a severability clause, whereby in cases where information under request includes material subject to an exception to disclosure, rather than refusing the request outright, the information should still be disclosed with the sensitive aspects severed, or redacted, if this is possible.

Complete. Completed in Q1 2023. See implementation documentation.

8.1.18

Where an information request is refused, or the information is provided in a redacted or severed form, the DIDP should require that ICANN's response include the rationale underlying the decision, by reference to the specific exception(s) invoked, as well as information about appeal processes that are available.

Complete. Completed in Q1 2023. See implementation documentation.

8.1.19

The Ombudsman's mandate regarding transparency should be boosted to grant the office a stronger promotional role, including by integrating understanding of transparency and the DIDP into ICANN's broader outreach efforts, by publishing a list of the categories of information ICANN holds.

Complete. Completed in Q1 2023. See implementation documentation.

8.1.20

Either the Ombudsman or the Complaints Officer should be tasked with carrying out reasonable monitoring and evaluation procedures, such as publishing the number of requests received, the proportion which were denied, in whole or in part, the average time taken to respond, and so on.

Complete. Completed in Q1 2023. See implementation documentation.

8.1.21

ICANN should commit to reviewing the DIDP every five years.

Complete. Completed in Q1 2023. See implementation documentation.

8.2 Documenting and Reporting on ICANN's Interactions with Governments

8.2 (Implementation Guidance)

In the interest of providing the community greater clarity with regard to how ICANN engages government stakeholders7 and to ensure that the ICANN community and, if necessary, the Empowered Community is fully aware of ICANN's interactions with governments, the CCWG-Accountability recommends that ICANN begin disclosing publicly the following (notwithstanding any contractual confidentiality provisions) on at least a yearly (but no more than quarterly) basis with regard to expenditures over $20,000 per year devoted to "political activities",8 both in the U.S. and abroad:

8.2.1.1 All expenditures on an itemized basis by ICANN both for outside contractors and internal personnel.

8.2.1.2 All identities of those engaging in such activities, both internal and external, on behalf of ICANN.

8.2.1.3 The type(s) of engagement used for such activities.

8.2.1.4 To whom the engagement and supporting materials are targeted.

8.2.1.5 The topic(s) discussed (with relative specificity).

This recommendation was overtaken by the implementation guidance provided by the CCWG-Accountability in Annex 9 of its Final Report.

CCWG-Accountability Implementation Guidance: Note - This recommendation needs to be consistent with DIDP exceptions, specifically the exception which states:

Information provided by or to a government or international organization, or any form of recitation of such information, in the expectation that the information will be kept confidential and/or would or likely would materially prejudice ICANN's relationship with that party (note - the WS2 Transparency recommendations for DIDP did not mention or modify this exception which is currently included in the DIDP and as such it would be expected to stand).

The above discussion of DIDP policies is by way of explanation, and does not expand the application of this policy.

Overall one must recognize that ICANN is a critical actor in the DNS and has significant expertise in the area. ICANN's corporate objectives include a number of activities and programs to share this expertise with all interested parties including governments.

As such any activities where ICANN is presenting information which is publicly available or which is part of formally published ICANN position on a subject through training programs, conferences or individual meetings should not be required to be disclosed beyond the reports which are currently published by ICANN and reports regarding bilateral conversations with governments.

Note: Reporting on bilateral conversations can be found in the ICANN Quarterly Reports. Additional information on specifics of these reports can be requested via the DIDP subject to the stated exceptions. An example of such a report can be found at https://www.icann.org/en/system/files/files/quarterly-report-08may18- en.pdf page 29.

To further facilitate the community's understanding of ICANN's objectives in discussions with governments it should publish an annual Government Engagement Strategy which should describe the focus of its interactions with governments for the coming year. This document should be derived from existing documentation including but not limited to annual planning, CEO reports to the Board and correspondence with the GAC.

Complete. Completed in 2020. See implementation documentation.

8.3 Transparency of Board Deliberations

8.3.1 (Implementation Guidance)

The DIDP exception for deliberative processes should not apply to any factual information, technical reports, or reports on the performance or effectiveness of a particular body or strategy, as well as any guideline or reasons for a decision which has already been taken or where the material has already been disclosed to a third party.

This recommendation was overtaken by the implementation guidance provided by the CCWG-Accountability in Annex 9 of its Final Report.

CCWG-Accountability Implementation Guidance: For the sake of greater clarity, current publications of Board Briefing Materials appear to fulfil this requirement

Note: As ICANN organization points out, documents/information already provided to a third party (without obligation to keep as confidential) should not be withheld simply because of a deliberative process exception.

Complete. See implementation documentation.

8.3.2 (Implementation Guidance)

The Bylaws should be revised so that material may only be removed from the minutes of Board meetings where it would be subject to a DIDP exception. Decisions to remove material from the minutes of Board meetings should be subject to IRP appeal.

This recommendation was overtaken by the implementation guidance provided by the CCWG-Accountability in Annex 9 of its Final Report.

CCWG-Accountability Implementation Guidance: The basis for redaction of Board minutes and withholding information from a DIDP request should be substantially consistent. For the most part this would seem to be the case including if the CCWG-Accountability recommendations which apply to the DIDP are implemented. As such ICANN should publish a register of all redaction of Board minutes explaining the basis for the redaction. Additionally, the register should explain how the basis for this redaction aligns with the DIDP exceptions and if it does not align with such an exception explain why.

Note: Re IRP appeal – this is currently in the Bylaws

Complete. Completed in Q4 2019. See implementation documentation.

8.3.3 (Implementation Guidance)

Where material is removed from the minutes of Board meetings, the default should be to allow for its release after a particular period of time, once the potential for harm has dissipated.

This recommendation was overtaken by the implementation guidance provided by the CCWG-Accountability in Annex 9 of its Final Report.

CCWG-Accountability Implementation Guidance: When redacting any information, the Board should identify if the redacted information can eventually be released or not (ICANN should publish the list of the classes of information which can never be disclosed by law, or other reasons, such as staff employment matters etc.). If redacted information is identified as eventually being subject to release it should identify the conditions which would allow the release (this information should be included in the above-mentioned Register). The CEO (or his/her designee) would annually review redacted information which is noted as being conditionally subject to release to see if the conditions for release are met and shall release all appropriate information and update the Register accordingly. For all redactions (other than those that are part of a category that can never be disclosed), the redacted material should be disclosed during the annual Register review process in the 15th year after the redaction was first entered onto the Register.

In progress. Targeted completion date: Q4 2023.

8.4 Improving ICANN's Anonymous Hotline (Whistleblower Protection)

8.4.1

The policy should be clearly posted as "Employee Hotline Policy and Procedures" on the ICANN public website under the "Who we Are" or "Accountability and Transparency" portions as soon as possible.

Complete. Completed in Q4 2021. See implementation documentation.

8.4.2

Related to the above, the term "whistleblower" should be included in introductory text explaining the policy so that an ICANN community member – who may not know that the policy is called a "Hotline Policy" – may easily locate it using "whistleblower" as the search term. For example: "The following outlines elements of ICANN's Hotline Policy and Procedures. Some organizations refer to this as "whistleblower protections."

Complete. Completed in Q4 2021. See implementation documentation.

8.4.3

The definition of incidents reported should be broadened from "serious issues" to encourage the report of all issues and concerns related to behavior that may violate local laws and conflict with organizational standards of behavior. Furthermore, the policy should provide specific examples of such violations to guide a potential reporter.

Complete. Completed in Q4 2021. See implementation documentation.

8.4.4

ICANN need to improve internal administration of the Hotline process by employing case management software to better enable tracking, documenting, reporting, and anticipating potential problem areas.

Complete. See implementation documentation.

8.4.5

ICANN should regularly provide employees with data about use of the Hotline, that details not only the frequency of use but also the types of incidents reported.

Complete. Completed in Q1 2022. See implementation documentation.

8.4.6

ICANN should not prioritize receipt of reports as "urgent" and "non-urgent," but treat every report as a priority warranting formal acknowledgment of receipt of a report within 48 hours at the latest.

Complete. Completed in Q2 2022. See implementation documentation.

8.4.7

ICANN needs to more effectively address potential fear of retaliation against the reporter by stating unequivocally that alleged retaliation will be investigated with the same level of rigor as alleged wrongdoing. ICANN should also guarantee remedy for reporters who suffer from retaliation as well as clarify that good-faith reporting of suspected wrong-doing will be protected from liability.

Complete. Completed in Q4 2020. See implementation documentation.

8.4.8

ICANN's Hotline Policy and Procedures should undergo a third-party audit least every two years to help identify gaps and enable timely corrections. The audit, in turn, should be posted on the public website.

In progress. Targeted completion date: Q1 2024.

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