ICANN Ombudsman Blog Creating Dialogue Affirming Fairness

October 27, 2013

Compliance Complaint Investigation Report

Filed under: Uncategorized — Chris LaHatte @ 5:58 pm

Office of the Ombudsman

Case 13-00098

In a matter of a Complaint by Garth Bruen and others

Report dated    28 October 2013

Introduction

This investigation began initially as a complaint from Garth Bruen, but has been expanded by a collective approach from at least 173 other complainants, coordinated by Garth Bruen. The complaints are essentially an attack on the way in which the Compliance Department of ICANN operates, and seek a full investigation into the performance of Compliance. I should add that one complainant objected to the word “attack” and asked that this be removed, because he did not want to use such a term. He is of course anonymous, but I record that at least he did feel this was a constructive criticism. The complainants allege that Compliance is not being run properly and that this has resulted in registrars not be held to the terms of the Registrars Accreditation Agreement, which they then allege causes or permits spam and phishing and rogue domain holders to operate freely.

Facts

At the heart of the issue is a complaint formulated by Mr. Bruen which was shared with a number of groups  resulting in a large number of filings of complaints on the same issues. These have come from a number of places, and I cite some of the wording from various sites and from the complaints. The extracts illustrate the difficulty in resolving matters which are factual, from rhetorical statements of position.

Linkedin complaints

“1. The records for the domains were forged

2. We used the official process for reporting them

3. The registrar did not enforce

4. The domain remained online

5. ICANN did not enforce the contract

5. ICANN refused to explain why

6. Employees who asked about it were fired

7. The public trust is broken”

“What do we want out of this? Not just an investigation, we want results and improvement. To be clear, we want a public accounting of what happened to your complaints and why certain employees were fired or retaliated against. However, on a grander scale we want a system which actually addresses the problems plaguing the Internet. Despite claims that “ICANN does not have any power to prevent unsolicited email” they actually have the power to cut down on significant amounts abuse by properly enforcing the contract and collecting statistics on abusive – things which they have refused to do so far.”

 

A typical extract says

 

“The domains cited were registered with false WHOIS which violates the registrant agreement and used in abuse directed at me. While proper complaints were filed and the domains remained in violation ICANN did not issue enforcement actions against the cited registrars”

 

And more-

 

“I am requesting a full and open investigation of the handling of the listed complaints by ICANN staff to be conducted by an impartial outside party. This review should also include a review of the way ICANN handled staff involved in the investigation of the complaints as I have heard reports of intimidation and unfair treatment. As a continuous recipient of Internet abuse I would like to see a compliance system put in place which is truly transparent and accountable. Part of this should be 1) a simple, user-friendly process which accepts abuse reports from the Internet user at-large without the expectation that those users will understand the complexities of ICANN policy, 2) an ongoing analysis of abuses of the Domain Name System and their impact regardless of direct contractual authority of ICANN in those abuses, 3) a quarterly review of compliance activities to be conducted by non-contracted members of the Internet community, and 4) a proactive plan to reduce abuses of the Domain Name System through effective use of ICANN policy.”

And more recently from a blog at CircleID by Garth Bruen at http://www.circleid.com/posts/20130924_icann_and_your_internet_abuse/

 

“KnujOn has published a report which demonstrates that ICANN Compliance appears to completely collapse between September 2012 and December 2012. Following December 2012, ICANN seems to stop responding to or processing any complaints. It is around this time certain compliance employees start disappearing. This was not limited to the Sydney office as some would have us believe, all while we have been given assurances the compliance team was being ramped up not down. The accepted budget has 20 Compliance staffers listed but in reality there are only 14 employees with another ubiquitous staff member vanished from the roster. Six phantom employees is a lot.”

 

“The focus of my complaint is not that spam is being sent subsequent to legitimate information being provided in WHOIS details, but instead that where false information has been provided, there are many examples of where nothing has been done about it when highlighted in complaints. It is simply not good enough for compliance to start flapping a broken wing at us by declaring they cannot control spam. We are not asking them to. We are simply asking them to carry out the work they have been hired to do. Most of us accept that registrars have no control over spam; that is a no-brainer. The complaint from my perspective has always been about a failure by those responsible for compliance to execute their duties effectively when complaints of non-compliance are made. It is also about what I perceive to be the arbitrary, ineffective, and arrogant manner in which they have handled some documented complaints of non-compliance.

 

I find it puzzling that ICANN execs appear to feel that they have a right to decide what parts of their jobs they do and do not execute. It further appears to me that, like many administrators who either cannot or will not solve the problems they should be solving, ICANN execs have begun to invent new problems they assert demand their attention more, as they appear to think this justifies them not carrying out the matters being raised in this complaint. Whenever executives start telling us that we need to “move on” and look to the “new challenges” facing an industry, I am always suspicious about what is not being done that should be done.”

 

As well as the material given to me by the complainants, to enable me to get a balance of the position, I have also been provided with material from Compliance, and of course read material accessible on the ICANN website.  See this site for example at http://www.icann.org/en/resources/compliance. It is important to note some substantial changes which have been introduced over the relevant period of this complaint and I quote as follows.

“ICANN Contractual Complaince Audit Program

On Monday, 26 November 2012, ICANN launched the Contractual Compliance Audit Program. This program will run on a three-year cycle during which each registry and registrar agreement will be randomly selected for audit. Contractual Compliance, working with KPMG as the contracted vendor, issued 323 Requests for Information (RFI) via email and fax to 317 Registrars and 6 TLDs. This is a major effort for ICANN and for contractual compliance as we seek to validate the contractual obligations per the RAA and Registry Agreement. More information can be found at https://www.icann.org/en/resources/compliance/audits. Contractual Compliance has released the first phase of the new consolidated complaint management system. The phased rollout improves both the user experience and the compliance operations by:

– Moving complaint submission from Internic.net to ICANN.ORG under Compliance

– Adding site navigation based on complaint types and FAQs

– Improving email correspondence to the complaint reporter and the Registrar/Registry

– Adding a follow-up Continuous Improvement Pulse Survey for the reporter and contracted parties

– Whois Inaccuracy is the first complaint type to migrate to the new application

– 1st step in consolidating the three complaint tools and different email complaints into one source”

There have also been very substantial changes in the way in which the website describes the compliance function, and new compliance complaint entry pages.

I am unsure whether the complainants have read the relevant pages on the Compliance pages of the ICANN site. The Compliance Operating plan for example, at http://www.icann.org/en/resources/compliance/operating-plan has a number of bullet points which are relevant in the questions raised by the complainants. The first which says “work constructively with registrars and registries to foster a culture of compliance”, has a philosophy of working with people to ensure compliance goals are met. While the plan does prioritise informal resolution if possible, it does state that non-compliance will be pursued aggressively. It is also relevant in this context to look at the audit program, which is on this page http://www.icann.org/en/resources/compliance/audits and which describes how Compliance are using a three-year audit cycle, with a goal of enabling ICANN to first identify and frame and then properly manage and help remediate deficiencies.

In these specific areas which have attracted most of the attention from Compliance critics, the pages contain detailed information about WHOIS complaints and enable users to lodge a ticket using a number of different complaint forms for various problems.

Jurisdiction

This is a matter where I clearly have jurisdiction because it falls under the issue of delay or unfairness within ICANN.

However I should also mention a specific concern about the late lodging of the complaint. I acknowledge that the initial complaint from Garth Bruen came in to my office in March 2013. But the specific matters he complains about occurred in 2012. The subsequent complaints, which are in reality the same issues, have come in over a period of time from early August to mid September 2013. It is not a strict pre-requisite or procedural requirement but the Ombudsman Framework adopted in 2009 does state that normally complaints will not be accepted for matters older than 60 days. The reason for such a time limit is the speed with which matters typically progress at ICANN.

In the balance, if there are over 173 people who have gone to the trouble of making a complaint, even if the issues are based on events from 2012, it would be wrong not to carefully consider what they have submitted.

Investigation

To undertake this investigation I have read a considerable amount of material sourced from Compliance, all of which is available to the public, on this section of the ICANN website at http://www.icann.org/en/resources/compliance/reports and at http://www.icann.org/en/resources/compliance/operating-plan. In particular I have read the presentations from Compliance presented from ICANN 42 at Dakar to ICANN 47 at Durban. I have also read the attachments which have been provided by the individual complainants, and their emails. A number of the complainants went to some trouble to explain that their own experience was unique and I acknowledge that their interaction with spamming and phishing does of course differ. In the course of this investigation I have had the opportunity to discuss this matter with a number of members of the Compliance team, and also with some registrars so that I could get a perspective of the relationship between registrars and Compliance. The individual complainants are of course only one part of the picture. The relationship between registrars and Compliance is also significant and important in discussing the allegations which have been made. During my discussions with the registrars I was told that complaints had been made about domains which they administered, but which had no validity at all. I have seen such a complaint provided by one of the registrars by Knujon, which makes it clear that the information is not only inaccurate but out of date.

It is a theme of the complaints in fact, that the information is largely out of date. Virtually all of it goes back to 2012.

It is critical in understanding this complaint to outline the role of the Registrars Accreditation Agreement in the various editions. This agreement is at the very core of the function ICANN was created to administer. ICANN established market competition for generic domain name registrations, and did so by adopting policy and then developing specific contracts with the registrars which have been refined to the most recent 2013 edition, which is gradually extending to all registrars. Such contracts have been developed through a vigorous policy development process and considerable debate and negotiation between ICANN and the registrars. Registrars must maintain a registration agreement which must include certain terms in Section 3.7.7 of the RAA and related consensus policies (such as the UDRP). It is important to understand the role of Compliance in the administration of the contracts. This is expressed on the ICANN website as “The overall goal of the Contractual Compliance Program is to ensure that ICANN’s contracted parties fulfill the requirements set forth in their agreements with ICANN.” For the purpose of this complaint it is therefore critical to understand where the obligations as alleged by the complainants are set out in the agreement. Because the complaints are historical, it is not necessary to consider the new 2013 version. However the Compliance Program is set out in full at this site http://www.icann.org/en/resources/compliance/registrar

A common theme through the complaints and from the original complaint relates to the WHOIS obligation, and the role of Compliance in ensuring that accredited registrars comply with their obligations. The complainants say that the failure to rigorously enforce the obligations has permitted spam and phishing, and made it difficult to enforce removal of such sites because the WHOIS information is not up-to-date. Garth Bruen goes to some pains to explain the commercial services which his company provides which are designed to cope with spam, phishing and other dubious sites.

Spam and website content have always been outside of the scope and authority of ICANN. After all, every ICANN staff member is issued with appropriate software to deal with spam and phishing and blocking inappropriate emails. If it were possible to control such problems, then obviously ICANN is as interested as any other Internet user in reducing the time wasted. ICANN cannot do anything about website content or spam, as it is outside of the RAA. However I was also told by Compliance that Internet users often make Whois inaccuracy complaints about spam domains without any evidence. There is a section of the RAA that states that registrars must abide by applicable laws, but ICANN practice is to interpret this to mean a final judgment from a court of competent jurisdiction rather than allegations.  Because laws vary by country, so does “what is illegal”.

So the real issue in this complaint is whether any alleged failure on the part of Compliance to enforce the terms of the Registrars Accreditation Agreement has contributed to the complainants getting unwanted spam and phishing and other unwanted email. None of the complaints on this issue refer to any attempt to use the ticketing system which has an elaborate multi-language set of options for lodging complaints about WHOIS accuracy. In addition, I have seen discussions, emails and memoranda which refer to the way in which bulk complaints are handled. Compliance has explained to me that the system for dealing with bulk complaints has been revamped and improved, and comments have been sought. There certainly has been some discussion, but I have not seen any criticism of the improved systems, which in my view appears to coincide with the very substantial improvements  introduced in 2012/2013.

I have had discussions with various registrars, from small to large. They were very willing to discuss their relationship with Compliance, and several were frank about the fact that they have quite an active relationship. The larger registrars in particular must deal with substantial numbers of compliance issues, and typically have a team of people who deal with Compliance, as well as law enforcement and other aspects. A common theme of the discussions is that compliance has matured over the last few years, the process is getting better and communication has improved. They mentioned that there are often quite vigorous discussions and debates, not just about specific issues but also about policy. One registrar commented that compliance is a very specific process, and Compliance must comply with policy. If there are complaints about policy as to Compliance, then this is a matter for a PDP process because otherwise they are outside the remit of Compliance.

Another comment was that it is in the registrars’ best interests to have compliance working efficiently, because the registrar business model relies upon the compliance complaint program.

I also mention one registrar in particular which has been openly criticised, being Bizcn.com. As part of the monitoring by Compliance, scorecards of requests are kept. Compliance informed me that Bizcn.com is a registrar that is prompt & cooperative with Compliance inquiries, including Whois inaccuracy complaints.  I was shown the scorecard, of all complaints since January 2013, which shows that all were resolved before a 3rd notice was needed.

 

Reasoning

The age of the complaints means that the transition from the previous Registrars Accreditation Agreement to the new 2013 version has largely overtaken the issues raised by the complainants. The principal complainant and the supporters in the group have not discussed the effect of these changes at all. There is no doubt that spam and phishing are an ongoing problem. However my investigations and discussions with compliance and with the registrars make it plain that there is an active and ongoing program to ensure that the old and new Registrars Accreditation Agreements are adhered to.

However it is important to note the new Whois requirements in the 2013 RAA, the new agreement says that for the Whois Accuracy Program Specification, registrar must within 15 days:

  • Validate the information identified in section 1 (e.g. Email, phone, postal address)
  • Verify the email address or phone number (by calling or sending SMS)
  • If verification fails, the registrar can verify manually or suspend the domain. This is mandatory, and must also occur when the information is changed

It is worth noting that in the Whois Accuracy Specification that for willful provision of inaccurate Whois information, the registrar must suspend or terminate a domain for failure to update or respond to inquiries within 15 days.

  • Registration Data Directory Service (Whois) Specification: registrars must include an abuse email and telephone number in the Whois output
  • Whois Accuracy Spec and Whois Spec are effective 1 January 2014 for registrars that are on the 2013 RAA.

Part of the problem with the complaint is that it does not correctly identify the test which applied for the older version. The complainant has asserted that the registrant must provide verifiable information. In fact the agreement provides for reliable information, which is substantially different. The RAA says at 3.7.7.1

“The Registered Name Holder shall provide to Registrar accurate and reliable contact details and promptly correct and update them during the term of the Registered Name registration, including: the full name, postal address, e-mail address, voice telephone number, and fax number if available of the Registered Name Holder; name of authorized person for contact purposes in the case of an Registered Name Holder that is an organization, association, or corporation; and the data elements listed in Subsections 3.3.1.2, 3.3.1.7 and 3.3.1.8.”

This is not the same as verifiable.

The complainants also assert that the registrar must enforce registrant violations. But again the test is in fact that the registrar must take reasonable steps to investigate and correct incorrect information. This is significant because there is a substantial change brought in under the new agreement, where there is a 15 day takedown period. So the problem is that the complainants have overstated the duties of the registrar, the registrant and the role of compliance in this matrix. But in any event the new agreement effectively resolves many of these issues. The older agreement in fact refers to this in RAA 3.7.8 providing that:

“Registrar shall, upon notification by any person of an inaccuracy in the contact information associated with a Registered Name sponsored by Registrar, take reasonable steps to investigate that claimed inaccuracy. In the event Registrar learns of inaccurate contact information associated with a Registered Name it sponsors, it shall take reasonable steps to correct that inaccuracy.”

It is important to remember that these policies were developed by ICANN Consensus Policy, with extensive negotiation between the affected parties. One of the features of a consensus policy is that it may not satisfy every party, but in this case, the complainants had not correctly identified the test which applies. They may prefer to have a more difficult standard, and the 2013 agreement certainly reflects the policy development of stricter standards. But at the relevant time is of this complaint, the earlier agreement was in force and applied to the obligations of the registrar and registrant.

I was requested to look at a number of specific issues, including a list of “bad registrars” which was given to compliance at the Prague meeting. There were five registrars identified, but I am told that these registrars have all been most cooperative with compliance. One of them did have some issues which have been resolved with the assistance of compliance. There was full cooperation I am told.

This was done because someone commented “everyone knows who the bad registrars are,” but it was not clear to Compliance staff who the persons present were identifying.  Some of the reasons why registrars were classified as “bad” were outside of the scope of the RAA (e.g. Spam, malware, cybersquatting havens). One registrar identified on the “bad registrar” list was under Compliance review prior to the Prague meeting.  The registrar was found to be compliant with the RAA, but later independently made changes to its terms and conditions regarding “pharma” domains.

The complainant’s issue is that Compliance is not doing its job. This requires however a leap in their argument from the role of Compliance within ICANN, through to the ability to deal with the spam and phishing issue, which is mentioned by many of the complainants. This regrettably is a fundamental misunderstanding of the role of Compliance within ICANN.

A number of other aspects to the complaints also need to be answered. Many of the complainants referred to the number of staff at Compliance being inadequate, although it seems on my investigation that this was based on staff numbers in a draft budget. Draft budgets are not always what results once the final decisions are made. In the case of compliance this was the case, although it is also worth noting that compliance teams are being established at Istanbul and Singapore to extend global coverage. There has also been a criticism that staff members were fired for raising issues of inadequate compliance action, but on my investigation I have found that the staff members who actually did the work are still at ICANN. I am confident from my investigation  that this allegation is unsubstantiated.

Result

As a result of this investigation, I consider that there is no substance to the complaints.

 

Chris LaHatte

Ombudsman

 

October 2, 2013

Report on DIDP Disclosure

Filed under: Uncategorized — Chris LaHatte @ 6:01 pm

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 5th February 2013 by Mr. Bruen, and the reply from ICANN on 13th 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.

  1. 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.”

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

© 2016 Internet Corporation for Assigned Names and Numbers