ICANN|ARCHIVES

Internet Corporation for Assigned Names and Numbers

To send comments to the editor of this report, please email <pdp-reports@icann.org>.

Introduction
Current Procedure for Changes in the Operation of TLD Registries
Requirements for a New Procedure
Recommendations to the GNSO
Compliance with Bylaw Requirements
Constituency Comments on this Report
Frequently Asked Questions (FAQs) About the Policy Development Process (PDP) on Development of Predictable Procedure for Consideration of Proposals for Contractual Approvals or Amendments NEW

Introduction

The ICANN community, and the Internet community at large have expressed interest in the process for consideration of changes in the operation of a TLD registry. The opinions expressed indicate that there be a predictable process prior to implementation of such changes that allows for an assessment of the potential effect on Internet operations, with due consideration given to all relevant factors - including the legitimate interests of the TLD operator.

In recognition of these concerns, Paul Twomey, President and CEO of ICANN, requested of Bruce Tonkin, Chair of the GNSO, that the GNSO initiate a Policy Development Process (PDP) designed to produce recommendations to the ICANN Board for a timely, transparent and predictable process prior to significant actions by TLD registries that, because of their architecture or operation, could affect the operational stability, reliability, security or global interoperability of the DNS, that registry, or the Internet.

At its 16 October 2003 meeting, the GNSO Council voted to request that the staff prepare an issue report under the GNSO PDP. The topic to be considered in the PDP is "the need for a predictable procedure for the introduction of new Registry Services (as defined in the gtld registry agreements)," but as discussed in more detail below, that is probably an unnecessarily narrow statement of the relevant issue. In response to this request, the Staff Manager consulted with the GNSO constituencies and on 31 October posted a Preliminary Catalog of Issues. Subsequently, the GNSO constituencies were offered an opportunity to submit additional statements, which several constituencies submitted on 7 and 10 November. This issue report was slightly delayed so those statements and other considerations could be considered.

Current Procedure for Changes in the Operation of TLD Registries

ICANN has agreements with registry operators (for unsponsored TLDs) and sponsors (for sponsored TLDs). In the agreements, ICANN designates the operator (or sponsor) as the sole operator (or sponsoring organization) for the TLD. In exchange, the operator or sponsor agrees that the TLD registry will be operated according to various specifications, policies, and other requirements. These agreements constrain the freedom of a TLD registry or sponsor to make changes in the architecture or operation of the registry that would not conform with those agreements, absent ICANN's prior consent. ICANN has agreed that it will not unreasonably withhold or delay this consent.

Among other constraints, unsponsored registry operators have agreed that they will not introduce new for-fee "registry services" except upon establishment of a maximum price for the new service with ICANN's written consent. "Registry services, "as defined by the agreements, are services provided as an integral part of the TLD's registry, such as operation of the Registry TLD zone servers and other services which the registry operator can only provide by virtue of its designation by ICANN as the sole operator of the registry.

Historically, these issues have been dealt with informally, in the following way. The registry operator or sponsor informs ICANN that it wishes to change the operation of the TLD registry in some way. ICANN staff performs an initial review of whether the proposed change requires ICANN approval or a modification of the relevant TLD agreement. Depending on the result of this review, the request is handled in one of several different ways.

If the proposed change is consistent with their contractual requirements (and does not require approval), ICANN staff notifies the registry operator or sponsor that the registry is entitled to go forward with implementation of the proposed change without further review.

If the proposed change is inconsistent with the contractual requirements (or the contract requires approval), the matter has been handled in a variety of ways, depending on whether the proposal appeared to raise significant issues or concerns. If it did not raise such concerns, the registry operator or sponsor would work with ICANN staff to procure the contractual approval or changes. If it did appear to raise issues, those issues would be dealt with in an appropriate process.

To facilitate compliance with the guideline in several of the unsponsored TLD agreements that approval of new for-fee services should, in ordinary circumstances, not take longer than 30 days, ICANN has developed a "quick look" procedure. (To minimize the time for action on requests for changes in general, this "quick look" procedure is currently applied to requests concerning all TLDs and for all proposed actions that would require modifications of contractual language.) Under the "quick look" procedure, ICANN staff makes an initial determination whether the change is likely to harm the legitimate interests of third parties, to threaten stability or security, or to contravene any existing ICANN policy. If not, ICANN takes the appropriate steps without further evaluation to give written approval or to adjust the contractual provisions. If, however, there appears to be a likelihood of harm to legitimate interests of third parties, a threat to stability, reliability, or security, or the proposed action is inconsistent with an existing ICANN policy, a more thorough scrutiny is conducted. In the past, this has included requests for reactions to the proposal by the GNSO and other affected groups.

There are three principal, yet often competing, considerations involved in evaluating these kinds of proposed actions by registry operators or sponsors. One consideration, of particular interest to the technical community, is whether it is plausible that the legitimate interests of others could be harmed by the proposed change. Harm has many meanings in an interoperable Internet, and may include elements such as the "Principle of Least Astonishment" when introducing change to the DNS, and concerns about shifting the burden of cost onto other Internet participants as a result of the registry change. These questions of harm, and some others, may be addressed through consultation with the relevant parties, and seeking an appropriate timeline for the introduction of the new or modified service. In some instances the change requested may exceed the acceptable limits of harm to others altogether.

A second consideration is that delays in the consideration process could result in barriers to changes and innovation at the TLD registry level. Certain changes, such as the adoption of Internationalized Domain Names (IDN) at the core, will benefit the global Internet community and promote interoperability. Another aspect in the consideration of such changes is that prohibiting or delaying new services at the core while allowing them at all other points of the Internet might disadvantage registry operators in the growth of their businesses. In some cases, not approving a new service at the registry level may produce more challenges to Internet interoperability and functionality than approving it.

A third and critical consideration is whether the change proposed is tied to the registry operator's sole-source status with regard to the registry. There is an inherent monopoly power in the operation of any TLD registry. New products or services, and some other changes in the operation of the registry, may amount to an extension of that market or monopoly power. For this reason, an analysis of the competitive effects of such changes is essential. There are no doubt cases where the change would be beneficial, even where it is dependent upon the monopoly operation of the registry for its effective operation. The offering of IDN character sets is a good example. There are also undoubtedly situations where the net effects of the proposed change would be harmful, either by eliminating competition with no offsetting redeeming value or by imposing unnecessary costs on those downstream that rely on the stable operation of the TLD.
The responsibility for reviewing registry requests has historically been placed initially on the President and the staff, who act under the guidance of ICANN's policies and the supervision of the Board of Directors. Objections to particular staff actions may be reviewed by various mechanisms including the reconsideration process and, in the case of the registry that is a party to the contract involved, a contractually agreed dispute resolution process.

Requirements for a New Procedure

The current procedure could be substantially improved - in terms of both clarity and predictability. The diverse characteristics of new or modified services that have been subject to the existing procedure have led to different results for different requests, without a clear articulation of the reasons for each decision.
Another area for potential improvement is the speed with which decisions can be made. Registry operators and other stakeholders deserve a clear and predictable schedule for the evaluation of proposed changes. Additionally, a timeline for an appeals procedure (reconsideration or dispute resolution) will provide a limit-point on the amount of time a registry operator (or sponsor) must invest in completing the approval process.

In their consultations with the Staff Manager, registry operators and sponsors have emphasized the need for the evaluation procedure to accord an appropriate degree of confidentiality to their proposals, to prevent unnecessary and premature disclosures of proprietary commercial information to their competitors.

Additionally, the unsponsored registry operators have noted the need to account for contractual agreements in the development of the evaluation procedure.

The registrar community has expressed concern that the evaluation procedure should include registrar consultation where a proposed new sole-source registry service might displace services provided on a competitive basis at the registrar level.

Several user constituencies have noted that their members' interests can be adversely affected by changes to the existing operation of a TLD registry. They have emphasized their desire to be heard concerning evaluation of such changes that are likely to have these adverse effects.

The considerations arising in the evaluation procedure (see the discussion in the preceding section) can raise issues that are outside the scope of ICANN staff expertise. To ensure that appropriate expertise is available in the evaluation, the process should allow ICANN staff to obtain qualified outside expertise, including through consultation with competition and technical experts.

Recommendations to the GNSO

PDP Should be Initiated

In view of the analysis above it is the recommendation of the Staff Manager that the GNSO initiate a PDP to develop a policy to guide the establishment of a predictable procedure for ICANN's consideration of proposals by registry operators and sponsors for changes in the architecture or operation of a gTLD registry. This formulation of the issue to be addressed in the PDP is based upon the 16 October 2003 decision of the GNSO Council that the topic of the PDP should be "the need for a predictable procedure for introduction of new Registry Services (as defined in the gTLD registry agreements)." It is adjusted to reflect the reality that proposed changes may include but are not limited to things that could be called "services" or "products," and that any proposed changes that could have the effects described should be subject to an appropriate consideration process.

The goal of the PDP should be the creation of a policy concerning the essential characteristics of the process by which ICANN considers registry operator or sponsor requests for contract changes and approvals to allow changes in the operation of TLD registries. The policy should focus on high-level guidance to ensure that ICANN's procedure is appropriately responsive and predictable, and achieves other core values. Developing a detailed administrative process according to this policy guidance will be the responsibility of the President.

To achieve this goal, the PDP should gather sufficient information and opinion from the ICANN community regarding characteristics of the procedure that are considered essential to ensure that it adequately addresses the various and competing tensions inherent in such changes, according to ICANN's core values and consistent with contractual requirements.

Sub-Issues to be Considered Initially

In identifying the essential characteristics of the procedure, it may be useful to begin by addressing the problems with the current procedure perceived by various segments of the community, as described above in the "Perceived Problems with the Current Procedure." These perceived problems allow the formulation of several sub-issues, which should receive early consideration in the PDP:

1. Documentation of the procedure.
   To make the procedure predictable, it should be documented in a way that is easily accessible to registry operators and sponsors, to GNSO constituencies, and to all other affected parties. The evaluation of registry requests calls for application of a set of policies concerning diverse topics and consideration of request-specific circumstances which call for nuanced decision making at points in the procedure. Nonetheless, the documentation of the procedure should identify the decision-points, the officials responsible for making the decisions, the time at which they will be made, and the significance of the decisions in the overall process-flow of the procedure.
2. Documentation of actions on particular registry requests.
   The predictability of, and public confidence in, ICANN's evaluation of registry requests will be enhanced by publication of ICANN's actions on particular registry requests, including the rationale for the actions. Intermediate decisions in the evaluation process should be published before final action where relevant to formulation of input by GNSO constituencies or other affected groups. Publication of decisions should be done in a way that gives due regard for appropriate assertions of confidentiality.
3. Timelines for acting on requests, and for review of actions (including "quick look" procedure for non-controversial requests).
   As noted above, ICANN's agreements with some unsponsored TLD operators state that ICANN will ordinarily act on some types of registry operator requests within 30 days. ICANN's goal is to act with speed, responsive to the Internet's needs, and consistent with obtaining input as necessary from those affected. Although there can be tension between acting quickly and obtaining full consultation, the best balance between these values can be obtained by conducting an initial "quick look" analysis to identify whether a request involves likely harm to the legitimate interests of third parties, a threat to stability or security, or implicates a violation of an existing ICANN policy. Requests not involving that likelihood should receive prompt action, so that ICANN acts on ordinary requests within 30 days. Other requests justify a more thorough evaluation or consultation, including with affected parties.
4. Measures to preserve proprietary information in requests prior to approval, in appropriate circumstances.
   ICANN's Bylaws provide that "ICANN and its constituent bodies shall operate to the maximum extent feasible in an open and transparent manner and consistent with procedures designed to ensure fairness." (Bylaws Article III, §1) Requests by registry operators and sponsors, or information they submit in support of their requests, at times involve proprietary information. In order to assure fairness to registry operators, the evaluation process should provide for appropriate procedures for confidential treatment, so that registry operators and sponsors are not required unnecessarily to disclose legitimately proprietary information to their competitors.
5. Procedures for consulting with experts in the evaluation process.
   As noted above, issues will often arise in the evaluation of registry requests that call for expert knowledge not possessed by ICANN staff, involving such disciplines as engineering or competition matters. The procedure of evaluation of registry requests should provide a mechanism for ICANN to receive expert advice in these situations, while providing safeguards to ensure that the advisors are impartial.
6. Procedures for learning the views of affected GNSO constituencies, as well as affected groups outside the GNSO.
   In the case of registry requests that are determined in the "quick look" (see sub-issue 3 above), to involve a likelihood of significant third-party harm, a threat to stability or security, or a violation of existing ICANN policy, there should be consultation with significantly affected entities. (See Core Value 9.) The procedure should provide a clearly documented way of conducting this consultation, with those consulted receiving background information as needed to give informed input for ICANN's consideration.

Other Suggested Procedures for PDP

Under the GNSO Policy Development Process the GNSO Council is responsible for deciding whether to initiate a PDP as described in this report. Under item 4 of the PDP, at the same meeting the Council should prescribe one of two mechanisms for proceeding with the PDP. One alternative is to appoint a task force consisting of a stated number of representatives from each constituency (and possibly outside advisors) which then is required to follow a prescribed process and schedule for gathering constituency positions and other information to be included in a formal task force report. The second alternative is to proceed without a task force, in which case each constituency appoints a representative to gather constituency views and provide them to the Staff Manager for inclusion, along with other information, in a report, which is submitted to the Council.

The Staff Manager recommends that the second, more flexible approach be followed for this PDP. The added flexibility should assist in including the input of other groups (such as the Advisory Committees and outside experts) in the GNSO's process; should facilitate closer cooperation with the ICANN staff to ensure that the policy guidance meets the staff's administrative needs; and should promote timely and successful completion of the PDP, particularly given the upcoming holiday season.

The Staff Manager recommends that the PDP should be divided into phases, with each phase devoted to a separable aspect of the information gathering process. Each phase would begin with preparation of a document by the staff, for consideration and comment by the constituencies (and, as desired, advisory committees) acting through their representatives. This process would begin with consideration of the material included above under "Sub-Issues to be Considered Initially," and then proceed in a narrowing fashion to consideration of other documents. Subject to the Council's views, these documents might include:

1) Sub-Issues (see above)
2) General Counsel's statement re: ICANN role under agreements
3) Requirements and Process for obtaining expert advice
4) Statement of process flow
5) Final Report

Compliance with Bylaw Requirements

In compliance with the requirements for Issue Reports in Appendix A of the ICANN Bylaws, the specific requirements as laid out in Section 2 are hereby addressed:

1. The issue raised for consideration is the development of a policy to guide the establishment of a predictable procedure for ICANN's consideration of proposals by registry operators and sponsors for contractual approvals or amendments to allow changes in the architecture or operation of a TLD registry. Sub-issues to be considered are discussed under "Issues to be addressed by the PDP" above.
2. The issue was submitted for Paul Twomey, President and CEO of ICANN.
3. The ICANN President is responsible for directing the staff in implementing ICANN policies. Having policy guidance for the establishment of a clear and well-documented procedure for handling such requests by registries would provide staff with the guidance in fulfilling this responsibility.
4. Support for the issue has been expressed through discussions with GNSO constituencies, as well as on mailing lists and other venues. See the discussion above.
5. The Staff Manager's Recommendation is to initiate the PDP on the issue stated above. General Counsel affirms that it is within the scope of the ICANN policy process and within the scope of the GNSO:
   1. Having policy guidance for the establishment of a predictable and well-documented procedure for evaluating such requests for changes in the architecture or operation of a TLD registry will allow for their more orderly handling, which will enhance the operational stability, reliability, security and global interoperability the Internet. This is, of course, the principal mission of ICANN. As set forth in our Bylaws,
   
   

   The mission of The Internet Corporation for Assigned Names and Numbers ("ICANN") is to coordinate, at the overall level, the global Internet's systems of unique identifiers, and in particular to ensure the stable and secure operation of the Internet's unique identifier systems

   2. The policy will govern the establishment of a predictable and well-documented procedure for evaluating such requests, which will affect multiple registries and have implications for the entire ICANN community.
   3. This policy will have lasting value to the ICANN community by providing long-term guidance for the procedures to be followed in handling such registry requests.
   4. This policy will allow implementation of a documented administrative procedure for making decisions on such requests by registries.
   5. As reflected in its core values, ICANN's policies call for it to make decisions according to its policies in a neutral, objective, informal, transparent, and timely manner. Documentation of the procedure for handling such registry requests, based on the policy guidance that this PDP is intended to provide, will give enhanced effect to those core values. This Issue Report is presented as completion of this item.

Constituency Comments on this Report

ALAC Preliminary Statement

Intellectual Property Constituency Statement

Internet Service & Connection Providers Constituency Statement

Unofficial Registrars Constituency Statement

Unsponsored Registries Statement

To send comments to the editor of this report, please email <pdp-reports@icann.org>.