ICANN Logo

CENTR Best Practice Guidelines for ccTLD Managers

(Version 2 – adopted 10 May 2001)


CENTR Logo

CENTR Best Practice Guidelines for ccTLD Managers

(Version 2 - Adopted 10 May 2001)

I  PREAMBLE

The Domain Name System structure contains a hierarchy of names. The root, or highest level, of the system is unnamed. Top Level Domains (TLDs) are divided into classes, ccTLDs and gTLDs, based on rules that have evolved over time. ccTLDs - country code Top Level Domains - are associated with countries and territories. gTLDs are (with some exceptions) generic and global in nature.

To date, ccTLDs have been assigned to countries and territories using the ISO-3166-1 list, on the basis that ISO has a procedure for determining which entities should be and should not be on that list. For more information about the ISO 3166 Maintenance Agency, please see the following web page:

http://www.din.de/gremien/nas/nabd/iso3166ma/

Historically, the management of ccTLD Registries was delegated by IANA to the existing ccTLD Managers. As of 1994, the delegation of the management of the ccTLD Registries was done under the guidelines published in IANA’s RFC 1591 and later ICP-1. The existing ccTLD managers all operate under these guidelines. A list of current TLD assignments and names of the ccTLD Managers can be accessed at:

http://www.iana.org/cctld.html

With further evolution of the Internet, and specifically the ICANN process, there is a need for best practice guidelines for ccTLD Managers. The ccTLD Managers have therefore established best practices guidelines, on the basis of the main principles of RFC 1591, which remain stable and sound.

1. Basic Objectives

This Best Practice document is intended to provide guidelines on the operation of Country Code Top Level Domain Name Registries (ccTLD) and policies for such registries. It is intended to be a Code of Conduct model for ccTLD registries. Whilst recognising that existing managers of ccTLD registries do not necessarily fully conform to best practice, most of the ccTLD Manager community is committed to work towards compliance.

2. Basic Principles

The Best Practice document closely follows established Internet principles such as:

a) self-regulation;
b) bottom-up authority (the Internet consists of cooperative networks);
c) consensus (requirement for self-regulation);
d) transparency (requirement for self-regulation);
e) cooperation based on trust and fairness.

Any interpretation of the Best Practice document must be in consideration with principles a) to e) above.

3. Authority of the Country Code Top Level Domain Name Registries

Legitimacy of a ccTLD registry may come from following parties in a given territory:

a) The public sector (e.g. governments or academic communities).
b) The private sector (e.g. commercial or non-commercial interest groups).
c) Both a) and b) above.

The Best Practice document defines the legitimacy of a ccTLD registry as to be given by c) above, usually designated "the Internet community" of a given territory. This is in agreement with paragraph 2. b) above and in the true Internet spirit. CcTLD registries thus seek authority from both public and private sectors in a given territory and act in the interest of both.

Under these best practices guidelines a ccTLD Manager's authority comes from serving the Local Internet Community and from the unremitting affirmation by the Local Internet Community of that authority. The Local Internet Community, including governmental and other authorities, has a responsibility to support and protect the ccTLD Registry, and to assist the ccTLD Manager serve the that community. Furthermore, a ccTLD Manager is entrusted with the management of a ccTLD Registry, and has no interest in the intellectual or other property rights in domain names. A ccTLD Manager should be equitable and fair to all eligible registrants that request domain names, should be competent and respond to requests in a timely manner, and should operate the database with accuracy, robustness, and resilience.

The authority of the Internet Corporation for Assigned Names and Numbers (ICANN) as a "private, not-for-profit corporation responsible for coordinating specific DNS functions for the benefit of the Internet as a whole" is accepted and supported by ccTLD registries. It is, however, felt necessary to stress the fact that the Internet community of a given territory (if applicable including the responsible governmental bodies of the territory) and local jurisdiction within the territory may be given priority over any recommendations issued by ICANN.

4. Operational Objectives of the Best Practice document

Any specific implementation of the Best Practice model has to be measured to be in accordance with the Basic Objectives and the following main Operational Objectives:

  • to ensure stability, accuracy, resilience and robustness of the Domain Name System;
  • to perform the function of a trustee for a public service (in some cases of ccTLD registries this function is performed by the private sector);
  • to establish and publish fair and objective registration policies;
  • to act efficiently with regard to time and cost;
  • to act responsibly and lawfully;
  • to operate with technical competence;
  • to abide by relevant Privacy and Data Protection laws.

5. Benefits for ccTLD registries from following the Best Practice document

Providing a sign of service quality, which immediately identifies the registry as operating in a fair, open, efficient and transparent manner for the benefit of the Local Internet Community.

Being accepted as responsible operator by other registries, ICANN and the Global and Local Internet Communities by following and contributing to self-regulation principles essential to the functioning of the Internet.

To be recognized as operating under the law of the territory the ccTLD designates and therefore representing the interests of the Local Internet Community with regard to Domain Names.

II  BEST PRACTICE GUIDELINES

1. Definitions

1.1 ccTLD - A country code top level domain in the top level of the global domain name system, assigned according to the two-letter codes in the ISO 3166-1 standard codes for the representation of names of countries or territories.

1.2 ccTLD Registry - The entity which records names as domain names in a register of domain names for the country-code top level domain name, according to policies and rules, and following procedures, established with the Local Internet Community (see below).

1.3 ccTLD Manager - A company, organisation or individual managing a ccTLD Registry.

1.4 DNS – The Domain Name System (see RFCs 1031 and 1035)

1.5 Registrant - A company, organisation or individual for whom a name has been registered as a domain name in the ccTLD domain name register.

1.6 ICANN - Internet Corporation for Assigned Names and Numbers.

1.7 IANA - Internet Assigned Numbers Authority (incorporated into ICANN in 1999).

1.8 Local Internet Community - The Internet industry and users and the government and authorities of the state or territory with which the ccTLD is associated. The definition of the Local Internet Community may vary from one country/territory to another, and is essentially a matter for the community in the country/territory.

2. Best Practice

2.1 Duties of ccTLD Managers

The primary duty of the ccTLD Manager is one of Public Service, and to manage and operate the ccTLD Registry in the interest of and in consultation with the Local Internet Community.

ccTLD Managers are entrusted with the management of the TLD Registry. A ccTLD Manager has no interest in the intellectual or other property rights in names registered as domain names or as part of domain names.

No intellectual or other property rights in the 2-character code accrue to a ccTLD Manager as a result of the act of delegation of the responsibility for a ccTLD Registry. ccTLD Managers may have rights to the intellectual and other property developed by them as a by-product of managing the ccTLD Registry, subsequent to the delegation of such responsibility.

2.2 Process to Define the Local Internet Community

A ccTLD Manager should design and organise a process to delineate the Local Internet Community. This process should be transparent, documented and be made available for public inspection.

2.3 Registration of Domain Names

2.3.1 ccTLD Managers must:

  • register domain names in an efficient and timely manner and follow policies, rules and procedures that have been established and published in a transparent manner in consultation with the Local Internet Community;
  • must collect the necessary information to ensure that the Registrant can be authoritatively identified.

2.3.2 ccTLD Managers should:

  • have a standard contract with Registrants;
  • recognise that a ccTLD Registry is a special function and, resulting from this, has a special position which should not be abused.
2.4 Registrant Policies

The ccTLD Manager must be equitable and fair to all eligible registrants that request domain names. Policies defining which organisations, businesses, individuals, etc.. are eligible to register domain names under the 2-character ccTLD must be defined by the ccTLD Manager in consultation with the Local Internet Community. Specifically, the registration of domain names should be based on objective criteria that are transparent and non-discriminatory. Policies and procedures may vary from country to country due to local customs, cultural values, local policies and objectives, law and regulations. The definition must be documented, available for public inspection, and transparent to the Local Internet Community.

2.5 Location

The ccTLD Manager, in consultation with and unless agreed otherwise with the Local Internet Community, and consistent with the requirement to best serve the interests of the Local Internet Community, should be resident in the territory of the ccTLD and, if the ccTLD Manager is a corporation, the ccTLD Manager should be incorporated there.

2.6 Technical Requirements

The ccTLD Manager supervises the process of registration of domain names in the registry of the ccTLD, and supervises the operation of the domain name servers and the maintenance of the appropriate zone files for the ccTLD. There must be permanent (24 hours, 7 per day) Internet Protocol (IP) connectivity to at least two name servers and the registry servers. There should be published e-mail and web address contacts, and these should be permanently accessible.

The ccTLD Manager must do a satisfactory job of supervising the operation of the DNS service for the TLD. Duties such as the assignment of domain names, delegation of sub-domains and operation of name servers must be done with technical competence (see RFC 2181). This includes keeping the IANA or other higher-level domain manager advised of the status of the domain, responding to requests in a timely manner, and operating the database with accuracy, robustness, and resilience (see RFC 1591 and ICP 1).

2.7 Changes to Information in the Register Database of IANA (other than a change of ccTLD Manager)

The ccTLD Manager must inform IANA, in a timely manner, of changes to the information that is maintained in IANA's register database. Notification of changes must be authorised by the Contact Person as specified in the register database. Changes to the Contact Person must be by an authorised member of the board or executive of the ccTLD Manager. Changes to the ccTLD Manager are outside the scope of the Best Practices document.

2.8 Financial Basis of ccTLD Manager Operations

ccTLD Managers should operate on a cost effective, cost recovery, basis, unless otherwise explicitly agreed with the Local Internet Community.

2.9 Subcontracting of Operations

Unless otherwise agreed with the Local Internet Community, a ccTLD Manager may contract out, on an "arms length" competitive basis, any or all of the operation and administration of a ccTLD Registry, provided that the ccTLD Manager contractually obliges the sub-contractor to comply with the requirements of this document.

2.10 Data Security

ccTLD Managers must take all reasonable professional measures to ensure that all Registry data is secured against damage or loss.

2.11 Domain Name Dispute Resolution

ccTLD Managers should define and publish their domain name dispute resolution policies and procedures, in consultation with the Local Internet Community.

Mechanisms should be established by the ccTLD Manager to handle fairly and independently any such disputes arising between registrants, or other parties, and the ccTLD Manager.

Making judgements in relation to disputes arising between third parties and domain name registrants are outside the remit of the ccTLD Manager.

3. Governing Law

ccTLD Managers will operate under the law of the country or territory where they are located. The relationship between Registrants and the ccTLD Manager (whether by explicit contract or otherwise) must be governed by the law of the country or territory of the ccTLD.

III PROCESS FOR CHANGING BEST PRACTICE GUIDELINES

1. Receiving Input

1.1 Comments and suggestions for change are to be initially submitted either to the CENTR Secretariat or to the L & R Group.

1.2 The CENTR Website (http://www.centr.org/) will publish for those outside of CENTR, an e-mail address where comments may be sent. Comments received will be reviewed by the L & R Group prior to recommendation to the General Assembly.

1.3 The CENTR Secretariat will ensure that the General Assembly is aware of all requests for change.

2. Processing Input

2.1 Small changes will be handled by the CENTR Secretariat, who will compose a draft wording for the proposed amendment (where this has not been done by the proposer). This will be submitted to the L & R Group, together with the original request for change, within one week of receipt.

2.2 Where substantial changes are requested, the CENTR Secretariat will notify the request to the L & R group who may form a small sub-group to work on a revised text. The L & R Group or a sub-group, if formed, then act as the Drafting Committee.

2.3 The Drafting Committee, will set work schedules and target deadlines for the production of amended drafts.

2.4 The Drafting Committee will invite the Originator of the request for change to participate in the drafting, if appropriate. If a request for change involves technical aspects of the Best Practice document participation from the CENTR Technical Group will also be sought.

2.5 Upon completion of a draft amendment by the Drafting Committee, the CENTR Secretariat will submit the draft to the full L & R Group, and the Originator. A period of 14 days will be allowed for comment and adjustments.

3. Seeking General Assembly Approval

3.1 Final draft texts and any L & R Group recommendations will be circulated to the General Assembly by the CENTR Secretariat together with the original request and Originator’s comments on the final draft.

3.2 Member registries will be asked to consult with their respective boards regarding the proposed change, in advance of a full debate. A vote will be conducted at the next appropriate General Assembly meeting.

3.3 No changes will be made to the Best Practice document without the provision of adequate notice to members of the proposed new wording and the proposed vote.

3.4 The General Assembly may request that the L & R Group make changes to the text for re-submission to the General Assembly for approval.

3.5 Changes to the Best Practice document will only be made where a two thirds majority of members vote in favour of its acceptance.

4. Notifying the Originator of the Outcome

4.1 The Secretariat will notify the outcome of the vote to the Originator of any request for change.

REFERENCES

[1]  http://www.isoc.org/isoc/mission/principles/
[2]  http://www.icann.org/general/white-paper-05jun98.htm
[3]  http://www.iana.org/cctld/icp1.htm


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

.

Page Updated 16-Dec-2001
©2001  The Internet Corporation for Assigned Names and Numbers. All rights reserved.