Introduction

One of the IANA functions that ICANN performs is to keep the root-zone up to date and maintain the authoritative Whois database for generic top-level domains (gTLDs) and country code top-level domains (ccTLDs). The following information is provided with the goal of assisting the Internet community to understand the process that is followed in addressing requests to add/change information in the root-zone and/or in the authoritative Whois database. Collectively, the end result of the processing of these requests is referred to as "Root Management". These requests include the following:

• Primary nameserver changes
• Secondary nameserver changes
• Change of administrative and technical contact
• Change of data for the sponsoring organization, administrative Contact, and technical Contact
• Change of data for the URL for registration services and port 80 whois server
• Redelegations of oversight and management authority for TLDs

The processes outlined below are those currently being followed. ICANN intends to continue to review and improve these processes as possible. We also intend to consult with the appropriate communities for input on further improving these processes.

Process for IANA Root Management Requests

The following flow chart shows the processing of requests, with each field explained in further detail below.

Flow Chart

Receive Request - Request received to make changes to the root-zone and/or the authoritative Whois database.

Confirm Receipt of request and assign transaction number - Confirmation of receipt of the request is sent and a transaction number in the format of ROOT-MGMT#YYYYMMDDNNN is assigned.

Review Request - The request is reviewed to determine the nature of the request, and clarification will be requested from the TLD manager if there are any points needing further explanation to understand the request.

Confirmation Process - After the request has been reviewed and the details of the changes determined, the administrative and technical contacts are sent communications seeking confirmation of the accuracy and legitimacy of the request.

DoC Confirmation if applicable - After all relevant communications to authenticate the request are received, the request is submitted to the United States Department of Commerce if the changes requested require DoC confirmation, according to <http://www.icann.org/general/iana-contract-17mar03.htm>.

Implement Changes - After all necessary confirmations are received and technical checks are performed, the changes are implemented in the IANA database and VeriSign will implement nameserver changes in the root-zone, according to <http://www.icann.org/nsi/coopagmt-amend11-07oct98.htm>.

Confirm with requestor when completed - After the changes have been completed, the administrative and technical contacts are notified.

There are additional steps that are not described above which are followed during the processing of a redelegation. Please see the ccTLD Redelegation Step-by-Step Overview for information.

Metrics for Processing Times

The following is a table that displays the goal processing times for steps in Root Management requests. The following goals are given in business days for ICANN, excluding weekends and respective holidays.

IANA Metrics Table

Days to complete - Index

0 - Same day

1 - Day after request was received

2 - 2 days after request was received

Areas Outside ICANN's Control

There are steps over which ICANN has no control over processing times. ICANN cannot progress the processing of a request until all necessary information has been received. In addition, there are third-parties (the DoC and VeriSign) who must act and the timeframes for their action are outside of ICANN's control.

• Receiving confirmations from the appropriate contacts - A confirmation is requested from the relevant contacts for the top-level domain, and there may be delays in response times from the contacts.
• Confirmation from DoC - A confirmation from the United States Department of Commerce is sometimes necessary to process changes.
• Implementation - VeriSign will implement nameserver changes in the root-zone only after approval has been received.

Areas where ICANN may experience delays

• Review of Request - The submission is reviewed to determine the details of the changes being requested. It is sometimes necessary to request more information or clarification about the details of the request from the administrative and technical contacts. The contacts must respond promptly in order for a request to be processed in a timely manner. Clarification of a request may take multiple communications with the contacts to make sure that the requested changes are clearly articulated and understood by all parties.
  
  Unclear or ambiguous requests for changes in nameserver and contact information can result in significant delays in the overall processing times of requests. Those requesting changes are encouraged to be as specific and detailed as possible so that there is less possibility for misinterpretation in reviewing the changes.
  
  
• Technical Check - Before any nameserver changes are submitted, necessary technical checks are performed to make sure the nameservers are operational and ready. If an issue arises during the technical check, the contacts are informed and the issues are reviewed. Once the problem is resolved, the changes are submitted. The contacts must respond to any inquiries about technical issues so that the request can be processed in a timely manner.

The IANA database is authoritative for contact information for the gTLD and ccTLD managers. Managers must inform the IANA of any changes regarding nameserver information or database changes for a top-level domain. This includes all contact details, including contact names, phone numbers, fax numbers, e-mail addresses, etc. ICANN relies on ccTLD and gTLD managers to submit changes to their contact information so that it is accurately reflected in the IANA database.

The IANA function goes through a review of the information to ensure that it is a valid request, that is, authenticating the request, and that the administrative and technical contacts are in agreement with the changes. Should there be a dispute, the IANA function seeks to have the parties resolve it amongst themselves. In cases of a redelegation, the ICANN follows the procedures listed in the step-by-step, found at: <http://www.iana.org/cctld/redelegation-overview-09jul05.htm>.

Focus on Improvements

ICANN is currently researching techniques in effort to improve processes. These include:

• Web-based Templates
• Workflow software
• Alternative or additional authentication methods

ICANN intends to consult with the appropriate communities for input on improvements designed for use in conjunction with third parties.

Future additions to this page

The purpose of providing this information is to assist the Internet community in understanding the procedures used for Root Management requests. As progress is made in improving the areas described above, we intend to update this document accordingly. We will continue to consult with the appropriate communities to identify areas and suggestions for improvement as well as any implementation of new workflow systems. Types of additional information that may be added to this document could include:

• Improvements and/or changes to procedures
• Frequently Asked Questions (FAQs)

In addition to the above, the IANA will endeavor to provide statistical information on actual processing times.

Useful Links for information:

General ccTLD information
General gTLD information
IANA ccTLD Database