Home / Blogs

Examples of Where ICANN Can Be More Accountable

During the “GNSO Discussion with the CEO” at the recent ICANN meeting in Durban, I stated that ICANN talks a lot about the importance of supporting the public interest, but in reality the organization’s first priority is protecting itself and therefore it avoids accountability and works very hard at transferring risks to others. In response to my comments, ICANN CEO Fadi Chehadé asked me to provide him examples of where ICANN can be more accountable. Copied below is my response letter to Chehadé, which provides six examples.

* * *

August 30, 2013

Fadi Chehadé
President and Chief Executive Officer
Internet Corporation for Assigned Names and Numbers
12025 Waterfront Drive, Suite 300?Los Angeles, CA 90094-2536

Re: GNSO Discussion with ICANN CEO

Dear Fadi:

As you will recall, we had an exchange during the GNSO discussion at the recent ICANN meeting in Durban. In that exchange, which is reprinted from ICANN’s transcript below, I indicated that ICANN was not holding itself accountable and that ICANN was elevating risk-avoidance over true accountability. In response, you asked me to send you a list of items that I felt displayed this behavior by ICANN. This letter contains a short list of such items that I have prepared in response to your request. By no means is this list intended to be exhaustive of the examples that could be identified to prove my point. Rather, this list is intended to be illustrative of the kind of unaccountable actions we have seen from ICANN in the recent past.

July 14, 2013 Exchange Between Chuck Gomes and ICANN CEO Fadi Chehadé

Gomes: . . . there is [sic] a lot of words given to the public interest and ICANN serving the public interest and partnership, etcetera. The one thing that it [sic] has continued in ICANN the corporation is that the number one priority is always protecting ICANN the corporation. That comes before public interest. That comes before partnerships. And in my opinion ICANN has never really been willing to step up very much at all in terms of assuming accountability for some of the things. The accountability is pushed down to contracted parties, to registrants, to everyone else except the corporation. And I’ve never seen any meaningful movement away from that. And in my opinion it would be very helpful if there was shared accountability and that takes lots of forms. So I point that out because that’s an area where I think if anything the corporation has even become worse at in the last year. Thank you.

Chehadé: I invite you to send me a list of the areas you think we can increase our accountability.

Examples of ICANN’s Unaccountable Actions as Requested by ICANN CEO Fadi Chehadé

1. One prominent example of ICANN’s unwillingness to be held accountable is with its agreements with registries and registrars. Whether it is a desire to minimize the number of resources devoted to contractual compliance, reduce the cycles to achieve policy completion or to increase the amount of control that ICANN has in this multi-stakeholder model, these agreements from the start have been slanted to ICANN’s favor and burdensome for applicants, registrars, and registries. All risks have been flowed down to registries and registrars with requirements to indemnify ICANN while removing any chance for the contracted parties to take action against ICANN, if warranted. This was compounded further in 2013 when the ICANN staff, in a surprise move, decided to impose the unilateral right to amend clauses in the new gTLD registry agreements. To this point of accountability, Verisign said at the time in a public comment the following:

In the current framework described in Section 7.6, ICANN cannot be held accountable because there is no mechanism to do so. ICANN refuses to allow any dispute about the “public interest” to be settled by a court of competent jurisdiction. Instead, ICANN is requiring arbitration lasting exactly one day. This response alone is telling: How could judicial review of a regulatory authority’s unilateral actions possibly be against the “public interest”? It is as if the community is being asked by ICANN to “wait and see” or to simply “trust us.” If judicial review does not fall within the “public interest” standard, it is reasonable to question ICANN’s perspective on, and analysis behind, what it may find to be in the “public interest.” Without defined criteria, accountability or consistency, how can the community that ICANN was created to serve rely on ICANN to reasonably determine what is in the “public interest?”

2. Since the Paris meeting in June of 2008, ICANN has extolled the benefits of new gTLDs to potential applicants, including brand owners. It was not until after applications were submitted in April 2012, and after hundreds of initial string evaluations had been conducted, that in August 2013 ICANN warned the world about possible SSR impacts that the SSAC had been communicating to ICANN and the ICANN Board of Directors through SSAC reports and advisories over the last four years. We view ICANN’s refusal to address the well documented SSR issues as indicative of its lack of accountability. No accountable organization would ignore the advice that ICANN has ignored for four years. If my Board of Directors did so in a similar fashion, the Board would be voted out, or sued, or both. Did ICANN consider the consequences of prioritizing the rollout of new gTLDs over security and stability for the betterment of the organization?

ICANN’s inattention to fundamental SSR issues is only one aspect of its accountability problem. We saw (and have now commented upon) ICANN’s proposal to mitigate the risks of name collisions and frankly, we are shocked at ICANN’s refusal to accept responsibility for the risks. Under ICANN’s proposal, all of the duties to preserve the stability and security of the DNS, as well as all of the risks and costs, are transferred by ICANN to applicants. One such risk is very clearly that ICANN’s proposal would almost certainly threaten the reputation of any brand applicant. Did ICANN consider that it is possible, if not likely, that reputational damage to a brand could result from that brand being required to warn users of harm caused by what is essentially a marketing campaign? Applicants would have to tell the global Internet services, businesses, and brand-loyal consumer communities that delegation of their brand TLD could break their networks and possibly result in the loss of confidential information and possibly enable cyber-attacks and other nefarious behavior. Does ICANN recognize, and will it be accountable for, prioritization of the new gTLD rollout over security and stability in a way that stands to hurt brands while enhancing the position of ICANN the organization over the community once again? To place this burden on applicants—with no community discussion, and no sensitivity to the potential reputational, legal, and other serious risks—is inconsiderate at best and most likely a calculated move to protect ICANN. This was precisely my point to you in Durban as reflected in the transcript above.

3. A third example is related to ICANN’s lack of accountability to its own multi-stakeholder processes. A clear recommendation from the Board-approved New gTLD PDP was that new strings should not be confusingly similar to existing gTLD, ccTLD, or other applied-for strings. In the implementation process of the new gTLD recommendations, the GNSO Council recommended that an exception process be designed to avoid false positives, i.e., cases where there might be visual string confusion but no actual user confusion. However, with vague rationale and minimal communication, ICANN staff refused to follow this advice. Specifically, in dealing with the issue of plural and singular strings, ICANN took a very liberal position that they are not confusingly similar and appear to have pushed this decision to the objection panels so as to not have to be accountable for terminating some future strings; it is quite likely that ICANN would not have had to do so if it had dealt with the exception procedure as recommended by its gTLD policy making body. ICANN has created the untenable situation today, where some plurals have been accepted and others have been rejected by these review teams. The question now is whether ICANN will accept responsibility and be held accountable for the situation created by its decisions.

4. Another example is ICANN staff’s recent tendency to issue top-down edicts that do not include community discussion while at the same time touting the virtues of the global multi-stakeholder model of Internet governance. It is a gross inconsistency to make such claims while operating in a top-down manner that does an end-run around the very multi-stakeholder processes from which it was founded. Change is fine, but change must arise from within the established governance model and not be driven by self-interested parties that are out of step with the consensus views. Reversing or ignoring decisions that arise within the multi-stakeholder processes by cherry-picking favorable public comments cannot be construed as a true implementation of the multi-stakeholder model. ICANN’s consideration and analysis of public comments too often reflects its own view and often provides mere lip service to views that are inconsistent with ICANN’s institutional preferences. ICANN is charged with resisting the tendency to merely act in its own self-interest. The public comment process is an important part of the multi-stakeholder process as it allows for discussion and suggestions from those not participating within the multiple constituencies and provides a last check to ensure that the process has gotten it right. A recent example of this relates to the previously mentioned process for making end-users aware of security issues pertaining to name collisions in the DNS. A hurried staff solution void of understanding of the unintended consequences and, where the proposed solution is so transparently in ICANN’s own best interest, is not consistent with the conduct of an accountable organization and is the opposite of a multi-stakeholder or consensus-driven process.

One of the key advantages of the multi-stakeholder model is to obtain broad input from representative stakeholders before making recommendations so that the public comments can be solicited on reasonably complete proposals. ICANN needs to be accountable to itself and to the community to uphold the multi-stakeholder process even when it is inconvenient for it to do so.

5. The establishment of the five strategic panels and the creation of “ICANN LABS” is another recent example of ICANN’s lack of accountability to the community and to the multi-stakeholder model. The purpose of these two efforts is to set the tone and direction for ICANN in the future apparently over the traditional consensus building process required by the AOC. A sustainable multi-stakeholder model is constituted by, and considerate of, the community at-large and yet these strategic initiatives are composed of ICANN-selected members and are managed by ICANN alone. We understand that $3.5 million has been allocated in the FY14 budget for the five strategic panels; I do not know how much is allocated for the Labs project. To this point, I am not aware of any discussion with the broader ICANN community on either of these efforts even though they will use significant portions of community-provided funds and could have a significant impact on ICANN future decisions and direction. It is certainly possible that these uncoordinated initiatives might have a positive impact but I am confident of one thing: The chances of them having a positive impact would have been increased if ICANN sought community input before initiating them. Both efforts are perfect examples of ICANN’s recent propensity to operate in an unaccountable top-down approach instead of ICANN’s traditional and mandated bottom-up fashion.

6. My final example relates to the posting of ICANN staff’s proposed Rights Protection Mechanism (RPM) requirements that took place on August 6. As mentioned above, ICANN staff simply ignored input from applicants who had been working with them for weeks and ICANN itself determined what the requirements should be. The group that had been initially working on this with ICANN suggested that their proposed revisions be integrated into the ICANN staff proposed requirements to ensure a fairer consideration of them. You will recall that a similar action happened with the 2013 Registrar Accreditation Agreement (RAA) and you promised that it would not happen again. Nevertheless, once again, the ICANN staff posted its own version of the proposed revisions excluding key elements. In my opinion that was, at best, inconsiderate of the multi-stakeholder model and of the working teams; in addition this action calls into question the motivation of the ICANN staff involved and the motives of its leadership. Those of us who had worked for weeks on this at least hoped that there would be an opportunity to obtain community input on our suggestions but only a small subset of them were included, and even those that were included were colored by ICANN staff commentary. Based on these recent actions, it appears as though the ICANN staff is taking advantage of the motivation by many to get their TLDs approved quickly and therefore is acting in an unaccountable manner inconsistent with the multi-stakeholder model.?

If the examples of ICANN’s unaccountable conduct noted above were minor or were infrequent, I would not be as concerned. Rather, the examples seem to represent the new standard operating policy for ICANN that, if anything, is getting more acute. I fully understand the ICANN Board’s fiduciary responsibility to protect the corporation but when this desire prevents ICANN from acting in the public interest, which is a paramount Board responsibility, then something is seriously askew. There needs to be balance when interests collide and there is very little if any balance now.

Sincerely,


Chuck Gomes
Vice President, Policy
VeriSign, Inc.

By Chuck Gomes, VP of Policy and Compliance, Naming and Directory Services at VeriSign

Filed Under

Comments

Comment Title:

  Notify me of follow-up comments

We encourage you to post comments and engage in discussions that advance this post through relevant opinion, anecdotes, links and data. If you see a comment that you believe is irrelevant or inappropriate, you can report it using the link at the end of each comment. Views expressed in the comments do not represent those of CircleID. For more information on our comment policy, see Codes of Conduct.

CircleID Newsletter The Weekly Wrap

More and more professionals are choosing to publish critical posts on CircleID from all corners of the Internet industry. If you find it hard to keep up daily, consider subscribing to our weekly digest. We will provide you a convenient summary report once a week sent directly to your inbox. It's a quick and easy read.

Related

Topics

Cybersecurity

Sponsored byVerisign

IPv4 Markets

Sponsored byIPv4.Global

DNS

Sponsored byDNIB.com

Domain Names

Sponsored byVerisign

Brand Protection

Sponsored byCSC

Threat Intelligence

Sponsored byWhoisXML API

New TLDs

Sponsored byRadix