Staff Manager's Issue Report on the Need for a Predictable Procedure for Changes in the Operation of TLD Registries
19 November 2003
Updated 2 December 2003
To send comments to the editor of this report, please email <email@example.com>.
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
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.
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.
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.
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:
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
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:
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
To send comments to the editor of this report, please email <firstname.lastname@example.org>.