Research Publication No. 2000-02

Pressing Issues II:

Understanding and Critiquing

ICANN’s Policy Agenda -

Briefing Book

The Berkman Center for Internet & Society, The Center for Democracy and

Technology, and The Markle Foundation

This paper can be downloaded without charge from the

Berkman Center for Internet & Society at Harvard Law School Research Publication Series at:

http://cyber.law.harvard.edu/publications

Briefing Book - Pressing Issues II November 12, 2000 - Los Angeles, CA

HomeRegistrationWebcastParticipantsBriefing MaterialsArchive

Table of Contents

Sunday, November 12, 2000 http://cyber.law.harvard.edu/icann/pressingissues2000/briefingbook

Edited by Rebecca Nesson, Ben Edelman, and Diane Cabell Berkman Center for Internet & Society

Executive Summaries of Key Documents http://cyber.law.harvard.edu/icann/pressingissues2000/briefingbook/executive-summaries.html

Privacy and Intellectual Property: UDRP Review and Whois Policy and Implementation

Berkman Center Student Analysis: Evaluating the Uniform Domain Name Dispute Resolution Policy by Dori Kornfeld http://cyber.law.harvard.edu/icann/pressingissues2000/briefingbook/udrp-review.html

Uniform Dispute Resolution Policy http://www.icann.org/udrp/udrp-policy-24oct99.htm

Registrar Accreditation Agreement http://www.icann.org/nsi/icann-raa-04nov99.htm

ICANN At-Large Membership: Elections and the Role of National Identity

Berkman Center Student Analysis: ICANN At Large Membership at a Crossroads by Leonard Kardon and Emel Wadhwani http://cyber.law.harvard.edu/icann/pressingissues2000/briefingbook/at-large-membership.html

Berkman Center Student Analysis: Global Ideal, National Reality by Jonathan Blavin and Jeremy Kutner http://cyber.law.harvard.edu/icann/pressingissues2000/briefingbook/nationalism.html

Results of ICANN At-Large Director Election http://www.election.com/us/icann/icannresult.html

Statistical Information on ICANN activated memberships http://members.icann.org/activestats.html

Yokohama ICANN Board Resolutions on Director Selection http://www.icann.org/minutes/prelim-report-16jul00.htm#AtLargeDirectorSelectionPlan

Yokohama ICANN Board Resolutions on ICANN's Geographic Regions http://www.icann.org/minutes/prelim-report-16jul00.htm#DefinitionofICANN'sGeographicRegions

Cairo ICANN Board Resolutions on At Large Membership

http://www.icann.org/minutes/prelim-report-10mar00.htm#AtLarge RFC 1591 - Berkman Center Summary http://cyber.law.harvard.edu/icann/pressingissues2000/briefingbook/rfc1591.html

New TLDS

Berkman Center Student Analysis: Analysis and Chart of the New TLD Applications by Leeor Farhadian, Talia Milgrom-Elcott, and Devesh Tiwary http://cyber.law.harvard.edu/icann/pressingissues2000/briefingbook/tld-application-chart.html

ICANN Board Resolutions on New TLDs http://www.icann.org/tlds/new-tld-resolutions-16jul00.htm

New TLD Application Process Overview http://www.icann.org/tlds/application-process-03aug00.htm

ICANN Staff Criteria for Assessing TLD Proposals http://www.icann.org/tlds/tld-criteria-15aug00.htm

List of New TLD Applicants and TLD Strings Requested http://www.icann.org/tlds/tld-applications-lodged-02oct00.htm

ICANN Staff Report on New TLD Applications http://www.icann.org/tlds/report/

General Information

Key Recent and Upcoming Milestones http://cyber.law.harvard.edu/icann/pressingissues2000/briefingbook/milestones.html

History of the Domain Name System http://cyber.law.harvard.edu/icann/pressingissues2000/briefingbook/dnshistory.html

White Paper Principles http://cyber.law.harvard.edu/icann/pressingissues2000/briefingbook/white-paper-principles.html

ICANN's Obligations under the DoC Memorandum of Understanding http://cyber.law.harvard.edu/icann/pressingissues2000/briefingbook/icann-obligations.html

Axes of Conflict http://cyber.law.harvard.edu/icann/pressingissues2000/briefingbook/axes.html

Sample of Remote Participation http://cyber.law.harvard.edu/icann/pressingissues2000/briefingbook/remoteparticipation-sample.gif

Berkman Center ICANN-Related Content Archive http://cyber.law.harvard.edu/icann

Berkman-ICANN FAQ http://cyber.law.harvard.edu/icann/bcisfaq

Profiles of the Panelists and Staff http://cyber.law.harvard.edu/icann/pressingissues2000/participants.asp

About this Briefing Book http://cyber.law.harvard.edu/icann/pressingissues2000/briefingbook/about.html

Translate with Altavista Babelfish: Deutsch, Espanol, Francais, Italiano, Portugues

Hosted by: The Berkman Center for Internet & Society http://cyber.law.harvard.eduand: Center for Democracy and Technology http://www.cdt.org Sponsored by: The Markle Foundation http://www.markle.org

EXECUTIVE SUMMARIES OF KEY DOCUMENTS <http://cyber.law.harvard.edu/icann/pressingissues2000/briefingbook/executive-summaries.html>

Table of Contents

ICANN Formation

The White Paper ICANN Articles of Incorporation ICANN By-laws Memorandum of Understanding (MoU) between the U.S. Department of Commerce (DoC) and the Internet Corporation for Assigned Names and Numbers

Amendment 1 to the MoU Amendment 2 to the MoU Status Report under the ICANN/DoC Mou Second Status Report under the ICANN/DoC Mou

ICANN Corporate Policies

Conflicts of Interest Policy Independent Review Policy Reconsideration Policy

ICANN Supporting Organizations

Address Supporting Organization Protocol Supporting Organization Domain Name Supporting Organization

ICANN Committees

Membership Advisory Committee Government Advisory Committee Committee of the Board of Directors on Reconsideration The Advisory Committee on Independent Review DNS Root-Server System Advisory Committee Audit Committee Executive Committee Executive Search Committee Election Committee Nominating Committee

ICANN Agreements, Recommendations, and Related Documents

ICANN/NSI Registry Agreement Registrar Accreditation Agreement NSI/DoC Memorandum of Understanding World Intellectual Property Organization (WIPO) Report ICANN/U.S. Government Contract for the IANA Function

IETF/ICANN Memorandum of Understanding Concerning the Technical Work of the IANA

FAQ about the Berkman Center's Relation to ICANN

ICANN Formation

The White Paper (June 5, 1998) Management of Internet Names and Addresses United States Department of Commerce, National Telecommunications and Information Administration http://www.ntia.doc.gov/ntiahome/domainname/6_5_98dns.htm

This document expresses the intention of the US government (USG) — through the Department of Commerce (DoC) — to end direct support of Internet name and address coordination services. As growth of commercial and international segments of the Internet has resulted in a distributed system beyond the jurisdiction of one nation to administer, the White Paper concludes that the US government should no longer take so central a role in the coordination of essential Internet services. In addition to providing a history of US government involvement with the Internet, the White Paper reviews and attempts to respond to public concerns (raised during a comment period following the issuance of the Green Paper), following what it calls the generally accepted guidelines of stability, competition, private bottom-up coordination, and representation. Disagreement on the need for central coordination of certain tasks (such as a single authoritative root for domain names) was noted as well as the fact that the actual decision to standardize a technical protocol is a function performed by non-governmental organizations not regulated by any government.

ICANN Articles of Incorporation (November 1998) http://www.icann.org/articles-pr23nov98.html

Articles of incorporation typically set up the basic structure of an organization; detailed implementation occurs in the by-laws (which are often easier to modify). ICANN's Articles establish it as a private 501(c)(3) non-profit entity under California law. As such it has no shareholders or other external structural oversight mechanism save for potential oversight from the Attorney General of California who may intervene to keep the Corporation's activities within the bounds of California law. For non-Californians, and particularly non-US netizens, this is arguably inadequate protection. Therefore, early drafts of the By-laws (below) were amended to provide for an at-large membership which would elect half of the Board of Directors. Also contentious is Article 9, a provision which allows a two-thirds majority of the directors of the Corporation to make amendments to the Corporation's Articles. Since ICANN's Board currently has only ten members, seven of them could completely change the Corporation's structure (as well as its By-laws) at any time. However, once ICANN has "members," any such amendment would have to be ratified by a two-thirds majority of those members voting on the proposed amendment. ICANN established a Membership Advisory Committee (see documents and summary below) which developed recommendations for the establishment of the At-large Membership.

ICANN By-laws (November, 1998 and subsequently revised) http://www.icann.org/bylaws-09apr99.html

One of the major debates over ICANN's structure concerned the relative power of the existing Internet technical community relative to the burgeoning ranks of commercial users and consumers. The By-laws set up a structure whereby half of the ICANN Board is elected by the technical community (the Supporting Organizations or SOs) and the other half by the general population at large (the At-large Membership).

The Supporting Organizations are expected to present themselves to ICANN for recognition and determine who best speaks for their concerns. To date, there are three: the Address Supporting Organization (or ASO, formed by the regional internet address registries), the Protocol Supporting Organization (or PSO, formed by the IETF and other organizations that have traditionally designed and approved standards for protocols), and the Domain Name Supporting Organization (or DNSO, to make recommendations on domain name issues). (See ICANN Supporting Organizations, below.) A Membership Advisory Committee (see ICANN Committees, below) was designated to recommend a structure for the At-large Membership.

However, neither the SOs nor the At-large Membership has the right to implement any policy. An SO's role is to advise and recommend; but the Board has final decision-making authority. Until there is some experience with this process, some in the technical community remain concerned that well-intended but technically disastrous policies will be recommended by the At-large Membership, while the at-large membership worries that the technical community will make decisions that favor well-connected insiders or otherwise disregard the public interest.

The By-laws also require the establishment of other advisory committees to consider interests not represented by the above or to tackle specific, detailed tasks assigned by the MoU below. Internal review procedures are also mandated so as to make redress less dependent on the Attorney General of California. (See ICANN Committees, below.)

ICANN's By-laws were developed at the direction of Dr. Jon Postel who is said to have selected the nine Interim Board members from a list of nominees suggested by the public at large. Although Dr. Postel was well-known and respected by many in the Internet technical community, his designees are not so widely known.

Memorandum of Understanding (MoU) between the U.S. Department of Commerce (DoC) and the Internet Corporation for Assigned Names and Numbers (ICANN) (November 1998) http://www.ntia.doc.gov/ntiahome/domainname/icann-memorandum.htm

Under the DoC's Joint Project Authority and at the direction of the US government, this document establishes a development program to design and test mechanisms for private coordination of certain Internet technical functions that previously had been handled under contracts with several different entities. It is also the primary formal vehicle through which ICANN was officially selected as the "newco" contemplated by the White Paper. Critics of the MoU, including critics of the White Paper that proceeded it, allege that the government has no right to transfer control of the Internet to private parties. Defenders respond that this agreement does not transfer regulatory

functions because the US government has not exercised any regulatory functions in this area. However, critics of the MoU argue that the weight of government support behind ICANN is substantially equivalent to regulatory authority. ICANN's position on Commerce's authority is that the distributed ownership of the components of the Internet makes it impossible for any one entity to exercise any authority over the whole system; ICANN therefore argues that it only exercises influence over component operators that trust it, and since the operators' delegation of decision-making to ICANN is voluntary, no actual regulatory power has been transferred.

Amendment 1 to the ICANN/DoC MoU (November 1999) http://www.icann.org/nsi/amend1-jpamou-04nov99.htm

Amendment 1 formally incorporated ICANN's Registry Agreement with NSI into the MOU but retained to the DoC the ultimate authority to ICANN's rights under all contracts with registries and registrars should the DoC withdraw its recognition of ICANN.

Amendment 2 to the ICANN/DoC MoU (September 2000) http://www.icann.org/general/amend2-jpamou-07sep00.htm

Amendment 2 extended the term of the MoU until September, 2001. It recognized ICANN's progress in accomplishing the tasks set out under the MoU and listed a set of continuing tasks for ICANN. These tasks included continuing to provide expertise on private-sector functions relating to management of the DNS, continuing development of relationships with the RIRs, implementation of an enhanced root-server system architecture, continuing efforts to achieve stable agreements with the ccTLDs, and proceeding with introduction of new TLDs.

Status Report under the ICANN/DoC MoU (June 1999) http://www.icann.org/general/statusreport-15june99.htm

The first status report under the ICANN/DoC MoU reviewed the principles laid out in the White Paper: stability, competition, private-sector bottom-up coordination, and representation. It also discussed the additional topics and action items covered by the White Paper and listed the specific actions ICANN took since entering the MoU. The report goes through each principle expressly looking at how ICANN's actions have addressed it. For stability, the report emphasized the continued stability of the DNS since ICANN took over management. For competition, ICANN noted the ongoing introduction of 5 test-bed registrars, the development of accreditation criteria, and the anticipated introduction of more registrars in the future. For private-sector bottom-up coordination, ICANN looked to the formation of the DNSO, the process of formation of the PSO, and the anticipated formation of the ASO in the near future. For representation, ICANN looked again to the formation of the Supporting Organizations and the difficult process of determining how to elect the 9 At-Large directors. In addition the status report addressed issues of incorporation, funding, staffing, governance, structure, new TLDs, and relations with governments. The report concluded with a stark picture of NSI's

unwillingness to fully cooperate in the introduction of competition and development and acceptance of consensus policies.

Second Status Report under the ICANN/DoC MoU (June 2000) http://www.icann.org/general/statusreport-30jun00.htm

The second status report under the ICANN/DoC MoU identified 9 specific tasks given to ICANN under the MoU and detailed ICANN's progress on each, in a few cases reporting that the task had been completed or were very near completion. However, the status report made clear that all tasks had not been completed and would not be finished by the end of the term of the MoU in September 2000. Thus the status report recommended an extension of the MoU (which was formalized in Amendment 2 to the MoU, above.) The tasks identified and the progress on those tasks are as follows (in paraphrase):

Task 1: Provide expertise on private-sector functions related to technical management of the DNS. Progress: ICANN has established stable relationships and understandings with the RIRs and SDOs. With the exception of establishing funding agreements with the RIRs, Task 1 is completed. Task 2: Design procedures for neutral third-party review of decisions. Progress: ICANN has adopted a Reconsideration Policy which in operation, and Independent Review Policy which is still in the formation stages, and an Arbitration Process which is largely implemented through agreements with the registries and registrars. Task 2 will be complete within a few months. Task 3: Introduce competition in domain-name registration services. Progress: Competition at the registrar level has successfully been introduced. Task 3 is completed. Task 4: Establish procedures for operation of and modifications to the root-zone file. Progress: ICANN established the Root Server System Advisory Committee to define technical procedures. This process is well underway. Completion of task 4 is expected within the next few months. Task 5: Establish more robust management for the root server system. Progress: Though this task is well underway, with study ongoing by the DNSOP, it will require a few more months for completion. Task 6: Establish procedures for allowing interested parties to participate in policy-making. Progress: The creation of all of the SOs and the different mechanisms for policy-making have been work towards the accomplishment of this goal. It is a difficult goal on which continuing work and development will always be necessary. Task 7: Establish procedures for getting information to the

public. Progress: The use of the ICANN website, mailing lists, webcasting and archiving of meetings. Though there will always be room for enhancement, this task has been completed to the satisfaction of the MoU requirements. Task 8: Establish additional procedures to ensure accountability and representation. Progress: Again the creation of all of the SOs, the review policies, the notice and comment mechanisms. Though there will continue to be development in this area, this task is completed to the satisfaction of the MoU requirements. Task 9: Addition of new TLDs. Progress: The DNSO has recommended the addition of new TLDs in a "measured and responsible manner" and the Board will act at Yokohama. Determinations about the future of new TLDs should be made by the end of 2000.

ICANN Corporate Policies

Conflicts of Interest Policy (March 1999) http://www.icann.org/general/coi-policy.htm

The Conflicts of Interest Policy prevents any director, officer or person from using his/her position within ICANN for personal benefit. Because ICANN is a corporation made up of interested stake-holders, the result of this policy is that directors (and others) must disclose any personal interest in policy decisions and exempt themselves from those decisions that are determined to be a conflict of interest.

Reconsideration Policy (March 1999) http://www.icann.org/general/reconsideration.htm

Under the Reconsideration Policy an interested person may request that the ICANN Board reconsider an action that it has taken. These requests are considered by a three-member Reconsideration Committee made up of ICANN Board members. The committee will evaluate the requests for reconsideration and make a recommendation for action on the request to the Board.

Independent Review Policy (March 2000) http://www.icann.org/indreview/policy.htm

In accordance with the ICANN bylaws the Board adopted a policy for third-party review of its decisions. The policy is intended to allow for independent review of whether ICANN has violated the Bylaws or Articles of Incorporation in one of its decisions. Requests for independent review are submitted to a nine member Independent Review Panel which is responsible for developing its own rules of procedure. Adjudications of requests are performed by three members of the review panel. IRP members serve for 4 year terms and are nominated by a nominating committee composed of two members from each SO Council. Nominees must be approved by the ICANN Board. The IRP will hear requests for review under the Articles of Incorporation and Bylaws or on the grounds that consensus did not exist.

ICANN Supporting Organizations (SOs)

Each of the three SOs will elect three Directors to ICANN’s Board, and each will be ICANN's primary source of policy recommendations within its respective area of expertise. Under the ICANN By-laws, the SOs must organize themselves in a bottom-up fashion and be recognized by the board. They are also required to be financially independent from ICANN. Participation in an SO must be open to any individual or organization that meets the SO's reasonable minimum qualifications as ratified by the ICANN Board.

Address Supporting Organization (ASO)

ICANN ASO Status Page http://www.icann.org/aso/asonew.htm

The Address SO is expected to consist of the three regional Internet registries (RIRs): APNIC (Asia-Pacific Network Information Center, http://www.apnic.net), ARIN (American Registry for Internet Numbers, http://www.arin.net), and RIPE NCC (Reseau IP Europeans, http://www.ripe.net). InterNIC formerly managed this task under a National Science Foundation (NSF) contract, but as the demand for name assignment grew, the number allocation tasks were spun off to these private, non-profit organizations. The Internet Assigned Numbers Authority (IANA) allocates Internet Protocol (IP) addresses (the numbers that actually identify each host machine) in large blocks to the RIRs which then assign them for a fee to major access providers which in turn allocate further downstream. Assignments are ordinarily made on a first-come, first-serve basis and have generally been easily obtained, except when issues of routing efficiency intervene. The field of numbers has just been increased dramatically with Internet Protocol Version 6 (IPv6).

Protocol Supporting Organization (PSO)

ICANN PSO Status Page http://www.icann.org/pso/psonew.htm

PSO Proposal from IETF POISSON Working Group http://www.icann.org/pso/pso1.html

MoU between IETF, W3C, and ICANN re the PSO http://www.ietf.org/internet-drafts/draft-ietf-poisson-mou-pso-00.txt

Protocols are standards for the transmission of data over a network. Although protocols are not mandatory, they are useful in the same sense as a standard style of electrical outlet allows multiple appliances to operate with it. Many protocols used on the Internet have been developed by the Internet Engineering Task Force (IETF, http://www.ietf.org) through its bottom-up online peer review procedure. Thus, the IETF is expected to play a key role in the PSO, while the European Telecommunications Standardization Institute (ETSI) is also expected to participate. Under a proposal from the IETF's POISSON Working Group, the IETF and other standards development organizations would collectively form the PSO. The proposal contemplates that standards development organizations will continue to design the technical aspects of standards, while ICANN will assume the ministerial role of assuring the uniqueness of numeric values as required by particular protocols.

Domain Name Supporting Organization (DNSO)

ICANN DNSO Status Page http://www.icann.org/dnso/dnso1.htm

DNSO Web Site http://www.dnso.org

Formation of the DNSO has generated nearly as much controversy as has its subject matter. Although the DNSO will "merely" make recommendations to ICANN regarding domain name policy, this ability to frame the issues is thought to be of critical importance. In March 1999, the ICANN board recognized what it said was the most popular DNSO structure: a two-tier DNSO with a General Assembly (GA) and constituencies that together choose a Names Council (NC). The GA consists of all interested individuals and entities; it is the initial source of both policy and representation. Any constituency that self-forms out of the GA and is recognized by the ICANN board can send three members to the NC. However, to prevent capture, there is a prohibition against more than one person from the same organization sitting on the NC.

Six initial constituencies were recognized by the ICANN board in May 1999: ccTLD Registries, Commercial and Business Entities, gTLD Registries, Intellectual Property, ISPs and connectivity providers, and Registrars. These constituencies representing commercial interests have organized rapidly. A Non-Commercial constituency called for by ICANN resolution is still in formation, and a proposed IDNO has not been accepted. Some concern exists about double-counting of votes among constituencies.

ICANN Committees

Membership Advisory Committee (MAC)

Berlin Report (May 26, 1999) http://www.icann.org/macberlin.htm

ICANN Resolutions on Membership (May 27, 1999) http://www.icann.org/berlin/berlin-resolutions.htm#3l

Representation in Cyberspace Study http://cyber.law.harvard.edu/rcs/

The MAC, responsible for recommending a structure for the at-large membership, was the first committee established by ICANN. Over 850 comments on the MAC's deliberations were received and are archived at http://www.icann.org/comments-mail/membership-current/maillist.html.

The MAC recommended that the at-large membership be free of cost, open to all individuals (but not organizations) with access to the Internet (whether or not

they were domain name holders), using online registration and voting methods pending sufficient protections against election fraud. A great deal of discussion concerned fears of capture in such an election. If only a few members registered to vote, it would be easy for a special interest (such as a particular company stacking the rolls with all its employees) to gain control. On the other hand, postponing elections until the establishment of a sufficiently large and broadly representative membership base would further delay the seating of an elected ICANN Board. The decision to prohibit corporate membership was also protested by those who believe that these organizations represent most of the actual domain registrants. The Committee recommended that five of the nine at-large board members be pulled from regional pools. This policy was problematic for many, for non-US interests worry that current US dominance of the Internet slights foreign interests. However, issues are not necessarily divided along regional boundaries, making it undesirable to base a voting system on geography alone.

At the Berlin Open Meeting in May 1999, the ICANN Board reaffirmed its intention to establish a mechanism for representational elections, and it requested its staff to report on implementation procedures and costs prior to its August meeting in Santiago. It resolved that the costs of holding elections should be borne by the Membership and that elections, however designed, should be sufficiently secure and authentic to avoid risking the operational stability of the Internet.

Government Advisory Committee (GAC)

http://www.icann.org/governmental-com.html

Berlin Communique (May 25, 1999) http://www.icann.org/gac-comm-25may99.html

The Government Advisory Committee (GAC) was established to provide a means by which official government representatives could express their interests in and thoughts about ICANN activities, since the White Paper (Structure, 4) and ICANN bylaws (Art. 7, Sec. 3) preclude government officials from having a direct say in ICANN's decision-making process. Hence, in accordance with the ICANN By-laws and White Paper guidance, the GAC provides a forum for discussion regarding ICANN activities as they relate to concerns of governments, "particularly matters where there may be an interaction between the Corporation's policies and various laws, and international agreements."

Members of the GAC include representatives of national governments, multinational governmental organizations, and treaty organizations, each of which may appoint one representative to the Committee. The representative must hold a formal, official position with the Member organization's public administration. Although the GAC reports its findings and recommendations to the ICANN Board, it is an advisory committee, and as such has no legal authority to act for ICANN.

The GAC, which has met at ICANN Open Meetings in both Singapore and Berlin, issued a communique from its Berlin meeting in which it generally endorsed the WIPO report and suggested that ICANN, in case of conflict over which entity should control a contested

country code top-level domain (ccTLD), should reassign the domain to the public authority with the support of the relevant community.

Critics of the GAC worried that closed GAC meetings would begin to make ICANN "a tool for the governments of the world to gain a measure of control over the ... difficult-to-regulate Internet" (ICANNWatch Archives). GAC Chairman Paul Twomey responded that "the meetings are closed for practical reasons ... [to] have discussions at a pragmatic level. ... Representatives need to have confidence that they may talk among themselves and not feel like they're talking to the world press [or] they simply won't speak their minds."

Committee of the Board of Directors on Reconsideration (Reconsideration Committee)

http://www.icann.org/reconsideration/recon-committee.htm

Any person affected by an action of ICANN may request review or reconsideration of that action by the Board of Directors, as required by the ICANN Bylaws (Art. III, Sec. 4(a)). The Committee of the Board on Reconsideration (Reconsideration Committee) was established in March 1999 to review and consider any such requests. Consisting of three directors, the Reconsideration Committee is charged with implementing ICANN's Reconsideration Policy (adopted March 4, 1999), and has the authority to investigate and evaluate requests for reconsideration. It then makes recommendations to the Board of Directors, which ultimately determines how to resolve such requests.

The Reconsideration Committee is ICANN's internal reconsideration process — as distinguished from the external Advisory Committee on Independent Review (see IRAC, below). It is suggested that an individual with a claim ought first to exhaust ICANN's internal reconsideration process before taking the claim to the Independent Review Panel (IRP) of IRAC. As IRAC suggests: "A requirement of exhaustion of internal remedies promotes efficiency by maximizing the odds that the ICANN Board will resolve disputes on its own before they reach the IRP. In addition, the IRP will benefit from any record of decision, including factual investigation and findings, developed during the course of ICANN's internal reconsideration process." At the same time, however, in cases in which ICANN's internal reconsideration process has not been concluded within 30 days, IRAC recommends that complaining parties be allowed to bypass the Reconsideration Committee and go directly to the IRP.

The Advisory Committee on Independent Review (IRAC)

http://www.icann.org/dnsroot-com.html

As called for in the ICANN Bylaws (Article III, Section 4(b)), the Advisory Committee on Independent Review (IRAC) is responsible for advising the ICANN Board on an appropriate mechanism for independent third-party review of Board actions. The eight-member committee was appointed in March 1999, selected from over fifty expressions of interest in response to ICANN's invitation. IRAC posted its initial "Draft Principles of Independent Review" for public comment and review before submitting the revised principles ("Addendum") to the ICAAN Board as an Interim Report to be considered at the Board's Berlin meetings, May 26-27, 1999.

The eleven principles of the IRAC included: nomination of IRP members by a Nominating

Committee separate from the Board of Directors; selection of IRP members based on experience, geography, and legal system representation; six year terms staggered every two years; public availability of all claims, procedures, and decisions; and online proceedings when possible to minimize costs.

The DNS Root-Server System Advisory Committee (RSSAC)

http://www.icann.org/dnsroot-com.html

As called for in the ICANN Bylaws, the DNS Root-Server System Advisory Committee is responsible for advising the board on the operational requirements of the root server system, including hardware, operating systems, name server software, network connectivity and physical environment. The RSSAC is also responsible for advising on security, robustness and reliability of the system. The RSSAC includes the operators of all 13 root servers and others. Their report, presented at the public forum in Yokohama, recommended migration to an enhanced dedicated master root-server system. The Board approved these recommendations and agreed to forward them to the DoC by the end of August. To date, they have not been forwarded.

Audit Committee

http://www.icann.org/general/audit-committee.htm

The Audit Committee is a three-member subcommitee of the ICANN board created by resolution in November 1999. The Audit Committee is responsible for recommending external auditors to the board and reviewing and forwarding the annual reports of the auditors.

Executive Committee

http://www.icann.org/general/executive-committee.htm

The Executive Committee was created by resolution of the Board in November 1999 to exercise the powers of the Board and oversee the management of the business affairs of the corporation. It is composed of the Chairman of the board and at least two other board members. All actions of the executive committee are recorded and reported at meetings of the Board.

Executive Search Committee

http://www.icann.org/committees/exec-search/

The Executive Search Committee was created by resolution of the Board in November 1999 to head the search effort for a successor to Michael Roberts as CEO of ICANN. Since its formation the Committee has retained the services of Christopher Mill and Partners to aid in the search process. It is the objective of the committee to find a successor for Mr. Roberts by the end of 2000.

Election Committee

http://www.icann.org/elcom/

The Election Committee was comprised of ICANN Board members and outside election experts to advise the ICANN Board on rules for the recently completed ICANN At Large Director election. The Election Commitee was also responsible for the specification for an online voting system provider and a recommendation to the Board. Based on the committee's recommendation, the Board selected Election.com. The Committee submitted recommendations to the ICANN Board which were accepted with minor alterations by the Board at its meeting in Yokohama. In substance, the Election Committee made 6 recommendations (in paraphrase):

Recommendation 1: The elections should be conducted regionally rather than globally. Recommendation 2: ICANN should post informational web pages about each candidate standardized in both substance and format. Recommendation 3: Discussion forums for each candidate should be created to foster communication with the voters. Recommendation 4: The elections should be conducted using a preferential voting system. Recommendation 5: 10% of a regions voters should be the required threshhold for member-nominations. Recommendation 6: Either a small committee or an independent organization should be tasked with evaluation of the fairness of the elections.

Nominating Committee http://www.icann.org/nomcom/

The Nominating Committee was created in order to take suggestions from the ICANN community and nominate candidates for places on the ballot for the At Large Director election. As criteria for selection, the Nominating Committee identified reputation for integrity and hard work, ability to exercise indepedent judgment, professional/volunteer roles and accomplishments, understanding the Internet's architecture and history, specific experience with the domain name and IP address system, experience in international and/or multicultural environments, educational background, skills not currently present on ICANN Board, available time, energy and interest, and likelihood of finding broad support in the ICANN community. The Nominating Committee received expressions of interest from over 200 people and heard from over 400 people. At the end of July, the Nominating Committee nominated between 2 and 5 candidates for each region.

ICANN Agreements, Recommendations, and Related Documents

ICANN/NSI Registry Agreement (November 1999) http://www.icann.org/nsi/nsi-registry-agreement-04nov99.htm

ICANN and NSI agree that NSI will be the Registry Operator for the .com, .net, and .org domains pursuant to extensive contractual obligations for both parties. In substance, NSI agreed not to restrain competition, to abide by all ICANN consensus policies, to escrow its registry data and make that data available under certain

circumstances, to pay $250,000 per year to fund the operation of ICANN, and to charge only $6 to registrars to register a domain name for one year. ICANN agreed to abide by its own rules of openness and transparency in policy-making, not to restrain competition, not to single out NSI for disparate treatment, and to ensure adequate appeal procedures for NSI.

Registrar Accreditation Agreement (RAA) (November 1999) http://www.icann.org/ra-agreement-051299.html

In order to become a registrar in the shared gTLD domain name space (currently .com, .net, and .org), an applicant must agree to terms specified by the RAA. In particular, the registrar must agree to make public the technical details and contact information for each second level domain (SLD) registered; to abide by policies to be specified by ICANN regarding the verification of information supplied by registrants; and to pay ICANN a specified fee, not to exceed $1, for each registration completed.

NSI/DoC Memorandum of Understanding http://www.networksolutions.com/nsf/agreement/

Recent amendments to the original 1993 MoU make this document a notable one, establishing the ongoing contractual relationship between NSI and the DoC. In Amendment 11 (October 1998), NSI agreed to acknowledge the authority of "newco," later designated as ICANN, to take on the powers specified in the White Paper. NSI also agreed to create the Shared Registration System by which registrars may compete in entering data into a single registry. The terms of Amendment 13 discuss NSI's obligations to registrars, in particular the terms on which competing registrars pay NSI for its registry services.

World Intellectual Property Organization (WIPO) Report

ICANN Resolutions on WIPO Proposal (May 27, 1999) http://www.icann.org/berlin/berlin-resolutions.html#2

Final WIPO Report on the Domain Name Process (April 30, 1999) http://www.icann.org/wipo/wipo_report.htm

As requested by the White Paper, the WIPO Report attempts to address the problem of cyberpirates: when an entity with no previous right to use a particular well-known mark registers a domain bearing that mark and attempts to sell the domain for profit; this blocks use by rightful owners or causes harm to the mark if its use is a lure for improper or misleading use. Trademark law requires owners of marks to aggressively police the commercial use of their mark or risk losing rights in it, so they cannot ignore the problem; furthermore, cyberpirates represent a significant threat to marks with many submarks or variations that are confusingly similar, as in mickeymouse.com, mickeymouse.net, minniemouse.com, and so on. Thus there is a huge burden of enforcement, worsened by the fact that the domain registrant might reside in a distant jurisdiction. In its final report, WIPO requested a uniform domain dispute policy across all gTLDs and assurance that the introduction of new gTLDs won’t make the situation worse. In particular, WIPO proposes a mandatory arbitration procedure for

cybersquatting disputes and a registration priority across all gTLDs for famous mark owners.

Opponents counter that WIPO only represents trademark interests at the expense of the legal rights of non-commercial users. Furthermore, potential gTLD registries and registrars not that WIPO's proposal would bind the few gTLDs to a new legal regime without altering the rules applicable to the hundreds of ccTLDs, giving those ccTLDs an unfair market advantage. Others suggest that existing law in each jurisdiction provides sufficient protection for trademark holders, that local laws in most jurisdictions do not grant special rights to famous trademark owners, and that ICANN is not the right means to establish a new global dispute resolution system.

ICANN has endorsed the principle that a uniform dispute resolution policy should be adopted for Registrars in the .com, .net, and .org Top-Level Domains (TLDs). It has asked the testbed registrars to work together to formulate a model dispute resolution policy for voluntary adoption. ICANN has also forwarded chapters three through five of the WIPO Report to the DNSO for further discussion and evaluation.

ICANN/U.S. Government Contract for the IANA Function (February 2000) http://www.icann.org/general/iana-contract-09feb00.htm

This agreement transferred the contract for fulfillment of the IANA function from USC, operating as a contractor of the Department of Defense, to ICANN. Under the agreement ICANN assumed responsibility for coordination of the assignment of technical protocol parameters, administrative functions associated with root management, assignment of IP address blocks, and other services requested by the Department of Commerce. Though both the location of the IANA and some of the key personnel remained the same, this agreement was a significant formal step in transferring technical management authority for the DNS to ICANN.

IETF/ICANN Memorandum of Understanding Concerning the Technical Work of the IANA (March 2000) http://www.icann.org/general/agreements.htm

This agreement essentially ratified the pre-existing understanding between the IETF and the IANA that the IANA would make technical changes pursuant to the decisions made by the IETF RFC process. In addition, the agreement specifies that in the event of a disagreement between the IETF and the IANA, the IAB will be the final arbiter.

FAQ about the Berkman Center's Relation to ICANN

http://cyber.harvard.edu/icann/bcisfaq

The mission of the Berkman Center is to investigate the real and possible boundaries in cyberspace between open and closed systems of code, commerce, government and education. Our work with ICANN represents the mainstay of our research into open government, constitutionalism, and cyberspace. Although we haven’t masterminded a grand experiment in which our collaborators are unwitting participants, we do feel that we are all participating in a

grand experiment that we hope will produce lots of good results—both pragmatic and academic. Please read the entire FAQ for details!

Evaluating the Uniform Domain Name Dispute Resolution Policy

<http://cyber.law.harvard.edu/icann/pressingissues2000/briefingbook/udrp-review.html>

Dori Kornfeld (dkornfel@law.harvard.edu), Harvard Law School

The document below is the work of Berkman Center student affiliates. Accordingly, it does not represent the views of the Berkman Center institutionally; rather, it presents the perspective of its authors.

The coveted dot-coms are becoming even more coveted as companies, entrepreneurs, and individuals vie for

space on the Internet.[1] The apparent assumption is that a catchy domain name is key to marketing the space

and attracting Web surfers.[2] Last year, eCompanies is said to have paid $7.5 billion for the domain name

<business.com>.[3] In 1998, the Compaq Computer Corporation paid more than $3.3 million to obtain rights to

<Altavista.com>.[4] A somewhat trickier question arises when a speculator tries to sell a domain name to the

rightful trademark holder – or to a competitor of the trademark holder – or to any interested party without realizing

the word is a trademark. Perhaps even more confounding is the situation when two companies have trademark

rights to the same word in different contexts – or only one company has the trademark but the domain name

holder has been maintaining the Web site for unrelated purposes. Suddenly, questions of rights, property,

identity, and freedom become entangled in the Web – producing what might be called a web of confusion.

Trademark Law in Cyberspace

The language of trademark law is shifting paradigms as traditional concepts are transposed to the new

communications medium. The terms “cybersquatting” and “reverse domain name hijacking” come to the fore.

Cybersquatting generally refers to the trafficking or registration of well-known trademark names with the intention

of using the mark owner’s need for the name to extort a substantial profit. Reverse domain name hijacking refers

to the bad faith attempt of a trademark owner to deprive a registered domain name holder of a domain name.[5]

These definitions, however, remain vague as new cases arise to test the bounds of peremptory claims to a

domain name.

Applying traditional trademark law to the cyberspace realm compels an expansion of prevailing standards. While

traditional trademark law generally limits protection to a specific geographic area and class of goods, domain

names cut across all geographic bounds and can identify any type of goods to the exclusion of all others. For

example, while both United Vans and United Airlines have rights to the “United” trademark in the physical world,

the Internet can reserve the domain name “united.com” for only one party. Different countries administer

contrasting trademark laws, but the conflicting legislation does little to accommodate a borderless cyberspace.

Trademarks in the physical world may legitimately be used by multiple different owners so long as the consumer

is unlikely to be confused as to the source or origin of the goods or services being offered under the brand

Does the manner in which domain names are used make the consumer more or less confused? Is the confusion

standard a reasonable or appropriate one to apply to the World Wide Web?

Generally, registrars for the .com, .net, and .org domains grant names on a “first-come, first-served” basis – with a

caveat: registrants must agree to submit to ICANN’s Uniform Domain Name Dispute Resolution Policy should

another party bring a claim against the registrant under a trademark which is identical or confusingly similar to the

domain name. At this point an administrative panel would look to the application of ICANN’s new standard of

“abusive domain name registration.”

The Rise of the Uniform Domain Name Dispute Resolution Policy

Domain name conflicts have been a pressing issue since before the establishment of ICANN. When the U.S.

government drafted the White Paper, proposing the creation of a private, non-profit corporation to administer the

Domain Name System, it specifically underscored the need for resolution of the “trademark dilemma.”[6] In 1998,

the U.S. government asked the World Intellectual Property Organization (WIPO) to conduct a study on the

regulation of trademarks in domain names. WIPO’s final report called for the institution of a uniform policy

enforced by all registrars to regulate names in the .com, .net, and .org Top Level Domains.[7] After numerous

drafts, revisions, and public comment periods, the ICANN Board formally adopted a final policy in October 1999.

[8]

The first proceeding under the policy (worldwrestlingfederation.com) commenced on December 9, 1999.[9] To

date, more than 2,000 UDRP proceedings have been initiated. Over 1,300 cases have been decided, more than

75 percent of which have resulted in a transfer of the name to the trademark owner.[10]

Fundamentals of the UDRP

The UDRP provides a quick and relatively inexpensive forum for parties to challenge domain name holders’ rights

to a name. First, the trademark owner files a complaint with an ICANN-accredited provider. The complainant can

opt for either a one-person panel or a three-person panel. The provider selects the panelist in one-person

panels. Both the respondent and complainant have discretion in the choice of panelists for three-person panels,

though the complainant still chooses the provider. Once the provider verifies that the complaint complies with

basic UDRP requirements, it sends the complaint to the domain name registrant, who must respond within twenty

days. The respondent has the discretion of opting for a three-person panel if the complainant has requested a

one-person panel, but the respondent will be required to pay one-half of the applicable fee for the three-person

panel. (Otherwise the complainant is fully responsible for the fee.[11]) Upon receiving the registrant’s response,

the provider has five days to appoint an arbitration panel of one or three members, which must issue a decision

within two weeks. The domain holder has ten days to appeal an adverse decision to a court of mutual jurisdiction

(either the jurisdiction of the registrar or the jurisdiction of the domain holder, whichever is selected by the

complainant). The remedies available to a complainant are limited to the transfer or cancellation of the domain

name; no monetary damages are awarded.[12]

To prevail in an administrative proceeding, the complainant must prove all of the following three elements (§4.a):

1. The domain name is identical or confusingly similar to a trademark or service mark in

which the complainant has rights.

2. The domain name holder has no rights or legitimate interests in respect of the domain

name.

3. The domain name has been registered and is being used in bad faith.[13]

Failure to prove any one of these would, by the language of the Policy, cause the complaint to fail. However,

many opinions have held that proof of one element may also establish proof of another.[14] The UDRP provides

several criteria to distinguish “rights or legitimate interests” and “bad faith.” (See “Definitions” section below.)

Little statistical data is available to track the progress of the UDRP to date. The numbers of wins and losses do

not reveal the basis for panel decisions; therefore the actual text of the opinions, all of which must be published

online, must be searched to properly analyze the efficacy of the procedure. Available search technology makes

this an arduous task.

Providers

ICANN delegates responsibility for the resolution of domain name disputes to independent, presumably impartial

service providers, yet questions have been raised as to whether the system adequately prevents bias.

To date, ICANN has accredited four service providers – CPR Institute for Dispute Resolution, eResolution, The

National Arbitration Forum, and the World Intellectual Property Organization.[15] ICANN particularly considers

three attributes when evaluating an applicant: the applicant’s record of competently handling the administrative

aspects of alternative dispute resolution proceedings, the applicant’s submission of a list of at least twenty highly

qualified and neutral individuals to serve as panelists, and the consistency of the applicant’s supplemental rules

and procedures with the UDRP rules and procedures.[16]

Some critics contend that by allowing complainants to choose the provider, the selection process is automatically

skewed to the complainants’ favor. Because the trademark owner is generally the complainant and usually pays

the fee, the inference is that providers have an economic incentive to favor trademark holders. Unlike most

private arbitrations, the parties do not negotiate the designation of the specific provider in advance. Although

respondents are able to opt for a three-member panel when the complainant has requested arbitration by a one-

member panel, the complainant may still retain an advantage. The complainant and respondent may each

nominate three candidates for a respective position on the panel and are free to suggest panelists that belong to

any of the accredited providers, although the parties have no way of knowing whether these individuals will be

available or eligible to serve. The host provider chooses the third panelist and, in the event that none of a party’s

nominees are available, also gets to appoint a substitute panelist. Therefore, it is entirely possible that all three

panelists may be selected by the host provider, who was selected in the first instance by the complainant.

Definitions

The UDRP was created to establish a uniform means of administering domain name conflicts. It is difficult to

provide consistent standards, however, when its key terms are both vague and unfamiliar – and perhaps

intentionally so, given the variety of extant trademark laws and concepts. Several reported decisions have

revealed that different panelists have seriously conflicting interpretations of these terms. Consequently, after

1,300 decisions, domain name registrants are still somewhat unclear as to which types of uses would constitute

“bad faith” as opposed to “rights or legitimate interests.” Both parties have relied on the ambiguities of the

guidelines to assert their respective contentions.

Bad Faith

A complainant must prove that a domain name holder has both registered and used a domain name “in bad faith”

in order to prevail in a UDRP proceeding, yet the concept itself is defined inconclusively. The UDRP lists four

circumstances that, in particular but without limitation, can serve as evidence that a domain name has been

registered and used in bad faith (§4.b):

(i) circumstances indicating that you have registered or you have acquired the domain name primarily for the purpose of selling, renting, or otherwise transferring the domain name registration to the complainant who is the owner of the trademark or service mark or to a competitor of that complainant, for valuable consideration in excess of your documented out-of-pocket costs directly related to the domain name; or

(ii) you have registered the domain name in order to prevent the owner of the trademark or service mark from reflecting the mark in a corresponding domain name, provided that you have engaged in a pattern of such conduct; or

(iii) you have registered the domain name primarily for the purpose of disrupting the business of a competitor; or

(iv) by using the domain name, you have intentionally attempted to attract, for commercial gain, Internet users to your web site or other on-line location, by creating a likelihood of confusion with the complainant's mark as to the source, sponsorship, affiliation, or endorsement of your web site or location or of a product or service on your web site or location.[17]

One unresolved issue is how broadly the term “use” can be construed within the context of “bad faith.” The panel

in Telstra Corporation Limited v. Nuclear Marshmallows (telstra.org) determined that registration alone may be

sufficient to establish bad faith in particular circumstances, despite the lack of any other overt action.[18] The

respondent’s domain name did not resolve to a Web site or other online presence, and the respondent could not

be reached through its contact information. In Loblaws, Inc. v. Yogeninternational (presidentschoicesocks.com),

however, the panel found that inactive use was insufficient evidence of “bad faith” and allowed the respondent to

retain the name.[19] It noted that the domain name may have been registered in bad faith, but concluded that the

requisite bad faith usage had not been established by the display of a standard “under construction” page.[20]

Rights and Legitimate Interests

A respondent can defend its retention of a domain name by establishing rights or legitimate interests in the name.

The UDRP (§4.c) cites some examples:

(i) before any notice to you of the dispute, your use of, or demonstrable preparations to use, the domain name or a name corresponding to the domain name in connection with a bona fide offering of goods or services; or

(ii) you (as an individual, business, or other organization) have been commonly known by the domain name, even if you have acquired no trademark or service mark rights; or

(iii) you are making a legitimate noncommercial or fair use of the domain name, without intent for commercial gain to misleadingly divert consumers or to tarnish the trademark or service mark at issue.[21]

Despite what seems to be clear language, it should be noted that at least one panel failed to recognize such

and legitimate interests as a complete defense against a registered mark owner. In Fiber-Shield Industries, Inc v.

Fiber Shield LTD (fibershield.net), the respondent had operated a legitimate, non-competing business under the

name for more than ten years but nevertheless lost the domain registration.[22]

Fair Use

The defense of “fair use”[23] as a right or legitimate interest has been less-than-enthusiastically received in UDRP

proceedings, perhaps because “free speech” is a concept not widely adopted outside the U.S. Some panelists

seem to give greater weight to the “free” part of “free speech” and will discount such claims where there is any

indication of an attempt to obtain commercial gain. One such case is Wal-Mart Stores, Inc. v. Walsucks and

Walmarket Puerto Rico (walmartcanadasucks.com, wal-martcanadasucks.com, walmartusucks.com,

walmartpuertorico.com, and walmartpuertoricosucks.com).[24] Although the Canadian respondent defended his

sites as “freedom of expression forums of complaint against Wal-Mart,” the panel rejected his contention, noting

that the respondent had offered his domain names to the corporation for purchase. The panel found the domain

names to be confusingly similar to the “Walmart” trademark, despite the “sucks” appendage, explaining that

confusion could arise if a Web surfer were to type the company’s name into an Internet search engine. Thus far,

nine completed UDRP proceedings have concerned a registrant’s use of the phrase “sucks,” and all nine disputes

have resulted in the transfer of the domain name.[25]

Generic Names

Generic words generally are not protected under trademark law due to the commonness of the word and the

interest in preserving the word’s utility in multiple contexts. Although the word may be incorporated into a

trademark with another word or phrase, the generic word itself is normally considered to be public domain. The

panel iterated such reasoning in CRS Technology Corp. v. Condenet, Inc. (concierge.com), declaring that “the

first person or entity to register the domain name should prevail in circumstances such as these where the domain

name is a generic word.”[26]

Administrative panels do not consistently apply trademark law to generic words, however. In J. Crew Int’l v.

crew.com (crew.com), the panel split in a decision over rights to the generic word “crew” in response to a

complaint by J.Crew, a leading retailer of men’s and women’s apparel.[27] The respondent had registered or

acquired more than 50 domain names consisting of trademarks or other generic words primarily for the purpose of

selling, renting, or otherwise transferring the names. The majority of the panel determined that the domain name

<crew.com> is identical to the trademark “crew.” It concluded that, given the respondent’s speculative behavior

and awareness of the trademark, the domain name should be transferred to the complainant. The dissenting

panelist contended that “the majority seems to assume that a trademark owner has some sort of God-given right

to use the trademark to the exclusion of others” and warned that the majority’s decision “creates a dangerous and

unauthorized situation whereby the registration and use of generic words as domains can be prevented by

trademark owners wishing to own their generic trademarks in gross.”

Bulk registrations

The case that gave rise to the claim of cybersquatting turned on the fact that the defendant’s registration and sale

of domain names identical to well-known trademarks in bulk established proof of commercial activity, which is a

necessary element of infringement under U.S. trademark law.[28] Bulk registrations, however, may also

constitute a legitimate business in vanity e-mail or domain name resales, and panels have recognized the

difference in many, but not all, cases.[29]

Procedure

Although efficiency is often lauded as one of the benefits of the UDRP, the proceeding’s truncated nature may not

be suitable for relatively complex cases involving a variety of claims and factual assertions. Administrative panels

generally prohibit in-person hearings, including teleconferences, video conferences, and web conferences. The

process includes no testimony, cross-examination, briefing, or argument; moreover, the arbitration grants no

power for discovery aside from the ability to request additional documents. Rebuttals are limited to the discretion

of the panelists. The UDRP has no mechanism for evidentiary review; therefore facts, such as trademark rights,

may be merely alleged. Photocopies of trademark certificates, copies of advertisements, or letterhead are usually

attached to a complaint as exhibits, but the documents need not be authenticated. More difficulty arises when the

complainant owns a common-law mark and cannot provide any registration at all. Often the panelist must make a

determination on the validity or existence of alleged trademark rights despite the fact that many panelists have no

particular expertise in trademark law.

The panel in Document Technologies, Inc. v. International Electronic Communications Inc. (htmlease.com) noted

the limited capacity of UDRP proceedings.[30] Responding to the complainant’s contention that cross-

examination of the respondent’s evidence would prove bad faith registration and use, the panel said that such a

matter should be resolved in “a forum, like a United States court, that permits for a more probing, searing search

for the truth. This proceeding is not conducive to such credibility determinations given the lack of discovery and,

in the normal course, the lack of live testimony.” The minimal evidentiary requirements of UDRP proceedings

render the system difficult to evaluate.

Choice of Law

The UDRP provides little guidance as to which laws should prevail when two parties belong to different

jurisdictions with contradictory rules. The only explicit reference in the Rules to choice of law questions can be

found in provision 15(a): “A panel shall decide a complaint on the basis of the statements and documents

submitted and in accordance with the Policy, these Rules and any rules and principles of law that it deems

applicable.”[31] As national trademark laws enforce different standards for such uses as parody or criticism,

panelists may be left with the burden of trying to balance one nation’s laws and interests against another’s.

Several cases demonstrate the ambiguity of the choice of law question. In Excelentisimo Ayuntamiento de

Barcelona v. Barcelona.com Inc. (barcelona.com), a conflict existed between U.S. law’s limits on protection of

geographical names and Spanish law’s provision for such protection.[32] The panel ruled to transfer the domain

name from the U.S. travel agent registrant to the City Government of Barcelona, declaring that the holder “is

definitely taking advantage of the normal confusion of the public which by using a Barcelona route in Internet

would normally expect to reach some official body or representative of the city of Barcelona itself.” In Tourism

and Corporate Automation Ltd. v. TSI Ltd. (tourplan.com) , the panelist dismissed both parties’ jurisdictional laws

altogether. A complainant from New Zealand with offices in London challenged a registration made in Australia

by an Australian citizen.[33] The panelist, who was from the United States, declared that the UDRP specifies “no

mandatory body of law to follow in making a decision” and that he would therefore apply U.S. law: “I determine

that it is not feasible for any given arbitrator or panel to be familiar with all bodies of trademark and unfair trade

law in all countries reached by the Internet, and that it is therefore sufficient for this proceeding that I am

reasonably familiar with U.S. trademark law.”

Precedent

Despite the lack of reliable evidentiary mechanisms, some panels rely on precedent established by previous

cases. The legitimacy of such dependence, however, becomes somewhat dubious given that all pleadings

viewed by a panel remain confidential. Although all UDRP final decisions, absent exceptional circumstances, are

posted on a publicly accessible Web site, viewers are at the mercy of the opinion writer for a full and complete

explanation of the panel’s rationale. While precedent may be useful in providing panelists with some degree of

guidance, the ambiguities of both fact and law in many cases may provide a slippery slope for adjudication in any

type of international forum.

New gTLDs

Currently ICANN is reviewing applications for new generic Top Level Domains (in addition to the .com, .org,

and .net suffixes).[34] Not all of the applicants propose to adopt the UDRP. The process can become

increasingly complex as one cybersquatter registers in multiple TLDs under multiple dispute procedures.

Providers should be consulted to see if the system is cost-effective from their perspective.

Conclusion

The UDRP serves an important function to resolve domain name disputes in an out-of-court proceeding that can

be implemented on an international basis. The question is whether the process is as fair and effective as it

be, and the answer is somewhat elusive. The UDRP certainly has shortcomings, some more acute than others:

inconsistent and sometimes uninformed decisions, vague terminology, a significant market gap among providers

suggesting inequalities of service, and insufficient data to review the justice of decisions or process.

Suggestions to consider:

1. Establish a commission consisting of UDRP panelists, UDRP provider management, trademark experts, arbitration experts, mark holders, domain holders, and eminent jurists to review the UDRP process.

2. Design a set of objective criteria to analyze the fairness and efficacy of the UDRP and its implementation by the respective providers. Require providers to collect and forward more objective data for review (e.g., number of defaults, number of pro se participants, amount of time spent per fee dollar, evaluation by users of procedure interface, number of unregistered marks). Make recommendations based on analysis. Review inconsistent decisions in particular and randomly sample others. Perform this review periodically.

3. Require more training for panelists in trademark principles.

4. Consider more precise definitions and provide more examples for terms such as fair use and rights and legitimate interests (particularly where panel decisions have been inconsistent).

5. Recommend a choice of law provision to guide disputes among complainants and respondents of diverse jurisdictions.

6. Establish guidelines for evidentiary documentation, especially for pro se and common law mark owners and owners whose mark claim is premature.

7. Establish guidelines for the refusal of cases.

8. Extend time to appeal a decision by five days.

9. Provide a fee-based option to domain name holders to file an internal appeal to a longer-tenured panel of experienced panelists (selected by the Providers).

10. Provide a complaint forum whereby parties may contend an abuse of procedure by a panelist. A pattern of complaints directed toward a particular panelist or provider may warrant investigation.

11. Request providers to design a mechanism to indicate to users which panelists are currently available to serve

on three-member panels.

12. Study mechanisms for allowing the domain holder to have a greater role in the choice of provider, such as allowing the holder to remove the proceeding to the venue of a different provider upon payment of the full fee.

The UDRP provides a basis for domain dispute adjudication, but the methodology must be examined in light of the progress thus far. If the UDRP is to successfully counter “cybersquatting,” and “reverse domain name hijacking,” it must establish relatively consistent standards to provide guidance to domain name registrants. Within less than a year, thousands of parties have sought the UDRP to resolve their conflicts. If the result is the emergence of a new area of international law, it is vital that principles of fairness, diligence, clarity, and equitability govern the application of the UDRP.

[1] More than 19 million domain names with the “.com” suffix have been registered. The total number of domain name registrations exceeds 31 million. NetNames, DomainStats, at http://www.domainstats.com/ (last visited Oct. 29, 2000).

[2] See Mark P. Wine, Cynthia A. Lock, Val H. Steiglitz, John B. Lunseth II, and Michael J. McGuire, Protecting Your Corporate Client’s Most Valuable Intangible Asset: Its Name, 67 Def. Couns. J. 285 (July 2000). [3] Mark Radcliffe and Dan Cook, Trading on Your Brand Name: Preserving Trademarks in Domain Names is Key to Doing Business on the Web, American Lawyer, Feb. 14, 2000. [4] Id. [5] A classic case of reverse domain name hijacking was the attempt of the maker of Gumby and Pokey toys to deprive a 12-year-old boy, nicknamed Pokey, of his domain name. Olivia Maria Baratta and Dana L. Hanaman, A Global Update on the Domain Name System and the Law: Alternative Dispute Resolution for Increasing Internet Competition – Oh, the Times They Are A-Changin’!, 8 Tul. J. Int'l & Comp. L. 325, 360 (Spring 2000). [6] “For cyberspace to function as an effective commercial market, businesses must have confidence that their trademarks can be protected. On the other hand, management of the Internet must respond to the needs of the Internet community as a whole, and not trademark owners exclusively.” Management of Internet Names and Addresses, 63 Fed. Reg. 31, available at http://www.ntia.doc.gov/ntiahome/domainname/6_5_98dns.htm (1998). [7] See World Intellectual Property Organization, The Management of Internet Names and Addresses: Intellectual Property Issues, available at http://wipo2.wipo.int/process1/report/finalreport.html (April 30, 1999). [8] ICANN, Timeline for the Formulation and Implementation of the Uniform Domain-Name Dispute-Resolution Policy, available at http://www.icann.org/udrp/udrp-schedule.htm (last modified Oct. 17, 2000). For a critique of the consensus process, see Michael Froomkin, Comments on ICANN Uniform Dispute Policy: A Catalog of Critical Process Failures; Progress on Substance; More Work Needed, available at www.law.Miami.edu/~amf/icann-udp.htm (Oct. 13, 1999). [9] Id. [10] ICANN, Statistical Summary of Proceedings Under Uniform Domain Name Dispute Resolution Policy, available at http://www.icann.org/udrp/proceedings-stat.htm (last modified Oct. 27, 2000). Of 2,143 proceedings (other than those terminated for recommencement), 1,392 have been decided. A name was transferred in 1,070 cases, cancelled in 15 cases, transferred/cancelled in one case. The respondent was able to retain the domain name in 296 cases. Ten cases resulted in split decisions. An additional 209 proceedings resulted in a settlement or dismissal. [11] Fees generally range from $750 to $4,500, depending on the provider, the number of domain names being challenged, and the number of panelists. [12] ICANN, Rules for Uniform Domain Name Dispute Resolution Policy, available at http://www.icann.org/udrp/udrp-rules-24oct99.htm (last modified Jan. 3, 2000). [13] ICANN, Uniform Domain Name Dispute Resolution Policy, available at http://www.icann.org/udrp/udrp-policy-24oct99.htm (last modified June 4, 2000). [14] See, e.g., ABF Freight System, Inc. v. American Legal (timekeeper.com) D2000-0185 (commenced Mar. 22, 2000), available at http://arbiter.wipo.int/domains/decisions/html/d2000-0185.html. The panel found that registration alone was sufficient to establish bad faith. [15] ICANN, Approved Providers for Uniform Domain Name Dispute Resolution Policy, available at http://www.icann.org/udrp/approved-providers.htm (last modified Oct. 17, 2000). [16] ICANN, Information Concerning Approval Process for Dispute-Resolution Service Providers, available at http://www.icann.org/udrp/udrp-provider-approval-process.htm (last modified May 6, 2000). [17] Supra note 13. [18] Telstra Corporation Limited v. Nuclear Marshmallows (telstra.org) D2000-0003 (commenced Jan. 12, 2000), available at http://arbiter.wipo.int/domains/decisions/html/d2000-0003.html. The complainant was Telstra Corporation Limited, the largest company listed on the Australian stock exchange, and the respondent was Nuclear Marshmallows, an unregistered business

name of an unidentifiable business entity with an Australian address.[19] Loblaws, Inc. v. Yogeninternational (presidentschoicesocks.com) AF-0164 (commenced Apr. 3, 2000), available at http://www.eresolution.ca/services/dnd/decisions/0164.htm.[20] The panel distinguished its opinion from Telstra in that the complainant did not deliberately conceal contact information or register the complainant’s actual mark (“President’s Choice” as opposed to “President’s Choice Socks”). [21] Supra note 13. [22] Fiber-Shield Industries, Inc v. Fiber Shield LTD (fibershield.net) FA0001000092054 (commenced Jan. 20, 2000), available at http://www.arbforum.com/domains/decisions/92054.html. [23] General forms of fair use include critical commentary, parody, and political speech. [24] Wal-Mart Stores, Inc. v. Walsucks and Walmarket Puerto Rico (walmartcanadasucks.com, wal-martcanadasucks.com, walmartusucks.com, walmartpuertorico.com, and walmartpuertoricosucks.com) D2000-0477 (commenced May 31, 2000), available at http://arbiter.wipo.int/domains/decisions/html/d2000-0477.html. [25] See D2000-0477, D2000-0583, D2000-0584, D2000-0585, D2000-0636, D2000-0681, D2000-0662, FA0095080, and D2000-0996. [26] CRS Technology Corp. v. Condenet, Inc. (concierge.com), FA0093547 (commenced Feb. 3, 2000), available at http://www.arbforum.com/domains/decisions/93547.html. [27] J. Crew Int’l v. crew.com (crew.com) D2000-0054 (commenced Feb. 16, 2000), available at http://arbiter.wipo.int/domains/decisions/html/d2000-0054.html. [28] See Panavision Int'l, L.P.v. Toeppen, 141 F.3d 1316 (9th Cir. 1998). [29] See, e.g., Allocation Network GmbH v. Steve Gregory (allocation.com) D2000-0016 (commenced Feb. 7, 2000), available at http://arbiter.wipo.int/domains/decisions/html/d2000-0016.html. [30] Document Technologies, Inc. v. International Electronic Communications Inc. (htmlease.com) D2000-0270 (commenced Apr. 17, 2000), available at http://arbiter.wipo.int/domains/decisions/html/d2000-0270.html. [31] Supra note 12. [32] Excelentisimo Ayuntamiento de Barcelona v. Barcelona.com Inc. (barcelona.com) D2000-0505 (commenced June 9, 2000), available at http://arbiter.wipo.int/domains/decisions/html/d2000-0505.html. [33] Tourism and Corporate Automation Ltd. v. TSI Ltd. (tourplan.com) AF-0096 (commenced Feb. 7, 2000), available at http://www.eresolution.ca/services/dnd/decisions/0096.htm. [34] See ICANN, TLD Application Review Update, available at http://www.icann.org/tlds/tld-review-update-23oct00.htm (last modified Oct. 23, 2000).

Last updated on 31 October 2000

Uniform Domain Name Dispute Resolution Policy

Policy Adopted: August 26, 1999 Implementation Documents Approved: October 24, 1999

Notes:

1. This policy is now in effect. See www.icann.org/udrp/udrp-schedule.htm for the implementation schedule.

2. This policy has been adopted by all accredited domain-name registrars for domain names ending in .com, .net, and .org. It has also been adopted by certain managers of country-code top-level domains (e.g., .nu, .tv, .ws).

3. The policy is between the registrar (or other registration authority in the case of a country-code top-level domain) and its customer (the domain-name holder or registrant). Thus, the policy uses "we" and "our" to refer to the registrar and it uses "you" and "your" to refer to the domain-name holder.

Uniform Domain Name Dispute Resolution Policy

(As Approved by ICANN on October 24, 1999)

1. Purpose. This Uniform Domain Name Dispute Resolution Policy (the "Policy") has been adopted by the Internet Corporation for Assigned Names and Numbers ("ICANN"), is incorporated by reference into your Registration Agreement, and sets forth the terms and conditions in connection with a dispute between you and any party other than us (the registrar) over the registration and use of an Internet domain name registered by you. Proceedings under Paragraph 4 of this Policy will be conducted according to the Rules for Uniform Domain Name Dispute Resolution Policy (the "Rules of Procedure"), which are available at www.icann.org/udrp/udrp-rules-24oct99.htm, and the selected administrative-dispute-resolution service provider's supplemental rules.

2. Your Representations. By applying to register a domain name, or by asking us to maintain or renew a domain name registration, you hereby represent and warrant to us that (a) the statements that you made in your Registration Agreement are complete and accurate; (b) to your knowledge, the registration of the domain name will not infringe upon or otherwise violate the rights of any third party; (c) you are not registering the domain name for an unlawful purpose; and (d) you will not knowingly use the domain name in violation of any applicable laws or regulations. It is your responsibility to determine whether your domain name registration infringes or violates someone else's rights.

3. Cancellations, Transfers, and Changes. We will cancel, transfer or otherwise make changes to domain name registrations under the following circumstances:

a. subject to the provisions of Paragraph 8, our receipt of written or appropriate electronic instructions from you or your authorized agent to take such action;

b. our receipt of an order from a court or arbitral tribunal, in each case of competent jurisdiction, requiring such action; and/or

c. our receipt of a decision of an Administrative Panel requiring such action in any administrative proceeding to which you were a party and which was conducted under this Policy or a later version of this Policy adopted by ICANN. (See Paragraph 4(i) and (k) below.)

We may also cancel, transfer or otherwise make changes to a domain name registration in accordance with the terms of your Registration Agreement or other legal requirements.

4. Mandatory Administrative Proceeding.

This Paragraph sets forth the type of disputes for which you are required to submit to a mandatory administrative proceeding. These proceedings will be conducted before one of the administrative-dispute-resolution service providers listed at www.icann.org/udrp/approved-providers.htm (each, a "Provider").

a. Applicable Disputes. You are required to submit to a mandatory administrative proceeding in the event that a third party (a "complainant") asserts to the applicable Provider, in compliance with the Rules of Procedure, that

(i) your domain name is identical or confusingly similar to a trademark or service mark in which the complainant has rights; and

(ii) you have no rights or legitimate interests in respect of the domain name; and

(iii) your domain name has been registered and is being used in bad faith.

In the administrative proceeding, the complainant must prove that each of these three elements are present.

b. Evidence of Registration and Use in Bad Faith. For the purposes of Paragraph 4(a)(iii), the following circumstances, in particular but without limitation, if found by the Panel to be present, shall be evidence of the registration and use of a domain name in bad faith:

(i) circumstances indicating that you have registered or you have acquired the domain name primarily for the purpose of selling, renting, or otherwise transferring the domain name registration to the complainant who is the owner of the trademark or service mark or to a competitor of that complainant, for valuable consideration in excess of your documented out-of-pocket costs directly related to the domain name; or

(ii) you have registered the domain name in order to prevent the owner of the trademark or service mark from reflecting the mark in a corresponding domain name, provided that you have engaged in a pattern of such conduct; or

(iii) you have registered the domain name primarily for the purpose of disrupting the business of a competitor; or

(iv) by using the domain name, you have intentionally attempted to attract, for commercial gain, Internet users to your web site or other on-line location, by creating a likelihood of confusion with the complainant's mark as to the source, sponsorship, affiliation, or endorsement of your web site or location or of a product or service on your web site or location.

c. How to Demonstrate Your Rights to and Legitimate Interests in the Domain Name in Responding to a Complaint. When you receive a complaint, you should refer to Paragraph 5 of the Rules of Procedure in determining how your response should be prepared. Any of the following circumstances, in particular but without limitation, if found by the Panel to be proved based on its evaluation of all evidence presented, shall demonstrate your rights or legitimate interests to the domain name for purposes of Paragraph 4(a)(ii):

(i) before any notice to you of the dispute, your use of, or demonstrable preparations to use, the domain name or a name corresponding to the domain name in connection with a bona fide offering of goods or services; or

(ii) you (as an individual, business, or other organization) have been commonly known by the domain name, even if you have acquired no trademark or service mark rights; or

(iii) you are making a legitimate noncommercial or fair use of the domain name, without intent for commercial gain to misleadingly divert consumers or to tarnish the trademark or service mark at issue.

d. Selection of Provider. The complainant shall select the Provider from among those approved by ICANN by submitting the complaint to that Provider. The selected Provider will administer the proceeding, except in cases of consolidation as described in Paragraph 4(f).

e. Initiation of Proceeding and Process and Appointment of Administrative Panel. The Rules of Procedure state the process for initiating and conducting a proceeding and for appointing the panel that will decide the dispute (the "Administrative Panel").

f. Consolidation. In the event of multiple disputes between you and a complainant, either you or the complainant may petition to consolidate the disputes before a single Administrative Panel. This petition shall be made to the first Administrative Panel appointed to hear a pending dispute between the parties. This Administrative Panel may consolidate before it any or all such disputes in its sole discretion, provided that the disputes being consolidated are governed by this Policy or a later version of this Policy adopted by ICANN.

g. Fees. All fees charged by a Provider in connection with any dispute before an Administrative Panel pursuant to this Policy shall be paid by the complainant, except in cases where you elect to expand the Administrative Panel from one to three panelists as provided in Paragraph 5(b)(iv) of the Rules of Procedure, in which case all fees will be split evenly by you and the complainant.

h. Our Involvement in Administrative Proceedings. We do not, and will not, participate in the administration or conduct of any proceeding before an Administrative Panel. In addition, we will not be liable as a result of any decisions rendered by the Administrative Panel.

i. Remedies. The remedies available to a complainant pursuant to any proceeding before an Administrative Panel shall be limited to requiring the cancellation of your domain name or the transfer of your domain name registration to the complainant.

j. Notification and Publication. The Provider shall notify us of any decision made by an Administrative Panel with respect to a domain name you have registered with us. All decisions under this Policy will be published in full over the Internet, except when an Administrative Panel determines in an exceptional case to redact portions of its decision.

k. Availability of Court Proceedings. The mandatory administrative proceeding requirements set forth in Paragraph 4 shall not prevent either you or the complainant from submitting the dispute to a court of competent jurisdiction for independent resolution before such mandatory administrative proceeding is commenced or after such proceeding is concluded. If an Administrative Panel decides that your domain name registration should be canceled or transferred, we will wait ten (10) business days (as observed in the location of our principal office) after we are informed by the applicable Provider of the Administrative Panel's decision before implementing that decision. We will then implement the decision unless we have received from you during that ten (10) business day period official documentation (such as a copy of a complaint, file-stamped by the clerk of the court) that you have commenced a lawsuit against the complainant in a jurisdiction to which the complainant has submitted under Paragraph 3(b)(xiii) of the Rules of Procedure. (In general, that jurisdiction is either the location of our principal office or of your address as shown in our Whois database. See Paragraphs 1 and 3(b)(xiii) of the Rules of Procedure for details.) If we receive such documentation within the ten (10) business day period, we will not implement the Administrative Panel's decision, and we will take no further action, until we receive (i) evidence satisfactory to us of a resolution between the parties; (ii) evidence satisfactory to us that your lawsuit has been dismissed or withdrawn; or (iii) a copy of an order from such court dismissing your lawsuit or ordering that you do not have the right to continue to use your domain name.

5. All Other Disputes and Litigation. All other disputes between you and any party other than us regarding your domain name registration that are not brought pursuant to the mandatory administrative proceeding provisions of Paragraph 4 shall be resolved between you and such other party through any court, arbitration or other proceeding that may be available.

6. Our Involvement in Disputes. We will not participate in any way in any dispute between you and any party other than us regarding the registration and use of your domain name. You shall not name us as a party or otherwise include us in any such proceeding. In the event that we are named as a party in any such proceeding, we reserve the right to raise any and all defenses deemed appropriate, and to take any other action necessary to defend ourselves.

7. Maintaining the Status Quo. We will not cancel, transfer, activate, deactivate, or otherwise change the status of any domain name registration under this Policy except as provided in Paragraph 3 above.

8. Transfers During a Dispute.

a. Transfers of a Domain Name to a New Holder. You may not transfer your domain name registration to another holder (i) during a pending administrative proceeding brought pursuant to Paragraph 4 or for a period of fifteen (15) business days (as observed in the location of our principal place of business) after such proceeding is concluded; or (ii) during a pending court proceeding or arbitration commenced regarding your domain name unless the party to whom the domain name registration is being transferred agrees, in writing, to be bound by the decision of the court or arbitrator. We reserve the right to cancel any transfer of a domain name registration to another holder that is made in violation of this subparagraph.

b. Changing Registrars. You may not transfer your domain name registration to another registrar during a pending administrative proceeding brought pursuant to Paragraph 4 or for a period of fifteen (15) business days (as observed in the location of our principal place of business) after such proceeding is concluded. You may transfer administration of your domain name registration to another registrar during a pending court action or arbitration, provided that the domain name you have registered with us shall continue to be subject to the proceedings commenced against you in accordance with the terms of this Policy. In the event that you transfer a domain name registration to us during the pendency of a court action or arbitration, such dispute shall remain subject to the domain name dispute policy of the registrar from which the domain name registration was transferred.

9. Policy Modifications. We reserve the right to modify this Policy at any time with the permission of ICANN. We will post our revised Policy at <URL> at least thirty (30) calendar days before it becomes effective. Unless this Policy has already been invoked by the submission of a complaint to a Provider, in which event the version of the Policy in effect at the time it was invoked will apply to you until the dispute is over, all such changes will be binding upon you with respect to any domain name registration dispute, whether the dispute arose before, on or after the effective date of our change. In the event that you object to a change in this Policy, your sole remedy is to cancel your domain name registration with us, provided that you will not be entitled to a refund of any fees you paid to us. The revised Policy will apply to you until you cancel your domain name registration.

Comments concerning the layout, construction and functionality of this site should be sent to webmaster@icann.org.

Page Updated 17-May-2002 ©2000, 2002 The Internet Corporation for Assigned Names and Numbers. All rights reserved.

On September 28, 1999, ICANN announced tentative agreement with the United States Department of Commerce and Network Solutions, Inc. on a series of agreements that will put the newly introduced competition among registrars in the .com, .net, and .org TLDs on a permanant and firmer footing. After written and oral public comments, these agreements were revised in several respects and were adopted by the ICANN Board on November 4, 1999.

One of these agreements is a revised registrar accreditation agreement to be entered by ICANN with registrars. Registrars with accreditation agreements dated before November 4, 1999 may substitute this agreement for their existing agreements.

To continue to register names with the .com, .net, and .org registry operated by NSI after November 30, 1999, registrars must have entered a new Registrar License and Agreement with NSI and the revised ICANN accreditation agreement (or other version of the accreditation agreement dated after November 4, 1999). The text of the revised accreditation agreement appears below.

REGISTRAR ACCREDITATION AGREEMENT

Table of Contents

I. DEFINITIONS

II. TERMS AND CONDITIONS OF AGREEMENT

A. Accreditation. B. Registrar Use of ICANN Name. C. General Obligations of ICANN. D. General Obligations of Registrar. E. Submission of SLD Holder Data to Registry. F. Public Access to Data on SLD Registrations. G. Retention of SLD Holder and Registration Data. H. Rights in Data. I. Data Escrow. J. Business Dealings, Including with SLD Holders.

Registrar Accreditation Agreement

(Approved November 4, 1999) (Posted November 9, 1999)

K. Domain-Name Dispute Resolution. L. Accreditation Fees. M. Specific Performance. N. Termination of Agreement. O. Term of Agreement; Renewal; Right to Substitute Updated Agreement. P. Resolution of Disputes Under This Agreement. Q. Limitations on Monetary Remedies for Violations of this Agreement. R. Handling by ICANN of Registrar-Supplied Data. S. Miscellaneous.

This REGISTRAR ACCREDITATION AGREEMENT ("Agreement") is by and between the Internet Corporation for Assigned Names and Numbers, a not-for-profit corporation, and ________________________________ ("Registrar"), a ___________________, and shall be deemed made on __________, 1999, at Los Angeles, California, USA.

I. DEFINITIONS

As used in this Agreement, the following terms shall have the following meanings:

A. "Accredit" means to identify and set minimum standards for the performance of registration functions, to recognize persons or entities meeting those standards, and to enter into an accreditation agreement that sets forth the rules and procedures applicable to the provision of registration services.

B. A "Consensus Policy" is one adopted by ICANN as follows:

1. "Consensus Policies" are those adopted based on a consensus among Internet stakeholders represented in the ICANN process, as demonstrated by (1) the adoption of the policy by the ICANN Board of Directors, (2) a recommendation that the policy should be adopted, by at least a two-thirds vote of the council of the ICANN Supporting Organization to which the matter is delegated, and (3) a written report and supporting materials (which must include all substantive submissions to the Supporting Organization relating to the proposal) that (i) documents the extent of agreement and disagreement among impacted groups, (ii) documents the outreach process used to seek to achieve adequate representation of the views of groups that are likely to be impacted, and (iii) documents the nature and intensity of reasoned support and opposition to the proposed policy.

2. In the event that Registrar disputes the presence of such a consensus, it shall seek review of that issue from an Independent Review Panel established under ICANN's bylaws. Such review must be sought within fifteen working days of publication of the Board's action adopting the policy. The decision of the panel shall be based on the report and supporting materials required by Section I.B.1 above. In the event that Registrar seeks review and the Panel sustains the Board's determination that the policy is based on a consensus among Internet stakeholders represented in the ICANN process, then Registrar must implement such policy unless it promptly seeks and obtains a stay or injunctive relief under Section II.P.

3. In the event, following a decision by the Independent Review Panel convened under Section I.B.2 above, that Registrar still disputes the presence of such a consensus, it may seek further review of that issue within fifteen working days of publication of the decision in accordance with the dispute-resolution procedures set forth in Section II.P below; provided, however, that Registrar must continue to implement the policy unless it has obtained a stay or injunctive relief

under Section II.P or a final decision is rendered in accordance with the provisions of Section II.P that relieves Registrar of such obligation. The decision in any such further review shall be based on the report and supporting materials required by Section I.B.1 above.

4. A policy adopted by the ICANN Board of Directors on a temporary basis, without a prior recommendation by the council of an ICANN Supporting Organization, shall also be considered to be a Consensus Policy if adopted by the ICANN Board of Directors by a vote of at least two-thirds of its members, and if immediate temporary adoption of a policy on the subject is necessary to maintain the stability of the Internet or the operation of the domain name system, and if the proposed policy is as narrowly tailored as feasible to achieve those objectives. In adopting any policy under this provision, the ICANN Board of Directors shall state the period of time for which the policy is temporarily adopted and shall immediately refer the matter to the appropriate Supporting Organization for its evaluation and review with a detailed explanation of its reasons for adopting the temporary policy and why the Board believes the policy should receive the consensus support of Internet stakeholders. If the period of time for which the policy is adopted exceeds 45 days, the Board shall reaffirm its temporary adoption every 45 days for a total period not to exceed 180 days, in order to maintain such policy in effect until such time as it meets the standard set forth in Section I.B.1. If the standard set forth in Section I.B.1 above is not met within the temporary period set by the Board, or the council of the Supporting Organization to which it has been referred votes to reject the temporary policy, it will no longer be a "Consensus Policy."

5. For all purposes under this Agreement, the policies specifically identified by ICANN on its website (www.icann.org/general/consensus-policies.htm) at the date of this Agreement as having been adopted by the ICANN Board of Directors before the date of this Agreement shall be treated in the same manner and have the same effect as "Consensus Policies" and accordingly shall not be subject to review under Section I.B.2.

6. In the event that, at the time the ICANN Board adopts a policy under Section I.B.1 during the term of this Agreement, ICANN does not have in place an Independent Review Panel established under ICANN's bylaws, the fifteen-working-day period allowed under Section I.B.2 to seek review shall be extended until fifteen working days after ICANN does have such an Independent Review Panel in place and Registrar shall not be obligated to comply with the policy in the interim.

C. "DNS" refers to the Internet domain-name system.

D. "ICANN" refers to the Internet Corporation for Assigned Names and Numbers, a party to this Agreement.

E. An "ICANN-adopted policy" (and references to ICANN "adopt[ing]" a policy or policies) refers to a Consensus Policy adopted by ICANN (i) in conformity with applicable provisions of its articles of incorporation and bylaws and Section II.C of this Agreement and (ii) of which Registrar has been given notice and a reasonable period in which to comply.

F. "IP" means Internet Protocol.

G. "Personal Data" refers to data about any identified or identifiable natural person.

H. The word "Registrar," when appearing with an initial capital letter, refers to ________________________________, a party to this Agreement.

I. The word "registrar," when appearing without an initial capital letter, refers to a person or entity that contracts with SLD holders and a registry, collecting registration data about the SLD holders and submitting zone file information for entry in the registry database.

J. A "Registry" is the person(s) or entity(ies) then responsible, in accordance with an agreement between ICANN and that person or entity (those persons or entities) or, if that agreement is terminated or expires, in accordance with an agreement between the US Government and that person or entity (those persons or entities), for providing registry services.

K. An "SLD" is a second-level domain of the DNS.

L. An SLD registration is "sponsored" by the registrar that placed the record associated with that registration into the registry. Sponsorship of a registration may be changed at the express direction of the SLD holder or, in the event a registrar loses accreditation, in accordance with then-current ICANN-adopted policies.

M. A "TLD" is a top-level domain of the DNS.

II. TERMS AND CONDITIONS OF AGREEMENT

The parties agree as follows:

A. Accreditation. During the term of this Agreement, Registrar is hereby accredited by ICANN to act as a registrar (including to insert and renew registration of SLDs in the registry database) for the .com, .net, and .org TLDs.

B. Registrar Use of ICANN Name. Registrar is hereby granted a non-exclusive worldwide license to state during the term of this Agreement that it is accredited by ICANN as a registrar in the .com, .net, and .org TLDs. No other use of ICANN's name is licensed hereby. This license may not be assigned or sublicensed by Registrar.

C. General Obligations of ICANN. With respect to all matters that impact the rights, obligations, or role of Registrar, ICANN shall during the Term of this Agreement:

1. exercise its responsibilities in an open and transparent manner;

2. not unreasonably restrain competition and, to the extent feasible, promote and encourage robust competition;

3. not apply standards, policies, procedures or practices arbitrarily, unjustifiably, or inequitably and not single out Registrar for disparate treatment unless justified by substantial and reasonable cause; and

4. ensure, through its reconsideration and independent review policies, adequate appeal procedures for Registrar, to the extent it is adversely affected by ICANN standards, policies, procedures or practices.

D. General Obligations of Registrar.

1. During the Term of this Agreement:

a. Registrar agrees that it will operate as a registrar for TLDs for which it is accredited by ICANN in accordance with this Agreement;

b. Registrar shall comply, in such operations, with all ICANN-adopted Policies insofar as they:

i. relate to one or more of the following: (A) issues for which uniform or coordinated resolution is reasonably necessary to facilitate interoperability, technical reliability and/or stable operation of the Internet or domain-name system, (B) registrar policies reasonably necessary to implement Consensus Policies relating to the Registry, or (C) resolution of disputes regarding the registration of domain names (as opposed to the use of such domain names), and

ii. do not unreasonably restrain competition.

2. To the extent that Consensus Policies are adopted in conformance with Section II.C of this Agreement, the measures permissible under Section II.D.1.b.i shall include, without limitation:

i. principles for allocation of SLD names (e.g., first-come/first-served, timely renewal, holding period after expiration);

ii. prohibitions on warehousing of or speculation in domain names by registrars;

iii. reservation of SLD names that may not be registered initially or that may not be renewed due to reasons reasonably related to (a) avoidance of confusion among or misleading of users, (b) intellectual property, or (c) the technical management of the DNS or the Internet (e.g., "example.com" and single-letter/digit names);

iv. the allocation among continuing registrars of the SLD names sponsored in the registry by a registrar losing accreditation;

v. the transfer of registration data upon a change in registrar sponsoring the registration; and

vi. dispute resolution policies that take into account the use of a domain name.

Nothing in this Section II.D shall limit or otherwise affect Registrar's obligations as set forth elsewhere in this Agreement.

E. Submission of SLD Holder Data to Registry. During the term of this Agreement:

1. As part of its registration of SLDs in the .com, .net, and .org TLDs, Registrar shall submit to, or shall place in the registry database operated by Registry the following data elements concerning SLD registrations that Registrar processes:

a. The name of the SLD being registered;

b. The IP addresses of the primary nameserver and secondary nameserver(s) for the SLD;

c. The corresponding names of those nameservers;

d. Unless automatically generated by the registry system, the identity of the registrar;

e. Unless automatically generated by the registry system, the expiration date of the registration; and

f. Other data required as a result of further development of the registry system by the Registry.

2. Within five (5) business days after receiving any updates from the SLD holder to the data elements listed in Sections II.E.1.b and c for any SLD registration Registrar sponsors, Registrar shall submit the updated data elements to, or shall place those elements in the registry database operated by Registry.

3. In order to allow reconstitution of the registry database in the event of an otherwise unrecoverable technical failure or a change in the designated Registry permitted by the contract Registry has with ICANN and/or the United States Department of Commerce, within ten days of any such request by ICANN Registrar shall submit an electronic database containing the data elements listed in Sections II.F.1.a through d for all active records in the registry sponsored by Registrar, in a format specified by ICANN, to the Registry for the appropriate TLD.

F. Public Access to Data on SLD Registrations. During the term of this Agreement:

1. At its expense, Registrar shall provide an interactive web page and a port 43 Whois service providing free public query-based access to up-to-date (i.e. updated at least daily) data concerning all active SLD registrations sponsored by Registrar in the registry for the .com, .net, and .org TLDs. The data accessible shall consist of elements that are designated from time to time according to an ICANN-adopted policy. Until ICANN otherwise specifies by means of an ICANN-adopted policy, this data shall consist of the following elements as contained in Registrar's database:

a. The name of the SLD being registered and the TLD for which registration is being requested;

b. The IP addresses of the primary nameserver and secondary nameserver(s) for the SLD;

c. The corresponding names of those nameservers;

d. The identity of Registrar (which may be provided through Registrar's website);

e. The original creation date of the registration;

f. The expiration date of the registration;

g. The name and postal address of the SLD holder;

h. The name, postal address, e-mail address, voice telephone number, and (where available) fax number of the technical contact for the SLD; and

i. The name, postal address, e-mail address, voice telephone number, and (where available) fax number of the administrative contact for the SLD.

2. Upon receiving any updates to the data elements listed in Sections II.F.1.b through d and f through i from the SLD holder, Registrar shall promptly update its database used to provide the public access described in Section II.F.1.

3. Registrar may subcontract its obligation to provide the public access described in Section II.F.1 and the updating described in Section II.F.2, provided that Registrar shall remain fully responsible for the proper provision of the access and updating.

4. Registrar shall abide by any ICANN-adopted Policy that requires registrars to cooperatively implement a distributed capability that provides query-based Whois search functionality across all registrars. If the Whois service implemented by registrars does not in a reasonable time provide reasonably robust, reliable, and convenient access to accurate and up-to-date data, the Registrar shall abide by any ICANN-adopted Policy requiring Registrar, if reasonably determined by ICANN to be necessary (considering such possibilities as remedial action by specific registrars), to supply data from Registrar's database to facilitate the development of a centralized Whois database for the purpose of providing comprehensive Registrar Whois search capability.

5. In providing query-based public access to registration data as required by Sections II.F.1 and II.F.4, Registrar shall not impose terms and conditions on use of the data provided except as permitted by an ICANN-adopted policy. Unless and until ICANN adopts a different policy, Registrar shall permit use of data it provides in response to queries for any lawful purposes except to: (a) allow, enable, or otherwise support the transmission of mass unsolicited, commercial advertising or solicitations via e-mail (spam); or (b) enable high volume, automated, electronic processes that apply to Registrar (or its systems).

6. In addition, Registrar shall provide third-party bulk access to the data subject to public access under Section II.F.1 under the following terms and conditions:

a. Registrar shall make a complete electronic copy of the data available at least one time per week for download by third parties who have entered into a bulk access agreement with Registrar.

b. Registrar may charge an annual fee, not to exceed US$10,000, for such bulk access to the data.

c. Registrar's access agreement shall require the third party to agree not to use the data to allow, enable, or otherwise support the transmission of mass unsolicited, commercial advertising or solicitations via e-mail (spam).

d. Registrar's access agreement may require the third party to agree not to use the data to enable high-volume, automated, electronic processes that apply to Registrar (or its systems).

e. Registrar's access agreement may require the third party to agree not to sell or redistribute the data except insofar as it has been incorporated by the third party into a value-added product or service that does not permit the extraction of a substantial portion of the bulk data from the value-added product or service for use by other

parties.

f. Registrar may enable SLD holders who are individuals to elect not to have Personal Data concerning their registrations available for bulk access for marketing purposes based on Registrar's "Opt-Out" policy, and if Registrar has such a policy Registrar shall require the third party to abide by the terms of that Opt-Out policy; provided, however, that Registrar may not use such data subject to opt-out for marketing purposes in its own value-added product or service.

7. Registrar's obligations under Section II.F.6 shall remain in effect until the earlier of (a) replacement of this policy with a different ICANN-adopted policy governing bulk access to the data subject to public access under Section II.F.1, or (b) demonstration, to the satisfaction of the United States Department of Commerce, that no individual or entity is able to exercise market power with respect to registrations or with respect to registration data used for development of value-added products and services by third parties.

8. To comply with applicable statutes and regulations and for other reasons, ICANN may from time to time adopt policies establishing limits on the Personal Data concerning SLD registrations that Registrar may make available to the public through a public-access service described in this Section II.F and on the manner in which Registrar may make them available. In the event ICANN adopts any such policy, Registrar shall abide by it.

G. Retention of SLD Holder and Registration Data.

1. During the term of this Agreement, Registrar shall maintain its own electronic database, as updated from time to time, containing data for each active SLD registration sponsored by it in the registry for the .com, .net, and .org TLDs. The data for each such registration shall include the elements listed in Sections II.F.1.a through i, as well as the name and (where available) postal address, e-mail address, voice telephone number, and fax number of the billing contact.

2. During the term of this Agreement and for three years thereafter, Registrar (itself or by its agent) shall maintain the following records relating to its dealings with the Registry and SLD holders:

a. In electronic form, the submission date and time, and the content, of all registration data (including updates) submitted in electronic form to the Registry;

b. In electronic, paper, or microfilm form, all written communications constituting registration applications, confirmations, modifications, or terminations and related correspondence with actual SLD holders, including registration contracts; and

c. In electronic form, records of the accounts of all SLD holders with Registrar, including dates and amounts of all payments and refunds.

Registrar shall make these records available for inspection by ICANN upon reasonable notice. ICANN shall not disclose such records except as expressly permitted by an ICANN-adopted policy.

H. Rights in Data. Registrar disclaims all rights to exclusive ownership or use of the data elements listed in Sections II.E.1.a through c for all SLD registrations submitted by Registrar to, or sponsored by Registrar in,

the registry database for the .com, .net, and .org TLDs. Registrar does not disclaim rights in the data elements listed in Sections II.E.1.d through f and II.F.1.d through i concerning active SLD registrations sponsored by it in the registry for the .com, .net, and .org TLDs, and agrees to grant non-exclusive, irrevocable, royalty-free licenses to make use of and disclose the data elements listed in Sections II.F.1.d through i for the purpose of providing a service (such as a Whois service under Section II.F.4) providing interactive, query-based public access. Upon a change in sponsorship from Registrar of any SLD registration in the registry for the .com, .net, and .org TLDs, Registrar acknowledges that the registrar gaining sponsorship shall have the rights of an owner to the data elements listed in Sections II.E.1.d and e and II.F.1.d through i concerning that registration, with Registrar also retaining the rights of an owner in that data. Nothing in this Section II.H prohibits Registrar from (1) restricting bulk public access to data elements in a manner consistent with any ICANN-adopted policies or (2) transferring rights it claims in data elements subject to the provisions of this Section II.H.

I. Data Escrow. During the term of this Agreement, on a schedule, under the terms, and in the format specified in the then-current ICANN-adopted policy on registrar escrow requirements, Registrar shall submit an electronic copy of the database described in Section II.G.1 to ICANN or, at Registrar's election and at its expense, to a reputable escrow agent mutually approved by Registrar and ICANN, such approval also not to be unreasonably withheld by either party. The data shall be held under an agreement among Registrar, ICANN, and the escrow agent (if any) providing that (1) the data shall be received and held in escrow, with no use other than verification that the deposited data is complete and in proper format, until released to ICANN; (2) the data shall be released from escrow upon expiration without renewal or termination of this Agreement; and (3) ICANN's rights under the escrow agreement shall be assigned with any assignment of this Agreement. The escrow shall provide that in the event the escrow is released under this Section II.I, ICANN (or its assignee) shall have a non-exclusive, irrevocable, royalty-free license to exercise (only for transitional purposes) or have exercised all rights necessary to provide registrar services.

J. Business Dealings, Including with SLD Holders.

1. In the event ICANN adopts a policy supported by a consensus of ICANN-accredited registrars establishing or approving a Code of Conduct for such registrars, Registrar shall abide by that Code.

2. Registrar shall abide by applicable laws and governmental regulations.

3. Registrar shall not represent to any actual or potential SLD holder that Registrar enjoys access to a registry for which Registrar is accredited that is superior to that of any other registrar accredited for that registry.

4. Registrar shall not activate any SLD registration unless and until it is satisfied that it has received a reasonable assurance of payment of its registration fee. For this purpose, a charge to a credit card, general commercial terms extended to creditworthy customers, or other mechanism providing a similar level of assurance of payment shall be sufficient, provided that the obligation to pay becomes final and non-revocable by the SLD holder upon activation of the registration.

5. Registrar shall register SLDs to SLD holders only for fixed periods. At the conclusion of the registration period, failure by or on behalf of the SLD holder to pay a renewal fee within the time specified in a second notice or reminder shall, in the absence of extenuating circumstances, result in cancellation of the registration. In the event that ICANN adopts a policy concerning procedures for handling expiration of registrations, Registrar shall abide by that policy.

6. Registrar shall not insert or renew any SLD name in any registry for which Registrar is accredited by ICANN in a manner contrary to an ICANN-adopted policy stating a list or specification of excluded SLD names that is in effect at the time of insertion or renewal.

7. Registrar shall require all SLD holders to enter into an electronic or paper registration agreement with Registrar including at least the following provisions:

a. The SLD holder shall provide to Registrar accurate and reliable contact details and promptly correct and update them during the term of the SLD registration, including: the full name, postal address, e-mail address, voice telephone number, and fax number if available of the SLD holder; name of authorized person for contact purposes in the case of an SLD holder that is an organization, association, or corporation; and the data elements listed in Section II.F.1.b, c, and h through i above.

An SLD holder's willful provision of inaccurate or unreliable information, its willful failure promptly to update information provided to Registrar, or its failure to respond for over fifteen calendar days to inquiries by Registrar concerning the accuracy of contact details associated with the SLD holder's registration shall constitute a material breach of the SLD holder-registrar contract and be a basis for cancellation of the SLD registration.

Any SLD holder that intends to license use of a domain name to a third party is nonetheless the SLD holder of record and is responsible for providing its own full contact information and for providing and updating accurate technical and administrative contact information adequate to facilitate timely resolution of any problems that arise in connection with the SLD. An SLD holder licensing use of an SLD according to this provision shall accept liability for harm caused by wrongful use of the SLD, unless it promptly discloses the identity of the licensee to a party providing the SLD holder reasonable evidence of actionable harm.

b. Registrar shall provide notice to each new or renewed SLD holder stating:

i. The purposes for which any Personal Data collected from the applicant are intended;

ii. The intended recipients or categories of recipients of the data (including the Registry and others who will receive the data from Registry);

iii. Which data are obligatory and which data, if any, are voluntary; and

iv. How the SLD holder or data subject can access and, if necessary, rectify the data held about them.

c. The SLD holder shall consent to the data processing referred to in Section II.J.7.b.

d. The SLD holder shall represent that notice has been provided equivalent to that described in Section II.J.7.b. above to any third-party individuals whose Personal Data are supplied to Registrar by the SLD holder, and that the SLD holder has obtained consent equivalent to that referred to in Section II.J.7.c of any such third-party individuals.

e. Registrar shall agree that it will not process the Personal Data collected from the SLD holder in a way incompatible with the purposes and other limitations about which it has provided notice to the SLD holder in accordance with Section II.J.7.b, above.

f. Registrar shall agree that it will take reasonable precautions to protect Personal Data from loss, misuse, unauthorized access or disclosure, alteration, or destruction.

g. The SLD holder shall represent that, to the best of the SLD holder's knowledge and belief, neither the registration of the SLD name nor the manner in which it is directly or indirectly used infringes the legal rights of a third party.

h. For the adjudication of disputes concerning or arising from use of the SLD name, the SLD holder shall submit, without prejudice to other potentially applicable jurisdictions, to the jurisdiction of the courts (1) of the SLD holder's domicile and (2) where Registrar is located.

i. The SLD holder shall agree that its registration of the SLD name shall be subject to suspension, cancellation, or transfer pursuant to any ICANN-adopted policy, or pursuant to any registrar or registry procedure not inconsistent with an ICANN-adopted policy, (1) to correct mistakes by Registrar or the Registry in registering the name or (2) for the resolution of disputes concerning the SLD name.

j. The SLD holder shall indemnify and hold harmless the Registry and its directors, officers, employees, and agents from and against any and all claims, damages, liabilities, costs, and expenses (including reasonable legal fees and expenses) arising out of or related to the SLD holder's domain name registration.

8. Registrar shall abide by any ICANN-adopted policies requiring reasonable and commercially practicable (a) verification, at the time of registration, of contact information associated with an SLD registration sponsored by Registrar or (b) periodic re-verification of such information. Registrar shall, upon notification by any person of an inaccuracy in the contact information associated with an SLD registration sponsored by Registrar, take reasonable steps to investigate that claimed inaccuracy. In the event Registrar learns of inaccurate contact information associated with an SLD registration it sponsors, it shall take reasonable steps to correct that inaccuracy.

9. Registrar shall abide by any ICANN-adopted policy prohibiting or restricting warehousing of or speculation in domain names by registrars.

10. Registrar shall maintain in force commercial general liability insurance with policy limits of at least US$500,000 covering liabilities arising from Registrar's registrar business during the term of this Agreement.

11. Nothing in this Agreement prescribes or limits the amount Registrar may charge SLD holders for registration of SLD names.

K. Domain-Name Dispute Resolution. During the term of this Agreement, Registrar shall have in place a policy and procedure for resolution of disputes concerning SLD names. In the event that ICANN adopts a policy or procedure for resolution of disputes concerning SLD names that by its terms applies to Registrar, Registrar shall adhere to the policy or procedure.

L. Accreditation Fees. As a condition of accreditation, Registrar shall pay accreditation fees to ICANN. These fees consist of yearly and on-going components.

1. The yearly component for the term of this Agreement shall be US $5,000. Payment of the yearly component shall be due upon execution by Registrar of this Agreement and upon each anniversary date after such execution during the term of this Agreement (other than the expiration date).

2. Registrar shall pay the on-going component of Registrar accreditation fees adopted by ICANN in accordance with the provisions of Section II.C above, provided such fees are reasonably allocated among all registrars that contract with ICANN and that any such fees must be expressly approved by registrars accounting, in aggregate, for payment of two-thirds of all registrar-level fees. Registrar shall pay such fees in a timely manner for so long as all material terms of this Agreement remain in full force and effect, and notwithstanding the pendency of any dispute between Registrar and ICANN.

3. On reasonable notice given by ICANN to Registrar, accountings submitted by Registrar shall be subject to verification by an audit of Registrar's books and records by an independent third-party that shall preserve the confidentiality of such books and records (other than its findings as to the accuracy of, and any necessary corrections to, the accountings).

M. Specific Performance. While this Agreement is in effect, either party may seek specific performance of any provision of this Agreement in the manner provided in Section II.P below, provided the party seeking such performance is not in material breach of its obligations.

N. Termination of Agreement. This Agreement may be terminated before its expiration by Registrar by giving ICANN thirty days written notice. It may be terminated before its expiration by ICANN in any of the following circumstances:

1. There was a material misrepresentation, material inaccuracy, or materially misleading statement in Registrar's application for accreditation or any material accompanying the application.

2. Registrar:

a. is convicted of a felony or other serious offense related to financial activities, or is judged by a court to have committed fraud or breach of fiduciary duty, or is the subject of a judicial determination that ICANN reasonably deems as the substantive equivalent of any of these; or

b. is disciplined by the government of its domicile for conduct involving dishonesty or misuse of funds of others.

3. Any officer or director of Registrar is convicted of a felony or of a misdemeanor related to financial activities, or is judged by a court to have committed fraud or breach of fiduciary duty, or is the subject of a judicial determination that ICANN deems as the substantive equivalent of any of these; provided, such officer or director is not removed in such circumstances.

4. Registrar fails to cure any breach of this Agreement (other than a failure to comply with a policy adopted by ICANN during the term of this Agreement as to which Registrar is seeking, or

still has time to seek, review under Section I.B.2 of whether a consensus is present) within fifteen working days after ICANN gives Registrar notice of the breach.

5. Registrar fails to comply with a ruling granting specific performance under Sections II.M and II.P.

6. Registrar continues acting in a manner that ICANN has reasonably determined endangers the stability or operational integrity of the Internet after receiving three days notice of that determination.

7. Registrar becomes bankrupt or insolvent.

This Agreement may be terminated in circumstances 1 through 6 above only upon fifteen days written notice to Registrar (in the case of circumstance 4 occurring after Registrar's failure to cure), with Registrar being given an opportunity during that time to initiate arbitration under Section II.P to determine the appropriateness of termination under this Agreement. In the event Registrar initiates litigation or arbitration concerning the appropriateness of termination by ICANN, the termination shall be stayed an additional thirty days to allow Registrar to obtain a stay of termination under Section II.P below. If Registrar acts in a manner that ICANN reasonably determines endangers the stability or operational integrity of the Internet and upon notice does not immediately cure, ICANN may suspend this Agreement for five working days pending ICANN's application for more extended specific performance or injunctive relief under Section II.P. This Agreement may be terminated immediately upon notice to Registrar in circumstance 7 above.

O. Term of Agreement; Renewal; Right to Substitute Updated Agreement. This Agreement shall have an initial term until [specific date to be inserted: five years for most agreements; for agreements substituting for the prior one-year agreements the inserted date will be the existing (one year) termination date of those agreements, as required by Section III.M of those agreements], unless sooner terminated. Thereafter, if Registrar seeks to continue its accreditation, it may apply for renewed accreditation, and shall be entitled to renewal provided it meets the ICANN-adopted policy on accreditation criteria then in effect, is in compliance with its obligations under this Agreement, as amended, and agrees to be bound by the then-current Registrar accreditation agreement (which may differ from those of this Agreement) that ICANN adopts in accordance with Sections II.C and II.D (as Section II.D may have been amended by an ICANN-adopted policy). In connection with renewed accreditation, Registrar shall confirm its assent to the terms and conditions of the such then-current Registrar accreditation agreement by signing that accreditation agreement. In the event that, during the term of this Agreement, ICANN posts on its web site an updated form of registrar accreditation agreement applicable to accredited registrars in the .com, .net, or .org TLDs, Registrar (provided it has not received (1) a notice of breach that it has not cured or (2) a notice of termination of this Agreement under Section II.N above) may elect, by giving ICANN written notice, to enter an agreement in the updated form in place of this Agreement. In the event of such election, Registrar and ICANN shall promptly sign a new accreditation agreement that contains the provisions of the updated form posted on the web site, with the length of the term of the substituted agreement as stated in the updated form posted on the web site, calculated as if it commenced on the date this Agreement was made, and this Agreement will be deemed terminated.

P. Resolution of Disputes Under this Agreement. Disputes arising under or in connection with this Agreement, including (1) disputes arising from ICANN's failure to renew Registrar's accreditation and (2) requests for specific performance, shall be resolved in a court of competent jurisdiction or, at the election of either party, by an arbitration conducted as provided in this Section II.P pursuant to the International Arbitration Rules of the American Arbitration Association ("AAA"). The arbitration shall be conducted in English and shall occur in Los Angeles County, California, USA. There shall be three arbitrators: each party

shall choose one arbitrator and, if those two arbitrators do not agree on a third arbitrator, the third shall be chosen by the AAA. The parties shall bear the costs of the arbitration in equal shares, subject to the right of the arbitrators to reallocate the costs in their award as provided in the AAA rules. The parties shall bear their own attorneys' fees in connection with the arbitration, and the arbitrators may not reallocate the attorneys' fees in conjunction with their award. The arbitrators shall render their decision within ninety days of the conclusion of the arbitration hearing. In the event Registrar initiates arbitration to contest the appropriateness of termination of this Agreement by ICANN, Registar may at the same time request that the arbitration panel stay the termination until the arbitration decision is rendered, and that request shall have the effect of staying the termination until the arbitration panel has granted an ICANN request for specific performance and Registrar has failed to comply with such ruling. In the event Registrar initiates arbitration to contest an Independent Review Panel's decision under Section I.B.2 sustaining the Board's determination that a policy is supported by consensus, Registar may at the same time request that the arbitration panel stay the requirement that it comply with the policy until the arbitration decision is rendered, and that request shall have the effect of staying the requirement until the decision or until the arbitration panel has granted an ICANN request for lifting of the stay. In all litigation involving ICANN concerning this Agreement (whether in a case where arbitration has not been elected or to enforce an arbitration award), jurisdiction and exclusive venue for such litigation shall be in a court located in Los Angeles, California, USA; however, the parties shall also have the right to enforce a judgment of such a court in any court of competent jurisdiction. For the purpose of aiding the arbitration and/or preserving the rights of the parties during the pendency of an arbitration, the parties shall have the right to seek temporary or preliminary injunctive relief from the arbitration panel or in a court located in Los Angeles, California, USA, which shall not be a waiver of this arbitration agreement.

Q. Limitations on Monetary Remedies for Violations of this Agreement. ICANN's aggregate monetary liability for violations of this Agreement shall not exceed the amount of accreditation fees paid by Registrar to ICANN under Section II.L of this Agreement. Registrar's monetary liability to ICANN for violations of this Agreement shall be limited to accreditation fees owing to ICANN under this Agreement. In no event shall either party be liable for special, indirect, incidental, punitive, exemplary, or consequential damages for any violation of this Agreement.

R. Handling by ICANN of Registrar-Supplied Data. Before receiving any Personal Data from Registrar, ICANN shall specify to Registrar in writing the purposes for and conditions under which ICANN intends to use the Personal Data. ICANN may from time to time provide Registrar with a revised specification of such purposes and conditions, which specification shall become effective no fewer than thirty days after it is provided to Registrar. ICANN shall not use Personal Data provided by Registrar for a purpose or under conditions inconsistent with the specification in effect when the Personal Data were provided. ICANN shall take reasonable steps to avoid uses of the Personal Data by third parties inconsistent with the specification.

S. Miscellaneous.

1. Assignment. Either party may assign or transfer this Agreement only with the prior written consent of the other party, which shall not be unreasonably withheld, except that ICANN may, with the written approval of the United States Department of Commerce, assign this agreement by giving Registrar written notice of the assignment. In the event of assignment by ICANN, the assignee may, with the approval of the United States Department of Commerce, revise the definition of "Consensus Policy" to the extent necessary to meet the organizational circumstances of the assignee, provided the revised definition requires that Consensus Policies be based on a demonstrated consensus of Internet stakeholders.

2. No Third-Party Beneficiaries. This Agreement shall not be construed to create any obligation

by either ICANN or Registrar to any non-party to this Agreement, including any SLD holder.

3. Notices, Designations, and Specifications. All notices to be given under this Agreement shall be given in writing at the address of the appropriate party as set forth below, unless that party has given a notice of change of address in writing. Any notice required by this Agreement shall be deemed to have been properly given when delivered in person, when sent by electronic facsimile, or when scheduled for delivery by internationally recognized courier service. Designations and specifications by ICANN under this Agreement shall be effective when written notice of them is deemed given to Registrar.

If to ICANN, addressed to:

Internet Corporation for Assigned Names and Numbers Registrar Accreditation 4676 Admiralty Way, Suite 330 Marina Del Rey, California 90292 Telephone: 1/310/823-9358 Facsimile: 1/310/823-8649

If to Registrar, addressed to:

With a copy to:

4. Dates and Times. All dates and times relevant to this Agreement or its performance shall be computed based on the date and time observed in Los Angeles, California, USA.

5. Language. All notices, designations, and specifications made under this Agreement shall be in the English language.

6. Entire Agreement. Except for any written transition agreement that may be executed concurrently herewith by both parties, this Agreement constitutes the entire agreement of the parties hereto pertaining to the subject matter hereof and supersedes all prior agreements, understandings, negotiations and discussions, whether oral or written, of the parties.

7. Amendments and Waivers. No amendment, supplement, or modification of this Agreement or any provision hereof shall be binding unless executed in writing by both parties. No waiver of any provision of this Agreement shall be binding unless evidenced by a writing signed by the party waiving compliance with such provision. No waiver of any of the provisions of this Agreement shall be deemed or shall constitute a waiver of any other provision hereof, nor shall any such waiver constitute a continuing waiver unless otherwise expressly provided.

8. Counterparts. This Agreement may be executed in one or more counterparts, each of which shall be deemed an original, but all of which together shall constitute one and the same instrument.

IN WITNESS WHEREOF, the parties hereto have caused this Agreement to be executed in duplicate by their duly authorized representatives.

INTERNET CORPORATION FOR ASSIGNED NAMES AND NUMBERS

By:__________________________ Michael M. Roberts President and CEO

[REGISTRAR]

By:__________________________

Page modified 9-November-1999

ICANN At Large Membership At a Crossroads Emel Wadhwani (ewadhwan@law.harvard.edu) &

Len Kardon (lkardon@law.harvard.edu) Harvard Law School

The document below is the work of Berkman Center student affiliates. Accordingly, it does not represent the views of the Berkman Center institutionally; rather, it presents the perspective of its authors.

Introduction The Internet Corporation for Assigned Names and Numbers (ICANN) just concluded its first election

for directors representing the At Large membership. Article II of the ICANN Bylaws requires the initiation of

"a comprehensive study of the concept, structure and processes relating to an 'At Large' membership"

following the ICANN annual meeting in November. The director selection process has been controversial,

with much debate over the past two years regarding the makeup of the At Large membership and the

structure for electing the directors. Underlying these discussions about process are fundamental

disagreements over the purpose of ICANN and role of the At Large membership. As the ICANN Board

recognized, "there remains a considerable diversity of views concerning the purpose of and rationale for the

At Large membership and Council” [ICANN Resolution 00.18]. This paper examines the two primary

contending views, which we call the “Technical Body Vision” and the “Democratic Process Vision.” The

paper argues that the 2000 At-Large election, under pressure from both camps, failed to choose between

these two visions and was thereby fraught with inconsistency. A resolution of the membership debate is

contingent on ICANN, its supporters, and its critics, making a clear, deliberate, and articulated choice as to

the purpose of At-Large membership.

Background

ICANN was formed to address the Department of Commerce’s White Paper, which called for the

creation of a private organization to "manage and perform a specific set of functions related to the

coordination of the domain name system.” Although vague in its details, the White Paper envisioned some

role for a user membership: “The organization and its board should derive legitimacy from the participation

of key stakeholders. Since the organization will be concerned mainly with numbers, names and protocols, its

board should represent membership organizations in each of these areas, as well as the direct

interests of Internet users.” The Joint Project Agreement with the DOC requires ICANN to "[c]ollaborate on

the design, development, and testing of appropriate membership mechanisms that foster accountability to

and representation of the global and functional diversity of the Internet and its users, within the structure of

the private-sector DNS management organization."

A fundamental issue that has been deeply contested is exactly who “the Internet users” invoked by

the White Paper are – individuals vs. organizations; domain holders vs. anyone with an e-mail address;

potential Internet users vs. current users. This year, anyone with an e-mail address and verifiable physical

address was allowed to become an At Large member during the registration period. Another controversial

issue has been the mandate to reflect a “global and functional diversity,” raising questions about regional

representation and voting mechanisms for ensuring a role for minority voices. While these questions

deserve more study, we have focused here on the more general issue of what the appropriate vision for the

At Large membership is in the first place. The details of who should be allowed to be members and how

they should be represented on the board will partly follow from the vision adopted.

Vision of At Large membership

The primary disagreement over the role of the At Large membership in ICANN centers on the

purpose of ICANN. Some see it as a very limited, technical standards body, with At Large membership

providing a bottom-up, consensus generating process adding to the diversity of views within ICANN (the

Technical Body Vision). ICANN states: "ICANN is a technical coordination body for the Internet . . .

assuming responsibility for a set of technical functions.”

Others see the membership as the central component of a democratic process by which to make

policy decisions concerning domain names and numbers and perhaps the Internet more broadly (the

Democracy Vision). The popular press as well as many advocacy groups perceive ICANN to be a powerful

policy-making organization. Wire reports refer to ICANN as "the powerful and controversial organization

charged with managing the Internet's vital addressing system" [Newsbyte] and "an Internet oversight

board" [Associate Press]. A group of ICANN-watchers contends that "ICANN has engaged in policy

matters that have important public repercussions." [Cyber-Federalist No. 1]

Technical Body Vision: A way of diversifying and making more transparent the technical and standards-based decision making conducted by a non-profit corporation

Under this approach, the At Large membership is just one of many groups of Internet stakeholders.

The Membership Advisory Committee (MAC) report states that the purpose of the At Large membership is to

“ensure representation on the ICANN board of directors of those individual and organizational users that are

not already represented by the Supporting Organizations.” The focus is on creating consensus. “As a

consensus-based body (unlike a legislature), the Board will work best when its members are chosen

diversely from stakeholder communities and a broad, diverse, numerous membership.” [E-mail from Andrew

McLaughlin, ICANN Chief Policy Officer, 10/19/00] The At Large membership should be selected and

structured “to create a vehicle for consensus development of policies that will promote the continued stable

operation of the DNS.” [Joe Sim’s, response to Froomkin’s comments on Proposed Changes to ICANN

Bylaws, Oct. 23, 1999]

ICANN as an organization has generally adhered to the Technical Body Vision. This is reflected in

the initial bylaws proposed by Jon Postel and IANA in October 1998 that left the issue of whether to even

create an At Large membership for the initial board to decide in the future. [IANA proposed bylaws] In

August 1999, the ICANN Board modified the bylaws to create an At Large Council to be placed between the

At Large members and the directors [ICANN Resolutions 99.87 and 99.88] disregarding the MAC report

which called for direct elections (the Council was eliminated later). This process would arguably provide

greater organizational stability and lead to the election of more technically qualified and knowledgeable

directors.

Adherents of this vision also point out that representation of the “Internet community” is practically

impossible. Over 375 million people will be Internet users this year [eTForecasts], but not many have the

knowledge and interest necessary to understand exactly what ICANN does. Although significantly above

original projections, only a very small percentage of this potential usership, some 76 thousand,

registered as members and activated their membership. Without adequate safeguards, such as an At Large

Council, this extreme imbalance between potential and actual votership can lead to a capture by special

interests. The At Large Council would also equalize the manner of election of the At Large directors and the

SO directors, who are similarly appointed by SO councils, and could additionally serve as an intermediary

group to look after the interests of the At-Large constituency. [E-mail from Greg Crew, ICANN Board of

Directors and ICANN Membership Advisory Committee, 10/19/00.]

Democracy Vision: A democratic process by which to make policy decisions concerning the Internet

This vision of the At Large membership is rooted in an understanding of ICANN as a policy-making

entity with governance powers. “In theory and by design, ICANN’s mission is narrow and technical. But

even technical decisions about who gets which names and numbers can have broader policy implications.

And because of ICANN’s central control over Internet functions, it will face pressures to make broad policy

decisions.” [Common Cause/CDT Report] Under this vision of ICANN as an Internet governance body,

“Legitimacy can only come if ICANN operates with the consent of the governed – those bound by and

affected by its policies.”[ibid.]

At the extreme, democracy advocates desire a fully elected board with no qualifications. The

dominant Democracy Vision, and the one used in this paper, recognizes that ICANN is a hybrid organization

that requires expert decisionmaking balanced by policy accountability. These advocates agree that the

technical community should be represented on the board through the SO’s, yet as it is currently structured,

ICANN “suffers from a democracy deficit.” [Statement on ICANN Elections, Civil Society Internet Forum.]

They see the At Large membership as a necessary counter-balance to the commercial interests represented

by the SO's and their influence on policy. In particular, the UDRP and the current selection process for new

top level domains have received the most attention and have been widely perceived as substantive policy

issues that could unfairly reflect a commercial bias.

Proponents of this perspective acknowledge that there is a tension between having qualified board

members with adequate technical skills and a direct election process that enfranchises the Internet

“user” [Common Cause/CDT Report]. They believe, however, that this tension can be resolved by putting

some minimum qualifications on who can be nominated rather than eliminating direct voting.

The Democracy Vision is also supported, reluctantly, by those arguing that ICANN’s powers, even

construed as narrowly as possible, are not legitimate or should not exist in the first place. While preferring

that no one exercise the policy-making functions they see ICANN performing, these critics argue for a more

democratic ICANN in order to keep it in check. "When Internet users have a voice in decision-making,

hopefully ICANN's decisions can be carefully limited to minimize its regulatory role." [Cyber-Federalist No.

1] Professor Neil Weinstock Netanel argues that any form of Internet governance, if not regulated by liberal

nation-states, would be inimical to liberal democratic principals. [Cyberspace Self-Governance: A Skeptical

View from Liberal Democratic Theory, California Law Review, March 2000] Furthermore, ICANN’s powers

may be contested as an unconstitutional delegation of executive power by the Department of Commerce.

[Professor Michael Froomkin, Duke Law Journal, Vol. 50:17] Given its tenuous legitimacy, argue these

critics, ICANN should at least be accountable in a democratic process.

Current Status

The election process, as it actually played out over the last few months, has been a hybrid of the two

visions. Those advocating the Democracy Vision succeeded in ensuring direct elections by the At Large

membership after the Cairo meetings eliminating the At Large Council. The membership requirements were

kept minimal to encourage as wide a participation of interests as possible. The candidate selection process

included both a nominating committee as well as member nominations constrained by some minimum

support qualifications. After criticism from Democracy Vision Advocates, the support needed for member

nomination was reduced from 10 percent to two percent. Subsequently, two of the five candidates elected

to the board were member nominated.

Yet, with only some 34 thousand of a potential membership in the millions actually casting votes, it is

difficult to claim any kind of democratic victory here, regardless of whether the votes were cast

directly. Furthermore, membership was grossly disproportionate across national boundaries, limiting the

extent to which a “global representation” could be claimed to have been achieved. Membership drives were

largely inspired by nationalistic sentiment, rather than an interest in the technical development of Internet

domains, casting doubt on how educated the votes actually were. Instead of adding to the diversity on the

board, the directors elected from Asia/Pacific and Africa are already members of the DNSO Names Council.

Given these inconsistencies, it is hard to view this first At-Large election process as achieving either one of

the visions that supported it – it was neither a democratic election nor a carefully and deliberately

constructed process by which to diversify the views on ICANN’s board of directors.

Conclusion

Resolution of the At-Large membership controversy is contingent on first choosing between the two

competing visions described above. The current structure is inconsistent with either vision. More study on

who registered and, of those, who voted may shed light on which interests were actually represented in this

election and give us a sense of which vision may be winning out. Christian Ahlert [ICANN Membership

Implementation Task Force, e-mail, 10/20/00] makes the interesting point that the results of the membership

drive as well as the election in Europe were more influenced by the popular press than by the online mailing

group set up for exchange of information on the process. These types of observations are useful in

determining how great a “democratic” interest there may be in ICANN’s process.

Whether or not the 2000 elections have been a “success” is highly subjective. However, by failing to

choose between the two visions, ICANN, its supporters, and its critics have also failed to take the steps that

would have increased the legitimacy of the process and its results under either vision. If the At Large

membership exists to incorporate an actual democratic process, ICANN could find ways to increase voter

participation and balance as well as encourage ongoing member involvement or at least attention to ICANN

issues. Although ICANN appointed a Membership Implementation Task Force to encourage registration in

the election just completed, critics argue that its efforts were inadequate and that the technical problems that

inhibited last minute registrations further discouraged participation. If, on the other hand, the At Large

membership exists to add another dimension of knowledgeable and technical views to those of the

SO’s, then stricter membership criteria or a return to the concept of an At Large Council may inspire greater

confidence in ICANN’s legitimacy. At the same time, ICANN will also have to address the concerns that it

has strayed beyond its technical mandate. Under either vision, ICANN can ensure the directors selected by

the At Large membership balance those selected by SO’s by requiring that At Large director candidates not

have any membership interest in the SO’s.

The current amalgam will only lead to continued questions about ICANN’s legitimacy. ICANN must

make a choice and clarify the purpose and mission of the At Large membership before it can begin to think

about how to reform the election process.

Global Ideal, National Reality <http://cyber.law.harvard.edu/icann/pressingissues/briefingbook/nationalism.html>

Jonathan Blavin (jblavin@law.harvard.edu) and Jeremy Kutner (jkutner@law.harvard.edu) The document below is the work of Berkman Center student affiliates. Accordingly, it does not represent the views ofthe Berkman Center institutionally; rather, it presents the perspective of its authors.

In early June 2000, a European coalition of companies and nonprofit groups that administer 30 European country code

top-level domains (ccTLDs) voted to refuse to pay ICANN the nearly $1 million in bills they owed to the organization.[1] While some of the members objected paying ICANN fees without first establishing formal legal agreements, others feared that ICANN

might ultimately desire to take away their ability to register domain names in the ccTLD’s they currently have authority over, giving

control of the domains back to governments or perhaps even removing ccTLD’s altogether. Furthermore, several small countries

that previously sold the rights to their ccTLDs to private registrar companies are now demanding the return of their domains.[2] Willie Black, who runs a British nonprofit organization that registers domain names in the .uk domain, articulated the increasingly

nationalist perceptions engulfing ICANN: “This is seen by us to be a domain name tax by a U.S. corporation on our sovereign top-

level domains.”[3] But are ccTLDs in fact an extension of state sovereignty, or are they better considered mere remnants of a now-outdated system created by Jon Postel only as a stopgap means of delegation to ease the administration of DNS?

Yet some observers had previously conceived of the Internet as a borderless universe where remnants of nationalism

have no place. However, this global ideal seems to have been slowly displaced by a nationalist reality. Martin Irvine, director of

the Communication, Culture, and Technology Program at Georgetown University, describes this phenomenon as global

localization: “Globalization, in one manifestation, is global localization; political groups use the Net to promote local interests and

identity politics rooted in very historic place-governed issues like race, nation, territory, and language.”[4] Though it is a major force behind globalization, recent experience shows that the Internet also creates new methods of information expression and

dissemination for nationalist movements: web pages for Scottish, Basque, and Quebeçois movements are prevalent on the

Internet.

This paper considers at the role that national identity and nationalism play and have played in the development of ICANN and ICANN policy. We will begin by looking at the role of the US government in relation to ICANN. Second we will look at the current status of the ccTLDs. Third, we will address the At-Large elections and the use of geographic regions for voting. Finally, we will conclude with a proposal for blending ICANN’s global scope with accountable national representation through a reformulation of the role of the Governmental Advisory Committee. ICANN and the US Government

The Internet was created under the control of the US government as a Department of Defense project. Since then, it has

grown into an essential part of people’s lives all over the world, important for governments and corporations, as well as a major

part of the worldwide “new economy.” With private communication and information increasingly taking place on the net, many

interests seek involvement in its governance. The US government has responded to increased international interest in the

Internet by transferring control of the Internet’s Domain Name System (DNS) to ICANN, though maintaining at least temporary

supervision via the Department of Commerce (DoC). It should be noted, in defense of the oft-chided US, that it was under no

obligation to give away control of the Internet; it did, after all, fund the network’s creation. As a Department of Commerce “spin-off,” ICANN is viewed by many critics as a “quasi-governmental” organization

covertly controlled by the US government. ICANN is still under a “Memorandum of Understanding” on continuing “policy

authority” with the US DoC.[5] Within this policy framework, the US government maintains control over certain aspects of ICANN. This control was previously scheduled to end in September 2000 but has not, leading critics to question whether the US

government is scared of completely giving away ICANN to the world.[6] But worth reemphasizing is that the US did not have to “give it away” at all. As Congressman Tom Bliley, Commerce Committee Chairman, argued in a scathing attack on ICANN at a

committee meeting in July 1999: “The Internet is too important to this nation, and the world at large, for this Committee to stay on

the sidelines.”[7] But even this assertion does not necessarily mean that the US government should not go further. Indeed, many would argue that the US still exercises too much control, and keeps too much of the Internet for itself. For example, perhaps

governmental, educational and military institutions worldwide should be able to use the .gov, .edu and .mil TLD’s. ccTLDs

Do country code top level domains (ccTLDs) contribute to the current nationally divided reality of the Internet, by emphasizing

division along country boundaries? At the very least, the registration and use of ccTLDs raise concerns over the transformation of

and emphasis on national sovereignty in the information age. To some extent, country codes currently serve as Internet domain

suffixes, lessening the need for numerous additional gTLDs. Although the ccTLD for the United States (.us) is rarely used,

corporations and organizations abroad frequently use ccTLDs.[8] Yet out of the 200+ countries that offer Internet domain registrations under their own ccTLDs, more than 70 have no local residence requirements and possess very weak trademark

laws.[9] This has brought up the interesting question of who exactly “owns” country domains. Are ccTLDs just gTLD’s by another name, and if that is the case, would it not further the global ideal to replace them with gTLDs? Does the answer change when it is

noted that some countries do prize their designated country domain as an extension of their territorial sovereignty. The Japanese

government, for instance, allows only Japanese organizations or companies to register one .jp name.[10] Is this just a remnant of the current national reality, which ICANN should be trying to move towards the global ideal? Other countries seem to consider

their TLDs to be a valuable windfall, as Tuvalu’s sale of .tv and Moldova’s sale of .md to the private sector demonstrate[11]. ICANN bases its decisions to grant ccTLDs on the presence of a country on the ISO-3166-1 list of two-letter country codes, a

list maintained by a designated department of the International Standards Organization (ISO). The 3166-1 list was developed not

for the purpose of designating ccTLDs, but rather to standardize country names into two-letter assigned codes.[12] Jon Postel, through IANA, decided to utilize the ISO 3166-1 list as a basis for creating ccTLDs in order to avoid making political decisions

himself, a practice which ICANN inherited and has maintained.[13] Thus, when IANA designated a ccTLD for France, they merely took “.fr” from the ISO 3166-1, rather than themselves choosing the string “.fr.”

A territory or region can be added to the ISO list even though it has not been recognized as a state by the UN. For example,

the ISO 3166 Maintenance Agency created .ps as the code for the Palestinian National Authority (PNA) territory. Thus, territories

that are not officially recognized as states by the United Nations, such as Taiwan and East Timor, have been granted their own

ccTLDs. The extension of ccTLDs to such territories raises important political concerns regarding the manifestation, and

possible redefinition, of sovereignty within cyberspace.

Granting the .ps domain to the Palestinian National Authority[14] is in a sense the cyberspace equivalent of internationally recognizing a state, regardless of whether or not it is done based on the ISO list. The Internet’s ability to transform evolving ideas

into realities has been shown to be a powerful social force. The use of ccTLDs presents an effective way for individuals and

institutions to associate themselves with particular territories, regions, and countries. The recent push by European companies

and organizations to persuade the ISO to add .eu to the list of country codes exemplifies this new perception of online

sovereignty; proponents of the .eu code assert their identity as European institutions in contrast to the generic, and US-dominated,

.com domain.[15] ICANN must recognize that adopting country codes merely because they are on a list created by a different organization with

a different raison d’être is a political decision in itself. Rather than simply grandfather in Jon Postel’s choice, ICANN should review

the decision to determine whether the choice of list was appropriate, or even whether ICANN should determine its own process,

possibly in consultation with the GAC, for deciding whether to adopt a new TLD. ICANN will soon decide the fate of the .eu TLD.

Of course, the European Union is not a state per se, but is rather a political union of states. But it has been ICANN’s policy not to

grant a ccTLD to any territory not on the ISO list, yet if ICANN does grant the domain, it will surely force acknowledgment that it

does itself make political decisions about which territories deserve TLDs. The At-large Elections ICANN’s bylaws state that it must have some “at-large” directors elected by the members, defined in the bylaws as ”individuals”.

The bylaws provide little detail about the “at-large membership,” although the Articles of Incorporation do say that the Company

must act for the “benefit of the Internet community as a whole.” The logic behind this method of ensuring representation seems to

have been to ensure that the interested stakeholders, including those who use and are affected by the DNS, have appropriate

representation. In that light, the aim of geographic distribution requirements seems to have been to prevent overwhelming

American control of ICANN. Though international representation was clearly a goal, it is less clear that the outcome of the recent At-Large Director elections is

what was intended. Yet it might be said that the outcome could easily have been predicted. The current state of international

sentiment seems to be such that individuals voting for representatives to an international organization are likely to prefer

representatives from their own nation, particularly when different languages are involved. Due to the size of the Board,

representation on the Board of every world nation was out of the question, even if ICANN had wanted to get the benefits of

representation and accountability that might result from it.[16] Global representation therefore presented the danger of capture of the board by Americans. Thus, ICANN chose regional representation, giving neither the democratic advantages of national

representation nor the potentially issues-over-nationality sensibility engendered by global representation. For example, if there were one representative from Germany who was pro-trademark holders’ rights, and more Germans

registered to vote than the rest of Europe put together, it would be likely that the German representative would be elected,

whether or not the nation (or, more broadly, Europeans) favored the interests of trademark holders. Indeed, many voters likely

investigated candidates no further than their nationalities. If the same thing happened in the other regions, then the elected

representatives might all end up representing a single, and not necessarily dominant point of view. As the recent elections have shown, this hypothetical is not far from reality. National publications in Germany, such as der Spiegel

(the German equivalent of Time), told readers of the importance of the upcoming ICANN elections. Der Spiegel called ICANN the

“government of the Internet”, a term subsequently used frequently throughout the nation, then reviewed ICANN’s candidates and

encouraged readers to register to vote. Thousands of Germans did, to the extent that once registrations were completed,

Germany actually had registered more voters than the rest of Europe combined. As expected, then, the European region elected

a German candidate. The structure of the regions is not, never can be, and perhaps was never intended to be, perfectly representative. However, as Prof. Jonathan Zittrain has noted, the structure certainly promotes competition among nations in a region, and thus possibly force representation where it would not otherwise have existed. However, allowing someone from one country to represent people from a broad diversity of cultures, languages and races may also give that person a disproportionate amount of influence, perhaps also tempting him not to represent certain viewpoints due to exogenous conflicts and experiences. For example, Israel will be represented by the person who also represents Egypt and Saudi Arabia. Even though Internet views differ from real world ideas, it is more than possible that different nations within the same region will be able to have very different “virtual views.”

Nowhere was this clearer than in the Asia/Pacific/Australia region. The Japanese press started printing stories similar to those

that had appeared in Germany, encouraging people to register. But then the rumors started. It was said that Japanese ISPs were

filling in and sending in forms for their clients. Why would they do this, if indeed these rumors were true? Possibly because in

doing so, they felt that it made the election of a Japanese representative much more likely, and as such, they would have more

influence over him/her, and thus within ICANN. It seems that when the Chinese heard these rumors, they reacted. Possibly they wanted a Chinese representative who they could

influence. Again, more rumors began circulating. It was said that Chinese programmers were writing scripts to repeatedly

reconnect to ICANN servers when registrants couldn’t get through, worsening server loads for everyone. Korea and Taiwan also

got involved, again, trying to ensure that a Chinese representative wasn’t elected, so the new director for Asia/Australia would be

more sympathetic to them. Whether any of the rumors were true or not is almost beside the point. Nearing the end of registration

ICANN servers were clogged almost to a standstill, preventing many voters from registering; nonetheless, more people registered

in the Asia region than the rest of the world put together, with almost 4 times as many Asians registering as North Americans. If the ICANN At-Large Board Members are to represent the global Internet community, the At-Large directors should be elected

globally, to enable issue-driven, rather than nationalistic, competition. The fear of capture by the United States seems to have

been proved unfounded by the recent elections. The greatest number of votes by far came from the Far East, rather than

America. Though the Japanese director-elect was elected by mainly Japanese voters, this does not have to be the case. Ideally

in the future voters will choose to vote on issues rather than national affiliation.[17]

The GAC and National Representation However, given that we do currently live in a national reality, some national participation is surely worthwhile, if not essential. The

Governmental Advisory Committee (the GAC) serves this purpose. The GAC only has the power to advise ICANN on any matter

it chooses, however it is clear from past action that the ICANN Board listens closely to the advice of the GAC. In theory, then, people should be able to feel their connections to ICANN through the GAC. However, it seems from the brouhaha

over the At-Large elections that individuals do not view GAC delegates as their representatives. This could be due to the lack of

publicity and transparency surrounding the GAC. Rather than seeing the GAC as an additional avenue for representation, the

press seems to view the GAC as a secretive organization that the Board obeys without question.[18] If the GAC were to operate in a more open, transparent, and representative manner, it might appropriately be given the formal

authority the press (seemingly erroneously) already alleges it has. The GAC might be the best avenue for gaining the sense of

national representation and accountability that many voters in the recent elections seemed to be seeking. If properly composed,

the GAC would contain knowledgeable representatives of all the national governments, and could report back to their home state,

as well as present their home state’s views to ICANN. The role of the GAC could be transformed to mirror the Supervisory Board in German companies (a better translation is Advisory

Board, which seems particularly fitting in this situation). Thus, the directors (via the staff) make the day-to-day decisions as to the

running of ICANN, and for this reason directors should still be elected by some form of membership, whether international or

national. However, the GAC would supervise and advise them on matters of major policy decisions. Thus, if a majority of states

believe that a policy put forward by the directors should not pass, the directors would need to rethink it before proceeding. This

consensus-driven model seems fitting given ICANN’s roots in consensus, and it is also a model familiar to Europeans given its

similarity with their collective decision-making via the EU.

[1] Jeri Clausing, “European Domain Operators Refuse to Pay Bills,” The New York Times on the Web, 7 June 2000,

[http://www.nytimes.com/library/tech/00/06/cyber/articles/07domain.html]. [2]

www.nytimes.com/library/tech/00/06/cyber/articles/07domain.html

[3] Jeri Clausing, “European Domain Operators Refuse to Pay Bills,” The New York Times on the Web, 7 June 2000,

[http://www.nytimes.com/library/tech/00/06/cyber/articles/07domain.html]. (Our italics) [4]

Martin Irvine, “Global Cyberculture Reconsidered: Cyberspace, Identity, and the Global Informational City,” Paper originally delivered at INET '98, Geneva. Revised 17 October 1999, [http://www.georgetown.edu/irvinemj/articles/globalculture.html]. [5]

See “Amendment 2 to ICANN/DOC Memorandum of Understanding,” 7 September 2000. [http://www.icann.org/general/amend2-jpamou-07sep00.htm].

[6] Milton Mueller argues that ICANN’s “self-regulation” is mere rhetoric, masking the reality that the US Department of Commerce still heavily regulates the

organization. Milton Mueller, “ICANN and Internet Governance: Sorting Through the Debris of Self-Regulation,” info vol. 1, no.6 (1999): 497-520. [7]

“Bliley Statement on Domain Name Privatization,” The House Committee on Commerce News Release, 22 July 1999, [http://com-notes.house.gov/cchear/].

[8] US commercial interests have largely ignored the .us ccTLD, having instead opted for the popular .com, .net, and .org domain suffixes. The Internet’s initial

commercial popularity within the US led many companies to opt for gTLDs. State and local governments are the primary users of the .us domain. [9]

Peter H. Lewis, “The Great Domain Name Hunt,” The New York Times on the Web, Technology. June 4, 1998. Does this make them functionally equivalent to

gTLD’s, and if so, why are they still needed?[http://www.nytimes.com/library/tech/98/06/circuits/articles/04tong.html]. [10]

David F. Gallagher, “Internet Labels Lose Meaning in Rush for Popular Addresses,” The New York Times on the Web, 29 November 1999, [http://www.nytimes.com/11/biztech/articles/29name.html]. [11]

The rights to .tv being sold for $50m to be used as a possible TLD for TV stations, and .md being promoted as a TLD for doctors.

[12] “Functions of the ISO 3166 Maintenance Agency,” ISO 3166-1 home page, 18 May 2000, [http://www.din.de/gremien/nas/nabd/iso3166ma/function.html].

[13] See RFC 1591 – ftp://ftp.isi.edu/in-notes/rfc1591.txt

[14]Although the ISO ‘recognizes’ the territory as a state in the real world, it is ICANN’s grant of the ccTLD, a separate action, even if ICANN does not admit this,

that gives the ‘state’ its all-important recognition in cyberspace. [15]

Joanna Glasner, “New Domain May Unite Europe,” Wired News, 20 December 1999, [http://www.wired.com/news/business/0,1367,33156,00.html]

[16] It could, however, have given the GAC more power, as will be argued below.

[17] Some would argue that we are being naïve. We would respond that ICANN should lead, and show the cyberworld the issue-based representation is the way

forward. [18]

This is because, although the GAC has little formal power, the Board has so far listened to everything the GAC has had to say. This is doubtless because foreign governments could possibly make life difficult for ICANN should they choose to do so. However, now that the at-large directors are in place, it is possible that this attitude may change, and the GAC could lose this informal ‘power’.

VOTE FOR REGION 1 DIRECTOR - Asia / Australia / Pacific

NUMBER TO BE SELECTED:

1 TOTAL VALID VOTES:17745 INITIAL QUOTA: 8873

Region Winner : Masanobu Katoh

Nominees CountJohannes Chiang 935Lulin Gao 1750Masanobu Katoh ***WINNER*** 13913Hongjie Li 749Sureswaran Ramadas 398Exhausted Ballots 0TOTAL 17745

Click here to return

VOTE FOR REGION 2 DIRECTOR - Europe

NUMBER TO BE SELECTED:

1 TOTAL VALID VOTES:11309 INITIAL QUOTA: 5655

Region Winner : Andy Mueller-Maguhn

Nominees CountMaria Livanos Cattaui 514Alf Hansen 629Jeanette Hofmann 2295Andy Mueller-Maguhn ***WINNER*** 5948Olivier Muron 544Oliver Popov 389Winfried Schueller 990Exhausted Ballots 0TOTAL 11309

Click here to return

VOTE FOR REGION 3 DIRECTOR - Latin America and Caribbean

NUMBER TO BE SELECTED:

1 TOTAL VALID VOTES:1402 INITIAL QUOTA: 702

Region Winner : Ivan Moura Campos

Nominees CountIvan Moura Campos ***WINNER*** 946Raul Echeberria 141Claudio Silva Menezes 157Aluisio S. Nunes 79Patricio Poblete 79Exhausted Ballots 0TOTAL 1402

Click here to return

VOTE FOR REGION 4 DIRECTOR - Africa

NUMBER TO BE SELECTED:

1 TOTAL VALID VOTES:130 INITIAL QUOTA: 66

Region Winner : Nii Quaynor

Nominees Count

Calvin Browne 30Alan Levin 33Nii Quaynor ***WINNER*** 67Exhausted ballots 0

TOTAL 130

Click here to return

VOTE FOR REGION 5 DIRECTOR - North America

NUMBER TO BE SELECTED:

1 TOTAL VALID VOTES:3449 INITIAL QUOTA: 1725

Region Winner : Karl Auerbach

NomineesFirst stage

2nd Stage Exclusion of: Langenberg

3rd Stage Exclusion of:

Chapin

4th Stage Exclusion of:

Miller

5th Stage Exclusion of:

Tiller

6th Stage Exclusion of:

LessigKarl Auerbach ***WINNER*** 1074 13 1087 51 1138 25 1163 148 1311 427 1738Lyman Chapin 127 11 138 Donald Langenberg 83 Lawrence Lessig 725 14 739 25 764 40 804 172 976 Harris Miller 179 13 192 21 213 Barbara Simons 771 18 789 24 813 38 851 230 1081 500 1581Emerson Tiller 490 14 504 14 518 83 601 Exhausted Ballots 3 3 27 30 51 81 49 130TOTAL 3449 83 3449 138 3449 213 3449 601 3449 976 3449REDUCING QUOTA

1725 1725 1724 1710 1685 1660

Click here to return

Final Total of Activated At Large Members

Date: 10/10/2000 23:59 UTC/GMT

Member Count: 76183

[Note: Since the original total of 76,504 activated At Large members was posted on 8 September, 421 were deactivated either as a result of bounced email or at the request of the member.]

Member Count by Region

Sorted by Region Name

Optional Data Counted by Region

Gender

Count Region 315 Africa

38,246 Asia and Pacific 23,442 Europe 3,548 Latin America and the Caribbean

10,632 North America

Africa

Asia and

Pacific Europe

Latin America

and the

Caribbean North

America Totals Female 34 3062 1868 294 1390 6648

Male 261 18225 19254 3158 7962 48860

No Response 20 16959

2320 96 1280 20675

Total 315 38246 23442 3548 10632 76183

Total: 76183

Domain Owner

Total: 76183

Age

Total: 76183

Role/Occupation

Africa

Asia and

Pacific Europe

Latin America

and the

Caribbean North

America Totals Yes 144 5562 10239 1871 5514 23330

No 143 13893 10500 1478 4068 30082

No Response 28 18791

2703 199 1050 22771

Totals 315 38246 23442 3548 10632 76183

Africa

Asia and

Pacific Europe

Latin America

and the

Caribbean North

America Totals 16-19 4 621 1002 154 462 2243 20-29 104 7787 7637 1211 2288 19027 30-39 101 7015 6667 1069 2330 17182 40-49 39 3410 2994 653 1835 8931 50-59 18 1400 1376 253 1240 4287

60+ 10 148 326 45 388 917 No

Response 39 17865 3440 163 2089 23596

Totals 315 38246 23442 3548 10632 76183

Asia and

Latin America

and the North

Total: 76183

Hear About

Total: 76183

Africa Pacific Europe Caribbean America Totals Business 25 5921 2673 473 916 10008 Computer Software 49 3886 2862 601 1764 9162

Education 21 1330 1815 329 690 4185 Government /

Public Service 19 1201 1496 273 441 3430

Internet Business 102 3338 3641 1065 2067 10213

Law 8 165 491 139 689 1492 Non-Profit

Organization 23 443 837 86 355 1744

Not Employed 2 180 236 9 196 623

Self-Employed 25 551 1621 222 993 3412

Student 13 2424 4201 203 956 7797 No Response 28 18807 3569 148 1565 24117

Totals 315 38246 23442 3548 10632 76183

Africa

Asia and

Pacific Europe

Latin America

and the

Caribbean North

America Totals At Work 53 5526 1868 370 610 8427

Banner Advertisement 1 114 41 6 9 171

Email 94 4105 5065 2129 1928 13321 Friend/Acquaintance 65 2761 3121 421 993 7361

Newspaper/Magazine 15 1348 4958 118 1352 7791 Other 13 887 972 126 882 2880

Print Media 1 162 844 21 212 1240 Search Engine 1 291 42 11 55 400

Website 45 4682 3679 183 3338 11927 No Response 27 18370 2852 163 1253 22665

Totals 315 38246 23442 3548 10632 76183

© 2000 ICANN. All rights reserved.

At Large Director Selection Plan

Resolved [00.66], that the Board endorses the overall plans for the Year 2000 "At Large" Director selection process recommended by the staff and Election Committee (in the documents entitled "ICANN At Large Election: Proposed Rules for Member-Nomination," posted May 19, 2000 as updated July 6, 2000, and "Draft Recommendation on Election Procedures," posted June 23, 2000) subject to the revisions and clarifications in resolutions 00.67 and 00.68 below; adopts them as so revised and clarified as part of a selection plan for "At Large" Directors under Article II, Section 2 of the bylaws; and directs the President to implement the At Large election schedule substantially in accord with the staff's proposed dates and deadlines; and

Resolved [00.67], that the Board endorses and accepts the Election Committee's recommendations, with the following clarifications:

The Board approves the use of Alternative/Preferential Voting to conduct the election.

The Board directs the President to appoint a number of suitably qualified individuals to monitor the election process in accordance with the scope of responsibilities defined in the Election Committee's Recommendation 6.

Resolved [00.68], that the Board adopts the following rules for the member-nomination phase:

1. An individual seeking to be nominated by the membership must notify ICANN by email of his/her wish to do so. The email must include the following information:

Name

Country of citizenship

Place of residence

Physical address and phone number

Email address

Employer(s)

A statement not to exceed 250 words addressing the individual's qualifications and experience specifically relevant to (a) ICANN's technical and administrative responsibilities, and (b) his/her leadership and policy-level roles.

Information indicating material ICANN-related interests, including an identification of:

Employment and consulting relationships

Ownership or investment interests in any ICANN-related businesses

Official positions in any ICANN-related businesses or organization

Any background information, personal statement, URL, or other information the candidate would like posted in connection with his/her name on the ICANN website.

Whether the individual is an official of a national government or a multinational entity established by treaty or other agreement between national governments, such as an elected official or employee of a government or multinational entity.

2. The deadline for an individual to notify ICANN of her/his wish to be nominated by the membership will be August 14.

3. For each individual seeking to member-nominate, ICANN will provide a web page listing the information in Rule 1, except for physical address, phone number, and email address (unless requested by the individual). The pages will be indexed on a common page, grouped by geographic region.

4. ICANN will provide a cgi interface that will allow any At Large Member to indicate support for a given candidate for member-nomination, by entering her/his membership number, password, and PIN number.

5. Each At Large Member will be able to indicate support for one candidate in his/her geographic region for member-nomination.

6. ICANN will send periodic email notifications to the At Large Membership, listing the names of individuals seeking to member-nominate and pointing members toward the web pages for candidates.

7. To obtain a place on the final ballot, an individual seeking member-nomination must meet the following conditions:

Support from 2% of the At Large Members in her/his geographic region, or 20 members, whichever is greater;

Support from residents of at least two (2) countries;

Subject to an absolute limit of 7 candidates per region, including both Nominating Committee-nominated and member-nominated candidates, except that in the event of a tie in which the number of threshold-exceeding tied candidates exceeds the number of available nominations, all tied candidates will be placed on the ballot.

8. The member-nomination process will conclude upon the announcement of the final ballot, which will include the candidates nominated by the Nominating Committee and any candidates who have met the conditions for member-nomination.

Definition of ICANN's Geographic Regions

Whereas, Article V, Sec. 6, of the ICANN Bylaws calls upon the Board to determine a specific allocation of countries among five general geographic regions (Europe; Asia/Australia/Pacific; Latin America/Caribbean islands; Africa; North America); and

Whereas, this year's At Large membership elections will entail the selection of one Director from each of ICANN's five geographic regions; and

Whereas, the Governmental Advisory Committee, upon the ICANN staff's request for advice, recommended that "With regard to the definition of ICANN's Geographic Regions, ICANN should make reference to existing international norms for regional distribution of countries," it is

Resolved [00.64], that the staff is directed to assign countries to geographic regions on the basis of the United Nations Statistics Division's current classifications of "Countries or areas, codes and abbreviations," as revised 16 February 2000, and "Composition of macro geographic (continental) regions and component geographical regions," as revised 16 February 2000.

At Large Membership

Whereas:

1. The Board adopted resolutions 99.87, 88, 89, 90, and 91 on August 26,1999 directing the staff to prepare amended Bylaws, and resolution 99.116 on October 29,1999, adopting amended Bylaws, that established, in Article II, an At Large membership and procedures for the selection of At Large Directors; and

2. The Board has received a significant amount of input from the Internet community relating to both the practical and conceptual bases underlying new Article II as adopted; and

3. The Board has observed that there remains, despite considerable efforts by the Board, ICANN staff, and other entities and individuals, and the limited technical mission of ICANN, a considerable diversity of views concerning the purpose of and rationale for the At Large membership and Council, and the advisability of the various electoral structures and procedures now set forth in Article II; and

4. The Board has observed that these widely divergent views have the effect of creating fundamentally different perspectives about the expected or desired results of the continuation of the At Large processes now underway; and

5. As a result, the Board has concluded that the concept and execution of the At Large membership requires careful and thorough reconsideration.

Whereas:

1. The Board believes that, notwithstanding this conclusion, it is important that the various stakeholders that do not or cannot easily participate in the ICANN process through the Supporting Organizations have a voice in the development of ICANN policy; and

2. The Board believes that such opportunity should not await the results of that reconsideration;

3. The Board believes that any solution to this problem pending the outcome of that reconsideration should ensure that, as is the case with the Directors selected by any single Supporting Organization, the At Large Directors should not be able to by themselves acting in the aggregate control the actions of the Board; and

4. The Board believes that it can accomplish all these objectives with the following set of actions.

Therefore it is resolved that the staff is directed to draft and present to the Board for its review and subsequent posting for public comment prior to adoption proposed amendments to Article II of the Bylaws and other resolutions that accomplish the following objectives:

1. Establish a deadline for the initial selection of five (5) At Large Directors (one each representing each ICANN region) by a direct ballot of qualified ICANN members in each region by no later than November 1, 2000 to serve a term to expire at the conclusion of the Annual Meeting of the Corporation in 2002;

2. Extend the terms of four (4) of the Initial At Large Directors, identities to be determined on the basis of willingness, geographic, and other factors, to expire at the conclusion of the Annual Meeting of the Corporation in 2001, and extend the terms of the other five (5) Initial At Large Directors to expire at the conclusion of the annual meeting in 2000;

3. Establish a Nominating Committee consisting of members appointed by the Board to accept recommendations and nominations from the Internet community as a whole, and to nominate five or more candidates for consideration by the At Large membership for selection to the ICANN Board;

4. Establish a petition process for additional nominations from the At Large membership that meet certain minimum qualifying criteria; and

5. Initiate a comprehensive study of the concept, structure, and processes relating to the At Large membership, on the following schedule:

a. The study to begin promptly following the selection of the five At Large Directors (to take place no later than 11/1/00), with such initial design as is feasible to be done prior to that time;

b. Results of the study to be presented to the Board no later than the second ICANN quarterly meeting in 2001;

c. The ICANN Board to consider the results of the study, and propose for public comment whatever actions it deems appropriate as a result on a schedule that would permit taking final actions no later than the Annual Meeting of the Corporation in 2001; and

d. Implementation of any actions taken so that any subsequent At Large selections can take place on a schedule that would allow any new At Large

Directors to be seated by the conclusion of the ICANN Annual Meeting in 2002;

6. Extend an open invitation to organizations worldwide to assist in the comprehensive study; and

7. Suspend those provisions of Article II of the Bylaws that deal with the structure and process of the selection of At Large Directors pending the completion of the study referenced above and any subsequent actions by the Board.

RFC 1591 - Berkman Center Summary full text available at <http://info.internet.isi.edu:80/in-notes/rfc/files/rfc1591.txt>

Title: Domain Name System Structure and Delegation Author: Jon Postel Date: March 1994

RFC 1591, written by Jon Postel in 1994, describes the structure of the DNS hierarchy. In this picture, the IANA is at the top, responsible for overall coordination, delegating day-to-day administration to registries: InterNIC (generic and unassigned), RIPE NCC (Europe), and APNIC (Asia-Pacific). The RFC outlines the management structure of TLDs, with the suggestion that the same criteria apply recursively to lower level domains as well.

The RFC describes the original nature of the generic domains: COM for commercial entities (with concerns already about the size of the domain); EDU for four-year degree granting institutions; NET "intended to hold only the computers of network providers"; ORG "the miscellaneous TLD"; INT for international organizations; and the US-only GOV and MIL. The substructure of ccTLDs is up to the individual country.

New ccTLDs are requested through InterNIC, and given designated managers responsible for their administration. The designated manager must "be able to carry out the necessary responsibilities, and have the ability to do a[n] equitable, just, honest, and competent job."

The manager is spoken of as a "trustee," to the global Internet community and to its country, for ccTLDs. "Concerns about 'rights' and 'ownership' of domains are inappropriate. It is appropriate to be concerned about 'responsibilities' and 'service' to the community," the RFC states. Equitable treatment of all groups requesting domain names is crucial. The same rules shall be applied non-discriminatorily to all applicants. IANA tries to stay in the background, allowing interested parties in a domain to agree upon the appropriateness of a designated manager. The RFC leaves open the possibility of partial delegation if parties cannot agree or if an applicant cannot fully perform management functions. The designated manager must be technically competent. Transfers of trusteeship must be approved by the IANA.

The IANA tries to take itself and the registries out of the legal and political questions, stating that beyond providing contact information, the registration authority shall have no role in trademark disputes. The ISO 3166 list is the basis for assigning country codes, and IANA is "not in the business" of deciding what is a country.

New TLD Application Analysis and Chart

Leeor Farhadian (lfarhadi@law.harvard.edu), Talia Milgrom-Elcott (tmilgrom@law.harvard.edu), Devesh Tiwary (atiwary@law.harvard.edu)

Harvard Law School

The document below is the work of Berkman Center student affiliates. Accordingly, it does not represent the views of the Berkman Center institutionally; rather, it presents the perspective of its authors.

Go directly to the chart or comment on this document

Introduction

In mid-April 2000, the Names Council of the Domain Name Supporting Organization (DNSO) recommended to the Board of ICANN that the Board establish a policy for the introduction of new top-level domains (TLDs) in a measured and responsible manner. By the close of the application process on 2 October, 2000, 47 applications, ranging from .i to .xxx to .cash, were submitted to the Board. These applications had the potential of becoming pioneers in the expansion of the Domain Name System (DNS) and prototypes for later additional TLDs.

In this paper, we review the application process its origins, goals, and applicants and offer you a non-partisan, outsider review of the 47 applications (see caveat, below). We assess the merits of the proposals (as the applicants present them in their application material on ICANN's website: http://www.icann.org/tlds/) based on the nine criteria established by the ICANN Staff.

In so doing, we are not offering a critical perspective on the standards themselves; instead, we take the existing criteria as the givens and try to give you, as individuals affected by the process, a chart that emphasizes the most important information submitted in the proposals and a guide for identifying the most comprehensive and urgent proposals. The bulk of our task was to summarize the proposals within the framework of the relevant criteria, but we have also interjected our own evaluations where we felt they complimented or elucidated the proposals, especially regarding the general criterion of completeness. Our perspective is decidedly non-expert, but provides the insights of regular Internet users interested and concerned with the selection process. By its very nature, our chart is an incomplete summary and cannot substitute for a thorough reading of each proposal.

We do believe, though, that its easy reference format can aid you, the concerned Internet user/citizen, by offering a base level framework by which to assess yourselves the relative strengths and weaknesses of the various proposals.

Background

In mid-April 2000, the Names Council of the DNSO recommended to the Board of ICANN that the Board establish a policy for the introduction of new top-level domains (TLDs) in a measured and responsible manner. Shortly thereafter, at its 16 July 2000 meeting in Yokohama, the ICANN Board of Directors adopted a policy for the introduction of new TLDs with the intention of bringing a small number of new TLDs into operation early in the year 2001.

The purpose of inaugurating new TLDs was threefold. First, there was broad consensus that the introduction of new TLDs would enhance the competition in the provision of registration services, a process which until

now has been dominated by Network Solutions, Inc. (NSI). Second, new TLDs held forth the possibility of increasing the utility of the DNS by allowing it to be filled in a way that makes logical sense. Third, expanding the number of TLDs would respond to the clear problem of a finite and quickly-depleting store of available semantically appealing domain names.

The introduction of a limited number of new TLDs could also be used as a test-case for the further expansion of the Domain Name System. As such, the Board resolved that the initial introduction of new TLDs should include a variety of types of TLDs, in order to provide useful data to determine what types of TLDs should be introduced in the future.

At the same time, the introduction of new TLDs posed a potential threat to the stability of the overall structure of the DNS. Given that the introduction of new TLDs is not an easily reversible act, particularly once domain names have been registered within it, the potential ramifications of the collapse of a new TLD are enormous. In order to ensure that the new TLDs not endanger the effective functioning of the DNS, the Board resolved to make stability of the DNS a paramount concern in the evaluation of the applications. The care with which the new TLDs are chosen further reflects the recognition that engendering broad user confidence in the technical operation of the new TLDs is critical to the ultimate success of the expansion of the DNS.

The Nine Criteria

The ICANN staff intends to consider the factors described below to determine its initial selection of TLDs. We outline them here to facilitate your understanding of the process and perusal of the chart.

1. The need to maintain the Internet's stability:

ICANN's first priority is to preserve the stability of the Internet including the domain-name system (DNS). The introduction of the proposed TLD should not disrupt current operations. Security and reliability of the DNS, in the face of system outage, technical failure, or malicious activity are important aspects of stability.

2. "Proof of concept" for introduction of top-level domains in the future:

Proposals should be chosen so as to promote effective evaluation of different policies, operational models, business and economic models, institutional structures and the feasibility and utility of different types of new TLDs.

3. The enhancement of competition for registration services:

Proposals will be evaluated to determine whether they are responsive to the general goal of enhancing competition for registration services. For example, how will the proposed TLD compete with other TLDs? Is the proposal particularly attractive to a significant sub-market in which it can compete effectively?

4. The enhancement of the utility of the DNS:

One motivation for introducing new TLDs is that doing so might increase the utility of the DNS. Under this view, the appropriateness of adding new TLDs should be evaluated based on whether addition of the new TLDs would sensibly add to the existing DNS hierarchy and would not create or add to confusion of Internet users in locating the Internet resources they seek.

5. Meeting existing needs:

The DNS should meet a diversity of needs, especially those which are presently unmet.

6. Diversity of the DNS and of registration services generally:

One goal of introducing new TLDs should be to enhance the diversity of the DNS and the manner in which registration services are provided. In particular, types sought are fully open top-level domains, restricted and chartered domains with limited scope, noncommercial domains, and personal domains. This criterion must be judged based on the whole group of selected proposals, rather than any single proposal.

7. Delegation of policy-formulation functions for special-purpose TLDs:

For restricted TLDs, the application suggests a "sponsorship" model, in which policy-formulation responsibility for the TLD would be delegated to a sponsoring organization that allows participation of the affected segments of the relevant communities. Proposals will be analyzed to determine whether they offer the opportunity for meaningful, real-world evaluation of various structures for appropriate delegation of policy-formulation responsibilities, as well as evaluation of various allocations of policy-formulation responsibilities between ICANN and sponsoring organizations.

8. Appropriate protections of rights of others:

In introducing new TLDs, care should be taken to ensure that the rights of third parties are appropriately protected. For example, does the proposal have a plan for name allocation during the start-up phase in a way that protects the legitimate interests of existing domain-name holders, businesses with legally protected names, and others with which conflict is likely? Is there a good mechanism for resolving domain-name disputes?

9. Proposal completeness:

The extent to which they demonstrate realistic business, financial, technical, and operational plans and sound analysis of market needs will be analyzed. Clearly presented proposals that are substantive, detailed, and specific will be preferred.

Picks

In compiling our recommendations for the best applications for new TLDs, we had a number of objectives in mind. First, we wanted a variety of types of TLDs reflecting the diversity of the applicant pool and the diverse array of possibilities for new uses of the top level domain name system. In this pursuit, we were guided by ICANN's own understanding of diversity as articulated in the nine criteria. As such, we looked especially towards picking an assortment: TLDs that offered unrestricted access, TLDs that proposed restricted and thematically organized access, and TLDs that experimented with entirely new models of what a TLD could provide.

For all of our picks, stability of the Internet and the domain name system as a whole functioned as a threshold requirement: even if we were enamored with a concept and the business model to support it, if we were not confident that the organization could assure the stability of the Internet and the security of its TLD, we did not include it in our list.

Lastly, we looked for impressive credentials across all nine of ICANN's criteria. Although no one criterion predominated, we did keep the idea of this process as a proof of concept in the not-so-distant background of our calculations. The importance of these first new TLDs in establishing positive and replicable precedent for the continued measured expansion of the TLD system remains a major concern.

The following is our list. We intend it less as an authoritative guide and more as a heuristic by which we invite you to assess your own judgements of the new TLD pool.

.air: .air is among the finer examples of a restricted and focused TLD. The potential constituency -- the airline business and related industries -- lends itself to easy definition of who is and who is not included and represents a burgeoning sector of the economy. The target sector stands to gain real benefits (safety, efficiency) from the proposal, as the new TLD would provide them with a useful set of functions. The combination of clear constituency and useful service/product makes for a potent business opportunity. The sponsor and registry possess the necessary expertise and have constructed a clear proposal with achievable objectives that fulfill ICANN's interest in restricted TLDs.

.biz (Abacus): Abacus's .biz is the most comprehensive plan of those proposed as alternatives to .com. Again, the registry is established and seems able to execute the ambitious proposal. While the proposal itself is not particularly creative, modeled as it is on the ubiquitous .com, it is a fine example of the generic and open TLDs we evaluated. If the expansion of the TLD hierarchy is motivated in part in order to provide genuine competition to .com, we believe that Abacus's .biz may be in the best position to fulfill that goal and/or test its validity.

.health: With .health, the World Health Organization proposes an innovative model of what a TLD can do: provide a seal of approval to health information on the Internet. The TLD is intended to be a source of credible health information and is, as such, not specifically commercial, although potential commercial applications are obvious. .health is representative of the minority of TLDs whose base is outside of the United States, in this case, in Geneva, home of the WHO.

.name: The .name TLD, backed by IBM, offers one of the strongest proposals for a personal domain space. With the goal of providing an easily recognized global personal addressing system, .name offers a non-commercial space that distinguishes individual users from corporate entities. The system is scalable: registration is available only at the third level; however, it remains to be seen how .name intends to deal with the problem of multiple applicants with the same first and last names.

.travel: .travel provides an interesting, focused proposal in an extremely thorough application package. The new restricted TLD is sponsored by a well-respected international organization with many decades of experience in resolving name and designation disputes in the offline world of airline and airport codes. The potential market is large and robust. The new TLD would offer an innovative combination of commercial and informational public service uses.

.post: .post, like .name, is another compelling example of a permanent personal address domain. Sponsored by a UN agency, .post offers yet a different take on the potential uses of a new TLD. The model here presented does so with specialized smart message delivery. The veteran registry operator is robust and trustworthy.

New TLD Application Chart

The following chart analyzes the applications for new TLDs according to the criteria expressed in the ICANN Staff's Criteria for Evaluation of new TLDs. Each TLD application is rated on each criterion on a scale from

0-3. Each application is then given an overall rating from 0-3 based on the ratings in each category.

TLD Label Applicant

General TLD Description

ICANN Staff Report Review

Summary

Stability Proof of Concept

Competition Utility Complementariness: Filling Unmet

Needs

Diversity Delegation Protection of Rights

Completeness

.ads

(Name.Space Inc)

almost 100 specific TLDs that aim to be given meaning by 2nd level domains.

Strength is registry-registrar experience. weaknesses are marketing plan, human resources. Weaker than others in category.

2: sufficient technical capabilities. Experience running an alternate root.

0: writes that new TLD’s are “beyond proof of concept,” b/c method already proven

1: considers itself as competitor to .com. No explanation of tld label choices. Standard registrar competition.

1: argues that global nature of net requires multiple, specific, TLD’s, that TLD alone is “meaningless”. Does not distinguish utility of any particular requested label,

0: not described 1: Uses standard model of relationship with registrars. For-profit model. American company.

N/A: no sponsoring organization. However labels requested suggest possibility of restrictions on registrations.

1: Rejects UDRP in favor of existing legal means; encryption, no cookies, no sale of info; has famous names policy

1: Contrary to established ICANN criteria and policy foundations; aims to work by operating numerous TLDs – unfeasible under current expansion

.africa

(Rawthbawn Computers Limited)

8 diverse TLDs to better characterize domains

Strength is registry experience and large target market. Incomplete demonstration of understanding of the business. Weaker than others in category.

2: cost-based registry model. Significant Internet experience. Accredited registrar, .hm management. Sufficient technical plan

2: value of identifiable domain names to characterize the domain space; demonstration of price elasticity of domain names

2: use of ICANN accredited registrars. Formal competition policy. Agreement to not to act as a registrar for the registry.

2: TLDs are semantically meaningful and appealing. Not confusingly similar to .com.

2: contrast to vagueness of “.com”, providing sites for populations underrepresented in .com.

2: Cost-based registry model. Irish company. Semantically but not formally restricted TLDs.

N/A: no sponsoring organization. However some of the proposed labels could require policy in the future.

2: endorses UDRP; short sunrise period

2: no explanation of why these particular TLDs were chosen; concept of unrestricted yet specific TLDs could internally conflict

.air

(Societe International de Telecommunications Aeronautique)

restricted TLD for the air transport industry, including information for travelers, airlines, etc.

strengths include focus on target market, commitment to IT to the air transport section, and revenue model and market definition. Stronger application.

2: some past Internet service experience. Sufficient technical plan. Possible financial difficulty due to small market.

2: defines a very clear market. Possibly a good test for the viability of a restricted-use TLD

1: Market is well represented in .com and small. Few registrars, little or no registrar competition

2: Very clear purpose, not at all confusing. Semantically meaningful selection of TLD label.

1: Potentially for a market already adequately served.

2: sponsored TLD with restrictions on registration. European organization.

3: Delegation of all decision-making about entry into TLD to expert body in airline field. Clear delineation of those who belong in TLD.

3: Generally conforms to ICANN policies, pre-screens for trademark infringement. Requires references.

2: the proposal is quite thorough and thoughtful.

.biz

(Abacus)

5 unrestricted TLDs, with focus on “.biz” as “.com” alternative

Strength is registrar experience and TLD market. Weakness is lack of marketing analysis and strategy. Overall not as strong as others in its category.

2: established business. Strong previous Internet and registration experience. Good technical plan. Adequate funding.

3: name registration requires registration of both a second and third level domain. Start-up phase has auctions for names requested by more than one person.

3: provides competition to .com. Uses ICANN Accredited registrars.

“.biz” creates DNS space; “.inc” as corporate info. space; “.xxx” as identifier, separator with “.fam” as counterpart, “.cool” for youth . May be confusing.

2: Choices of TLDs based on surveys inquiring into need. Attempting to deal with the saturation of .com

2: new model for registration for unrestricted TLD. Interesting start-up phase. Similar in business model to .com. For-profit. American.

N/A: no sponsoring organization and proposing and unrestricted TLD. Some of the requested strings could require delegation in the future.

3: supports UDRP with minor modification; pre-screening for confusing domains; sunrise period for famous marks

3: comprehensive and useful; diversity in TLDs

.biz

(Affinity)

alternative to “.com” restricted to established businesses to prevent cyberhoarding

Strengths are large market, Internet experience and innovative business model. Weaknesses are lack of detailed marketing plan and support for revenue model. Overall not as strong as others in category.

1: Very good capital and good technical capabilities.

2: restricting to “active” businesses while still competing with .com. registration similar to some cc’s in that registration may be in a third level with the tld, then a country code, then the company name

1: doesn’t claim to increase comp.

2: corollary to “.com” may be useful for providing some level of trust that businesses there are legitimate businesses.

1: possibly filling any need created by .com scarcity or for TLD for verified businesses.

2: restricted to “legitimate businesses”. Registrations in third level domains. One registration per registrant no registration of confusingly similar names.

2: Registrar accepts applications, checks initial biz eligibility, checks duplicates; registry records registrations, maintains database, final checks

2: prevent cyberhoarding through checks on biz credentials; screening period for trademarks searches, similar names; major marks system; slightly modified UDRP;

2: laudable goal of prevention of cyberhoarding, might not necessitate creation of new TLD; unclear what role “.com” would continue to play

TLD Label Applicant

General TLD Description

ICANN Staff Report Review

Summary

Stability Proof of Concept

Competition Utility Complementariness: Filling Unmet

Needs

Diversity Delegation Protection of Rights

Completeness

.biz

(idomains)

an alternative to “.com” restricted to commercial businesses and particularly attentive to intellectual property problems

Strengths are registrar experience, marketing, involvement of CORE. Weakness is low initial capitalization. Stronger than others in category.

2: Good past experience through sister company. Good technical plan. Adequate financials.

2: testing out potential of emphasizing geographic location by giving 3rd level domains in 2nd level country-specific domains. Fat registry

2: directly competitive with .com

2: Expert group will determine criteria to distinguish commercial identities; dual naming aids in directory services; still may cause confusion.

2: alternative space to “.com” to deal with .com scarcity problem.

2: very similar to .com model. Good geographic diversity and strong emphasis on geographic diversity.

2: No sponsoring organization but a Business Advisory Panel to enforce restriction. Allows only commercial enterprises and checks by tax ID

2: sunrise period for trademarks: adopts UDRP; reqd. prepayment, min. 2 year registration period; no pre-screening

1: seems to make disorganization problem of other countries our own in dual naming

.biz

(jvteams)

competition for .com in the form of a large .biz TLD limited to use by businesses.

Strength is very strong marketing plan and exploration of target markets. Weakness is high projected initial losses. Stronger than others in category.

2: Solid technical and financial plan

1: generally quite similar to .com in structure. Some small innovations in start-up policies and management of registrant data.

2: directly competitive with .com. Structured similarly to allow for good competition. Use of accredited registrars.

2: possibility of confusion with .com. Semantically meaningful because it is only for businesses.

2: alternative space to “.com” to deal with .com scarcity problem.

1: restricted to businesses. Otherwise very similar to .com

2: very little delegation, but some is needed in order to make determination of whether organization is a business.

2: adopts the UDRP with minor modifications. Structure of registrations is similar to .com with respect to prevention of trademark disputes.

2: a thorough and clear proposal. The most basic .com competitor applying. Few innovations, but solid proposal.

.biz

(kdd internet solutions)

two very generic, unrestricted TLDs, aiming to create space, with focus on expanding Asian presence

Strengths are parent with resources and partner with Internet experience. Weakness is role of NSI. Stronger than others in category.

2: thorough compliance scheme

2: increase in domain names; upgrade of whois; geographic diversity

2: competition for Asian business

“.biz” for global, “.home” for homepage; more sophisticated Whois

2: need for more Asian registrants

2: Asian registry and large emphasis on geographic diversity.

N/A: no sponsoring organization

2: endorses UDRP and other existing procedures; no sunrise period

No details of functions of TLD’s except focus on Asian market – might be achieved through increased attention under existing TLD’s

.cash

(Diebold)

3 TLDs that restore self-identification to domain holders that have been diluted by “.com”

Strength is resources and stability. Weaknesses are lack of experience, market definition, incompleteness of application. Weaker than other apps in category.

2: more stability by sponsor as registry and registrar; adequate financial and technical plans

2: single-registry, registrar model; augmented DNS space; self-i.d.; measured by registration numbers and problems

1: none initially at registrar level; aims for more efficient pricing

2: restores self-i.d. of affinity groups; claims image of security to domains using “.secure,” but no tech. support. May cause confusion with .com

2: generally expanding name space to deal with the scarcity problem.

2: 3 TLD’s aimed to certain groups, but not restricted. Not all necessarily distinguishable from .com

N/A: no sponsoring organization

2: sunrise period to check trademarks; no pre-screening or pre-registrations; supports UDRP; open access to whois info.

2: benefit is essentially creating more DNS space, but risk of confusion (e.g. mcdonalds.global or mcdonalds.com)

.co-op

(Cooperative League of the USA)

Restricted TLD for co-ops to identify themselves to users

Strengths are assessment of market, thoroughness of business proposal, and critical objectives. Registry may need more employees. Solid, strong proposal.

2: Respond to all elements of application; physical security not discussed

Firewalls, 3rd party monthly sweeps; no single point of failure; off-site redundancy;

2: TLD with cross-sector reach; TLD cuts across different industries, levels of wealth; unique registry model

1: single registrar during startup period; expertise re co-ops req’d.; competition with existing TLDs

2: clearly serving a particular target audience.

1: limited use for users outside co-ops but co-ops financially distinct from current TLD’s; establish trust and identity

2: members must be co-ops; diverse in economies

2: registrar checks eligibility; otherwise, standard delegation

2: supports UDRP, no pre-screening; only legal names can be registered; sunrise period

2: limited use even for co-ops; required i.d. as co-op creates risk in registry model

.dir

(Novell)

Meta-directory TLD restricted to existing TLDs as second level domains, for purpose of allowing domain name holders in other domains to publish directory information about their site in an easy to locate spot

Strength is innovative approach. Weakness is insufficient marketing plan and chance of no market acceptance. Interesting but risky proposal.

2: maintains pre-existing TLD in 3rd level; no rush for new names, no ambiguity, disputes

2: number of registrations, different uses; level of interoperability; new routing procedures

3: differentiated marketing; competition in interoperable services, hosted content; model encourages longevity

3: facilitates digital certificates (encryption, authentication…);

better data delivery; fresher data

2: federation point for building relationships

2: restricted to existing domain names in second level

2: direct dealing with registrar; standard delegations

2: supports UDRP; good-faith checks

3: aids biz to biz, fresher data; stable and realistically achievable implementation; unique in scope and aim among proposals

TLD Label Applicant

General Description

ICANN Staff Report Review

Summary

Stability Proof of Concept

Competition Utility Complementariness: Filling Unmet

Needs

Diversity Delegation Protection of Rights

Completeness

.dot

(NeuStar)

proposes “.web” as unsponsored, unrestricted domain space to compete with “.com” on the Net.

Strength is thorough marketing and analysis. Good application made weaker by withdrawal of Melbourne IT as a partner.

2: ample physical security and infrastructure

2:level of competition; lower prices, charter compliance within limited UDRP, round robin startup method, fat registry

3: unlimited registrars; ICANN accreditation basis

1: possibility of confusion with “.com” by users

1: conventional advantages of creating more space; competition, fresh infrastructure, better pricing

1: generic TLD, conventional registry model

N/A: unsponsored TLD.

3: modified “daybreak;” supports UDRP; will follow ICANN; “string screening;”

2; thorough proposal, a new “.com” space and nothing more

.dubai

(Dubai Technology Electronic Commerce and Media Free Zone Authority)

1 restricted TLD, “.dubai” and one general, “.go”

Strength is resources. Weakness is insufficient market analysis and financial statements. Weaker than other apps in category.

2: multi-database servers with offsite backup; alliance with Network Solutions

1: number, satisfaction of applicants; costs and revenues

0: not discussed 2: theoretically more stringent standards against abuse by registrants

1: new open space in “.go”; affiliation with UAE in “.dubai”

2: restricted and unrestricted proposals, “.dubai” to be affiliated with UAE, additional criteria for “.go” to be devised

2: registry to create policies and registrar to implement them; registry runs whois

2: screening criteria; monetary damages; description of use; projected activation dates; supports UDRP

2: proposed goals are same as current TLD system; basically a fresh start for “.com,” but with almost no new safeguards; poor proof of concepts

.event

(Internet Events International, Inc.)

to represent event industry in its broadest characterization; 2nd level domains during first 6 months only, beginning with 6 already picked

Weaknesses: no firm financing, no detailed business plan, no registrar or registry experience. Weaker than other apps in category.

2: registration in parts aids stability

2: projected registrations; publically accessible restricted TLD; sub-domain structure; search engine

1: will compete with online TLDs at all levels

2: easier searches 1: easier accessability of events, organization of related sites

2: use of sublevels diversifies; content limited by PICS; new sub-event domains

occur quarterly

0: not described 2: startup period for commercial uses only; supports UDRP

1: incomplete, no specific needs to be met by proposal, no description of biz model

.fin/.finance

(Association Monegasque Des Banques)

A restricted TLD devoted to the finance sector to “promote the interests of the international financial community.”

Strengths are targeted market, experience in sector. Weak marketing, demand, and representativeness. Could be successful within its market.

2: experienced registry/ar; independent systems at different locations of well known connectivity

2: value of restricted TLDs; connection between accredited membership and integrity of information available; appeal to financial sector of a TLD other than .com; no pricing scale

1: may provide alternative to .com. all ICANN- approved registrars can register; no proposals for how they’ll compete with .com; serving needs of arguably well-served constituents

2: the name is well-matched to its function, but not in all languages; may lead to confusion, as .fin can refer to find, as well.

1: although TLD could add integrity to financial information on the web, the entities that would be served by .fin are arguably well-served by .com already.

2: Geographic; strong European and internat’l base; restricted with clearly defined membership; commercial.

2: decisions made by Board and approved by government of Monaco.

1: no sunrise period; posting of all apps. on web site; review;

for disputes, either Board decides or UDRP; UNCITRAL;

compliance with “all competent legal authorities;” Whois

2: criteria for inclusion in .fin not yet established; procedure for denying or canceling membership not established; little advertising.

.find/.yp

(Monsoon Assets Limited)

A search engine that will provide a technology platform to enhance existing directory services.

Strength is innovative proposal. Weakness is incomplete and insufficient business proposal. Other apps in category are stronger.

3: fully respond to criteria in application

2: innovative use of a TLD; value of directory as TLD; use of region as basis.

1: doesn’t enhance or intend to enhance competition; doesn’t serve new market.

1: .yp is confusing, especially for non-users of American yellow pages; .find is also particularly English; similar to .fin

2: Doesn’t service a new population; does enhance ease of access. Q: is this technology uniquely suited to be a TLD?

2: different conception of how to use TLDs; doesn’t serve a new constituency

2: Unclear; policy issues secondary.

2: largely a non-issue, as this is only providing a service; UDRP.

3: careful analysis; good tech background; strong principals participants; strong business model.

.firm/

.game/.news/ .shop/.tour (Eastern Communications Company Limited_

Unrestricted but differentiated TLDs for commercial purposes.

Strength is diversity and financials of Eastcom. Weakness is no marketing plan, rationale for estimate demand, rationale for resources to meet demand. Weaker than other apps in category.

3: high level of expertise; respond to all elements of application.

2: viability of differentiated but unrestricted TLDs; no pricing scale to deal with initial rush.

2: may offer competition to.com; utilizes all existing registrars.

2: the names relate to their purposes, but primarily in English; there are no restrictions to membership, so members’ content need not relate to TLD name.

2: potential competition, for .com; not tapping a new market.

1: unrestricted with intended limited scope; commercial; based in China.

2: unspecified, except that utilize ICANN policy where it already exists.

1: undeveloped and conflicting plan (ex. Reference to contradictory policy for famous marks); UDRP; Whois; ICANN-NSI privacy policy

2: undeveloped business proposal;

TLD Label Applicant

General TLD Description

ICANN Staff Report Review

Summary

Stability Proof of Concept

Competition Utility Complementariness: Filling Unmet

Needs

Diversity Delegation Protection of Rights

Completeness

.geo

(SRI International)

TLD that will provide infrastructure for registering and discovering georeferenced information on the Internet.

Strengths are sponsor and operator resources, experience and capabilities. weaknesses are market definition and acceptance. Overall, could lead to a successful new TLD

3: high level of expertise; respond to all elements of application.

2: value of innovative use of a TLD; ability of TLD to enhance a technology; does it reflect purpose of adding TLDs?

2: new market; competition in geodata providers; no apparent competition with existing TLDs; competition among registrars.

2: while .geo will not add confusion and is semantically connected, unclear that it adds sensibly to existing DNS hierarchy.

2: unclear if this is a need that hasn’t been met and would be best served by adding a TLD as opposed to offering a web-based service

3: different conception of how to use TLDs; restricted domain with limited scope for a uniquely defined constituency

2: delegate policy to body within SRI which will open and representative.

2: start-up phase protection for trademarks. Whois. Unclear dispute resolution. Verification certificates.

3: well-conceived; sufficient resources; as long as there is real market need, the plan looks strong.

.health

(World Health Organization)

Restricted TLD to “promote health information quality on the Internet.”

Strengths are WHO role in community, trusted health info, and CORE involvement. Weak target market discussion and financial statements. Could be successful.

2: respond to all elements of application; however, registry failure provisions do not seem as robust as other TLDs’.

3: restricted, not specifically commercial TLD; sunrise period for approval process; competition between registrars re: pricing and services.

3: Registrars can compete based on speed and efficacy of accreditation; potential competition with existing health sites

3: .health suggests the purpose; is chosen by international body, so likely useful in many different languages; doesn’t conflict with existing tlds

3: plans to provide a seal of approval to health info on the net, a potentially growing and useful service.

3: sponsored; restricted; not specifically commercial; centered in Geneva; source for information.

2: no specific delegation of policy; WHO will make decisions; accept recommendations from outside organizations.

3: provisions for variety of circumstancess; UDRP; ex ante attempts to minimize infringement; Whois.

2: well-conceived; backed by serious resources and respected international body; potential liability problem; what are international ethical principles?

.i

(Sarnoff Corporation)

Structured addressing system which is hierarchically expansible based on an ordered naming convention.

Strength is good marketing plan. Weakness is unclear capital commitment. Stronger than other in category.

2.5: high level of expertise; respond to all elements of application;

2: value of innovative use of a TLD; ability of TLD to enhance a technology; pay scale: free registration for a lesser domain name.

2: Competition b/w registrars; competition in software creation; no competition with existing TLDs.

1: while .i relates to personal information in English, .i has no relevance in other languages.

2: provides a personal domain, in contrast to .com, .net, and .org

2: different conception of how to use TLDs; non-commercial; personal domain.

2: plan to create an unofficial policymaking organization to develop standards.

3: non-transferability of domain names; UDRP; Sunrise (here called daybreak); takedown policy; Whois

2: application is robust;

.web/.info/.site

(Afilias, LLC)

Unrestricted TLD intended to compete with .com, positioning itself in relation to a global or particularly international market.

Strengths are market understanding, market plan, resources, and rationale for demand. Stronger than other applications in its category.

3: well-thought through plans; mirroring servers to minimize potential disruption; sunrise period before official registration period opens up; no technical staff yet.

3: whether unrestricted TLD can compete with .com without duplicating; co. owned by collection of rivals; flat fee

2: registrar-level competition;

unclear how TLD will compete with .com; could lead to confusion and second-rate status.

3: .web is connected to intent of the TLD, is recognized internat’lly. Fosters creation of web presence for companies that share DNs.

2: mirrors .com for global market; replenishes set of DNs; offers previous DN holders priority, so unclear why xyz.com won’t just buy xyz.web.

1: commercial; unrestricted; i does not provide diversity in manner in which registration services are provided; geographic diversity in support facilities.

1: manage most affairs internally.

2: sunrise period; robust Whois services; UDRP; no pre-screening;

Privacy: Full disclosure, must sign privacy policy; no unsolicited emails based on Whois list.

2: unclear that any unrestricted TLD can compete with .com in interesting way; possible that experimenting with it will lead to the to backtrack; may be worth it for P of C; otherwise strong

.kids

(Blueberry Hill Communications, Inc.)

unrestricted TLD intended to provide a secure environment for kids, but without guidelines for content.

Strengths are target market and vision. Weaknesses are lack of registration restrictions and committed subcontractor. Weaker than others.

2: Less robust technical background; some of the technical elements of proposal are speculative or vague.

2: Using business to generate charitable funding; low capital requirement; new use of DNS

1: unclear how .kids will compete with .com or what particular appeal .kids as an unrestricted TLD holds;

2: TLD label suggests use, although primarily in English; is distinct from existing TLDs; no guarantee that label predicts content.

1: open access doesn’t provide code of ethics for kids’ material .kids says is lacking.

1: commercial, fully open; no particular geographic diversity; standard business model

2: Unclear; advisory board for facilitation, but no explicit policy-making functions

2: accept UDRP; privacy policies, limited access to Whois; don’t charge upfront; sunrise phase

1: no definition of “appropriate material for children”; no body to deal with questionable content; vague business plan

.kids

(DotKids, Inc.)

Unresitricted TLD for kids and teens intended to give Internet users confidence in the content.

Strengths are vision and experience of partner. Weaknesses are irregular financial statements. Weaker than others in category.

1: Less robust background than other TLDs; no information on operation of registry system; Plans to outsource to unknown company.

1: No plans as to technical operations makes for dangerous first round new TLD; does provide rating system along with TLD.

2: standard competition among registrars; unclear if .kids could compete with .com based on unrestricted nature

2: See above. 1: Since TLD is unrestricted, unclear why it will provide confidence in the material.

1: see above 3: team consisting of partners with varying expertise; using outside advisers and rating service

2: Full implementation of UDRP; sunrise for trademark holders; privacy: undetermined.

1: : The business model is unclear and the technical side is virtually nonexistent. See section D.13.2.7 and 2.8

TLD Label Applicant

General TLD Description

ICANN Staff Report Review

Summary

Stability Proof of Concept

Competition Utility Complementariness: Filling Unmet

Needs

Diversity Delegation Protection of Rights

Completeness

.kids/.xxx

(ICM Registry)

Two TLDs with the goal of differentiating child- from adult-oriented material through self-rating and self-determined guidelines.

Strengths are marketing strategy, large target market, IP experience, financials, and technical partners. Weaknesses are staff size and feasibility of objective. Stronger than others in category.

3: partners with experience and credibility in providing such services; detailed plan that deals with necessary elements.

3: Auction method of DN registration and protection of IP rights; advisory boards to establish norms and regulate content; filtering services as revenue generator

2: will provide competition to .coms in the registration of porn sites, although likely existing porn sites will want the parallel .xxx site, as well, leading to redundancy.

2: TLD labels do suggest use; uncertain if proliferation of porn on the web, a certain outcome of .xxx, is a primary goal for this first round of new TLDs.

1: While relative consensus as to need for kids' space, not so for porn; unclear that TLD is way to provide for kids; unclear that this plan provides incentive for DN holders to self-rate their content?

1: restricted domain with scope based on purpose; geographic: plan to market to N America first; largely commercial (although .kids may be non-profit); standard business model

3: Based on a coalition of businesses; policy made by Advisory Board w/ broad base of members

2: UDRP; sunrise period; public posting of all applications; independent Regsitry to monitor IP infringement; auction when interests compete.

2: while strong business plan, unclear how disputes will be resolved by policy boards; how rating system and filtering will comply with Const. limits.

.kids

(.Kids Domain Inc.)

Restricted TLD with internally mandated standards whose goal is to create a safe platform for businesses to reach children.

Strengths are narrow focus, content control, capitalization. Weakness is unspecified marketing plan. Strongest application in this category.

2: While tech partner Tucows has experience and existing and uses an open-source system to increase portability, registry failure provisions are relatively thin.

3:Restricted, content-based site with internal audit; many DNs procured through auction; high costs of registration; shared pages for disputed marks.

1: no registrar-level competition; possible that auction will price smaller DNholders out of market for appealing DNs; may provide competition with .com for kid-related sites.

3: TLD label suggests use, although primarily for English-speakers; is distinct from existing TLDs.

2: Broad appeal of monitored kids' space on net, although uncertain if TLD and this plan are best solution.

2: Restricted TLD based on their internally-created criteria; commercial.

2: While policy is based on external standards, it is internally created and enforced by a Content Policy Board

3: UDRP (patterned on existing one); Whois; sunrise period; independent checks against existing TMs; plan for shared pages for disputed TMs.

2: Funding commitment for .kids, tech partner Tucows has established fiancial capabilities. However, see concerns above.

.law

(DotLaw, Inc.)

Restricted TLD whose purpose is to serve the international legal community

Strength is focus community. Weakness is lack of detail, marketing and financial statements. Weaker than others in category.

2: Redundant systems; constant power supply; guarded protection; scalable system; current backup

2: Effect of small pool on startup process; restricted, themed site; outside authorization for admision

2: Registrars must apply; potential competition for .com, but will it only lead to duplicative sites?

3: TLD label suggests use, for English and non-English speakers; distinct from existing TLDs.

1: Entities that would be served by .law are arguably well-served by .com already.s

2: Restricted; sponsored; crierion for inclusion established; American-based; both commercial and non-commercial.

2: Unclear: will look to the Bar Associations and ICANN

2: no DN resale; protection for famous TMs; Whois; UDRP; right of first refusal

3: Specific marketing plan; business plan; guidelines for content established

.mall

(Commercial Connect)

3 second-level TLDS for commercial entities with different registration criteria for each TLD

Strength is financials of one partner, registry experience of others. Weakness is lack of detailed business/marketing plan. Weaker than others in category.

2: creation of new space probably doesn’t disrupt old, but for familiar problem of user confusion in using proper TLD; core backed proposal

1: that shopping can proliferate exponentially

1: will create more demand for new shopping services on the web, and competition will follow

2: clarity of use from user perspective; personalized service

2: creates new space as alternative to “.com;” claims to restore “purity” to the Net

2: restricted TLD w/ biz credentials checks; for private individuals as well; “.shop” for sale of goods, “.svc” for services; “.mall” for commercial outlets

2: majority of dealings w/ registrar, registry as overseer

2: adopts UDRP, sunrise period; no pre-screening; thick registry; centralized whois; 2 year initial registration

2: thorough but uncreative application; 3 TLDs excessive for biz use; poor proof of concept, competitive model

.mas

(Nokia)

8 non-profit TLDs focusing on the power of mobile communications, with phone number or nickname as domains, plus special services designed for mobile access

Strength is financial and technical resources. Weakness is marketing and business plan. Not as strong as others in its category.

2: domains managed systematically; technical solutions developed step by step to allow testing

2: utility of this distinct TLD, ease of mobile communications; registry model; creation of new features

1: substantial number of registrars projected

3: supports mobile communications in efficient manner; users will be sure phone can handle the content; allows creation of new features

2: Supports increasing Net use by phone of distinct, untraditional uses

2: restricted to providers of mobile services

2: registry registers 2nd level domains, registrars the 3rd; traditional overseer role for registry

2: must demonstrate clear utility for users of domain; similarity to trademark checks; pre-screening, UDRP adopted

3: wireless internet is the future and will require sweeping changes for better compatibility

.museum

(Museum Domain Management Association)

Restricted TLD devoted to serving the international museum community through museum related sites

Strengths are sponsor’s international presence in community, financial resources, authenticity, operators registry experience. Weak demand and financial projections. Strong proposal.

3: high level of Internet-related expertise of CORE, proposed registry operator; respond to all elements of application.

3: Restricted TLD; small membership determined by long-standing, international body; non-profit sponsor; use of TLD to promote education; two-tiered naming convention

2: Limits registrars; registrars establish retail pricing; no true competition with other TLDs; may provide competition between museums.

3: .mus based on Latin “museum”; used in many languages

2: Legitimacy of source of information from website; small number of registrants but could service international cultural community;

3: Non-profit; public interest; education-oriented; international; small number of registrants, clearly defined, but potential wider audience?

2: Although voting rights for professionals, members of MDMA, no official delegation of policy making to outside body as such. Board makes decisions.

3: robust WhoIs capability; 5-day cooling-off period; strict eligibility criteria; UDRP; no pre-screening; privacy agreement

2: Thorough; strong if small constituency; solid business plan.

TLD Label Applicant

General TLD Description

ICANN Staff Report Review

Summary

Stability Proof of Concept

Competition Utility Complementariness: Filling Unmet

Needs

Diversity Delegation Protection of Rights

Completeness

.name

(Global Name Registry, Limited)

“To provide an easily recognized global personal addressing system that is reserved for the community of individual users.”

Strengths are very good marketing plan and financial backing. Stronger than other applications in its category.

3: backed by IBM, careful planning in response to potential problems; orderly assignment of DNs

3:Reducing charge scale; registration only at 3rd level; viability of personal name-based TLD; round robin distribution

2: Uses all registrars, but controls the prices; no true competition with other TLDs providing same service.

3: highly associated purpose with name; dist. individual users from corporate entities

3: a/c to mkt research, large numbers; no similar space reserved for individual users

3: new market, restricted use, creation of non-commercial space, personal domain

2: low level of affected pop. participation; does give registry operator full flexibility based on ICANN model

3: Whois w/ limited queries. Highly specific. Choice of law explicit (Eng)

2: The sponsors guarantee seriousness of endeavor, but don’t deal explicitly with multiple John Smith problems.

.nom

(CORE)

Restricted TLD devoted to personal use by individuals.

Strength is experience in the market. Weakness is delegation of marketing responsibility to registrars. Overall stronger than others in category.

3: high level of technical background; respond to all elements of application.

3: Restricted TLD without prescreening; two dot policy; registrar flexibility; not intended for but allowing commercial use; modified UDRP; centrally-managed application queues.

1: Registrar flexibility leads to competition in price and service; cost-recovery model could lead to price competition.

2: name suggests use; potential confusion with .com

3: No current personal gTLD, so no similar space reserved for individual users

3: new market; restricted use; personal domain;

2: advisory counsel; Working Group for policy formulation; public comments on web

3: Modified UDRP; user contract for accuracy; no pre-screening; complaint driven; non-transfer policy; limited WhoIs; sunrise period; queue-building process (E12)

2: Build on existing success of other TLDs; considered potential pitfalls of personal TLD, but don’t deal explicitly with multiple John Smith problems; discussion of commercial use unclear (see E3)

.nom

(DotNOM Consortium)

For communities amateurs, professionals, and hobbyists,

Strengths are market analysis and requests for capitalization. Weakness is only in comparison to others in category which were more thorough on marketing and business plan.

2: respond to all elements; wide Internet and technology experience; registry for dotTV; failure provisions not as robust

1:mix of personal and limited commercial registrants; viability of personal name-based TLD; no demand dampening mechanism; unrestricted personal space;

1: accredited and non-accredited registrars; open pricing for DNs;

2: name suggests use; broad multi-lingual appeal; potential confusion with .com

3: No current personal gTLD, so no similar space reserved for individual users

3: new market; unrestricted personal domain; international;

1: no explicit delegation; encourages ICANN to establish “best of class” procedures

1: first-come, first-serve; UDRP; no sunrise; complaint driven; Whois with limited queries

2: Thorough Operator’s Proposal; dotTV already runs TLD; appears that certain key issues have not been fully thought through

.one

(Group One Registry, WebVision, Inc.)

TLD reserved for names made up of digits for Internet-connected devices other than computers

Strengths are large potential market. Weaknesses are market acceptance, lack of registrar experience. Stronger than others in category.

3:long-term Internet-related experience; robust registry failure provisions; respond to all elements

3: value of numeric names; phased registration process; ability of TLD to enhance technology; separation of marketing and tech

2: registrar-level competition; may aid competition among Internet services providers and devices

1: while distinct, .one does not necessarily suggest a numbers-only TLD; is not applicable across languages.

2: growing market of Internet-connected devices other than computers; unclear if this constituency is aided by a TLD; more efficient, but harder to remember.

2: Numeric only TLD; new model for efficiency of TLD

1: No explicit delegation, although plan to look to ICANN for policy; Registry Policy Board

3: Consulted with WIPO; as SLDs are numbers, IP protection less crucial; UDRP; Whois

2: Unclear if numeric-based DNs will be palatable for consumers; possible that they have hit on growing market niche, though. Strong proposal otherwise.

.per

(JVTeam)

personal non-commercial TLD

Strengths are very thorough marketing and business plans. This is one of the stronger applications in its category.

3: Multiple global centers, firewalls, 24/7 security. Respond to all elements of application; extensive Internet-related experience

2: noncommercial personal TLD; generic; round robin startup method; information gathering to aid in measuring; feasibility of ICANN consultations

3: expanded registrar base through enhanced registry service; potential competition with existing email providers

3: name suggests use across a variety of languages; not easily confused with existing TLDs or other meanings

3: No current personal gTLD, so no similar space reserved for individual users; creating new standard for transactions between the registry and registrars; deal with problem of multiple John Smiths

3: personal domain; international; intended solely for individuals, but not exclusive

2: Have parent companies with a strong history in policy development

3: Modified UDRP; monitoring through IP Notification Service; Whois; privacy provisions; individual certification of name

2: Good proposal; but common name problem not well resolved (first come first served)

.pid

(DADA Spa)

Permanent ID domain

Strengths are innovative approach and resources. Weaknesses are implementation strategy and demand assessment. Stronger than others in category.

1: Duplicate hardware; physical security not discussed; Sponsor is ICANN accredited in Italy as .com, .org and .net registrar

2: DNS as a resource (person) locator

3: Unlimited registrars, compete by service

2: TLD name not intuitive, may be confusing.

3: No current personal global TLD

2: No current universal way to keep permanent ID ; submitted by DADA Spa, an Italian organization

1: no sponsoring organization and no mention of how to handle delegation of policy decisions.

1: UDRP; 1 registration per applicant; verification procedure not stated; Whois with option of locking records given to registrants

2: Good proposal; but common name problem not well resolved (use nicknames)

TLD Label Applicant

General TLD Description

ICANN Staff Report Review

Summary

Stability Proof of Concept

Competition Utility Complementariness: Filling Unmet

Needs

Diversity Delegation Protection of Rights

Completeness

.post

(Universal Postal Union)

Restricted monitored TLD for organizational and personal addresses

Strengths are sponsor relation to target market and operators experience. Weakness is demand analysis. This is a weaker application.

3: large registrar history, 800,000 domain names

3: Use of DNS for secured, verified postal service

2: CORE (proposed registry) itself is association of competing companies

3: Obvious name; similar in many languages; trust-engendering

3: No current verified general purpose TLD

3: Different from current TLDs, but broad appeal

3: Verification by postal authorities; submitted by UN agency: Universal Postal Union

3: Accreditation service; UDRP is last resort; centralized Whois

2: Sponsored by a UN agency, fulfills need for a permanent personal address with specialized “smart” message delivery. Robust veteran registry operator

.pro

(DotPRO Consortium)

special purpose TLD,

Professional sites, subdivided by profession

Strength is understanding of general marketplace. Weakness is general financials. Weaker than other apps.

3: redundancy, firewalls; core registry functions spanning two continents

2: Easier Second Level Domain Name roll-out

0: Not mentioned 2: Name suggests use in many languages; but may confuse with a “pro” stance towards an issue

1: Professional sites, but not verified

2: Slightly different purpose from existing TLDs, but may evolve into .com alternative

1: No delegation because no verification

2: auction for disputed names, then UDRP; central Whois database

3: Very thorough proposal; good backing; without credential verification, limited usefulness

.pro

(RegistryPro)

Special purpose TLD,

restricted to licensed professionals, subdivided by profession

Strength is partner’s experience, well conceived. Weakness is potential lack of demand and initial losses. Overall stronger than others.

3: highly redundant services with core registry functions spanning two continents

3: restricted TLD survival; alternative to directory; minimize confusion

3: All ICANN accredited registrars

2: Name suggests use in many languages; but may confuse with a “pro” stance towards an issue

3: “Verified” professionals

3: “Verified” professionals

1:Allow, but not require, verification by professional organizations

2: Sunrise period, then UDRP; shared registry, centralized Whois database

3: Very thorough proposal; good backing; application states it wants trustworthy sites, but not willing to require verification

.tel

(Pulver, Peek, and Marschel)

Special purpose TLD, map existing phone numbers

Strength is thorough business plan. Weakness is state of market of Internet telephony. Overall this is a stronger application in this category.

3: multi-site hardware redundancy; firewalls

3: Converge PSTN and internet addressing; lower barriers of entry for registrars

3: Modified ICANN accreditation; compete with e164.arpa

3: Name suggests use in most languages

3: For internet telephony

2: No current similar special purpose TLD; ENUM compliant

3: international non-profit Internet-Telephony Addressing Board defines policies “guaranteeing open and free competition for the provisioning of ENUM services on a global basis”; Whois provided by NetNumber

3: Only “day-to-day” phone number owner can register, so no start-up rush expected; UDRP last resort

3: Thorough proposal; backed by large groups

.tel

(Number.tel, LLC)

Special purpose TLD, map existing phone numbers

Strength is Tucows’ experience. Weakness is lack of marketing and promotional strategy. Other applications are stronger from a business perspective.

2: hardware redundancy spanning US, Japan, Europe

3: Usefulness of number based system; eliminate domain name selling; administration via 3 part system: a non-profit Oversight Board for overseeing the sale and use of TLD in cooperation with ICANN

3: ICANN accredited registrars; perhaps telephone companies and financial institutions

1: increase in international usage of the web and promote the use of foreign websites by persons throughout the world; name suggests use in most languages

0: Not stated 0: Not stated N/A: only verification by phone companies

3: only individuals, businesses or organizations to which a telephone number is already assigned by a national telephone system can register it; no sunrise period; Whois in compliance with current ICANN-NCI Registry Agreement

1: Incomplete; tripartite governance intriguing, but overall mission not clearly stated

TLD Label Applicant

General TLD Description

ICANN Staff Report Review

Summary

Stability Proof of Concept

Competition Utility Complementariness: Filling Unmet

Needs

Diversity Delegation Protection of Rights

Completeness

.tel

(TelNIC,

CentralNIC)

Generic, top-level domain dedicated to communications-over-the-Internet, including video, voice and data communications.

Strengths are financing, potential market, and experience. Lack of market analysis and support for demand assumptions. Weaker application within category.

3: Respond to all elements of application; hardware redundancy spread throughout 6 continents; firewalls; experience running ISP

2:; value of innovative use of a TLD; ability of TLD to enhance a technology; 2-phase rollout; Q; does .tel reflect purpose of adding TLDs?

1: ICANN-accredited registrars, plus some unspecified criteria; unclear if .tel would provide any competition with existing TLDs; may compete with email providers.

2: .tel is semantically associated with communication, if not exactly name-based internet telephony; name suggests use in mostlanguages; is not confusingly similar to any other TLD.

3: Expand the development and use of video and voice internet telephony services; unclear whether there is great need for such a TLD,o or whether TLD is best way to enhance technology.

3: different conception of how to use TLDs; ; geographic; variation on personal domain;

2: Independent Policy Advisory Board with proposed ICANN involvement, no details determined Telnic will control most policy;

2:UDRP; Whois; 2 month pre-launch period to register trademarks

3: Thorough application; interesting use; may help increase nontraditional use of internet; may be better to wait until the market for non-computer Internet communication increases in prominence and stability.

.travel

(International Air Transport Association)

Special purpose TLD restricted to providers of travel-related products, services and information.

Strengths are focus on specific market and understanding of market. Weakness is lack of unmet need within market. Could lead to a successful TLD.

2: Respond to all elements of application; multiple global centers; firewalls; 24/7 security; experience in .com.au registry operations

2: value of restricted TLDs; connection between accredited membership and integrity of information available; ability of TLD to promote industry; non-profit sponsor;; round robin startup; information gathering to aid in measuring;

3: Expanded registrar base through enhanced registry service; may provide competition to .com for travel sites, although possible will encourage some duplication.

2: Whiile .travel is semantically associated with its purpose in English, not so in other languages; no confusion with existing TLDs.

2: While .travel has the potential of growing the online travel industry and guaranteeing integrity of information, given current success, it is not clear that there is great need for a travel-specific TLD. Special purpose TLD for travel related businesses and information; intuitive name for English speakers

3: Restricted based on industry; narrow scope; commercial and information provifers;geographic diversity; not-for-profit TLD

3: Ceation of advisory committee; IATA-Registrars Forum; IATA will manage .travel, establish membership criteria

3: UDRP + 8 tiers of monitoring and DR; monitoring through Notification Service; accreditation; Whois; privacy provisions;

3: Extremely thorough application; sponsored by long-standing international organization; large, well-established and -researched market; provides for both commercial use and informational public service; robust registry operator.

.union

(International Confederation of Free Trade Unions)

Restricted TLD reserved for the use of bona fide trade union organizations sponsored by ICFTU, a UN-related trade organization.

Strengths are market assessment, business processes and critical objectives. Weaknesses are employee sharing between registry operator traditional services and new services. Overall, this could lead to a successful TLD.

2: Respond to all elements of application; physical security not discussed

Firewalls, 3rd party monthly sweeps; no single point of failure; off-site redundancy;

3: Non-profit registrar; value of limited membership TLD; ability of low cost of DN to help bridge digital divide; flat pricing scheme

2: 1 registrar during startup period, then open registration to any registrar; niche marketing; unlikely to compete with .com or other proposed TLDs.

2: .union highly associated with workers in English; not so in other languages, but indication by applicant of desire to map to other languages; no likely confusion with other TLDs.

2: Restricted but large (123 million workers) market; unclear what exactly a TLD for workers will accomplish;

2: geographic diversity: sponsored by international non-profit ICFTU based in Belgium; restricted TLD; clearly-defined constituency;

2: ICFTU will make policy decisions specifically regarding membership; Initial core group during startup, then open;

2: 3 phases of registration;; user contract for accuracy; no pre-screening; UDRP, ICANN privacy agreement modified in undetermined ways; Whois;

: Thorough proposal serving a clearly-defined constituency; concern that too few TLDs will be given out to justify .union as among the first new TLDs; interesting opportunities borne of TLD devoted to sector that uses the Internet less than average.

.web

(Image Online Design)

.Web offers an unrestricted TLD intended to compete directly with.com, .net and .org

Strengths are general understanding of the market. Weaknesses are unrealistic projections, business plan, and technical support. Overall a weaker application in its category.

2: Claim to have been operating .web registry for four years outside DNS root. Adequate financial and technical capabilities and plan.

2: whether unrestricted TLD can compete with .com; no pricing mechanism to control registration; controlled DN registration prices.

1: May offer competition to.com;; single registrar during start-up, then ICANN-accredited registrars can compete; controlled pricing structure

2: While the name .web is connected to the web, it does not help users guess what type of sites they will find there. Could be confused with a TLD devoted to web-related activity.

2: replenishes set of available domain names; concern, however, that broad nature of TLD will dilute its efficacy

1: commercial; mirrors set-up of .com; US based; unrestricted

N/A: Unrestricted, unsponsored TLD, so no policy delegation not required; do not offer any policy delegation model.

3: UDRP; trademark holders get blackout period with pre-emptive challenge rights; free exchange of DNs in cases of potential infringement; Whois; no pre-screening.

2: Thorough proposal; concern about their historical position as a non-NIS root system; usefulness of creating a TLD even more inclusive than .com

At its meeting on 16 July, in Yokohama, the ICANN Board of Directors approved the following resolutions on new top-level domains(TLDs):

New Top-Level Domains

Whereas, the Domain Name Supporting Organization (DNSO) has conducted a consensus-development process on the introduction of new TLDs and the issues concerning the protection of famous trademarks in the context of introduction of new TLDs;

Whereas, the Names Council of the DNSO made a set of recommendations to the Board on 18/19 April 2000, including the recommendation that the Board establish a policy for the introduction of new gTLDs in a measured and responsible manner;

Whereas, the Names Council of the DNSO made a second set of recommendations to the Board on 19 May 2000, which concerned Famous Trademarks and the Operation of the DNS;

Whereas, the ICANN staff has posted a document entitled "ICANN Yokohama Meeting Topic: Introduction of New Top-Level Domains" on 13 June 2000 and sought public comment on the web site concerning the Names Council recommendations and related issues;

Whereas, over 1,300 comments were received on the ICANN web site in response to the staff posting;

Whereas, on 15 July 2000 a public forum was held in Yokohama concerning the issues discussed in the staff paper;

Whereas, the Names Council recommendations were transmitted to the Protocol Supporting Organization and the Address Supporting Organization for their comment regarding the implications on activities within their scopes of primary

Resolutions of the ICANN Board on New TLDs

16 July 2000

responsibility;

Whereas, no negative comment was received from either Supporting Organization;

Resolved [00.46], that the Board hereby adopts the Names Council's recommendation that a policy be established for the introduction of new TLDs in a measured and responsible manner.

Resolved [00.47], that the President is authorized to implement this policy according to the following schedule, which the President may adjust if necessary to accommodate circumstances that arise:

1 August 2000 - ICANN to issue a formal call for proposals by those seeking to sponsor or operate one or more new TLDs, accompanied by a New TLD Registry Application Form, instructions for filling out the application, and a statement of criteria for the Board's eventual decision.

1 October 2000 - Deadline for ICANN's receipt of applications. Portions of these applications deemed appropriate for publication for purposes of public comment or otherwise will be posted on ICANN's web site.

15 October 2000 - Close of period for public comments on proposals.

20 November 2000 - After approval by the Board, ICANN to announce selections for negotiations toward entry of agreements with registry sponsors and operators.

31 December 2000 - Target date for completion of negotiations.

Resolved [00.48], the President is authorized to establish a non-refundable fee of USD $50,000 for the submission of an application to become a sponsor or operator of a registry, which the Board finds is a reasonable estimate of ICANN's costs likely to be associated with receipt and evaluation of such applications, and follow-up.

Resolved [00.49], in connection with applications, the President should seek information that he determines is appropriate. Without limiting the information that may be sought, the Board commends to the President's consideration the data elements described in section IV of the staff paper, and also notes that the data elements should include:

full information about the technical, business, management, and financial capabilities of the proposed operator of the registry;

a detailed description of the policies contemplated to promote orderly registration of names in the initial phases

of introduction of the TLD;

full details concerning arrangements proposed to protect users in the event of registry failure; and

measures proposed for minimizing use of the TLD to carry out infringements or other abuses of intellectual property rights.

Resolved [00.50], that the President is authorized to establish guidelines for assessing which proposals to select for negotiations toward entry of agreements with registry sponsors and operators. The Board commends the following topics to the President for inclusion in the guidelines:

The need to maintain the Internet's stability, and especially the protection of domain-name holders from the effects of registry or registration-system failure.

The extent to which selection of the proposal would lead to an effective "proof of concept" concerning the introduction of top-level domains in the future, including the diversity the proposal would bring to the program, such as fully open top level domains, restricted and chartered domains with limited scope, noncommercial domains, and personal domains; and a variety of business models and geographic locations.

The enhancement of competition for registration services at the registry and registrar level.

The enhancement of the utility of the DNS.

The evaluation of delegation of policy-formulation functions for special-purpose TLDs to appropriate organizations.

The extent to which the proposal would meet previously unmet types of needs.

The importance of appropriate protections of rights of others, including intellectual property rights, in connection with the operation of the TLD, especially during the start-up phases.

Resolved [00.51], that the President is authorized to seek technical advice from appropriate individuals or organizations to assist the evaluation of proposals.

Comments concerning the layout, construction and functionality of this site should be sent to webmaster@icann.org.

Page Updated 6-August-00. (c) 2000 The Internet Corporation for Assigned Names and Numbers All rights reserved.

New TLD Application Process Overview

On 16 July 2000, ICANN's Board of Directors adopted a policy for introduction of new Internet top-level domains (TLDs) in a measured and responsible manner. The adopted policy calls for submission of proposals to sponsor or operate new TLDs by interested persons and organizations. After public comment, these proposals will be evaluated and a limited number of proposals will be selected for negotiations toward agreements between ICANN and the TLD sponsors and operators. The goal is to complete negotiations for appropriate agreements by 31 December 2000.

The following is an ICANN-staff-prepared overview of the upcoming application process. Complete, detailed instructions and an application form will be available soon (see the schedule below). This overview is provided to assist those considering applying to sponsor or operate a new TLD. It contains:

1. Requirements for Proposals

a. General Information b. Definition of Terms: Sponsored and Unsponsored TLDs c. Elements of Written Applications d. The Sponsoring Organization's Proposal e. The Registry Operator's Proposal f. New TLD Policy Proposal

2. Application Fee

3. Multiple Applications

New TLD Application Process Overview

Posted: 3 August 2000

4. Schedule

5. Obtaining Additional Information

1. Requirements for Proposals

a. In General. To apply to sponsor or operate a TLD, one must submit a detailed, multi-part proposal accompanied by extensive supporting documentation. The effort and cost of preparing a sufficient proposal should not be underestimated. The proposal must be based on a thoroughly formulated plan for the establishment and viable long-term operation of the TLD. The application should clearly and effectively describe the plan, show that the necessary resources have been arranged (or that firm commitments have been obtained) to implement the plan, and demonstrate that the proposal would be superior to others in promoting the goals of the new-TLD policy.

In formulating proposals, applicants may wish to consider carefully the guidelines that will be followed in selecting from among the proposals received. At its Yokohama meeting in July 2000, the ICANN Board gave a general statement of several topics to be included in the guidelines. Under the Board's resolutions, detailed guidelines are scheduled to be posted on 15 August.

Successful proposals will effectively address complex technical, financial, business, and legal problems presented by operation of a TLD. Those who are planning to apply are strongly urged to secure now the professional assistance of technical experts, financial and management consultants, and lawyers to assist in formulation of their proposals and preparation of their applications.

b. Sponsored and Unsponsored TLDs.

Applications for two different types of TLDs may be made:

Sponsored TLDs (i.e. TLDs having sponsoring organizations), and

Unsponsored TLDs.

The written applications for these two types of TLDs have different required elements, as listed below. To determine whether to propose a sponsored or an unsponsored TLD, the following terms should be understood:

Sponsoring Organization An organization to which ICANN delegates some defined level of ongoing policy-formulation responsibility regarding the manner in which a particular TLD is operated, provided the policies are within the scope of the TLD's charter and comply with requirements concerning

interoperability, availability of registration data, and the like intended to ensure that the interests of the overall Internet are served. In TLDs which have a sponsoring organization, that organization is primarily responsible for choosing the registry operator (see below).

The extent to which certain policy-formulation responsibilities are appropriately delegated to a sponsoring organization will depend upon the characteristics of the organization that may make such delegation appropriate. These characteristics may include the mechanisms the organization proposes to use to formulate policies, its mission, who will be permitted to participate and in what way, and the degree and type of accountability to the community it will serve (to the extent these are necessary and appropriate). The Sponsoring Organization's Proposal provides an opportunity to provide information on these characteristics.

Registry Operator The entity that is responsible for the actual operation of the registry for the TLD, including accepting registration requests (whether from registrars or directly from registrants), maintaining a database of the necessary registration data, generating zone files, and providing nameservers to publish the zone file data throughout the Internet. Although some portions of these services may be subcontracted, the registry operator is responsible for ensuring that the services are reliably provided. Where a TLD is sponsored, the sponsoring organization is primarily responsible for selecting the registry operator; otherwise ICANN selects the registry operator.

A single organization can be both a sponsoring organization and a registry operator for a TLD, provided it has the features described here that make it suitable for both roles. If a registry operator does not have features appropriate for a sponsoring organization, then the sponsoring organization must be independent of the registry operator.

Unrestricted TLD A TLD with no enforced restrictions on who may apply for a registration within the domain or on what uses may be made of those registrations. Examples of unrestricted TLDs include .com, .net, and .org. (Note that RFC 1591 states that these domains are intended for various uses. As a practical matter, however, anyone may register and use names in these domains for any purpose.) A TLD having a structure with second-level domains below which registrations are offered for registration is considered an unrestricted TLD only if all of the domains in which registrations are offered are themselves unrestricted. Unrestricted TLDs can operate either without a sponsoring organization (i.e. policies to be established and modified only through the ICANN process) or with a sponsoring organization (in which case policy-making responsibility is allocated between ICANN and the sponsoring organization).

Restricted TLD A TLD with enforced restrictions on (1) who may apply for a registration within the domain, (2)

c. Elements of Written Applications.

i. Sponsored TLDs: To apply for a sponsored TLD, there are three major parts of the written application that must be submitted:

Sponsoring Organization's Proposal (prepared by proposed sponsoring organization) Registry Operator's Proposal (prepared by proposed registry operator) Description of Proposed TLD Policies (prepared by proposed sponsoring organization)

All three parts are required for a complete application for a sponsored TLD and should be submitted by the proposed sponsoring organization. (Where the proposed sponsoring organization has not yet been formed, the submission may be made by the organizers of that organization.) A summary description of the contents of each of these three parts is given in sections 1(d), 1(e), and 1(f) below.

ii. Unsponsored TLDs: To apply for an unsponsored TLD, there are two major parts of the written application that must be submitted

Registry Operator's Proposal Description of Proposed TLD Policies

Both parts are required for a complete application for an unsponsored TLD and should be prepared and submitted by the proposed registry operator . A summary description of the contents of each of these two parts is given in sections 1(e) and 1(f) below.

what uses may be made of those registrations, or (3) both. Examples of restricted TLDs include .edu (open only to certain four-year degree-granting colleges and universities), .gov (for registration of US governmental entities on the federal level only), and .arpa (for Internet infrastructure applications). Because restricted TLDs require definition and implementation of policies concerning naming restrictions, which are most appropriately addressed by subsets of the global Internet community, proposals for restricted TLDs should ordinarily provide for a sponsoring organization.

d. Sponsoring Organization's Proposal.

As will be described in greater detail in the application instructions scheduled to be released on 15 August, the Sponsoring Organization's Proposal will have three basic sections: organization/structure; proposed extent of delegation of policy-formulation authority; and contract terms with registry operator.

i. Organization/Structure: This section is intended to demonstrate that the proposed organization has characteristics that make it appropriate to delegate policy-formulation authority to it. Responses should include the organization's organizational documents (such as articles of incorporation and bylaws), membership, and its present (or proposed initial) directors and officers. These materials should describe the stakeholders the organization is intended to represent and should demonstrate that the organization is well-designed and situated to formulate policy for the TLD in an open and transparent manner that represents those stakeholders. If the sponsoring organization and the registry operator are not the same, measures to ensure legal and financial independence from the registry operator should be described.

ii. Proposed Extent of Delegation of Policy-Formulation Authority: This section should describe the areas over which a delegation of policy-formulation authority is sought. In general, matters involving the interests of the entire Internet community are poor candidates for delegation, while matters of special importance to the segment of the Internet community represented by the sponsoring organization are good candidates for delegation. For restricted TLDs, sponsoring organizations must take responsibility for monitoring and enforcing naming restrictions.

iii. Contract Terms with Registry Operator: Each sponsoring organization is responsible for choosing and securing an initial registry operator. This section should describe the terms under which the registry operator has made a firm commitment to operate the registry for the new TLD. It should clearly delineate the registry operator's performance obligations, and provisions for handling change, non-performance, and termination. Registry operator's capabilities should be addressed in the Registry Operator's Proposal.

e. Registry Operator's Proposal.

The Registry Operator's Proposal is intended to fully describe the identity, capabilities, and plan of the proposed registry operator. The applications scheduled for release on 15 August will set forth detailed requirements for the format of the proposal and the topics it covers. The following overview should assist in beginning formulation of the proposal.

In the case of an unsponsored TLD application, the Registry Operator's Proposal will be prepared and submitted by the proposed registry operator. In the case of a sponsored TLD application, the proposed sponsoring organization must identify a registry operator, obtain that registry operator's firm commitment (such as by a letter of intent) to specific terms under which registry services would be provided, and have that registry operator prepare the Registry Operator's Proposal for inclusion with the sponsored TLD application.

The registry operator is responsible for provisions of all aspects of registry services, including accepting registration requests (whether from registrars or directly from registrants), maintaining a database of the necessary registration data, generating zone files, and providing nameservers to publish the zone file data throughout the Internet. The Registry Operator's Proposal may propose subcontracting services to other vendors; in this case the proposal must be accompanied by firm commitments by the proposed subcontractors, as well as detailed descriptions of their capabilities.

The Registry Operator's Proposal primarily consists of two sections: a Business Capabilities and Plan section and a Technical Capabilities and Plan section.

i. Business Capabilities and Plan: The Business Capabilities and Plan section of the Registry Operator's Proposal must include a comprehensive, professional-quality business plan. This business plan will require detailed, verified business and financial information about the proposed registry. The topics listed below are representative of the type of subjects that will be covered in the Business Capabilities and Plan section of the application. To those who are planning to apply, we strongly recommend securing professional assistance from financial and management consultants to aid in the formulation of your business plan, in securing the necessary sources of financing, and in preparation of the Business Capabilities and Plan section of the Registry Operator's Proposal.

As is customary in formal business and financial plans for significant projects, the following topics should be addressed fully: company information, current and past business operations, registry/Internet related experience and activities, mission, target market, expected costs/expected budget, expected demand, capitalization, insurance, revenue model, marketing plan, use of registrars and other marketing channels, management and employees, staff size/expansion capability, long-term commitment/registry failure provisions. Required supporting documentation will include: documents of incorporation (or similar documents), company references, annual report (or similar document), proof of capital and/or proof of firm commitment of capital, proof of insurance, personnel resumes and references.

ii. Technical Capabilities and Plan: The Technical Capabilities and Plan section must include a comprehensive, professional-quality technical plan for establishment and operation of all aspects of the registry. The technical plan will require detailed, specific information regarding the technical capabilities of the proposed registry. It should be developed with reference to the standard technical capabilities of major providers of Internet services. The topics listed below are representative of the type of subjects that will be covered in the Technical Capabilities and Plan section of the Registry Operator's Proposal. We strongly recommend that those who are planning to apply secure professional assistance from engineers and/or other technical consultants to aid in the formulation of the technical plan and the preparation of the Technical Capabilities and Plan section of the Registry Operator's Proposal.

At least the following topics should be addressed fully: physical plants, hardware, software, facility and data security, bandwidth/Internet connectivity, system outage prevention, system restoration capabilities and procedures, information

systems security, load capacity, scalability, data escrow and backup capabilities and procedures, Whois service, zone file editing procedures, technical and other support, billing and collection, management and employees, staff size/expansion capability, and provisions for preserving stability in the event of registry failure. Required supporting documentation will include: company references, diagrams of systems (including security) at each location, personnel resumes and references.

f. Description of Proposed TLD Policies.

As will be described in more detail in the application instructions scheduled to be released on 15 August, this part of the application will cover the basic policies for all new TLDs. For unsponsored TLDs, ICANN will have policy-formulation responsibility for the new TLD and the policies will initially be generally defined as the existing policies for .com, .net, and .org as described in the ICANN/NSI/DOC agreements of November 4, 1999 and amendments. Registry operators for unsponsored TLDs may use this part of the application to propose variations on or additions to those policies, which may be negotiated with ICANN. For sponsored TLDs, the sponsoring organization may use this section to propose policies for those areas in which it seeks to have policy-formulation responsibility, though the policies need not differ from existing ICANN policies. Sponsoring organizations for restricted TLDs must include proposed naming policy for the new TLD. Both sponsored and unsponsored TLD applicants must address the proposed start-up registration policies and some general questions about the purpose and utility of the proposed TLD.

This part of the application will have three basic sections: variations (if any) in existing policies in .com, .net and .org; registration policies during the start-up phase; and the general purpose and advantages of the proposed TLD. Although this section will not require preparation of a formal plan, it will require a similar level of detail and forethought in preparation. The following topics are representative of the topics that will be covered in this section of the application:

i. Variations in existing TLD policies: This section will provide a description of policies for the TLD (including those relating to protection of intellectual property) that vary from or add to policies followed in .com, .net, and .org; any lower-level structure to be employed in the TLD; for restricted TLDs (which should have sponsoring organizations), this part should also include a detailed description of the TLDs naming policy, including restrictions on registration, enforcement procedures, naming conventions, and dispute resolution mechanisms.

ii. Start-up registration policies: an explanation of the policies contemplated to promote fair and orderly registration of names in the start-up phase.

iii. General purpose and advantages: an analysis of the proposed TLDs community to be served, advantages the TLD would bring to the DNS, uniqueness/service of unmet needs, enhancement of competition for registration services, and utility to the evaluation of the "proof of concept" for new TLDs.

2. The Application Fee

The application fee for each new TLD application is US$ 50,000. This fee must be paid before ICANN will consider the application. It is intended to cover ICANNs costs of receiving and evaluating the application, including performing technical, financial, business, and legal analyses, as well as ICANNs investigation of all circumstances surrounding the applications and follow-up items. The application fee is non-refundable and ICANN's only obligation upon accepting the application and fee is to consider the application.

Each application (whether for a sponsored or an unsponsored TLD) requires payment of a US$ 50,000 fee.

It is anticipated that only a few of the applications that are received will be selected for further negotiations toward suitable contracts with ICANN. Those submitting applications that are not selected for negotiations, or that are selected but do not result in successful negotiation of mutually satisfactory agreements, will not be refunded their application fee, nor will ICANN reimburse their (probably larger) cost of preparing the application.

3. Application for Multiple TLDs

A single application may propose multiple TLD strings, but all parts of the proposal (including the Business Capabilities and Plan and Description of TLD Policies) must apply to all of the strings without significant variation. If the TLD strings requested in a single application are supported by proposals with significant variations, the applicant may be required to elect which of the variations to pursue in the application.

There is no limit on the number of applications an organization may submit, but each application must be complete on its own and must be accompanied by the non-refundable US$ 50,000 application fee.

Those seeking to sponsor multiple TLDs should consider the effect of the goals of the New TLD Policy, as adopted by the Board, of (a) providing diversity of proposals that will lead to an effective "proof of concept", and (b) enhancing competition for registration services at the registry level.

4. The Schedule

3 August 2000 This description of the New TLD Application Process becomes available.

15 August 2000 Detailed New TLD Registry Application Form, instructions for filling out the application, and a statement of criteria for the Board's eventual decision to be posted.

5 September 2000 First day on which ICANN will accept applications. Amendments to applications will be accepted until the 2 October 2000 deadline.

5. Obtaining Additional Information

As noted above, a detailed New TLD Registry Application Form, instructions for filling out the application, and a statement of criteria forthe Board's eventual decision are scheduled to be posted on 15 August 2000.

After that posting, questions regarding the new TLD application process may be sent to tld-applications@icann.org. To help provide all applicants with equitable access to information about the process as they prepare their applications, until the application deadline on 2 October 2000 all requests to ICANN for information about the process or issues arising in preparation of an application must be submitted in written form (preferably by e-mail). During the application period, requests for personal or telephone consultations regarding these matters will not be granted.

Ordinarily, any substantive responses to written questions submitted during this period will be posted on the ICANN web site. Those sending questions should take this into account in framing their questions.

Comments concerning the layout, construction and functionality of this site should be sent to webmaster@icann.org.

Page Updated 12-August-00 (c) 2000 The Internet Corporation for Assigned Names and Numbers. All rights reserved.

2 October 2000 Deadline for ICANN's receipt of completed applications (including all supporting materials and application fees).

5 October 2000 Portions of these applications deemed appropriate for publication for purposes of public comment or otherwise will be posted on ICANN's web site.

19 October 2000 Close of period for public comments on proposals.

mid-November 2000 (during or shortly after ICANN annual meeting)

After approval by the Board, ICANN to announce selections for negotiations toward entry of agreements with registry sponsors and operators.

31 December 2000 Target date for completion of negotiations.

Criteria for Assessing TLD Proposals ICANN expects to receive many applications to sponsor or operate new top-level domains (TLDs). In this year's application program, it is likely that only a few of these will be selected by the ICANN Board for negotiations toward registry sponsor and operator agreements. To the extent possible, as this process continues ICANN will provide additional guidance on the likely number of TLDs to be included.

The ICANN staff is responsible for gathering information about submitted applications, evaluating the applications and associated information, and making recommendations to the Board based on the applications, associated information, and evaluations. In its evaluations, the ICANN staff currently intends to consider at least the factors described below. Applicants are invited to be creative and to explain the value of their proposals in the context of these and any other relevant factors.

1. The need to maintain the Internet's stability.

ICANN's first priority is to preserve the stability of the Internet, including the domain-name system (DNS). Proposals should demonstrate specific and well-thought-out plans, backed by ample, firmly committed resources, to operate in a manner that preserves the Internet's continuing stability. The introduction of the proposed TLD should not disrupt current operations, nor should it create alternate root systems, which threaten the existence of a globally unique public name space. Security and reliability of the DNS are important aspects of stability, and proposals should set forth comprehensive strategies to assure both.

ICANN will undertake a wide-ranging assessment of a proposal's treatment of stability issues. Among the significant aspects of stability ICANN will review are:

a. The prospects for the continued and unimpaired operation of the TLD in the manner proposed by the registry operator or sponsor throughout the period for which the delegation is agreed;

b. Provisions to minimize unscheduled outages of registry or registration systems due to technical failures or malicious

Criteria for Assessing TLD Proposals

15 August 2000

activity of others;

c. Provisions to ensure consistent compliance with technical requirements in operation of the TLD;

d. Effects of the new TLD on the operation and performance of the DNS in general and the root-server system in particular;

e. Measures to promote rapid correction of any technical difficulties that occur (whether or not due to the TLD's operation), such as availability of accurate, consistent, and helpful Whois information;

f. The protection of domain-name holders from the effects of registry or registration-system failure, such as procedures for rapid restoration of services from escrowed data in the event of a system outage or failure; and

g. Provisions for orderly and reliable assignment of domain names during the initial period of the TLD's operation.

2. The extent to which selection of the proposal would lead to an effective "proof of concept" concerning the introduction of top-level domains in the future.

Recent experience in the introduction of new TLDs is limited in some respects. The current program of establishing new TLDs is intended to allow the Internet community to evaluate possible additions and enhancements to the DNS and possible methods of implementing them. Stated differently, the current program is intended to serve as a "proof of concept" for ways in which the DNS might evolve in the longer term.

Proposals should be chosen so as to promote effective evaluation of :

the feasibilty and utility of different types of new TLDs, the effectiveness of different procedures for launching new TLDs, different policies under which the TLDs can be administered in the longer term, different operational models for the registry and registrar functions, different business and economic models under which TLDs can be operated; the market demand for different types of TLDs and DNS services; and different institutional structures for the formulation of registration and operation policies within the TLD.

This factor will be best served by applications that clearly articulate what concept or proposition the proposal would test, how the results of that test should be evaluated, and how the results of the evaluation would assist in the long-range management of the DNS.

3. The enhancement of competition for registration services.

As noted in the White Paper, market mechanisms that support competition and consumer choice should, where possible, drive the management of the DNS. One of ICANN's core principles is the encouragement of competition at both the registry and registrar levels. Though the market will be the ultimate arbiter of competitive merit, the limited number of new TLDs to be introduced at this time makes it appropriate to make a preliminary evaluation of competitive merit for the "proof of concept."

A proposal's contributions to enhancement of competition can take various forms, depending on the specifics of the proposal. Depending on the characteristics of the TLD proposed, the nature and degree of competition involved may vary. Proposals will be evaluated to determine whether they are responsive to the general goal of enhancing competition for registration services.

Some examples of competitive issues that may be considered in evaluating proposals are:

a. What prospects do the proposed TLD and registry have for effectively competing with other TLDs and registries (either pre-existing or introduced at the same time)? Are the proposed pricing and service levels likely to be competitive with other TLDs and operators having significant market shares? If effective marketing is necessary to make the TLD competitive, does the proposal adequately provide for that marketing? If the proposal is for an unrestricted TLD, are any features proposed to maximize the prospect that the TLD will be attractive to consumers as an alternative to .com?

b. Is the proposal particularly attractive to a significant sub-market in which it can compete effectively? Are distinctive services being proposed that will meet the needs of those not being served adequately by existing services?

c. Is there any significant competitive concern that the proposed TLD is likely to lead to lock-in of domain-name holders, so that inter-TLD competition is constrained? To the extent there is a concern about constrained competition, what measures are proposed or available to ensure competitive operation of the TLD (periodic rebidding of registry, etc.)?

d. What effect would the proposal have on registrar-level competition? Does the proposal restrict the ability of accredited registrars to offer registration services within the TLD on competitive terms? What mechanism is proposed for selecting registrars?

e. If accredited registrars are not permitted to offer registration services within the TLD on a competitive basis, are there other, effective mechanisms for providing competitive choices to domain-name holders seeking to register within the TLD?

f. Would the proposal advance competitive frontiers by introducing an innovative use of the DNS?

g. Would restrictions proposed for a restricted TLD impair (either in principle or in implementation) competition among potential registrants?

4. The enhancement of the utility of the DNS.

One motivation often cited for introducing new TLDs is that doing so might increase the utility of the DNS. Under this view, the appropriateness of adding new TLDs should be evaluated based on whether addition of the new TLDs:

would sensibly add to the existing DNS hierarchy and would not create or add to confusion of Internet users in locating the Internet resources they seek.

At least the following considerations will be considered in this regard:

a. If the TLD is intended for a particular use or purpose, does the TLD label suggest that use? Is this true for a large portion of Internet users globally (i.e. in different languages)?

b. Is the proposed TLD semantically "far" from existing TLDs, so that confusion is avoided? (For example, TLD labels suggesting similar meanings might be more easily confused.) Is it phonetically distinct from existing TLDs? Meanings and pronunciations in different languages may be relevant to these inquiries.

c. Does the proposed TLD avoid names reserved by RFCs (or documents that are nearly RFCs), notably ".local" (from the HTTP State Management draft) and those names listed in RFC 2606.

d. In the case of a restricted TLD, is the restriction one that will assist users in remembering or locating domain names within the TLD? (E.g., users might conclude that "ford.car" is associated with the automobile company, not the modeling agency.)

5. The extent to which the proposal would meet previously unmet types of needs.

The DNS should meet a diversity of needs. Close examination will be given to whether submitted proposals exhibit a well-conceived plan, backed by sufficient resources, to meet presently unmet needs of the Internet community.

6. The extent to which the proposal would enhance the diversity of the DNS and of registration services generally.

One goal of introducing new TLDs should be to enhance the diversity of the DNS and the manner in which registration services are provided. In examining submitted proposals, consideration will be given to the diversity the proposal would add to the DNS. Among the diversity of proposals sought, ICANN hopes to receive proposals for fully open top level domains, restricted and chartered domains with limited scope, noncommercial domains, and personal domains. Diversity in business models and of geographic locations are also advantageous. (Note that this criterion must be judged based on the whole group of selected proposals, rather than any single

proposal.)

7. The evaluation of delegation of policy-formulation functions for special-purpose TLDs to appropriate organizations.

As noted in the ICANN-staff-prepared document entitled "ICANN Yokohama Meeting Topic: Introduction of New Top-Level Domains," the DNS is a hierarchical system that facilitates delegation of policy-formulation authority for particular TLDs. In the context of unsponsored TLDs, this can appropriately be accomplished for many operational matters by giving the registry operator flexibility in the registry contract. For restricted TLDs, some have suggested a "sponsorship" model, in which policy-formulation responsibility for the TLD would be delegated to a sponsoring organization that allows participation of the affected segments of the relevant communities. Proposals will be analyzed to determine whether they offer the opportunity for meaningful, real-world evaluation of various structures for appropriate delegation of policy-formulation responsibilities, as well as evaluation of various allocations of policy-formulation responsibilities between ICANN and sponsoring organizations.

8. Appropriate protections of rights of others in connection with the operation of the TLD.

In introducing new TLDs, care should be taken to ensure that the rights of third parties are appropriately protected. Examples of matters to be examined in this regard include:

a. Does the proposal have a well-thought-out plan for allocation of names during the start-up phase of the TLD in a way that protects the legitimate interests of significant stakeholders, including existing domain-name holders, businesses with legally protected names, and others with which conflict is likely?

b. Does the proposal provide for a reasonably accessible and efficient mechanism for resolving domain-name disputes?

c. Has the proponent considered intellectual property interests or otherwise designed protections for third-party interests?

d. Does the proposal make adequate provision for Whois service that strikes an appropriate balance between providing information to the public regarding domain-name registrations in a convenient manner and offering mechanisms to preserve personal privacy?

e. Does the proposal incorporate policies that are likely to discourage abusive registration practices?

9. The completeness of the proposals submitted and the extent to which they demonstrate realistic business, financial, technical, and operational plans and sound analysis of market needs.

The ICANN staff intends to place significant emphasis on the completeness of the proposals and the extent to which they demonstrate

that the applicant has a thorough understanding of what is involved, has carefully thought through all relevant issues, has realistically assessed the business, financial, technical, operational, and marketing requirements for implementing the proposal, has procured firm commitments for all necessary resources, and has formulated sound business and technical plans for executing the proposal. Applicants are strongly encouraged to retain well-qualified professional assistance (e.g., technical, engineering, financial, legal, marketing, and management professionals, as appropriate) in formulating their proposals. Proposals that are presented in a clear, substantive, detailed, and specific manner will be preferred.

Comments concerning the layout, construction and functionality of this site should be sent to webmaster@icann.org.

Page Updated 15-August-00. (c) 2000 The Internet Corporation for Assigned Names and Numbers All rights reserved.

As of 5:00 pm California time on Monday, 2 October 2000, application materials seeking to operate or sponsor the new TLDs listed below were submitted to ICANN. These applications have not yet been verified to be complete or to be in proper form. (There may be missing parts of the application, omitted attachments, no or an inadequate application fee, a transmittal not in the specified form, a lack of required signatures, etc.) Requests for confidential treatment of material submitted have not yet been evaluated according to the procedure outlined in Section I of the Statement of Requested Confidential Treatment of Materials Submitted. Nor has ICANN yet made any determinations, where multiple TLD strings are included in a single application, whether to require the applicant to elect which of the strings to pursue in the application.

The procedure that will be used by ICANN to review these materials is described in the TLD Application Review Procedure.

TLD Applications Lodged

(2 October 2000) (corrected through 10 October 2000)

TLD String(s) (as listed in Item E2 of the Description of TLD Policies)

Applicant(s) (as listed in Item A2 of the Sponsored TLD Application Transmittal Form or Item B1 of the

Unsponsored TLD Application Transmittal Form) .ads .agency .aids .air .antiques .art .artists .auction .audio .bbs .books .cafe

.gallery

.games

.gay

.graphics

.group

.guide

.hotel

.help

.history

.index

.insurance

.jazz

.records

.school

.service

.sex

.shoes

.shop

.show

.security

.society

.sound

.shareware

.site

Name.Space, Incorporated 11 East 4th Street, Second Floor New York, New York 10003 USA +1 212 677 4080 info@name-space.com

.cam

.card

.cars

.center

.city

.channel

.church

.club

.commerce

.computers

.consulting

.culture

.design

.digital

.direct

.dtv

.dvd

.factory

.fashion

.festival

.fiction

.film

.films

.foundation

.free

.fun

.fund

.funds

.jobs

.lab

.mad

.mag

.magic

.mail

.market

.media

.men

.monitor

.movie

.music

.news

.now

.nyc

.one

.online

.opera

.page

.partners

.people

.planet

.politics

.power

.productions

.projects

.properties

.radio

.software

.solutions

.soup

.space

.sports

.star

.studios

.sucks

.systems

.tech

.temple

.theater

.time

.times

.toys

.trade

.travel

.voice

.war

.watch

.weather

.women

.world

.writer

.zine

.zone

.africa

.llc

.sansansan

.sex

.three33

.wap

.xxx other portions of application claimed confidential

Rathbawn Computers Limited 7826 Lone Pine Drive, Golden, Colorado 80402 USA -and- 5 Badham Street Dickson, ACT 2602 Australia Edward Sweeney

+61 2 6257 6758 +61 2 6262 8511 ed@totalnic.com Vincent Hamm +1 303 271-1288 vince@totalnic.com

.air (also mentioned .aer and .aero, though not under item E2)

Société Internationale de Télécommunications Aéronautiques 14, avenue Henri Matisse 1140 Brussels, Belgium +32 2 745 01 05 26, Chemin de Joinville PO Box 31 1216 Geneva, Switzerland +41 22 747 60 00 rosa.delgado@sita.int

.biz JVTeam, LLC 1120 Vermont Avenue., NW Washington, DC 20005 USA Ken Hansen +1 202 533-2600 Ken.hansen@neustar.com

.biz

.cool

.fam

.inc

.xxx

Abacus America, Inc. 5266 Eastgate Mall San Diego, California 92121 USA +1 858 455-7709 project@abac.com

.biz

.ebiz

.firm

.inc

.real

Affinity Internet, Inc. 101 Continental Boulevard, 3rd El Segundo, California 90245 USA +1 310 524-3000 TLDapplication@affinity.com

biz Regulatory and Advisory Council, LLC dba bizTrac

181 Hudson Street, Suite 7c New York, New York 10013 USA

.biz

.ebiz

.ecom

iDomains, Inc. 23 West 4th St. Bethlehem, Pennsylvania 18015 USA Henry A. Lubsen, Jr. +1 610 317-9606 hlubsen@idomains.com

.biz

.homeKDD Internet Solutions Co., Ltd. 1-8-1 Otemachi, Chiyoda-ku, Tokyo 100-8186 Japan Toru Asami +81 3 3347 7004 to-asami@kddi.com

.cash

.global

.secure

Diebold Incorporated Worldwide Headquarters 5995 Mayfair Road North Canton, Ohio 44720 USA +1 330 490-4000 marshm@diebold.com

.co-op

.coopCooperative League of the USA dba National Cooperative Business Association 1401 New York Avenue, NW, Suite 1100 USA Washington, D.C. 20005-2160 Paul Hazen +1 202 383-5444 ncba@ncba.org

.dir Novell, Inc. 1800 South Novell Place Provo, Utah 84606 USA +1 801 861-7000 cledbetter@novell.com

.dot

.info NeuStar, Inc. 1120 Vermont Avenue., NW

.site

.spot

.surf

.web

Washington, DC 20005 USA Ken Hansen +1 202 533-2600 ken.hansen@neustar.com

.dubai

.goDubai Technology, Electronic Commerce and Media Free Zone Authority Lars Olof Kanngard P.O. Box 73000 Dubai, UAE +9714 3998888 icann@dubaiinternetcity.com

.event Internet Events International, Inc. 10901 S. 1000 E Sandy, Utah 84094 USA +1 801 619-7096

.fin Association Monegasque des Banques 7 Rue du Gabian MC 98000 Monaco Etiennne Franzi +377 97 97 84 97 amb@mc-monaco.com

.find

.yp

.ypa

.ypi

Monsoon Assets Limited (BVI) dba dotYP, Inc. 2292 Paradise Drive Tiburon, California 94920 USA +1 415 435-4700 fcorsini@dotyp.com dansokol@dotyp.com

.firm

.game

.inc

.info

.ltd

.news

.shop

.store

Eastern Communications Company Limited No. 80-84, Wensan Road Hangzhou, Zhejiang P.R. China +86 571 8865383 webmaster@eastcom.com

.tour

.geo SRI International 333 Ravenswood Ave. Menlo Park, California 94025 USA +1 650 859-2000 inquiry.line@sri.com

.health World Health Organization 20, Avenue Appia CH-1211 Geneva 27, Switzerland +41 22 791 3111 tld@who.int

.i Sarnoff Corporation 201 Washington Road Princeton, New Jersey 08540 USA +1 609 734-2000 ssuman@sarnoff.com Atomic Tangerine, Inc. 149 New Montgomery Street, 2nd Floor San Francisco, California 94105 USA +1 415 901-4840 lbilodeau@atomictangerine.com NextDNS, Inc. 201 Washington Road Princeton, New Jersey 08540 USA +1 609 734-2371 info@nextdnsinc.com

.info

.site

.web

Afilias, LLC Skadden, Arps, Slate, Meagher & Flom LLP Four Times Square New York, New York 10036 USA Rita A. Rodin +1 212 735-3000 rrodin@skadden.com

.jina

.name

.nom

.san

.xing

The Global Name Registry, Limited 10 Fenchurch Avenue EC3M 5BN, London, UK Hakon Haugnes +44 207 663 5600 hakon.haugnes@theglobalname.org

.kids Blueberry Hill Communications, Inc. 77-670 Springfield Lane, Suite 11B Palm Desert, California 92211 USA Craige G. Campbell +1 760 360-4600 cgc@bluehill.com

.kids DotKids, Inc. 5th Floor, 103 West Broad Street Falls Church, Virginia 21202 USA +1 703 771-3338 acorrent@dotkid.com

.kids

.xxxICM Registry, Inc. Jason Hendeles 2300 Yonge Street, Suite 907 P.O. Box 2326 Toronto, Ontario M4P 1E4 Canada +1 416 485-3888 jason@icmregistry.com

.kids .KIDS Domains, Inc. 2600 West Olive Avenue Suite #100 Burbank, California 91505 USA Page Howe +1 818 729-3835 page@kidstld.com

.law W. McKay Henderson dotlaw, Inc. 947 Swinks Mill Road

McLean, Virginia 22102 USA James D. Fonger, MD +1 703 902-8401 jfonger@thelawdomain.net mhenderson@thelawdomain.net

.mall

.shop

.svc

Commercial Connect, LLC 1418 S. Third Street Louisville, Kentucky 40208-2117 USA Jeffrey S. Smith +1 502 357-6507 jss@cas-com.net

.mas

.max

.mid

.mis

.mobi

.mobile

.now

.own

Nokia Corporation Keilalahdentie 4, P.O. Box 226 FIN-00045 Nokia Group, Finland +358 9 180 71 Mr. Reidar Wasenius reidar.wasenius@nokia.com

.mus

.muse

.musea

.museum

.museums

Museum Domain Management Association Cary Karp Director Department of Information Technology Swedish Museum of Natural History Svante Arrheniusv. 3 Box 50007 104 05 Stockholm, Sweden +46 8 5195 4055 ck@nrm.se Kenneth Hamma Assistant Director, The J. Paul Getty Museum 1200 Getty Center Drive Suit 1000 Los Angeles, California 90049 USA

+1 310 440-7186 khamma@getty.edu

.nom CORE Internet Council of Registrars World Trade Center II 29 route de Pré-Bois CH-1215 Geneva, Switzerland Werner Staub +41 22 929 5744 tldapp@corenic.org

.nom The dotNOM Consortium 130 W. Union Street Pasadena, California 91103 USA +1 626 685-4904 a@www.tv The .TV Corporation International 130 W. Union Street Pasadena, California 91103 USA +1 626 685-4904 a@www.tv Lycos, Inc. 400-2 Totten Pond Road Waltham, Masachusetts 02451 USA +1 781 370-2700 tmurphy@lycos.com SK Telecom 99 Seorin-dong Jangro-gu Seoul, Korea +82 2 2121 2621 XO Communications, Inc. (formerly Concentric Network) 1505 Farm Credit Drive, 6th Floor McLean, Virginia 22102 USA

+1 703 547-2444 nsommerfeld@cncx.com OnlineNIC, Inc. 7F International Trade Building 388 Hubin Road Xiamen, 361004 China +86 592 516 1011 tony@onlinenic.com 7DC 38-40 Sarnlip Building, 3rd Floor Yuksangdong Kangram-gu Seoul 135-711 Korea +82 2 588-1282

.number

.tel

.phone

De Breed Holdin B.V. EC Rider Baronielaan 184 4837 BE Breda, The Netherlands +31 765 654321 debreed@debreed.nl

.nyc WorldNames, Inc. 271 Madison Avenue, Suite 700 New York, New York 10016 USA +1 212 481-8283 bsemich@worldnames.net

.one Group One Registry, Inc. 16771 NE 80th Street Suite 100 Redmond, Washington 98052 USA Paul Stahura +1 425 376-0505 x207 paul.stahura@webvision.com

.per JVTeam, LLC

1120 Vermont Avenue., NW Washington, DC 20005 USA Ken Hansen +1 202 533-2600 ken.hansen@neustar.com

.pid DADA Spa Via de' Pandolfini, 34/r 50122 Firenze, Italy +39 055 20351 registraradministrative@dada.it

.post Universal Postal Union Weltpoststrasse 4 3000 Berne 15, Switzerland Steve Gray +41 31 350 31 11 steve.gray@upu.int

.pro The dotPRO Consortium 130 W. Union Street Pasadena, California 91103 USA +1 626 685-4904 a@www.tv The .TV Corporation International 130 W. Union Street Pasadena, California 91103 USA +1 626 685-4904 a@www.tv Lycos, Inc. 400-2 Totten Pond Road Waltham, Masachusetts 02451 USA +1 781 370-2700 tmurphy@lycos.com SK Telecom

99 Seorin-dong Jangro-gu Seoul, Korea +82 2 2121 2621 XO Communications, Inc. (formerly Concentric Network) 1505 Farm Credit Drive, 6th Floor McLean, Virginia 22102 USA +1 703 547-2444 nsommerfeld@cncx.com OnlineNIC, Inc. 7F International Trade Building 388 Hubin Road Xiamen, 361004 China +86 592 516 1011 tony@onlinenic.com 7DC 38-40 Sarnlip Building, 3rd Floor Yuksangdong Kangram-gu Seoul 135-711 Korea +82 2 588-1282

.pro RegistryPro, Ltd. c/o Hayes & Curran Solicitors 6 Fitz William Square Dublin 2, Ireland +353 1614-5000 tburke@mhc.ie

.tel Jeff Pulver +1 631 547-0800 jeff@pulver.com David P. Peek 650 Suffolk St., Suite 307

Lowell, Massachusetts 01854 USA +1 603 362-4315 dpeek@i-tab.org Glenn W. Marschel 650 Suffolk St., Suite 307 Lowell, Massachusetts 01854 USA +1 978 454-4210 x24 gmarschel@netnumber.com

.tel Number.tel LLC 16563 Via Santa Fe Rancho Santa Fe, California 92067 USA William Nicholson +1 858 756-2061 winicholson@yahoo.com

.tel Telnic Limited 211 Picadilly W1V 9LD London, UK Fabien Chalandon +44 20 7776 5221 admin@telnic.org

.travel International Air Transport Association Route de l'Aeroport P.O. Box 416 CH-1215 Geneva 15 Airport, Switzerland +41 22 799 2525 murphyp@iata.org

.union International Confederation of Free Trade Unions (ICFTU) 5 Boulevard du Roi Albert 11, Bte 1 1210 Brussels, Belgium Duncan Pruett +32 2 224 0211 duncan.pruett@icftu.org

.wap dotWAP Domain Registry (DDR), Inc.

Comments concerning the layout, construction and functionality of this site should be sent to webmaster@icann.org.

Page Updated 10-October-2000 (c) 2000 The Internet Corporation for Assigned Names and Numbers. All rights reserved.

1251 Randol San Jose, California 95126 USA Jeremy C. Adrian +1 408 351-8908 dotwap@privacyx.com

.web Image Online Design, Inc. dba Web Registry 1201 Johnson Avenue, Suite 201 San Luis Obispo, California 93401 USA +1 805 543-4716 info@iodesign.com

Preface

I. Background

A. ICANN B. Top-Level Domains and the Domain Name System C. Development of ICANN's New TLD Policy D. Applications

II. Methodology

A. Goals B. Description of the Evaluation Process C. Outside Advisors

III. Analysis and Recommendations

A. Categories B. Application of the August 15 Criteria to Each Category or Group

1. General-Purpose TLDs

a. General Group b. Personal Group c. Restricted Content Group d. Restricted Commercial Group

Report on New TLD Applications (9 November 2000)

2. Special-Purpose TLDs

3. New Services TLDs

a. Telephony-Related Group b. Message Routing Group c. Other Group

Appendix A - Outside Advisors

Appendix B - Summaries of Applications

Comments concerning the layout, construction and functionality of this site should be sent to webmaster@icann.org.

Page Updated 09-November-2000 (c) 1998-2000 The Internet Corporation for Assigned Names and Numbers. All rights reserved.

Click Here to Enter Comment Area on New TLDs

Key Recent and Upcoming Milestones <http://cyber.law.harvard.edu/icann/pressingissues2000/briefingbook/milestones.html>

1999

July 1, 1999 - New ICANN fiscal year begins.

July 16, 1999 – Expected completion of testbed phase of the Shared Registration System. (Extended)

July 31, 1999 - DNSO submited recommendations to the ICANN board on Chapter 3 of the WIPO report (Conflict Resolution) and uniform dispute policy.

August 6, 1999 – ICANN, NSI, and DoC agree to extend the test bed phase of the Shared Registration System to September 10.

August 10, 1999 - Final Report of Advisory Committee on Independent Review submitted.

August 23-26, 1999 - ICANN Open Meetings in Santiago, Chile. Meetings of DNSO Constituencies. Public meeting of the Names Council and General Assembly of the DNSO.

September 10, 1999 – ICANN, NSI, and DoC agree to extend testbed phase of the Shared Registration System to September 30.

September 28, 1999 – ICANN, NSI and DoC announce tentative agreements, which include: a Registry Agreement between ICANN and NSI; a revised Registrar Accreditation Agreement between ICANN and all registrars registering names in the .com, .net., and .org domains; a revised, post-testbed Registrar License and Agreement between NSI and all registrars registering names in the .com, .net., and .org domains; an amendment to the Cooperative Agreement between the Department of Commerce and NSI; and an amendment to the Memorandum of Understanding between the Department of Commerce and ICANN.

September 29, 1999 - Proposed Uniform Dispute Resolution Policy (UDRP) for .com, .org, and .net registrars published for public comment.

October 12-13, 1999 - DNSO elects two members to the Board of Directors.

October 13, 1999 - Public comment period on UDRP ends.

October 18, 1999 - Final report on Famous Trademarks and new gTLDs due from DNSO.

October 25, 1999 - Time expires for SO elections to the Board of Directors.

November 2-4, 1999 - ICANN Meetings in Los Angeles, including first Annual Meeting on November 4. Meeting of the General Assembly of the DNSO; seating of SO Board members; tentative agreements between ICANN, NSI, and DoC go before the ICANN Board for final consideration.

November 5, 1999 - Testbed period for .com, .net., and .org domain ends.

2000

January 15, 2000 - NSI as registry will charge registrars $6 per registration-year for the remainder of the term of the Registry Agreement (decreases from $9).

March 7-10, 2000 - ICANN Meetings in Cairo.

July 13-17, 2000 - ICANN Meetings in Yokohama

September 30, 2000 - ICANN-DOC MoU scheduled to expire and is extended for an additional year.

October 2, 2000 - ICANN accepts applications for new TLDs.

October 10, 2000 - ICANN's At-Large membership elects 5 new At-Large Directors

Brief History of the Domain Name System <http://cyber.law.harvard.edu/icann/pressingissues2000/briefingbook/dnshistory.html>

1950s & 1960s 1970s 1980s 1990s

• Jan. 7, 1958 – President Eisenhower requested funds to start ARPA.

• Early 1958 – ARPA in created.

• Late 1950s – MIT computer researchers invented “time share.”

• 1960 – 1965 – Paul Baran working at RAND developed idea of packet switching and computerized “distributed networks” using “a rapid store and forward system” nicknamed “hot potato routing” and wrote 11 volumes of memoranda papers in an attempt to convince AT&T officials to support the network.

• 1961 – Due to lack of funds, the Air Force gave the Q-32 computer in Santa Monica, California to ARPA

• July 1961 – Leonard Kleinrock at MIT published a report analyzing the problem of data flow in networks and presenting ideas on packet switching.

• August 1962 – The first recorded description of the social interactions that could be enabled through networking was a series of memos written by J.C.R. Licklider of MIT

• 1965 – ARPA funded Tom Marill’s project to link the TX-2 computer in MIT’s Lincoln Laboratory to the Q-32 in Santa Monica, California, asking Larry Roberts at MIT to oversee the project.

• 1965 – The Air Force agreed to fund Baran’s network, however the Pentagon gives the DCA the job of managing the network. Rather than see his network die at the hands of conventional communications experts, Baran declined the funding.

• 1965 – Marill developed a “set of procedures for sending information back and forth” also known as “message protocol.”

• Spring 1966 – Donald Watts Davies, working for the NPL, gave a public lecture on his independently developed idea of packet switching. (and gave packet switching its name)

• Late 1966 – Roberts conceived ARPANET

• Early 1967 – Meeting of ARPA’s principal investigators in Ann Arbor, Michigan. Roberts (the director of the IPTO) put forward the idea of a computer network. Wes Clark introduced the idea of a subnetwork: small, identical computers all interconnected – “interface message processors (IMPs).” Engelbert volunteered to the Network Information Center (NIC).

• 1967 – Roberts published paper on ARPANET.

• End of 1967 – The Association for Computing Machinery’s computer conference in Gatliburg, Tennessee. Roberts presented his first paper on ARPANET and heard of work done by Donald Davies’ team at NPL and Paul Baran at RAND.

• Early 1968 – Roberts and Baran meet, and Roberts chooses the first 4 IMP sites.

• July 1968 – Roberts and the DARPA funded community refined the overall structure and specifications for the ARPANET as described in the Request for Proposals (RFP) on building the IMP network which was sent to 170 companies.

• Summer 1968 – Meeting of computer science graduate students in Santa Barbara, CA. This group of emerging computer scientists that later became known as the Network Working Group (NWG) began contemplation of host-to-host communications.

• December 1968 – In response to a RFP, Bolt Beranek and Newman (BBN) wins contract for the development of the IMPs and the IMP network.

• April 7, 1969 – Steve Crocker distributed the first Request for Comments (RFC) titled “Host Software” which discussed issues raised in the 1968 Santa Barbara and subsequent meetings.

• Spring 1969 – UCLA computer experts received BBN report 1822 – a set of specifications for connecting host computers to IMPs. UCLA computer experts, lead be Mike Wingfield began building the host-to-IMP interface.

• August 30, 1969 – BBN installed the first IMP at UCLA and within hours of its arrival the IMP and the Sigma – 7 were passing data back and forth.

• October 1, 1969 – The second IMP arrived at SRI (at Stanford University); a two node network was created.

• November 1, 1969 – The third IMP was installed at UC Santa Barbara.

• December 1, 1969 – The fourth IMP was installed at the University of Utah.

• December 1969 – NWG meeting in Salt Lake City. The NWG invented Telnet – a remote login protocol.

• End of 1969 – four host computers were connected together into the initial ARPANET

• 1969 – ALOHANet constructs a network using radios for transmission.

• Early 1970s – ARPA used communications satellites to create SATNet – an intercontinental network.

• January 1970 – Bob Kahn and Dave Walden of BBN flew to LA to test the network on Kahn’s fears of congestive failure and reassembly lockup. Kahn’s fears proved to be correct. Upon returning to Cambridge, MA, Kahn set to work with Crowther to fix the potential problem.

• Late March 1970 – The first cross – country circuit was installed, connecting UCLA’s computer to BBN.

• Spring 1970 – Heart’s BBN team invented remote maintenance and diagnostics which allowed troubleshooting and occasionally fixing IMPs by remote control.

• Summer 1970 – IMPs were placed at MIT, RAND, System Development Corp., and Harvard. AT&T replaced the link between BBN and UCLA with a link between BBN and RAND, and added a like between MIT and the University of Utah.

• November 1970 – BBN improved upon the existing Network Control Center and placed Alex McKenzie at its head.

• December 1970 – the Network Working Group (NWG) working under Steve Crocker finished the initial ARPANET Host-to-Host protocol, called the Network Control Protocol (NCP).

• End of 1970 – Carnegie-Mellon University and Case Western Reserve University were connected to the network.

• Early 1971 – BBN developed a terminal IMP – known as TIP – which allowed users to log in to the network without using a host computer.

• Mid 1971 – Kahn and Al Vezza along with a group of 8 principal researchers began planning a public demonstration of ARPANET which would take place at the first International Conference on Computer Communication (ICCC)

• Late Summer 1971 – The first 4 deliverable TIPs were delivered to BBN.

• Fall 1971 – 3 TIPs were up and running on the network. ARPANET had 19 nodes.

• Early 1972 – Several more Honeywell IMPs and TIPs were added to the network.

• Early 1972 – Jon Postel became the editor of the RFCs.

• Early 1972 – Ray Tomlinson coded the e-mail program, and was responsible for putting the @ sign in e-mail addresses.

• Early July 1972 – The NWG finished tweaking the File Transfer Protocol (FTP) which was published as RFC 354.

• August 1972 – A third cross-country line was added. ARPANET consisted of 29 nodes.

• October 1972 – Kahn along with other computer experts presented a large, very successful demonstration of the ARPANET at the first ICCC in Washington DC.

• 1972 – Kahn introduces the idea of open-architecture networking.

• 1973-1975 – The growth of ARPANET was roughly one node per month.

• 1973 – Kahn and Vint Cerf teamed up to develop a new version of the NCP protocol which could meet the needs of an open-architecture network environment. This protocol would eventually be called the Transmission Control Protocol/Internet Protocol (TCP/IP).

• Spring 1973 – Cerf and Kahn finalized a conceptual framework for creating a network of networks. This framework was based on the idea of a “gatekeeper” computer between the two networks. This gatekeeper would appear to be a host computer to each network.

• Late Spring and Summer 1973 – Cerf and Kahn presented the challenge of working out the details to the Stanford computer science graduate students.

• September 1973 – Cerf and Kahn presented their paper on host-to-host protocol to the International Networking Working Group at the University of Sussex in Brighton.

• 1973 – Larry Roberts wrote the first mail manager program, called RD.

• 1973 – The Open vs. Closed Source Code debate sparked over BBN’s refusal to release the IMP source code. Upon receiving pressure from DARPA, BBN finally agreed to release the source code.

• 1973 – Bob Metcalf of Xerox Park developed a short distance network called Ethernet.

• May 1974 – Cerf and Kahn’s paper “A Protocol for Packet Network Intercommunication” was published.

• April 1975 – Tel Myer and Austin Henderson of BBN issued a list of “standard headers” as RFC 680 entitled Message Transmission Protocol. RFC 680 sparked debates called the Header Wars. The wars were about what exactly belonged in the header. The computer engineering community split into two factions: those for long headers, and those for short headers.

• June 7, 1975 – Steve Walker (an ARPA program manager) proposed the foundation of the Message Services Group (Dubbed the MsgGroup) “to develop a sense of what is mandatory, that is nice, and what is not desirable in message services.”

• Summer 1975 – The Defense Communications Agency (DCA) took over the management of ARPANET.

• 1975 – John Vittal wrote a mail program called MSG which, unlike the RD program, could deal with numerous e-mails. This program was also the first to use the ANSWER command.

• 1975 – Yogen Dalal, drawing on the Cerf/ Kahn 1974 paper created a list of connector specifications.

• 1976 – The first computerized adventure game was created by Will Crowther. Later in 1976, Don Woods asked Crowther if he could revise the game. When revisions were done, Adventure was placed on the Stanford AI Lab computer. Crowther and Woods encouraged piracy of Adventure on the idea that software development was open – and therefore anyone was free to contribute.

• 1976 – The first commercial e-mail programs appear, starting with The Computer Corporation of America’s $40,000 COMNET, soon followed by On-Line Software International’s $18,000 MESSENGER.

• Fall 1976 – Jimmy Carter’s presidential campaign became the first to use e-mail. Carter became nicknamed the “computer driven candidate.”

• May 12, 1977 – Ken Pogran, John Vittal, Dave Crocker and Sustin Henderson published more than 20 pages of specifications for “A Proposed Official Standard for the Format of ARPA Network Messages,” as RFC 724. This proposal was widely criticized.

• October 1977 – Cerf, Kahn and several others demonstrated the first three network system. The three networks were packet radio, ARPANET and SATNET.

• November 1977 – The RFC 724 team revised the previous proposal and published the revision as RFC 733. The revision met with concern because it was not compatible with ARPANET’s most popular mail program – MSG.

• 1977 – Paul Baran and Dave Farber co-author the first paper written over e-mail with the authors 500 miles apart.

• April 12, 1979 -- Kevin MacKenzie, motivated by the feeling that e-mail was too impersonal, created the first smilies ☺ which would later be assimilated into cyber-culture.

• Early 1978 – TCP was broken into two parts: TCP – charged with breaking up and reassembling the messages, and IP – charged with routing. Thus TCP became TCP/IP.

• May 1979 – The National Science Foundation (NSF) sponsored a meeting to talk about a possible new network called Computer Science Research Networks (CSNET).

• Early 1980’s Universities wanted to connect their Local Area Networks (LANs) to the Internet. Ethernet made that desire possible, and as a result networking mushroomed.

• Summer 1980 – The NSF board decided to invest $5 million in the CSNET.

• 1981 – Bill Joy, at Berkeley, received ARPA funding to integrate TCP/IP into the Berkeley version of UNIX.

• August 1982 – Jon Postel and other in the MsgGroup decided to create a separate transfer protocol for e-mail. This decision led to the creation of Simple Mail Transfer Protocol (SMTP).

• 1982 – Joy teamed up with two Stanford Business School graduates to create a company called Sum Microsystems, which sold powerful computer “workstations” with Berkeley’s TCP/IP version of UNIX. These workstations greatly aided the re-popularization of TCP/IP.

• January 1, 1983 – ARPANET changed from NCP to TCP/IP.

• By June 1983 – More than 70 sites were connected to CSNET.

• November 1983 – The rapid growth of the internet caused massive problems in bookkeeping. To deal with this problem a group including Jon Postel, Paul Mockapetris and Craig Partrige published RFC 882 which created the domain name system (DNS) to make Internet navigation easier. With DNS, users can type host names such as “USC-ISIF” instead of “10.2.0.52.” Every Address would have information from specific to general.

• 1983 – The DCA decided that the ARPANET was too large to maintain high security standards. Therefore, ARPANET was broken into the networks: MILNET (sites carrying non-classified military information) and ARPANET (sites for the computer research community).

• October 1984 – RFC 920 establishes 7 generic “top level domains” (gTLDs, including .com, .net, .org and .gov) to provide domain space for corporations, non-profits, schools, networks, US government offices and the US military.

• 1985 – DARPA put pressure on Internet Users to adopt DNS addresses.

• 1985 – Using 5 new supercomputer centers, NSF built a “backbone” network called NSFNET in response to interest from non-computer science researchers. NSF agreed to connect self-organized regional networks to the backbone.

• 1985 – After Bob Kahn left, DARPA decided that ARPANET was obsolete compared with the faster NAFNET, and therefore decided to close ARPANET down.

• January 1986 – After a grand summit meeting, network representatives decided that the DNS system could and would work.

• By 1986 – The vast majority of the American computer science departments and many private corporations were connected to CSNET.

• November 1987 – RFC 1020 transfers control of Internet Protocol numbers from Jon Postel and ISI to the Network Information Center (NIC) at SRI International. First transfer of DNS activity to private sector.

• 1988 – The US Government chose Open Systems Interconnection (OSI) over TCP/IP for the new standard.

• 1989 – ARPANET passed the torch to NEFNET and the regional networks, and ceased to exist.

• September 1991 – RFC 1261 transfers NIC to Government Systems, Inc., in a document written by Network Solutions (NSI) employees.

• January 1, 1993 – NSI and National Science Foundation (NSF) sign Cooperative Agreement granting NSI authority to manage DNS

registration and database. Agreement set to expire on 9/30/98.

• October 22, 1996 to May 1, 1997 – The Internet International Ad Hoc Committee (IAHC, a coalition of participants including ISOC, IANA, ITU and WIPO among others) forms to recommend policy and procedure changes for administering gTLDs.

• February 28, 1997 – IAHC releases the "generic Top Level Domains Memorandum of Understanding" (gTLD-MoU) as its recommendation of DNS policy; IAHC holds working meetings and solicits signatories to the Memorandum.

• May 1, 1997 – 80 organizations sign the gTLD-MoU and the IAHC dissolves. Dissenters to gTLD-MoU claim that it bypasses governance structures and fails to protect individuals/small businesses in Internet policy debates; there is further concern regarding the centralization of power over DNS in a non-governmental organization.

• January 30, 1998 – Department of Commerce issues a proposed policy statement, known as the Green Paper, to improve the technical management of Internet names and addresses. Elements of the gTLD-MoU are incorporated.

• June 5, 1998 – In response to comments received regarding the Green Paper, Department of Commerce issues a statement of policy, known as the White Paper, calling for the end of direct federal support of Internet name and address coordination services; and calls for "Newco" to be created and take over the DNS. Many of the same concerns raised in the gTLD-MoU debate resurface.

• July/August 1998 – The International Forum on the White Paper holds a series of meetings around the world to address issues left open in the White Paper such as dispute resolution and the formation of new registries.

• November 21, 1998 – The Internet Corporation for Assigned Names and Numbers (ICANN) incorporates with aim of receiving designation as "Newco".

• November 25, 1998 – Department of Commerce signs Memorandum of Understanding (MoU) with ICANN recognizing ICANN as the "Newco" called for in the White Paper.

The Principles of the White Paper <http://cyber.law.harvard.edu/icann/pressingissues2000/briefingbook/white-paper-principles.html>

1. Stability. The U.S. Government should end its role in the Internet number and name address system in a manner that ensures the stability of the Internet. The introduction of a new management system should not disrupt current operations or create competing root systems. During the transition and thereafter, the stability of the Internet should be the first priority of any DNS management system. Security and reliability of the DNS are important aspects of stability, and as a new DNS management system is introduced, a comprehensive security strategy should be developed.

2. Competition. The Internet succeeds in great measure because it is a decentralized system that encourages innovation and maximizes individual freedom. Where possible, market mechanisms that support competition and consumer choice should drive the management of the Internet because they will lower costs, promote innovation, encourage diversity, and enhance user choice and satisfaction.

3. Private, Bottom-Up Coordination. Certain management functions require coordination. In these cases, responsible, private-sector action is preferable to government control. A private coordinating process is likely to be more flexible than government and to move rapidly enough to meet the changing needs of the Internet and of Internet users. The private process should, as far as possible, reflect the bottom-up governance that has characterized development of the Internet to date.

4. Representation. The new corporation should operate as a private entity for the benefit of the Internet community as a whole. The development of sound, fair, and widely accepted policies for the management of DNS will depend on input from the broad and growing community of Internet users. Management structures should reflect the functional and geographic diversity of the Internet and its users. Mechanisms should be established to ensure international participation in decision making.

Source: The Department of Commerce White Paper on the Management of Internet Names and Addresses http://www.ntia.doc.gov/ntiahome/domainname/6_5_98dns.htm

ICANN's Obligations Under the DoC-ICANN Memorandum of Understanding

<http://cyber.law.harvard.edu/icann/pressingissues2000/briefingbook/icann-obligations.html>

1. Design and test a plan for competition in domain name registration services including consistent accreditation requirements for registrars.

2. Develop procedures for operation and management of the primary root server including the possible expansion of the number of gTLDs (e.g. .web, .per, etc.).

3. Develop processes for affected parties to participate in the formulation of policies and procedures that address the technical management of the Internet.

4. Design and test appropriate membership mechanisms that foster accountability to and representation of the global and functional diversity of the Internet and its users.

5. Make recommendations regarding trademark policy, taking into account recommendations made by the World Intellectual

Property Organization (WIPO).

Source: The DoC-ICANN Memorandum of Understanding http://www.ntia.doc.gov/ntiahome/domainname/icann-memorandum.htm

AXES OF CONFLICT <http://cyber.law.harvard.edu/icann/pressingissues2000/briefingbook/axes.html>

Below, we have attempted to identify some major axes of conflict in the DNS debate. Each axis represents a pole of tension within the discussion.

Authority and Process central coordination unregulated market top-down rule-making bottom-up consensus building expert management democratic management cost recovery imposition of tax insulated from self-identified stakeholders (independent of political pressures or unaccountable?)

controlled by self-identified stakeholders (captured by special interests or reflective of community consensus?)

Registrar Accreditation stability easy entrance for competition consumer protection market competition

Supporting Organizations technical expertise non-technical considerations decision-makers advisors

Domain Names famous mark holders non-commercial domain holders; some trademark holders uniform mandatory dispute procedures preference for rights under local law special treatment for famous marks conflict with other name rights

At-Large Membership accountable to constituents accountable to special interests open to all Internet users address/name holders only individual members only corporation and organizational members financially self-supporting open to anyone regardless of income

online elections authenticating voter identity cost to administer election cost of fraudulent results representational democracy protection of minority interests

Government Participation efficiency of private enterprise protection of governmental procedures rapid response layered bureaucracy direct connection to consumer intervention of international treaty

Internal Review attorney-general of California international body paralysis pending litigation efficient complaint process

Openness and Transparency flexibility in decision-making answerable to public insulation from interest group pressure marginalization of minority opinion protection of work in progress discovering bad decisions after the event necessary exemptions from disclosure hiding important information encouragement of uninhibited deliberation on BoD knowledge of BoD opinions

New gTLDs TLD explosion slow addition of TLDs content-based unrestricted single registry owns TLD registries compete in every TLD new gTLDS expanded use of ccTLDs recognize established interests start fresh

Consensus estimation of rough consensus metrics for measuring consensus alienation of stakeholders investment of stakeholders silent majority vocal minority rapid implementation of policy time for input from all interested parties business rights individual voices

Uniform Dispute Resolution Policy trademark interests rights of the individual preventing abusive registrations legitimate speculation on domain names anti-tarnishing free speech reverse domain name hijacking legitimate protection of trademark

Root Server single authoritative root system root competition

Berkman Center ICANN-Related Content Archive

ICANN Public Meetings

November 13-16, 2000 Los Angeles, California July 14-17, 2000 Yokohama, Japan March 7-10, 2000 Cairo, Egypt November 1-4, 1999 Los Angeles, California August 24-26, 1999 Santiago, Chile May 25-27, 1999 Berlin, Germany March 2-4, 1999 Suntec City, Singapore November 14, 1998 Cambridge, Massachusetts

Other ICANN-Related Content from the Berkman Center

Pressing Issues II: Understanding and Critiquing ICANN's Policy Agenda, November 12, 2000 - Archives Available, including Briefing Book A Day with the ICANN North-American Candidates, October 2, 2000 "ICANN & The Public Interest: Pressing Issues" Workshop - Archives Available, including Briefing Book on Current ICANN & DNS Issues

and Issue Analysis Papers The ICANN-Related Analysis Site, including Analysis of Proposed Fall 1999 Contracts ICANN-Related Events Archive, including recordings of the "Governing the Commons: The Future of Global Internet Administration" conference by the Computer Professionals for Social Responsibility ICANN / Berkman Center Search Engine including Search of UDRP Proceedings Press Roundtable -- July 23, 1999 DNSO Content Archive including Teleconference and Physical Meeting Archives and a Proposed Process and Procedure for Names Council Meetings The IFWP/DNS Work-in-Progress Site, including a collection of links related to the interim board members The Representation in Cyberspace Study, including analysis of posts to a variety of ICANN-related discussion lists Experimental Cross-Registrar WHOIS Berkman Center-ICANN FAQ Partial Archive of the IFWP-Geneva Site

CONTACT INFORMATION

For additional information, please contact:

Ben Edelman Berkman Center for Internet & Society at Harvard Law School (617) 495-7547

Other ICANN-Related Content from The Berkman Center for Internet & Society Translate with Altavista Babelfish: Deutsch, Espanol, Francais, Italiano, Portugues

FAQ About the Berkman Center’s Role in ICANN

How did the Berkman Center get involved in the DNS mess?

The Berkman Center became involved in the process leading up to the formation of ICANN in July, 1998, during the meetings of the International Forum on the White Paper (IFWP), a series of conferences aimed at gathering consensus as to how--and by whom--the domain name system and related Internet functions would be coordinated in the future. These meetings were prompted by a U.S. Government policy statement, the "White Paper," calling for the creation of a new non-profit corporation, "newco" to coordinate key Internet management tasks. Tamar Frankel, Professor of Law at Boston University and Chair of the IFWP invited Berkman Center Executive Director Jonathan Zittrain to accompany her to the first of these meetings in Reston, Virginia. Zittrain and fellow Berkman Center faculty member Larry Lessig were tapped as moderators for the IFWP meeting in Geneva, and the Center constructed a public interest Web page that contained the complete compendium of IFWP-related materials, including a Berkman-drafted document comparing the various proposals generated during the process.

Then what happened?

As a September 30 deadline for presentation of proposals for a "newco" to the U.S. government approached, the IFWP struggled to move from calling meetings of stakeholders to developing a proposal reconciling interests among them. Network Solutions, which had developed its own suggested bylaws, offered to participate in an IFWP-sponsored process. The Internet Assigned Numbers Authority (IANA) had also been developing bylaws, and was uncertain about such participation. The Berkman Center accepted a request from the IFWP steering committee to organize a meeting among IANA, NSI, and others to hammer out a consensus solution. The Berkman Center called off the meeting at the request of both NSI and IANA when their private negotiations were successful enough to produce a progress toward a joint proposal between them--a proposal that eventually, after further modification, became the proposal that IANA submitted to the U.S. Government as the proposal for ICANN.

The "Boston Working Group" was formed as an informal gathering of people who had planned to attend the Berkman Center-organized meeting and wanted to continue to develop a consensus proposal even without delegates from IANA and NSI. BWG submitted a competing proposal to the U.S. Government, elements of which were added to the ICANN bylaws at the urging of the U.S. Government.

What is the current connection to ICANN?

In October of 1998, the Internet Corporation for Assigned Names and Numbers (ICANN) was incorporated. The corporation, which sought formal recognition by the U.S. Government as the new coordinating body for the DNS and related functions, asked the Berkman Center to facilitate an open meeting, held in November, at which ICANN board members would introduce themselves to the public and gather input as to how ICANN could more adequately represent the broad scope of Internet stakeholder interests.

ICANN also asked Berkman Center fellow Molly Shaffer Van Houweling and later, fellow Andrew McLaughlin, to take positions as advisors to ICANN in addition to their work as Berkman Center fellows. Both requests were granted, initiating an ongoing Berkman Center-ICANN collaboration that has resulted in the Berkman Center providing technical meeting support (scribing, webcasting, and remote participation faclitation) at ICANN Open Meetings in Singapore, Berlin, Santiago, LA, Cairo, Yokohama, Marina del Rey, Melbourne, and Stockholm. ICANN does not pay the Berkman Center for these services, but it pays rental fees for equipment used and pays some technical staff who work at the meetings. Berkman Center affiliates Rebecca Nesson and Benjamin Edelman have subsequently worked for ICANN.

Fellow Diane Cabell is a panelist for one of the Uniform Domain Name Dispute Resolution service providers that was accredited by ICANN to resolve disputes concerning bad faith registration of domain names. The UDRP service providers are independent corporate entities operating under a contractual agreement with ICANN.

How did the Representation in Cyberspace study get started?

The U.S. Government formally recognized ICANN in a Memorandum of Understanding on November 25, 1998, following adoption of some alterations to ICANN’s bylaws that were urged at the public meeting on November 14. ICANN subsequently requested that the Berkman Center undertake a study of possible options for its membership structure. The Berkman Center agreed to do so, and Jonathan Zittrain was named to ICANN's Membership Advisory Committee (MAC) as a non-voting liaison between the committee and the membership study. Tamar Frankel joined the Berkman Center as a fellow in mid-December to contribute to this and other projects. Along with members of the MAC, the Berkman Center produced a final report on membership issues that was presented to the ICANN Board of Directors and the public at the March 3 ICANN meeting in Singapore. The Berkman Center also provided technical support for that meeting--producing real-time notes, audio and video webcasting, and other on-site and online support. Upon the completion of the RCS study, MAC member Diane Cabell accepted a Berkman fellowship.

Why is Berkman doing the study, or working with ICANN at all?

The Berkman Center undertook the RCS study in the same spirit in which it has undertaken its other collaborations with ICANN: we are working constructively to improve an organization whose success may be important to the future of the Internet, and whose structure is fascinating to anyone interested in questions of cyberspace governance. The Berkman Center was not paid for this effort beyond reimbursement for the out-of-pocket expenses associated with our work.

Our mission at the Berkman Center is to investigate the real and possible boundaries in cyberspace between open and closed systems of code, commerce, government and education. The ICANN membership study represents the mainstay of our research into open government, constitutionalism, and cyberspace, and Charles Nesson and I have given counsel to ICANN in these areas. Although we haven’t masterminded a grand experiment in which our collaborators are unwitting participants, we do feel that we are all participating in a grand experiment that we hope will produce lots of good results—both pragmatic and academic. We're also users of the Net ourselves; we have interests that come from being members of ".edu" and ".org."

We are an independent research center, and as such have a large tent--Larry Lessig is under it, as are Zittrain, Nesson, Cabell, our students, and our fellows. Our institutional interest, if there can be said to be one apart from the sum of our parts, is in exploring forms of coordination--governance, even--well-suited to the medium of the Net and its traditions. We're also users of the Net ourselves; we have interests that come from being members of ".edu" and ".org." Beyond that, Andrew and Molly have special duties to ICANN apart from their affiliation to Berkman. (Note that Shaffer Van Houewling has since left her position at ICANN for a federal clerkship.)

What about the Membership Advisory Committee?

Berkman Center Executive Director Jonathan Zittrain was a non-voting liaison to the MAC, working in large part to coordinate the efforts of the MAC with the RCS study.

Where else is the Berkman Center-ICANN relationship described?

In hearings before the Subcommittee on Investigations and Oversight, Committee on Commerce, U.S. House of Representatives (July 22, 1999), Jonathan Zittrain submitted testimony that further describes the relationship between the Berkman Center and ICANN.

Last updated on October 19, 2000 by Ben Edelman

Participants - Pressing Issues II November 12, 2000 - Los Angeles, CA

HomeRegistrationWebcastParticipantsBriefing MaterialsArchive

The current panelists and moderator for each panel are list below with links to biographies or home pages.

Intellectual Property and Privacy in ICANN Policy: UDRP Review and Whois - 1:00pm

Alan Davidson of the Center for Democracy and Technology will lead a panel discussion focused on review of the first year of operation of the UDRP.

Moderator:

Alan Davidson, Center for Democracy and Technology

Panelists:

Professor Milton Mueller, Syracuse University Louis Touton, General Counsel, ICANN Mike Palage, InfoNetworks Professor Ethan Katsh, UMASS Amherst Professor Michael Froomkin, Miami School of Law J. Scott Evans, International Trademark Association Francis Gurry, Assistant Director General and Legal Counsel, World Intellectual Property Organization

At-Large Membership and Elections - 2:30pm

Harvard Law School professor Charles Nesson moderate a discussion on the role of the ICANN membership, the role of national identity in the ICANN policymaking process, and the import of the process and outcome of these first At-Large elections.

Moderator:

Professor Charles Nesson, Harvard Law School

Panelists:

Nii Quaynor, ICANN Board Member-Elect, Africa Region Barbara Simons, Association for Computing Machinery and ICANN At-Large Candidate for the North American region Andrew McLaughlin, Chief Policy Officer, ICANN Izumi Aizu, Secretary General, Asia & Pacific Internet Association Don Simons, General Counsel, Common Cause Professor Hans Klein, Internet Democracy Project and Georgia Tech School of Public Policy Jeannette Hofmann, ICANN At Large Candidate, Europe Region Ivan Moura Campos, ICANN Board Member-Elect, Latin America Region

New TLDs - 4:30pm

Following a short afternoon break, Professor Jonathan Zittrain will moderate a discussion about the new TLD application process and upcoming decision to add new TLDs. Panelists will include representatives of organizations submitting applications as well as outside analysts.

Moderator:

Professor Jonathan Zittrain, Harvard Law School

Panelists:

Chris Ambler, CEO, Image Online Design Richard Forman, CEO, Register.com Cary Karp, Director, Department of IT, Swedish Museum of Natural History Steve Metalitz, President, Intellectual Property Constituency Dave Crocker, Brandenburg Consulting Louis Touton, General Counsel, ICANN

About this Briefing Book <http://cyber.law.harvard.edu/icann/pressingissues2000/briefingbook/about.html>

This briefing book is a combination of useful background materials on the topics to be discussed at Pressing Issues II and student analysis of those same issues. Though the background materials contain analysis to the extent that they summarize documents or important arguments, they are primarily factual. The student analysis, on the other hand, provides the views of the views of the students who authored the papers. They are not intended as background, and they do not represent the views of the Berkman Center for Internet & Society. They are included in the briefing book to illuminate the issue being discussed and to present one thoughtful perspective on that issue.