If the DIDP Did Its Job

Over the course of two years, the Centre for Internet and Society sent 28 requests to ICANN under its Documentary Information Disclosure Policy (DIDP). A part of ICANN’s accountability initiatives, DIDP is “intended to ensure that information contained in documents concerning ICANN's operational activities, and within ICANN's possession, custody, or control, is made available to the public unless there is a compelling reason for confidentiality.”

Through the DIDP, any member of the public can request information contained in documents from ICANN. We’ve written about the process here, here and here. As a civil society group that does research on internet governance related topics, CIS had a variety of questions for ICANN. The 28 DIDP requests we have sent cover a range of subjects: from revenue and financial information, to ICANN’s relationships with its contracted parties, its contractual compliance audits, harassment policies and the diversity of participants in its public forum. We have blogged about each DIDP request where we have summarized ICANN’s responses.

Here are the DIDP requests we sent in:

ICANN’s responses were analyzed and rated between 0-4 based on the amount of information disclosed. The reasons given for the lack of full disclosure were also studied.

ICANN has defined a set of preconditions under which they are not obligated to answer a request. These preconditions are generously used by ICANN to justify their lack of a comprehensive answer. The wording of the policy also allows ICANN to dodge answering a request if it doesn’t have the relevant documents already in its possession. The responses were also classified by the number of times a particular DIDP condition for non-disclosure was invoked. We will see why these weaken ICANN’s accountability initiatives.  

Of the 28 DIDP requests, only 14% were answered fully, without the use of the DIDP conditions of non-disclosure. Seven out of 28 or 40% of the DIDPs received a 0-rated answer which reflects extremely poorly on the DIDP mechanism itself. Of the 7 responses that received 0-rating, 4 were related to complaints and contractual compliance. We had asked for details on the complaints received by the ombudsman, details on contractual violations by Verisign and abuse contacts maintained by registrars for filing complaints. We received no relevant information.

We have earlier written about the extensive and broad nature of the 12 conditions of non-disclosure that ICANN uses. These conditions were used in 24 responses out of 28. ICANN was able to dodge from fully answering 85% of the DIDP requests that they got from CIS. This is alarming especially for an organization that claims to be fully transparent and accountable. The conditions for non-disclosure have been listed in this document and can be referred to while reading the following graph.

On reading the conditions for non-disclosure, it seems like ICANN can refuse to answer any DIDP request if it so wished. These exclusions are numerous, vaguely worded and contain among them a broad range of information that should legitimately be in the public domain: Correspondence, internal information, information related to ICANN’s relationship with governments, information derived from deliberations among ICANN constituents, information provided to ICANN by private parties and the kicker - information that would be too burdensome for ICANN to collect and disseminate.

As we can see from the graph, the most used condition under which ICANN can refuse to answer a DIDP request is F. Predictably, this is the most vaguely worded DIDP condition of the lot: “Confidential business information and/or internal policies and procedures.” It is up to ICANN to decide what information is confidential with no justification needed or provided for it. ICANN has used this condition 11 times in responding to our 28 requests.

It is also necessary to pay attention to condition L which allow ICANN to reject “Information requests: (i) which are not reasonable; (ii) which are excessive or overly burdensome; (iii) complying with which is not feasible; or (iv) are made with an abusive or vexatious purpose or by a vexatious or querulous individual.” This is perhaps the weakest point in the entire list due its subjective nature. Firstly, on whose standards must this information request be reasonable? If the point of a transparency mechanism is to make sure that information sought by the public is disseminated, should they be allowed to obfuscate information because it is too burdensome to collect? Even if this is fair given the time constraints of the DIDP mechanism, it must not be used as liberally as has been happening. The last sub point is perhaps the most subjective. If a staff member dislikes a particular requestor, this point would justify their refusal to answer a request regardless of its validity. This hardly seems fair or transparent. This condition has been used 9 times in our 28 requests.

Besides the DIDP non-disclosure conditions, ICANN also has an excuse built into the definition of DIDP. Since it is not obliged to create or summarize documents under the DIDP process, it can simply claim to not have the specific document we request and thus negate its responsibility to our request. This is what ICANN did with one of our requests for raw financial data. For our research, we required raw data from ICANN specifically with regard to its expenditure on staff and board members for their travel and attendance at meetings. As an organization that is answerable to multiple stakeholders including governments and the public, it is justified to expect that they have financial records of such items in a systematic manner. However, we were surprised to learn that ICANN does not in fact have these stored in a manner that they can send as attachments or publish. Instead they directed us to the audited financial reports which did little for our research. However, in response to our later request for granular data on revenue from domain names, ICANN explained that while they do not have such a document in their possession, they would create one. This distinction between the two requests seems arbitrary to us since we consider both to be important to public.

Nevertheless, there were some interesting outcomes from our experience filing DIDPs. We learnt that there has been no substantive work done to inculcate the NETmundial principles at ICANN, that ICANN has no idea which regional internet registry contributes the most to its budget, and that it does not store (or is not willing to reveal) any raw financial data. These outcomes do not contribute to a sense of confidence in the organization.

ICANN has an opportunity to reform this particular transparency mechanism at its Workstream 2 discussions. ICANN must make use of this opportunity to listen and work with people who have used the DIDP process in order to make it useful, effective and efficient. To that effect, we have some recommendations from our experience with the DIDP process.

That ICANN does not currently possess a particular document is not an excuse if it has the ability to create one. In its response to our questions on the IANA transition, ICANN indicated that it does not have the necessary documents as the multi stakeholder body that it set up is the one conducting the transition. This is somewhat justified. However, in response to our request for financial details, ICANN must not be able to give the excuse that it does not have a document in its possession. It and it alone has the ability to create the document and in response to a request from the public, it should.

ICANN must also revamp its conditions for non-disclosure and make it tighter. It must reduce the number of exclusions to its disclosure policy and make sure that the exclusion is not done arbitrarily. Specifically with respect to condition F, ICANN must clarify how information was classified as confidential and why that is different from everything else on the list of conditions.

Further, ICANN should not be able to use condition L to outright reject a DIDP request. Instead, there must be a way for the requester and ICANN to come to terms about the request. This could happen by an extension of the 1 month deadline, financial compensation by requester for any expenditure on ICANN’s part to answer the request or by a compromise between the requester and ICANN on the terms of the request. The sub point about requests made “by a vexatious or querulous individual” must be removed from condition L or at least be separated from the condition so that it is clear why the request for disclosure was denied.

ICANN should also set up a redressal mechanism specific to DIDP. While ICANN has the Reconsideration Requests process to rectify any wrongdoing on the part of staff or board members, this is not adequate to identify whether a DIDP was rejected on justifiable grounds. A separate mechanism that deals only with DIDP requests and wrongful use of the non-disclosure conditions would be helpful. According to the icann bylaws, in addition to Requests for Reconsideration, ICANN has also established an independent third party review of allegations against the board and/or staff members. A similar mechanism solely for reviewing whether ICANN’s refusal to answer a DIDP request is justified would be extremely useful.

A strong transparency mechanism must make sure that its objective are to provide answers, not to find ways to justify its lack of answers. With this in mind, we hope that the revamp of transparency mechanisms after workstream 2 discussions leads to a better DIDP process than we are used to.