Academic journal article The Review of Litigation

Is This as Good as It Gets? an Appraisal of ICANN's Uniform Domain Name Dispute Resolution Policy (UDRP) Three Years after Implementation

Academic journal article The Review of Litigation

Is This as Good as It Gets? an Appraisal of ICANN's Uniform Domain Name Dispute Resolution Policy (UDRP) Three Years after Implementation

Article excerpt


In October 1999, the Internet Corporation for Assigned Names and Numbers (ICANN) implemented the Uniform Domain Name Dispute Resolution Policy (UDRP or Policy), establishing a uniform system for trademark owners to challenge "cybersquatting," which occurs when Internet domain names are abusively registered.1 Approximately three years after its implementation, it is important to examine the UDRP to determine whether it is achieving its intended result of providing a quick, inexpensive method for resolving domain name disputes fairly and accurately. This Note arrives at three main conclusions regarding the UDRP's success in realizing its goals. First, the UDRP deserves the acclaim it has received for providing a cheap, quick method of dispute resolution; in this regard, the UDRP offers a significant improvement over litigation. Second, the UDRP's procedural guidelines are ineffective for guarding against misapplication of the Policy. One consequence of the defects in the UDRP's procedures is that arbitrators lack guidance concerning which interpretations of the Policy are best. In the absence of such guidance, some dispute resolution providers appear to be applying the UDRP in a biased manner to gain market advantage over their peers. Third, the UDRP's incentive structure is flawed because it facilitates cybersquatting and "reverse domain name hijacking."2 As IMAGE FORMULA170

a result, the phenomenon of cybersquatting continues unabated three years after the UDRP was implemented, and innocent domain name registrants are badgered by overly aggressive trademark owners.

In order to correct these problems, ICANN should first address the UDRP's procedural defects by creating a UDRP Review Board. The Board's purpose would be to identify or issue decisions that would act as binding precedents on all arbitrators. Over time, this process would flesh out the meaning of the Policy, to help ensure its consistent, fair, and accurate application. Second, ICANN should balance the incentives created through the implementation and use of the UDRP so that it encourages neither cybersquatting nor reverse domain name hijacking. Domain name registration fees should be modified to remove the economic incentives of cybersquatting. Additionally, the Rules for UDRP3 should be altered to include a penalty for reverse domain name hijacking to deter overly aggressive complainants from misusing the UDRP process.

Part II of this Note begins with a problem orientation that discusses the history of domain names and the domain name registration process, explores the rise of cybersquatting, and considers the circumstances that led to the enactment of the UDRP. Part III describes the goals of the UDRP, examines its substantive and procedural aspects, and recommends solutions for its procedural flaws. Part IV discusses problems with the incentive structure created by the implementation and use of the UDRP and proposes changes to address those problems. Part V discusses barriers to changing the UDRP.


A. Domain Name Fundamentals

Domain names are easy-to-remember combinations of letters and numbers (e.g., that facilitate the receipt and transmission of data over the Internet. Domain names were developed in the mid-1980s to make referring to IP addresses IMAGE FORMULA175

(numerical strings like "" that uniquely identify Internet computers and enable Internet communication) simpler and easier for human computer users.4 Domain names, IP addresses, and the communications protocols that manage how data is sent over the Internet comprise the domain name system (DNS). The DNS is constructed as a hierarchy of top-level domains (TLDs) and sublevel domains.5 A "root" server sits at the top of the hierarchy, maintaining a directory of all the servers that hold top-level domain directories. …

Search by... Author
Show... All Results Primary Sources Peer-reviewed


An unknown error has occurred. Please click the button below to reload the page. If the problem persists, please try again in a little while.