Toll Free Industry News and Consulting - ICBTollFree.com

Find 800 number assistance

   


CONTENTS

Legend
F = Free - News and Features articles (see Registered Users below.)
P = Premium - Unlimited site access including contents listed under Additional Services for Premium Access Subscribers.
About ICB
 - Company Bio
 - Press: Articles, Quotes
   & News Releases
 - Privacy & Security
 - Site Map
 - Testimonials

Registered Users

News
 - Headlines
 - News Briefs
 - Reference Library

Features
 - .COM Miscellany
 - 1-800 Domain Names
 - 800 Miscellany
 - 800 Provider Directory
 - Ask the Expert
 - ICB Classifieds
 - Editorials
 - Industry Links
 - Search

Additional Services for Premium Access Subscribers

 - 888 Replication Specs
 - Behind the Scenes
 - Frost & Sullivan
 - Industry Insights
 - Law Library
 - Regulatory Room
 - Research Review

Contact Us
 - Advertising
 - Feedback/Questions
 - ICB Classifieds
 - ICB Consultancy
 - Reciprocal Links

Account Information

 - Change/Update Info
 - Account Activity
 - Subscribe/Upgrade
 - Renew Subscription

YOUR INTERNET GOVERNMENT [IN]ACTION

An Analysis of ICANN’s Reconsideration Policy

 

 

 

 

 

 

Three Years of Experience: A Report on
ICANN’s
Request for
Reconsideration”
Policy

 

 

 

by

 

Professor Ethan Katsh
Co-Director
 Center for Information Technology
and Dispute Resolution

University of Massachusetts at Amherst
katsh@legal.umass.edu

 

and

 

Dr. Alan Gaitenby
Assistant Director
Center for Information Technology
and Dispute Resolution

University of Massachusetts at Amherst
gaitenby@disputes.net

 

 

June 25, 2002

 

This report is being published by the Center for Information Technology at the University of Massachusetts.
Information about the Center is accessible at http://www.umass.edu/dispute
(voice) 413.545.5879

 

Please note: Readers should be aware that one of the co-authors of this report, Professor Katsh, was the petitioner in a recent request for reconsideration filed with ICANN <http://www.icann.org/committees/reconsideration/katsh-request-12apr02.htm>. Shortly before this report was to be released on June 24, 2002, Professor Katsh was notified that the Reconsideration Committee had ruled on his request and that it was being denied <http://www.icann.org/committees/reconsideration/rc02-4.htm>. We do not believe that the participation of one of us in the reconsideration process impairs our objectivity but we also believe that this is a fact we should acknowledge.

 


 

In March, 1999, the Internet Corporation for Assigned Names and Number (ICANN) adopted a Reconsideration Policy. The Policy states that “Any person affected by an action of the Internet Corporation for Assigned Names and Numbers ("ICANN") may request review or reconsideration of that action by the Board of Directors.” A Reconsideration Committee, composed of members of the ICANN Board, reviews the request and makes a recommendation to the Board as to whether or not to take the action requested.

 

This report looks at ICANN’s experience with the Request for Reconsideration process. While this process received relatively little attention during its first two years, questions have been raised about it recently. For example, in President Stuart Lynn’s February 2002 report ICANN – The Case for Reform” the claim is made that the reconsideration process is one “where precious staff and Board time have been devoted to what are often clearly frivolous requests.” In its most recent plan for reforming ICANN, the organization’s Committee on Evolution and Reform proposed several changes to the reconsideration process in order “to improve ICANN's structure and appeal processes to ensure fairness while limiting frivolous claims.”

 

Is there any basis for these conclusions about frivolous claims being brought? Has the process been underused or overused? Is the process likely to be an effective mechanism for enhancing trust and confidence in the manner in which ICANN carries out its responsibilities? All requests for reconsideration as well as ICANN’s responses are posted on the Web. We have, as a result, been able to examine both the nature of requests being made and the nature and timing of ICANN’s response to the requests. Our conclusion differs from the one presented by ICANN. If there are problems with the process, the problem is more with ICANN than with any users of the process. More specifically, our principal findings are as follows:

 

  • Thirty one requests for reconsideration have been filed. Excluding pending cases and other cases not pursued or available, ICANN responded to twenty six cases. Of these twenty six requests, only one was responded to favorably.

  • Petitioners requested stays in eleven of the twenty six requests. No stays were granted and only one was even acknowledged.

  • While the Reconsideration policy states that ICANN will attempt to respond within thirty days, that almost never happened. More disputes went unanswered for six months than were answered in one month.

  • Fifteen of the requests involved issues related to the selection of new top level domains (tlds). Most of the other eleven raised questions of significance to the ICANN community. There does not seem to be any basis for finding that the reconsideration process has suffered form frivolous complaints.

 

1. Number and nature of Reconsideration Requests 1999 - 2002

 

There have been thirty one requests for reconsideration filed since March 1999. One of these is currently pending, two were not fully pursued after the request was filed, one has been removed from the ICANN Web site in response to a request from the petitioner, and one, filed in March, 2000 was never responded to but also does not appear to be pending. The remaining twenty six fall into three categories. Ten involved requests from entities that had proposed new tlds in 2000 but were not selected by ICANN. Five more involved some issue related to the tld selection process. The remaining eleven involved a array of issues ranging from the UDRP, to various contracts involving ICANN in some way, to whether domain names could employ characters such as ? or ~ or a hyphen as the last character, to a Board action concerning the Independent Review Policy.

           

It is difficult to see which, if any, of the requests could be considered frivolous. There were several that were not filed within the thirty day period during which requests must be filed. There were also several that involved matters which ICANN may have had no authority to resolve. This does not mean, however, that the petitioners understood or agreed that ICANN had no authority. What is clear from the requests is that interesting issues were raised and that the drafting of almost all of the requests took considerable time and effort. The petitioners believed that they had been negatively affected by some action either made by ICANN or involving ICANN. They may have been wrong but they do not appear to be acting frivolously. In any event, the Reconsideration Policy itself states that “To protect against abuse of the reconsideration process, a request for reconsideration may be dismissed by the Reconsideration Committee where it is repetitive, frivolous, non-substantive, or otherwise abusive.” The simplest response for the Reconsideration Committee to any request it considered frivolous would have been to dismiss the request. There were no requests dismissed by the Committee for any of these reasons.

 

The Reconsideration Committee found merit in only one of the requests for reconsideration. The single request that was accepted concerned clarifying and accelerating the process of posting minutes of Board meetings. The number of requests filed during the last three years provides us with a fairly small sample but it is clear already that the odds of having a request accepted by the Reconsideration Committee are not high.

 

2. Time frame for responding to requests for reconsideration

 

            The ICANN Reconsideration Policy states that “The Reconsideration Committee will endeavor to complete its work and submit its recommendation to the Board within 30 days of the filing of the request.” We found that this rarely happened. Recommendations in three requests were made within thirty days, recommendations in five required more than five months, and most required more than three months. One request made March 10, 2000 has never been formally responded to. The need to have a deadline for responding to requests is discussed below.

 

3. Request for a stay

 

            The Reconsideration Policy gives petitioners the option to request a temporary stay of the action. In theory, requesting a stay would suggest that the petitioner is concerned that if too much time passed, the protested action will not be able to be undone. We found that stays were requested in ten of the requests. A prompt response to the request for a stay was provided in only one of the requests. In most of the others, the request for a stay was simply ignored. Decisions and recommendations made no mention of the request for a stay and the request for a stay did not appear to bring a faster response. For example, a stay was not requested in the two requests that were responded to most quickly whereas it took almost seven months to make a recommendation in one case where a stay was requested.

 

Discussion

 

The Blueprint for Reform states that the “ICANN Reconsideration Process should be amended to apply to (a) actions by staff alleged to contradict established Board policy or to be inconsistent with known facts, or (b) actions by the Board alleged to be based on error or lack of relevant information. The Reconsideration Process should require that the Board consider any reconsideration request no later than the second Board meeting following receipt of the request.” These recommendations for change in the process involve two issues of importance, what can be complained about and how long the process should take from beginning to end.

 

1. As noted above, the existing Reconsideration Policy states that “Any person affected by an action of the Internet Corporation for Assigned Names and Numbers ("ICANN") may request review or reconsideration of that action by the Board of Directors.” The recommendations would narrow the subject matter of complaints and, as a result, reduce the number of such complaints. Is there any reason to narrow the subject matter of complaints? We do not believe there is.

 

We found that the majority of resolved requests during the three years dealt with a single issue, that of the selection process for new tlds in 2000.  ICANN staff may feel that even the remaining sixteen complaints over a three year period is too many, and we recognize that it is often difficult to gauge whether there is too much use or too little use of a particular dispute resolution process. What we do know about dispute resolution systems is that they have two purposes. The first is, quite obviously, to settle problems. The second, which ICANN seems aware of, is to demonstrate the legitimacy of the organization by the manner in which the disputes are settled. The request for reconsideration process is identified in the Blueprint for Reform as a means for contributing to “accountability.” Perhaps surprisingly, perceptions of accountability are likely to grow not by the absence of disputes but by the public airing of disputes and by the resolution of those disputes in a fair and efficient manner. In other words, a basic principle in a situation where accountability is desired is that it is not the policy itself that will be important but the manner in which the policy is used.

 

We understand that the Request for Reconsideration process is not meant to be the sole means for achieving “accountability.” It never could be the sole means as long as the persons reviewing and ruling on the requests are the same people who made or participated in the decisions being challenged. Yet, such a process can certainly contribute to levels of trust in an organization if, when disputes are brought, the petitioners are responded to promptly and in accordance with stated rules.

 

There are too few requests for reconsideration to reach any firm conclusion as to whether petitioners are receiving the same response that they would receive from an independent third party. What is clear is that there have been so few requests that ICANN, as an institution seeking the confidence and trust of its constituents, should not be focused on modifying policies that will reduce the level of complaining through official channels.

 

2. The second recommendation of the Blueprint for Reform is that the Board should “consider any reconsideration request no later than the second Board meeting following receipt of the request.” This compares with the current Reconsideration Policy which states that the “Reconsideration Committee will endeavor to complete its work and submit its recommendation to the Board within 30 days of the filing of the request.” As noted earlier, there is no pattern to how long it took for the Committee to make a recommendation but it almost never occurred within thirty days.

 

The Evaluation and Reform Committee is correct to recognize the time for responding as important since responsiveness and timely responsiveness can be considered to be core qualities of accountability. What is also necessary, however, is that any time frame be fair to all parties. For any petitioner, a schedule indicating that a response will be forthcoming by the “second Board meeting following receipt of the request” is much too ambiguous. This can be as long as seven or eight months away or as short as two months away if Board “meetings” include teleconferences.

 

Reasonable people can probably differ on whether a petitioner in a situation like this should expect to receive the Committee’s recommendation within thirty, sixty or ninety days. We do believe that it should be measured in days, not Board meetings, and that a response of some kind should be guaranteed to the petitioner by the end of that time frame. We can certainly understand that a request may involve such complexity that a lengthier time frame may occasionally be necessary. In such cases, however, the Reconsideration Committee should be required to request an extension from the Board, to state explicitly the reason for the extension, and to inform the petitioner when a recommendation will be forthcoming. 

 

The Reconsideration Policy allows a petitioner to request a temporary stay. In such situations, the petitioner must “identify what harms will result if the action is not stayed.” As noted earlier, stays were requested in eleven instances, responded to directly in one, and approved in none. It is not unreasonable to assume that those who requested a stay felt particularly concerned that their request be acted upon quickly. In this situation as well, if there were reasons to delay acting upon the requested stay, petitioners should have been notified early.

 

ICANN should be concerned about the picture we have drawn of the reconsideration experience. It may be only a coincidence that petitioners lose consistently in a process where winning and losing is determined by those who participated in the very decision being contested. Such outcomes, however, will inevitably appear to be self-serving.

 

The ICANN Evaluation and Reform Committee has recently proposed additional processes that would be employed to enhance “accountability.” These include the following:

 

  • Creation of an Ombuds Office

  • Appointment of a staff member to oversee and manage public participation

  • Establishment of a non-binding arbitration process for challenging Board actions that might violate ICANN bylaws.

 

We would urge that in both design and implementation, more attention and oversight be given to these new processes than has been given to the reconsideration request process.

 



CONTENTS

Copyright © 1995 - 2007 ICB. Inc. All rights reserved. "ICB Toll Free News" is a trademark of ICB Inc. ICB Inc. assumes no responsibility for use or misuse of information contained herein and / or accessible via this site. ICB Inc. cannot and does not vouch for the accuracy and / or usability of any of the contained or linked-to information, and assumes no responsibility for any errors or omissions.