Documentary Information Disclosure Policy

Documentary Information Disclosure Policy (DIDP) is intended to ensure that ICANN makes available to the public information contained in documents concerning ICANN's operations and within ICANN's possession, custody, or control unless there is a compelling reason for confidentiality.

Overview

The DIDP is a fundamental component of ICANN's efforts at fulfilling its commitment to transparency. Anyone can request information by emailing ICANN at didp [@] icann.org. ICANN will respond to the request within 30 calendar days. ICANN will inform the requester in writing as to when a response will be provided if the organization cannot respond within the first month and explain why the extension is necessary. If ICANN denies the information request, it will provide a written statement identifying the reasons for the denial. If requestors want to appeal their decision, they can file a Reconsideration request. ICANN posts all requests and responses on its website.

DIDP Process

1. Upon receipt of a DIDP Request, an ICANN staffer reviews the request and identifies the information requested, who may be in possession of or have knowledge of the information.
2. The ICANN staffer then interviews the relevant staff members and performs a document search.
3. The ICANN staffer collects the documents and reviews whether they answer the questions asked in the request and/or are subject to the Defined Conditions for Nondisclosure.
4. If the document falls under any of the Defined Conditions for Nondisclosure, a review is conducted as to whether the public interest in disclosing the documentary information outweighs the harm that may be caused by such disclosure.
5. Documents that are responsive and appropriate for public disclosure are posted on ICANN’s website. If ICANN deems a document's disclosure to be premature, ICANN will indicate it in its response to the request and notify the requestor when the document is posted.
6. The ICANN staffer prepares an email response to the DIDP Request and posts the request and response and Request to the DIDP page.

Defined Conditions for Nondisclosure

ICANN does not disclose documentary information that is:

1. from a government or international organization if it would prejudice ICANN's relationship with that party.
2. internal and would compromise ICANN's deliberative decision-making process by inhibiting communication with ICANN Board directors, advisors, staff, consultants, contractors, or agents.
3. prepared for exchange between ICANN, its constituents, and/or other entities with which ICANN cooperates that would compromise the decision-making process between them
4. personnel, medical, contractual, remuneration, or similar records or internal appeals mechanisms and investigations that would constitute an invasion of personal privacy
5. provided to ICANN that would materially prejudice the party's commercial, financial, and/or competitive interests or is pursuant to a nondisclosure agreement
6. confidential business information and/or internal policies and procedures
7. likely to endanger the life, health, or safety of any individual or materially prejudice the administration of justice
8. subject to attorney-client privilege, or any other applicable privilege
9. a draft of correspondence, reports, documents, agreements, contracts, emails, or any other form of communication
10. related 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.
11. a trade secret or commercial/financial information not publicly disclosed by ICANN
12. in response to an unreasonable, overly burdensome, unfeasible, or abusive/vexatious request

These twelve situations are referred to in DIDP policy documents and responses as Defined Conditions for Nondisclosure.

Other Rationales for Negative Responses to Requests

ICANN's DIDP policy specifies that "ICANN shall not be required to create or compile summaries of any documented information, and shall not be required to respond to requests seeking information that is already publicly available." In many responses to DIDP requests, ICANN often cites this section in responding to elements of the request.

History

From 2007 to 2008, ICANN developed the DIDP after community consultation as part of its Accountability and Transparency Frameworks and Principles. The first use of the DIDP was in September 2008, by Danny Younger, who requested information about a couple of registrar accreditation applications submitted to ICANN.

In 2012, ICANN updated the policy following another community consultation.

In December 2021, ICANN proposed several changes to the DIDP based on the Cross Community Working Group on Enhancing ICANN Accountability Work Stream 2 recommendations.

Criticism

• As part of the Public Comment proceedings for ICANN's proposed revisions to its current DIDP,

• The Registries Stakeholder Group noted that the conditions for nondisclosure would be broader; advised that any additional DIDP roles for the Ombudsman should not remove or replace the Reconsideration Request process; requested clarification on community members', and the Ombuds' resultant, procedures for appealing to DIDP responses; and recommended that the Complaint’s Officer should be the home for additional review of DIDP Responses.
• ALAC expressed concern that the changes would grant "ICANN the right to refuse any and all requests." It warned that ICANN should not use DIDP to "cover up its errors or poor judgement." Finally, the committee submission recommended that ICANN:
  1. Allow Ombuds to oversee the mechanism for requestor review of ICANN DIDP responses;
  2. Document in DIDP Policy recourse when DIDP is not fully satisfied; and
  3. Revise the new language on conditions for nondisclosure.
• Kevin Murphy summarized various community members' and collectives' critiques as accusing ICANN of "shirk its transparency obligations" by granting greater ability to deny requests without any explanation.

• Dr. Sarah Clayton argues that the 12 defined conditions of non-disclosure (DCND) "essentially provide an administrative loophole for ICANN to restrict the free flow of information." Furthermore, her statistical p* models demonstrate that
  1. ICANN Organization considers lengthier submissions to be more likely to request contentious information and are more likely to apply DCND to them
  2. ICANN Stakeholder Groups/Working Groups are more likely to receive DCND in every condition category, except the "Affects Individual" condition
  3. "Burdensome conditions" are rarely imposed on law firms, which tend to request precise information about a specific case
  4. Registrants are less likely to receive ICANN "Integrity" conditions as they are more concerned about their own domain name registrations than about ICANN
  5. "Confidential External Business Information" conditions are less likely to be imposed on internet non-profits, as they are more interested in ICANN’s interface with Internet Governance than third-party business interests.
• Indian stakeholders have cited difficulties in accessing documents under DIDP and asked for greater transparency.
  • Padmini Baruah, of The Centre for Internet and Society, explains that ICANN deflects most requests for information, using clauses about internal processes, stakeholder discussions, protecting financial interests of third parties (cited in over 50% of the responses up to 2016) to avoid disclosing its Contractual Compliance audits and reports of abuse to registrars. Baruah's complaint is that because ICANN regulates a global public good, it should be far more open.