Report on DIDP Disclosure

Office of the Ombudsman

Case 13-00284

In a matter of a Complaint by Garth Bruen

Report dated 3rd October 2013

Introduction

This investigation is about a DIDP request and response from ICANN. The acronym, DIDP means the  Documentary Information Disclosure Policy found at http://www.icann.org/en/about/transparency/didp. The policy states that “ICANN's Documentary Information Disclosure Policy (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.”

Facts

The essence of the complaint is a complaint in relation to a DIDP request made on 5^th February 2013 by Mr. Bruen, and the reply from ICANN on 13^th March 2013. The complaint was made to my office on the 5 September 2013, and challenges the rejection of the request.

Jurisdiction

The ICANN ombudsman has a specific function with regard to disclosure of documents and the openness and transparency requirements for ICANN. The ombudsman bylaw specifically gives the power to look at all documents, and requires ICANN staff and supporting structures to cooperate when the ombudsman requests information. It is probably the most substantial power held by the office. It is therefore logical, that a request in relation to the DIDP policy comes within the jurisdiction of the office. The appropriate oversight for DIDP requests and decisions must be with the ombudsman.

In considering jurisdiction, I also need to look at the Ombudsman Framework, which is part of the background within which I work. This states that complaints are not accepted if made more than 60 days from the act which gives rise to the complaint. There is no doubt that in this case, the complaint is outside of the recommended time period within the framework. However because this complaint is necessarily related to another current complaint, in relation to the operation of Compliance at ICANN, in my view, this complaint should be considered on the merits rather than excluded. When complaints include an element of suspicion as to the internal processes, the sunshine of an investigation, even if a little faded in time, is important to allay further suspicion.

In addition, when a DIDP request is rejected, the normal course is to take the matter to the BGC (Board Governance Committee). The DIDP policy refers to this. In this case no such reconsideration has been sought. Again however, the BGC has expressed that in such cases the ombudsman should have a role in any event, although perhaps normally after the BGC has considered the reconsideration request. It is noted that in this case therefore, the complaint has been effectively fast tracked to my office, but the usual procedure should normally be followed.

Issues

The issue which I am required to investigate are carefully outlined by Mr. Bruen and I cite them in full as follows.

This is a complaint about the denied response

(http://www.icann.org/en/about/transparency/bruen-response-07mar13-en.pdf)

to Documentary Information Disclosure Policy (DIDP) requests I submitted to ICANN as the response contains factual inaccuracies and arguments unrelated to my request (http://www.icann.org/en/about/transparency/bruen-request-05feb13-en.pdf).

My concern is that the DIDP was rejected for incorrect or unfounded reason and that the actual requested information should be made public. The specific issues are outlined below.

I will also provide all previous emails relating to these issues for reference separately.

1. [Non-Transparent Process] Because DDIP responses are not signed by any identifiable staff member, it is impossible to discern the quality of the source of any denial. It is not known If the author has any detailed understanding of the issue or the authority to answer or deny. Appeals of the decision apparently go through the same channel. The process and its functionaries are secret, which in effect means the very transparency process created by DIDP is neither transparent or accountable. I therefore question the basic validity of such a process.

2. [Disregard for unique nature of requests] The original DDIP requests were in 9 (nine) separate documents with unique details, but the ICANN response summarized them in one document, removing and obfuscating the original meaning. Therefore the unified response does not address the unique issues presented. Each request was submitted separately and ICANN did not seek my permission in “bundling” the requests. I therefore question the sincerity and accuracy of the response.

3. [Inapplicable citation (i)] ICANN rejected the various requests because disclosure would be “inhibiting the candid exchange of ideas and communications.” The DIDP requests concerned material covered by ICANN advisories (http://www.icann.org/en/news/announcements/advisory-10may02-en.htm &

http://www.icann.org/en/news/announcements/advisory-03apr03-en.htm) in reference to RAA requirements to take reasonable steps to correct WHOIS inaccuracies including contacting the registrant “… by all commercially practicable means available to the registrar: by telephone, e-mail, and postal mail.” There is no possibility of “inhibiting” communication since these matters are requirements of the contract and not a choice. I therefore submit that this is an inapplicable citation for denying the request.

4. [Inapplicable citation (ii)] ICANN rejected the various requests because disclosure would be “likely to materially prejudice the commercial interests…of such party.” If the registrar(s) in question followed the proper procedure there isno threat to their commercial interests whatsoever, conversely if the registrar(s) in question did not follow procedure the issue would be the subject of public notice through breach.

This is a simple matter of demonstrating that the registrar fulfilled its obligations and does not impede any business or expose any trade secret. I therefore submit that this is an inapplicable citation for denying the request.

5. [Inapplicable category] ICANN declined to release “the ticket logs” for the issues listed citing are they are “also subject to Defined Conditions for Nondisclosure”. The system logs for the ticketing system are not communication between ICANN and contracted parties or even communications between ICANN staff members. These are perfunctory system entries which aside from information which is already public, like the WDPRS ticket numbers and domain names, has times and dates of entries which are governed by the lifecycles defined in the RAA. The purpose of this request is to determine if entries were made in the time frames claimed and that the ticketing system performed as claimed. This can be done without revealing any confidential information and is merely a completely technical accounting which does not contain any material governed by non-disclosure. I therefore submit that this request is not deniable under the conditions of nondisclosure.

6. [Inaccurate claim] As part of the ICANN response the following justification as made as a cause for denial of disclosure:

“Notably, your history of communication with ICANN’s Contractual Compliance Department on these specific tickets has generated some internal communications as the Department prepares responses to the follow-‐up inquiries you have submitted that seek much of the same information sought within your DIDP Requests. The internal exchange of draft documents and reports that were ultimately submitted to you in response to those inquiries is not subject to disclosure under the DIDP pursuant to the conditions listed above. As the finalized responses (which appear to include reference to the tickets identified in your Requests) have already been provided to you, ICANN is not providing those documents to you with this DIDP Response.”

This is a completely inaccurate statement. While there was a collaborative exchange between myself and compliance staff for some time, this communication ceased when it became clear that compliance staff had not followed procedure or could not explain certain omissions and inconsistencies. Compliance staff indicated it would no longer answer further questions which was the motivation submitting the DIDP. The details requested in the DIDP requests are for items refused by Compliance. Most of the requests arose from follow-up answers from Compliance which created curious situations suggesting a general breakdown in process. The irony is that Compliance had already provided information technically covered by nondisclosure but only initiated nondisclosure protection when the details appeared to call Compliance activity into question. This situation appears to completely violate the Affirmation of Commitments in terms of Accountability and Transparency because the call for nondisclosure does not seek to protect any aspect of the DNS but rather to provide cover for ICANN Staff who may or may not have followed procedure. The initializing of nondisclosure here is not done in any public interest but instead for the apparent interest of an internal ICANN group. Moreover the claim that ” the finalized responses … have already been provided to you” and ” inquiries you have submitted that seek much of the same information sought within your DIDP Requests” are completely inaccurate and cannot provide any rationale for denying a request. I therefore submit that this is completely inappropriate statement and the DIDP should be revaluated without this potential prejudice.

7. [Illogical reasoning] ICANN also provides this statement as part of its rejection rationale:

“Further, the enhanced level of Contractual Compliance Department reporting that exists today demonstrates far greater transparency into the Department’s operations than ever before, which also mitigates against the value of releasing information regarding internal investigations of tickets submitted over 18 months ago.”

There are several problems with this statement. Once is there is no public evidence that the compliance process has improve whatsoever. The answer is in fact unknowable since “internal procedures” are subject to nondisclosure.

We in the community must take it on faith that there are improvements. The answer also seems to imply that the Compliance system did in fact fail, but this should be ignored because the situation has improved. Next, the idea that the author claims Compliance “demonstrates far greater transparency into the Department’s operations than ever before” while at the same time denying transparency is a logical fallacy. Finally, the statement that the details have no value because they are “18 months” old is outrageous. The age of the issues is completely attributable to delays within ICANN. The process of submitting requests and asking follow-up questions of Compliance staff was extensive. At first I communicated directly with Khalil Rasheed on these issues and developed good working relationship. As the investigations progressed Rasheed was inexplicably “removed” from the work and eventually became completely unreachable. Many of the documents and data submitted to Rasheed had to be resent to other staff. Compliance became less cooperative at this point and took longer and longer period of time to answer questions.

The “18 Months” can be explained in their entirety and should not be cited as rationale for dismissing the requests. I therefore submit that this reasoning should be excluded from the DIDP response and the request be re-evaluated on the remaining merits.

8. [Inaccurate answer to request] ICANN declined to produce the requested DNS records relating to certain tickets because the “zone file data is publicly available.” The request for DNS records in these DIDPs referred to the specific DNS changes cited by ICANN staff as the rationale for stating that the registrars in question had complied with the WDPRS process. ICANN's response to the DIDP refers to general zone file access from the registry and does not answer the question. If Compliance staff was able to determine that a registrar complied with the WDPRS process by checking the zone file to see if the domain had been removed – then this information should be easy to produce. In certain cases, available historical DNS records show that the domains in question were not truly removed from the zone or were removed temporarily and then replaced after. Since this information is not subject to nondisclosure ICANN staff should be able to produce this documentation. I therefore submit that this information should be produced in response to the DIDP”

Reasoning

In the course of this investigation I have considered material supplied to me by Mr Bruen, the DIDP policy, the request by Mr Bruen and response made by ICANN, and additional material supplied by Mr Bruen. I have also discussed the complaint with the Compliance and Legal teams at ICANN. I had previously considered issues in relation to the DIDP policy in the context of another complaint. This has been of some assistance.

The material which I have read, and the background information and the discussions have enabled me to look carefully at the merits of the eight issues outlined above.

I have therefore dealt with the eight issues, using the same numbering.

The first complaint which he raises is in relation to there being no identifiable staff member. He asserts that there is therefore no way to ascertain the quality of the source of any denial. He questions whether the author of the report has any understanding of the issue, and raises the same issue about a possible appeal. He asserts that the process and functionaries are secret. I specifically discussed the procedure with the Legal Team at ICANN, so I could gain some understanding of the way in which DIDP process is received, handled and resolved. Normally the legal team handle requests for DIDP, because it is essentially a legal issue whether documents should or should not be disclosed, within the constraints of the DIDP policy. I was advised that there is usually a team member who takes ownership of all such requests, but that a team is set up for each request to consider the merits of the request and the legal implications. The process is that the staff internally coordinate any response, discussion and review. There is consultation with the department who actually own the documents, and they are involved with, and consulted about, the decision on disclosure. When a decision has been made this is reviewed, and depending on the nature of the request, this is at a senior level. There is no particular need to identify the team who make the decision, but I am assured that the process is taken seriously and a rigorous examination of each request is made. Certainly as a result of my discussions, and my previous involvement with DIDP requests, it is clear to me that there is a careful approach and a team effort.

An additional point, further raised by Mr Bruen at the review stage, is that the people in the team making the decisions should be identified. The argument for this is that to be open and transparent, the individual staff should be identified. Staff details are shown on the ICANN website, but without direct contact details. And they can be approached at the ICANN meetings if they are present. But to identify the team is in my view unnecessary. Because the decision can be reviewed, I have the power to talk to the team, and did so in this case. Beyond that, exposes the staff to personal criticism and possibly some personal risk, when it is a team decision. The policy does state that-

“Personnel, medical, contractual, remuneration, and similar records relating to an individual's personal information, when the disclosure of such information would or likely would constitute an invasion of personal privacy, as well as proceedings of internal appeal mechanisms and investigations.”

The second complaint is that the response was one document, but a response to nine separate documents with unique details. While the details may have had some differences in each document, the issue as to disclosure is the same for each of the requests. Handling the requests individually would be a duplication of effort, for no added value in considering the request. It is common to deal with such requests as a consolidated reply, as can be seen from previous responses.

This was criticised on review, as trivialising the serious nature and detail of the requests. This has to be tested against reality. If the requests were very different, then this would be a valid criticism, but in fact they are very similar. In practical terms nothing is lost by dealing with them together, in this case.

Some disclosure was rejected because of the criteria in the DIDP policy in relation to “inhibiting the candid exchange of ideas and communications”. Garth has objected on the basis that these are contractual requirements and are therefore not a choice. However the range of discussions between compliance and registrars is from the informal and open, with issues such as problem solving right through to the extreme of formal notices of breach. Compliance inform me that the free exchange of ideas and opinions is critical to their work. However discussion of this outside of the direct relationship and disclosure to all would greatly inhibit such discussions. Ideas are often exchanged which have nothing to do with breach but are about improving the relationship and the service between ICANN and the registrars. The results of formal discussions, where there is a breach notice, are disclosed on the compliance website in any event.

The policy does state that “Information exchanged, prepared for, or derived from the deliberative and decision-making process between ICANN, its constituents, and/or other entities with which ICANN cooperates that, if disclosed, would or would be likely to compromise the integrity of the deliberative and decision-making process between and among ICANN, its constituents, and/or other entities with which ICANN cooperates by inhibiting the candid exchange of ideas and communications.”

In my opinion, this must obviously limit the information to the decisions, rather than the discussion and debate before a decision is made. An analogy could be drawn with discussions and debate made with a contract is negotiated. In legal terms, that discussion and debate is often inadmissible in interpreting the contract. The reason for that is clear. Free and open discussion is often vital to resolving problems, but having those exposed to public view would have an inhibitory effect and prejudice such negotiations.

A further criticism was made on review that the process of demonstrating compliance is made behind closed doors, and the process of assessing that a registrar is compliant is said to be a secret. A fully compliant registrar is likely to be appalled at the concept of having the negotiation and check of compliance openly available. A registrar who was not compliant, would have this demonstrated, if necessary, by a formal notice. The Compliance Department does report on its operations to the CEO and the board. Whether it is necessary for the ICANN community to be able to look at the internal decision-making process within the department is another matter. In my view, a line has to be drawn to enable the internal operations to proceed freely. The community is free to challenge policy on the operations, but the operational decisions fall within the executive function, rather than policy. The ability to look so closely runs the danger of micromanagement from outside. I have not therefore persuaded that such detail is necessary.

The fourth item relates to a rejection because disclosure would “likely to materially prejudice the commercial interests”. Again, because there is a considerable amount of discussion about many issues in relation to the agreement, and potential breaches being only a part of such discussions, there cannot be a blanket rule about such disclosure. The inhibiting effect of total disclosure of all matters which seriously prejudice any relationship with the registrars. Even potential breach action is commercially sensitive, and only notified at the formal stage. If a complaint were made about a registrar seeking breach action, but which was unjustified upon investigation by compliance, disclosure of the complaint and investigation could potentially be commercially devastating. It is unrealistic therefore to expect the level of disclosure and an appropriate criteria for refusal.

On review this was challenged as possibly leading to a “relationship with the registrars trumping ICANN’s commitments to the public”. But this is another way of seeking information, which I have dealt with under item 3 above.

The fifth item refers to a failure to disclose what is described as the ticket logs. The compliance complaint system involves a compilation of the complaint, the investigation, responses and the result. Effectively, what is being sought is sometimes referred to as the metadata. The purpose of the request is said to be to determine if entries were made in the timeframes claimed, and that the ticketing system performed as claimed. The extent of analysis required for a response to this, is well outside the scope of the DIDP policy. This policy is for provision of documents not about the information creation process.

On review this is criticised as meaning that it can never be demonstrated to the public that serious complaints are handled properly. This overlooks the perhaps obvious answer, that if a complaint is not handled properly, then there are a number of mechanisms for reviewing this. At least one of these is of course to complaint to the ombudsman, and of course such matters can be raised at the open forum at an ICANN meeting, or on one of the many blogs which often contain a vigorous and uninhibited criticism of ICANN. But it also overlooks the analysis and reports which are now prepared by Compliance, which are also posted on the ICANN website.

The sixth item criticises the failure to respond, where ICANN has already provided documents in the past. It is difficult to see the point in seeking DIDP disclosure of documents already provided. Mr Bruen criticises this by saying that he considers that the reason for nondisclosure was to provide cover for ICANN staff, who may or may not follow procedure. But the bottom line is, that if disclosure is sought in several requests, but is about the same information, then I cannot understand the point in repeating the disclosure.

On review this was criticised as being factually incorrect. It is correct that there have been a number of requests for disclosure. The more recent ones have sought the material identified above. But certainly the correspondence I have seen does appear to seek material already provided, albeit in a different context. But it does not make the decisions unfair.

The seventh item relates to the balancing required in considering whether or not documents should be released. Again going back too far in time, when problems are resolved, would directly interfere with the relationship between compliance and registrars. Mr. Bruen makes specific reference to a staff member and appears to consider that when he left ICANN, the information flow was reduced and that this somehow related to the refusal to release documents. I have asked about this issue, and has no bearing on the decisions.

The eighth item relates to a suggestion ICANN declined to produce DNS records and zone files. ICANN does not maintain the zone files but they are available as a matter of public record and so the request relates to material not held by ICANN.

This is criticised as not answering contradictions within DNS records. But certainly there can be no obligation to produce records not maintained by ICANN. If there are contradictions, then this can be raised.

In my opinion, there needs to be a clear distinction between disclosure of documents, and the great volume of exchanges of views, both informal and formal, which represent the wide range of relationships required between ICANN and the supporting bodies and the community. The DIDP policy has very clear guidelines on what should or should not be disclosed.

On review a general criticism is made that ICANN “has not even attempted, even in severely redacted form, any of the materials which will support their claim of an effect of compliance system”. This report is limited to a review of the DIDP decisions. It would go beyond the scope of this particular enquiry to delve into whether the compliance system was working.

Result

It is very important for an organisation like ICANN, to be accessible to the stakeholders and community. And I am grateful to Mr. Bruen for carefully considering the issue, and his complaint was quite properly brought to the office of the ombudsman. The fact that our community has vigilant members who feel free to address these concerns is very important. I should add that I have had full cooperation from ICANN staff in discussing these matters. The views have also been very helpful in explaining the application of the policy to the request. As a result of this investigation, I do consider the overall position is that Mr. Bruen differs in his views as to the meaning of the policy behind the DIDP process, which means that he does not accept the decisions. This does not make the decisions unfair. In essence this is about disclosure of documents, and not about the process itself. So I do not uphold his complaint, and therefore do not recommend that the documents he has sought be disclosed. I should add that if I believed his request had been incorrectly rejected, I would then have needed to consider the delay in making this complaint, the failure to make a complaint within the normal 60 days. There was a protracted discussion about the responses over an extended time. In the end, if his request had merit, I would not have insisted on the time period barring his complaint.

Chris LaHatte

Ombudsman