ICANN Montevideo Meeting Topic: Update on ccTLD Agreements Posted: 2 September 2001 Updated: 20 September 2001

One topic on the agenda of the ICANN Public Forum Montevideo on 9 September 2001 is an update on country-code top-level domain (ccTLD) agreements. ccTLD agreements, including models, concepts, etc., have been discussed in various forums, and resulted in various very useful documents.

The update provides a good opportunity to begin consolidating some of the thinking developed in the past years, so as to move forward on agreements (in whichever form) between ICANN and ccTLDs. To assist in this consolidation, this page reflects:

• Background on the function of ccTLDs in the Internet's domain name system (DNS) and the relationship among the various parties responsible for ccTLD administration (the ccTLD managers, the relevant governments and public authorities, and ICANN);
• Considerations developed in discussions in various ICANN forums regarding the need to provide a greater level of certainty and stability to those relationships due to their function in the DNS, such as by entering formal agreements, memoranda of understanding, and other written instruments;
• The types of approaches to agreements that are being discussed among ICANN and the other entities responsible for ccTLD administration; and
• The progress toward agreements made to date and intended schedule for further progress.

In the last respect, it is expected that the ICANN Board will be asked at its 10 September 2001 meeting to consider entering a ccTLD Sponsorship Agreement between ICANN and .au Domain Administration Limited (auDA), which has been reviewed and supported by the Australian Government, and which culminates a lengthy process within the Australian Internet community to create an accountable private-sector entity to administer the .au ccTLD.

A. Background on Development of ccTLD Delegation and Administration Policies

As background, the domain name system (DNS) was implemented in the mid-1980s and now consists of approximately 250 "top-level domains" or "TLDs" (the string, such as .com, to the right of the last period in a domain name). These TLDs currently consist of two or more letters. Two-letter TLDs are referred to as "country-code top-level domains" or "ccTLDs," because those codes correspond to the two-letter abbreviations for countries (such as .dk for Denmark) or external territories (such as .gl for Greenland) that are presented on the ISO 3166-1 list, which is maintained by a branch of the International Organization for Standardization (ISO).

ccTLDs were established by the Internet Assigned Numbers Authority (the IANA)¹ to facilitate and promote the spread of the Internet globally. They are delegated to designated managers, who operate the ccTLDs according to local policies that are adapted to best meet the economic, cultural, and linguistic circumstances of the country or territory involved. The ISO 3166-1 list has been used as the authoritative source for the two-letter country codes because, as was stated in RFC 1591, "the IANA is not in the business of deciding what is and what is not a country."

Beginning shortly after it deployed the DNS in 1985, the IANA began delegating the responsibility for ccTLD management, usually to volunteer Internet pioneers in the respective countries or territories, under policies for the administration and delegation of TLDs generally, and ccTLDs in particular. These policies included basic technical requirements and detailed the circumstances under which the IANA would make or change a delegation. From the outset, the policies for administration of ccTLDs have been premised on the principle that each ccTLDs should be operated in service to the local Internet community for which it was established, within the framework of the needs of a global network.² In keeping with this fundamental premise, the policies required delegated managers to treat applicants for domain names within their countries on an equitable basis, and provided accountability to the local Internet community by permitting interested members of the local Internet community to request the IANA to transfer "designated manager trusteeship" if the trust was not being properly fulfilled.

As the Internet has spread to every corner of the globe, become a critical communications medium for hundreds of millions of users, and come to accommodate increasing levels of commercial use, the IANA's policies have evolved. In March 1994, Dr. Jon Postel of the IANA published RFC 1591, which described the "Domain Name System Structure and Delegation" generally, including both ccTLDs and gTLDs. After issuance of that RFC, the IANA periodically adjusted the policies and, from time to time, issued memos (such as the ccTLD News series) that documented the evolving policies, building on the basic principle of accountability to the local and global Internet communities.

In the fall of 1998, ICANN was formed by the global Internet community as a private-sector, not-for-profit corporation to assume responsibility for technical coordination of the Internet's DNS, including the IANA functions then performed at the University of Southern California under contract with the U.S. Government. In November 1998, ICANN entered into a Memorandum of Understanding with the U.S. Department of Commerce under which responsibilities are being transitioned in phases to private-sector coordination under ICANN's auspices. In December 1998, ICANN entered a transition agreement with ISI under which it assumed, subject to U.S. Government approval, responsibility for the IANA's operation. In February 2000, ICANN entered into a contract with the U.S. Government for the operation by ICANN of the IANA. Among other things, that contract approved the transition from ISI.

Prior to this, however, in May 1999, ICANN and the IANA jointly issued a document entitled "Internet Domain Name System Structure and Delegation", commonly known as "ICP-1." This document contains a statement of the policies then being followed by the IANA in connection with ccTLDs. Those policies are still in effect today, making ICP-1 both the best reference for existing policy and a starting point for consideration of ccTLD policy changes.

In carrying out its responsibility for selecting, and when necessary changing,³ appropriate managers for ccTLDs, the IANA has relied heavily on each country's local Internet community to reach consensus on how the ccTLD should be operated. In matters of delegation and redelegation of a ccTLD, the IANA seeks input from persons concerned or affected by the transfer, particularly those within the nation or territory that the ccTLD has been established to benefit. As explained in RFC 1591:

Significantly interested parties in the domain should agree that the designated manager is the appropriate party.

The IANA tries to have any contending parties reach agreement among themselves, and generally takes no action to change things unless all the contending parties agree; only in cases where the designated manager has substantially mis-behaved would the IANA step in.

However, it is also appropriate for interested parties to have some voice in selecting the designated manager.

As Dr. Postel observed in ccTLD News Memo # 1, and as is reiterated in ICP-1, the views of the government or public authority of the affected nation or territory are taken very seriously in this regard. Governmental views are particularly pertinent when the government is fulfilling its role of promoting management of the ccTLD in the public interest.⁴

Even with this heavy reliance on the local Internet community to converge on consensus-based arrangements for ccTLD administration, the IANA has found the oversight responsibility for ensuring that the interests of the local Internet community are being served to be a difficult role that, in cases where consensus is not reached, presents significant challenges in investigating and assessing how the interests of the local Internet will be best served. These challenges have necessarily made the process of investigating redelegation requests quite lengthy at times.⁵

Since the issuance of ICP-1, there have been several redelegations and one delegation. In each case, the IANA carefully reviewed the circumstances to address the responsibilities of each party and the local Internet community. In early February 2000, the IANA issued a report on a request for redelegation of the .pn (Pitcairn Island) top-level domain, concluding that redelegation was appropriate; in March, the IANA issued a report on the delegation of .ps (Palestinian Territories); and in December 2000, the IANA issued a report on the .ca (Canada) top-level domain, likewise concluding that redelegation was appropriate. In all these cases the U.S. Government directed implementation of the IANA's redelegation decision, as is required at this stage of the transition process, without delay.⁶ In August 2001, the IANA issued a report concluding that the .au (Australia) top-level domain should be redelegated to auDA, a broad-based organization formed by the Australian Internet community, once an appropriate agreement is concluded between ICANN and auDA.

B. The Need to Move Forward with More Formal Arrangements

Although the fundamental principles of the ccTLD delegation and administration policies continue to serve well, the informal way in which they have been documented is not suited to the increasingly formal framework in which the ccTLDs and the IANA must operate. As the Internet and ccTLDs have grown in size (one ccTLD now has over four million registrations) and importance to the global economy, the need for clearly articulated commitments has become clear.

There now appears, over 15 years since the deployment of the DNS, to be a widely held belief throughout the Internet community that the relationships described in the IANA's historical documents (RFCs, ICPs, news memos, and reports) should be formalized in way that makes them more transparent to the Internet community, more predictable, and more accountable, while continuing an industry-led, bottom-up approach.

This sentiment is in accord with the requirements that the community must achieve to complete the transition to private-sector technical coordination of the Internet through ICANN. One of the requirements under ICANN's Memorandum of Understanding with the U.S. Government for completion of the transition is that ICANN develop appropriate relationships with other entities involved in the Internet's operation, to allow it to meet its technical-management responsibilities in a manner that ensures continued stable operation of the Internet. These entities include the managers of the ccTLDs as well as those governments of the affected countries or territories that are prepared to contribute to the overall coordination effort. Specifically, under a September 2000 update to the Memorandum of Understanding, completion of the transition to private-sector coordination requires achieving "stable agreements with the organizations operating country-code top level domains" covering redelegation issues, allocations of policy formulation responsibilities, and relationships with relevant governments or public authorities.

In past meetings, the ICANN Board has affirmed the need to move forward with agreements with ccTLD managers. At the Cairo meeting (March 2000), the Board heard several presentations and held an extended discussion on ccTLD administration and delegation policies. At this meeting the Board resolved that

the President and staff are authorized to work with the ccTLD managers, Governmental Advisory Committee, and other interested parties to prepare draft language for contracts, policy statements, and/or communications, including appropriate funding arrangements, to be presented to the Board and posted for public comment as soon as practicable.

At the Melbourne meeting (March 2001), the ICANN Board discussed the ccTLD issues, and in resolution 01.37 resolved that

ICANN management is directed to press forward with continued vigor toward the completion of draft legacy agreements, and to pursue, as needed, acceptable ccTLD agreements in triangular situations.

Stakeholders within the ICANN community have risen to these challenges and worked hard on fashioning proposals for formalizing, and in some respects adjusting, the current policies concerning ccTLD administration and delegation. Nearly all the proposals are based on establishing a structure of agreements or other written instruments providing clear statements of commitment by parties involved in administering the ccTLDs. For nearly 2 years, ICANN and ccTLD managers have been engaged in wide-ranging discussions about the appropriate form and substance of the relationships among ICANN, the ccTLD manager, and the relevant government or public authority. Numerous discussions have also been held between governments and ccTLD managers and between ICANN and governments.

Working together, ccTLD managers have prepared various sets of draft documents and best practices. Recognizing a ccTLD manager's significant responsibility to both the local and global Internet communities, the ccTLD managers have undertaken to organize themselves and work toward common principles and practices that serve the best interests of their diverse local Internet communities. These efforts are reflected in the Best Practice Guidelines for ccTLD Managers (Version 4.1, 1 June 2001).

In February 2000, the ICANN Governmental Advisory Committee (GAC) issued a document entitled "Principles for the Delegation and Administration of Country Code Top Level Domains," commonly known as the "GAC Principles." These principles serve as "best practices" to guide governments in assuming proper roles with respect to the Internet's naming system, which the GAC has observed is a public resource to be administered in the public interest.

The GAC Principles, like the draft Best Practice Guidelines of the ccTLD Constituency, reaffirm the soundness of the basic underpinning of the longstanding IANA policy concerning ccTLDs: that "the manager of a ccTLD performs a public service on behalf of the relevant local community and as such the designated manager has a duty to serve this community." The GAC Principles recognize that, consistent with the Internet's heritage of private-sector leadership, administration of a ccTLD should be conducted within a three-party "framework of accountability" in which the ccTLD manager, the relevant government, and ICANN cooperatively work to promote stable administration of the ccTLD in a manner that best serves the local Internet community. The manager has basic administrative and policymaking responsibilities for a ccTLD, to be pursued on behalf of the local Internet community, with accountability to the government and ICANN.

The GAC Principles recognize that each government has the ultimate responsibilty within its territory for its national public-policy objectives and that ICANN has the responsibility for ensuring that the Internet domain-name system continues to provide an effective and interoperable global naming system.

Although the ccTLD Constituency and the GAC have sometimes differing views on specifics, they both clearly support two basic points:

(a) the fundamental historical premise of ccTLD policy, that the delegated manager serves as a trustee in service of the local Internet community, remains sound.⁷

(b) There is a need for more formal documentation, in agreements or equivalent written instruments, of the respective commitments of the various entities involved in the administration of ccTLDs.

C. Structures of Agreement Approaches Being Pursued

Basic Subjects of Agreement

Any agreement reached between ICANN and a ccTLD manager should provide for commitments by the ccTLD manager that it will discharge its responsibilities to both the local and global Internet community and do so under an appropriate framework of accountability. The following areas should be addressed in any ICANN-ccTLD manager agreement:

1. Delegation, including circumstances when the designated manager of a ccTLD should be changed, and applicable principles.

2. Local and Global policy responsibilities, and support of the ccTLD Manager's duty of public service to manage and operate the ccTLD in the interests of and in consultation with the local Internet community, mindful of the global Internet community and its policies.

3. ccTLD relationship to ICANN and the IANA, and the respective responsibilities.

4. ICANN funding for overseeing global stability and interoperability.

Covering these four general topics in a manner that best serves the overall purposes of the ccTLD policies requires careful attention to the detailed circumstances of each ccTLD. In any event, the above topics should be addressed in an agreement (or memorandum of understanding) between ICANN and the ccTLD manager, setting out the role and responsibilities of each party, providing an audit trail for decisions and transactions, and clarifying to the local and global Internet community the terms of the delegation.

Variations of Agreement: Legacy and Triangular Situations

Over the past two years, it has become evident that no single agreement—indeed, no single agreement structure—will be appropriate for every ccTLD. Although discussions initially focused on trying to develop a single template agreement that could be used for every ccTLD manager, it became evident over time that the enormous diversity in ccTLD situations and their local communities made that objective unrealistic. The ccTLD community comprises a huge diversity of management structures, organizational forms, registration policies, mechanisms of accountability, and relationships with governments.

Accordingly, over many long hours, weeks, and months of discussion, there have emerged two primary structural situations deserving differing treatment, distinguished by the involvement or non-involvement of the local government or public authority. These have been commonly referred to as the triangular situation (involving the relevant government or public authority) and legacy situation (not involving the relevant government or public authority).

It seems appropriate at this juncture to try to solidify some of this thinking.

In simplest form, in the legacy situation the ccTLD manager operates, as in the past, subject to whatever laws prevail in its country but otherwise under the oversight only of the IANA and ICANN. In the legacy situation, the IANA's responsibility for ensuring that the ccTLD manager serves as an appropriate trustee for both the local and global Internet communities remains as it has been in the past.

The triangular situation arises where the relevant government or public authority is prepared to play an appropriate role in ensuring that the interests of the local Internet community are served. This situation takes advantage of the government's ultimate authority over public policies within its national borders by formally assigning to the government the responsibilty to oversee the ccTLD manager's fulfillment of its obligation to serve the local Internet community. In the triangular situation, ICANN handles the responsibility for ensuring that the operation of the ccTLD promotes the interests of the global Internet community in stability and interoperability and, to the extent the ccTLD encourages registration by nonresidents, certain other matters. This arrangement has the benefit of placing oversight of the ccTLD manager's service to the local Internet community in the hands of the local (i.e. national) government, which is nearby and institutionally better suited than ICANN to perform this oversight.

The triangular and legacy situations have been extensively discussed, and it is appropriate to analyze them in detail to evaluate what sorts of model agreements between ICANN and ccTLD managers might be appropriate. What follows seeks to do just that, but it should be kept in mind that, even with the two models, there are likely to be variations of either the triangular situation or the legacy situation that will require minor adaptation. Likewise, there will doubtless be situations that fall between the two models.

The choice of a legacy or triangular arrangement will depend on the particular circumstances of the ccTLD and its relation to its government. The choice of which arrangement to pursue is a matter essentially between the government and the ccTLD manager, in consultation as appropriate with the local Internet community. The tenor of the community discussions is that ICANN should accommodate either type of arrangement (where appropriate conditions are met), but should neutrally allow the government and ccTLD manager to work out between themselves, in the context of their country's laws and policies, which arrangement to pursue.

Applicability of Triangular Model

In general, for the triangular situation to arise, the following sequence will occur:

1. The relevant government or public authority should have an interest in assisting in the cooperative framework of accountability envisioned in the triangular model.

2. The relevant government or public authority should have the capability to perform this role. In many cases, governments have indicated that they are unable to enter into a triangular relationship absent authorizing legislation, which will take time to enact.

3. The relevant government or public authority and the ccTLD manager should enter into an appropriate agreement or other communication covering the matters described by clause 9 of the GAC Principles. In general, the precise manner in which these matters are addressed by the communication between the government and the ccTLD manager are to be resolved between those parties, in appropriate consultation with the local Internet community.

4. The relevant government or public authority should formally communicate to ICANN, ordinarily by a letter, its designation of the ccTLD manager. In that letter, the government should also should communicate to ICANN how it will require the manager to abide by the terms and conditions outlined in clause 9 of the GAC Principles (on the content of the government-ccTLD manager communication), should state its commitment to ensure that local (i.e. national) interests and public policies are served, and should acknowledge ICANN's responsibilty for coordinating the DNS (including ccTLDs) in a manner that ensures stability and interoperability of the entire Internet.

5. Upon receiving the elements of the government's communication to ICANN (item 4 above), to complete the communications forming the triangular situation ICANN would then ordinarily seek to craft an appropriate agreement with the ccTLD manager, as described below.

Provisions of the "ccTLD Sponsorship Agreement" in Triangular Situation

A model agreement between ICANN and organizations responsible for managing ccTLDs, known as a "ccTLD Sponsorship Agreement," has been developed in consultation between ICANN legal staff and several organizations interested in entering into triangular situations. That model agreement, which is posted, follows the general plan of clause 10 of the GAC Principles. It also takes into consideration various materials collected by the ccTLD constituency on dispute-resolution mechanisms, including from the International Chamber of Commerce. In brief summary, the model ccTLD Sponsorship Agreement addresses the four major issues identified above as follows:

1. Delegation and redelegation: the agreement provides that the sponsoring organization will serve as the ccTLD manager until the agreement is terminated, which can occur because the organization breaches its communication with the government (concerning national interests) or because it breaches its commitments to ICANN concerning global interests such as adherence to policies promoting interoperability. (Sections 2.10, 3.1, and 6.2.)

2. Local and Global policy responsibilities: The ccTLD manager, under governmental oversight, has autonomy to set policies affecting local interests. It agrees to comply with ICANN policies concerning interoperability, operatational capabilities, and performance of the ccTLD and transparency of delegation and registration data. Where the ccTLD's policies encourage or promote registrations from non-resident entities or individuals, the manager will comply with ICANN policies that are specifically applicable to it, unless the government instructs it not to comply. (Section 4.5.)

3. ccTLD-ICANN/IANA relationship: Section 3 provides for ICANN to provide root-zone service for the ccTLD according to a variety of specifications. The ccTLD manager agrees to various operational requirements to promote stability and interoperability in Section 4.

4. ICANN funding: the ccTLD manager agrees to contribute funding to ICANN "in accordance with an equitable scale, based on ICANN's total funding requirements (including reserves), developed by ICANN on the basis of consensus." (Section 4.6.)

Applicability of Legacy Model

In situations in which the relevant government or public authority is not interested in participating in a triangular situation, or it cannot do so because of lack of authorizing legislation or other factors, a two-party arrangement between ICANN and the ccTLD manager may be possible. These are referred to as "legacy" situations.

Based on discussions within the ccTLD Constituency and the Governmental Advisory Committee, however, there are several limitaitons on the applicability of the legacy model. Some likely limitations are:

1. To permit governments to consider whether they desire to and are capable of participating in a triangular situation, ICANN has pledged, in cooperation with the ccTLD manager, to inform the government that an agreement is under discussion, respecting the fact that the situation in each ccTLD and country will be unique and must be taken into account.

2. Where a request for redelegation is pending, it would ordinarily not be appropriate to enter into any agreement in either the legacy or triangular situation until the request is resolved.

3. In addition, the weight of opinion among the managers and governments is that legacy-model agreements should not be entered where the ccTLD manager is not within the jurisdiction of the relevant government or public authority, unless the relevant government or public authority is agrees to such an arrangement.

The GAC has also expressed the view, in its Melbourne communiqué, that any "legacy" agreements should be provisional and interim in nature, pending appropriate expression by the relevant government or public authority for participation in a triangular situation. This view is of concern to some members of the ccTLD Constituency, and some additional discussions among the ccTLD Constituency, the Governmental Advisory Committee, and other members of the Internet community will be required to further refine the issue.

Meanwhile, however, it is desirable in promoting orderly, stable relationships, and it should be beyond controversy, to proceed with lightweight documents reflecting interim bilateral commitments in those situations where governments are not yet prepared to participate in a triangular situation. To this end, the ICANN legal staff has prepared a model Memorandum of Understanding for consideration in legacy situations. The legal staff, in preparing this draft, referred to, among other things, the 26 November 2001 ccTLD constituency draft "Contract for Services between ccTLD Managers and ICANN" (as to the subjects it covers) and version 4.0 of the "Best Practice Guidelines for ccTLD Managers".

This model MoU (linked below) is designed to be terminable by either party upon notice and does not create any obligations enforceable within the legal system. Even such an untenured MoU, however, has the benefit of memorializing the intended commitments of ICANN and the ccTLD manager, to provide an added measure of clarity and stability to relationships in the legacy situation. In the absence of an express objection of the relevant government or public authority, entry of this form of MoU should promote ICANN's overall mission of maintaining the stability of the DNS.

In particular circumstances and with assent of the relevant government or public authority, it may also be appropriate to enter into agreements with enhanced obligations and tenure of delegation in legacy situations. The precise contours of such agreements will inevitably require discussions among the parties of the particular country involved.

D. Progress to Date and Next Steps

ICANN legal staff has been engaged in discussions with ccTLD managers in three countries (Australia, Canada, and Japan) concerning the terms of agreements between ICANN and the manager. In each case, officials of the relevant government were notified at the commencement of these legal discussions and have been kept apprised of the status.

In many other cases, other ICANN staff responsible for liaison on ccTLD issues have conducted preliminary discussions with ccTLD managers and governmental officials. These preliminary discussions indicate that ccTLD managers in many countries are prepared to proceed into discussions regarding appropriate language for an agreement with ICANN.

In the case of Australia, the discussions have led to closure on the terms of a ccTLD Sponsorship Agreement between ICANN and .au Domain Administration Limited, (auDA), subject to approval of those organization's boards. This is a triangular situation, in which auDA has entered into an appropriate communication with the Government of Australia. The Government of Australia, in turn, has endorsed auDA as the delegee of the .au ccTLD and has committed to fulfill its responsibility under the triangular situation to provide oversight of auDA's service to the local Internet community, while acknowledging ICANN's responsibilty for "oversee[ing] the technical coordination of the Internet in a manner that will preserve it as an effective and convenient mechanism for global communication and commerce." It is expected that the proposed ccTLD Sponsorship Agreement will be presented to the ICANN Board at its 10 September 2001 meeting for its consideration.

(In addition, since the Montevideo meeting ICANN staff have been engaged in giving presentations on the status of agreements. At the CENTR meeting on 20-21 September 2001 ccTLD Liaison Herbert Vitzthum gave a presentation entitled "ICANN ccTLD Agreements.")

Notes:

1 As noted in RFC 1591, upon its deployment of the DNS in 1985, the IANA assumed the overall responsibilty for administration of the DNS as part of its mission of administering the Internet's unique-identifier spaces in the public interest: "The Internet Assigned Numbers Authority (IANA) is responsible for the overall coordination and management of the Domain Name System (DNS), and especially the delegation of portions of the name space called top-level domains."

2 As stated in RFC 1591:

These designated authorities are trustees for the delegated domain, and have a duty to serve the community.

The designated manager is the trustee of the top-level domain for both the nation, in the case of a country code, and the global Internet community.

Concerns about "rights" and "ownership" of domains are inappropriate. It is appropriate to be concerned about "responsibilities" and "service" to the community.

3 "In cases when there are persistent problems with the proper operation of a domain, the delegation may be revoked, and possibly delegated to another designated manager." RFC 1591.

4 IANA Report on Request for Redelegation of the .pn Top-Level Domain (11 February 2000).

5 As noted in ccTLD News Memo #1:

On a few occasions, the parties involved have not been able to reach an agreement and the IANA has been required to resolve the matter. This is usually a long drawn out process, leaving at least one party unhappy, so it is far better when the parties can reach an agreement among themselves.

6 In June 2001, the IANA also issued a report finding that the ccTLD for the former country of Zaire (.zr) should be deleted. That action was also implemented without delay.

7 From the ccTLD Constituency's Best Practice Guidelines for ccTLD Managers (Version 4.1 - 1 June 2001):

A ccTLD Manager is a trustee for the delegated domain, and has a duty to serve the community it represents as well as the global Internet community. Concerns about "rights" and "ownership" of top-level domains are inappropriate. It is appropriate to be concerned about "responsibilities" and "service" to the community.

From the GAC Principles (23 February 2000):

[T]he principle of RFC 1591 remains sound: the manager of a ccTLD performs a public service on behalf of the relevant local community and as such the designated manager has a duty to serve this community. The designated manager also has a responsibility to the global Internet community.