World Wide Alliance of Top Level Domain-names

ccTLD ICANN Meetings in Shanghai

 Home | Meetings | AdCom | ccTLD | Participants 

Draft document cc-IANA v.2.0

Presented at Shanghai meeting by William Black
29 October 2002

Project to Define a cc-IANA

Background

Members of the World Wide Alliance of CCTLD Managers present at the ICANN meeting in Shanghai agreed, on 29 October to establish a working group to develop a project plan for the establishment of independent management of the DNS root entries and database entries by the cc Top Level Domain Managers.

It is expected that this plan will be developed in parallel with the continuing work of the CCNSO Assistance Group, on the establishment of a CCTLD Supporting Organisation within a reformed ICANN.

The cc Top Level Domain Managers in Shanghai consider that in the interests of stability of the DNS the project plan should be ;

  1. made available to the ICANN Board ERC prior to the ICANN 2002 Annual Meeting in Amsterdam and Board Meeting on 14 -15 December, for consideration as part of the implementation of the 'steady-state' future of ICANN; and

  2. in any event distributed on the World Wide Alliance of CCTLD Managers' list, as a basis for further discussion concerning the stable functioning of the DNS root name server system.

It is antipicated that the World Wide Alliance of CCTLD Managers project will be developed well into 2003 as the recommendations of the project are reviewed by the community

Outline Proposal

It is proposed that the ccTLD community initiate a project, which will lead to the independent management of the DNS root entries and definitive database of designated ccTLD managers (individual or organizations - the term "manager" is used throughout for both although it is believed that the majority of ccTLDs are now managed by an organization rather than an individual).

This combined database will be managed by the existing ccTLD regional organizations: CENTR, APTLD, AFTLD and LACTLD. It will contain only entries for those ccTLDs wishing to participate - the others being maintained in the status quo until either they decide to participate or until another mechanism is available to them.

Critically, the success of this project will be measured by the number of "substantial" ccTLDs who choose voluntarily to participate and subsequently by the acceptability of the solution to their respective local Internet communities and governments.

Three aspects of the problem need to be addressed:

  1. Technical Aspects
  2. There is a requirement to define a suitable database schema to contain the records for each participating ccTLD. It is suggested that, as a minimum, the database records:

    A further technical requirement is to have a documented set of procedures to be followed by a ccTLD manager when requiring a change to its database entry and the service level to be expected from the servicing organization.

    Lastly, the servicing organization will need to generate (from the above database) zone file entries for the participating ccTLDs for merging into the A-Root server in a timely basis; and also appropriate extracts to be available on a web site and WHOIS server. The specific information to be made public must be clearly documented. Clearly it might not be appropriate to publish the anti-spoofing mechanisms!

    The first aim of the proposed project is to document these technical aspects.

  3. Legal Aspects
  4. In order to be effective, the participating ccTLDs and the servicing organization(s) must be bound by some form of contract (or memorandum of understanding). The participants must be convinced that, by being part of this agreement, it will bring stability, reliability and added value. The contract should be as lightweight as possible, should permit the widest possible set of models for the operation of ccTLDs without artificial or cultural constraints. There is no role for such a servicing organization in defining policies for the operation of a ccTLD, which are exclusively the responsibility of the local Internet communities and governments concerned. Any policies of the servicing organisation must only be those minimal ones required to operate the root servers effectively.

    The key points of the contract should include the following.

    The second aim of the proposed project is to refine and document this contract in a legally acceptable way.

  5. Political Aspects
  6. Even with an agreed technical plan and procedures, and with a set of contracts between the (majority) of ccTLDs and service organization(s), nothing will be effective unless the maintainers of the A-root server are instructed to reflect the changes made by a manager in the database maintained by its service organization. The A-root server maintainers (quite reasonably) are only prepared at present to accept the authority of the US Department of Commerce.

    If this project is to be successful, the support is required from the relevant governments. They need to have confidence that the proposed technical mechanisms and legal/contractual basis will be effective. They also need to be assured that they will maintain stability of the DNS root, introduce no barrier to local public policy making within the ccTLD and that they can persuade the US to accept the entries as authoritative for the ccTLDs prepared to enter into the contractual basis.

    The US Department of Commerce, from its side, needs to have these same assurances and the firm acceptance of the other respective governments that they should accept these entries as authoritative.

    The third aim of this project is to carry out the necessary consultations with the ICANN Government Advisory Committee members and the US Department of Commerce to achieve their acceptance.

Implementation

This project aims to prepare the above materials and carry out the appropriate consultations. It follows that, if accepted by many ccTLDs, appropriate service organizations need to be identified. It is envisaged the regional organizations might offer to do this under the co-ordination of a suitable administrative committee drawn from each.

 


© ccTLD Managers
Page updated : 2003-05-26 17:41:50