Domain Name System (DNS) / Internet Corporation for Assigned Names and Numbers (ICANN) ISSUES BRIEFING BOOK

EXECUTIVE SUMMARIES OF RELEVANT DOCUMENTS

 

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

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

Correspondence Concerning House Commerce Committee Hearing of July 22

ICANN Agreements, Recommendations, and Related Documents

Registrar Accredidation Agreement
NSI/DoC Memorandom of Understanding
World Intellectual Property Organization (WIPO) Report

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 follwoing 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 recomended 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 proceded 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.

 

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 Europeens, 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 representional 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.

Correspondence Concerning House Commerce Committee Hearing of July 22

Letter from Rep. Tom Bliley, Chairman of the U.S. House Commerce Committee, to ICANN (June 22, 1999)
http://www.icann.org/correspondence/bliley-letter-22june99.htm

Cover Letter and Response from ICANN to Chairman Bliley (July 8, 1999)
http://www.icann.org/correspondence/dyson-letter-08july99.htm

http://www.icann.org/correspondence/bliley-response-08july99.htm

Response of Andrew Pincus, Department of Commerce to Chairman Bliley (July 8, 1999)
http://www.ntia.doc.gov/ntiahome/domainname/blileyrsp.htm

In his June 22, 1999 letter to ICANN, Representative Bliley raised a number of concerns that ICANN and Pincus attempt to address in their respective responses. In particular, Bliley expressed concern regarding ICANN's proposed initial funding structure (a $1 fee to be collected from each gTLD domain name registration and renewal), as well as concerns regarding the size of ICANN's budget. He further questioned ICANN's authority to terminate NSI's right to register gTLDs if NSI fails to sign ICANN's Registrar Accredidation Agreement.

ICANN responded to Bliley's concerns by noting that it must cover its costs; that the US Government previously funded similar functions through IANA; that its proposed funding model passes its costs on to stakeholders, as contemplated by the White Paper; and that the cost savings to consumers as a result of competition in gTLD registrations are likely to far exceed the cost of funding ICANN. Pincus's letter went further, suggesting that ICANN should eliminate the $1/domain fee because "it has become controversial" but offering to help obtain interim resources for ICANN until long-term funding can be finalized.

With respect to ICANN's assertion that NSI must sign the Registrar Accredidation Agreement, Dyson and Pincus agree that such a decision falls under the authority of the Department of Commerce, and both express serious concern at the potential threat to the operational stability of the Internet as well as to the overall process contemplated by the White Paper if NSI, DoC, and ICANN cannot reach agreement regarding the terms on which NSI will operate. Finally, Pincus notes that negotiations between DoC and NSI are ongoing and that he remains hopeful for agreement on outstanding issues.

 

ICANN Agreements, Recommendations, and Related Documents

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

NSI's proposed version of RAA
http://netsol.com/policy/icann299/

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 Memorandom 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 eneity 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.

 

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!