CBUC statement Approval process for gTLD service change Updated version

CBUC statement Approval process for gTLD service change

Updated version

20 February 2004

Commercial and Business Users Constituency position on "Procedure for use by ICANN in considering requests for consent and related contractual amendments to allow changes in the architecture or operation of a gTLD registry."

Version 6

Introduction

In the latter half of 2003, registry operators introduced new registry services at the registry level of the domain name system (DNS) without notice to Internet users.

The Internet Community has called for a defined, predictable process for the consideration of new services or other such changes in the architecture or operation of a gTLD registry prior to any changes being introduced. The Commercial and Business User Constituency (BC) supports this call wholeheartedly.

Commercial and Business User Interest

Stability and security of the DNS core of the Internet provides the platform for innovation

Business users are today engaged in building, networks, services and applications at the "edge" of the DNS. Reliable, stable and predictable operation of the DNS is essential to the stability and security of the Internet, and to the ability of businesses, regardless of their size, to innovate in services and applications and to use the Internet.

The DNS is reliable, when it operates according to the technical protocols that guide its functioning, but it is vulnerable, when someone purposely or accidentally violates these operational assumptions. The Internet purposefully has a distributed architecture. Largely, innovation originates and belongs at the edge of the Internet, not at the core. Introducing abrupt changes into the core of the DNS creates an unpredictability which directly threatens the Internet's stability.

The Internet is essential to the way the world communicates today

Today, over half a billion users are on the Internet; and there are already close to 200 million hosts that are largely provided by enterprises, including BC members. As important as the Internet has become already to communications and information access, its full value is only beginning to emerge. Increasingly, the Internet is an infrastructure that is relied upon for information and transactions by NGOs, enterprises, individuals and governments.

The registry monopoly brings rewards and responsibilities

Registry functions are a small, but critical part of the core infrastructure of the global Internet. They are one of the elements where stable operation is key, so that other functions can operate reliably. The gTLD registry operations are the result of a contract award by ICANN to a single entity to manage the registry service for a single generic TLD. Such awards are a "natural monopoly": monopoly status brings specific responsibilities, benefits and certain limitations.

Therefore, the BC supports the need for a clear, defined process to determine whether, when, and how new registry services may be introduced, and what notice and remedy may be necessary.

The rational for an ICANN policy in this area

ICANN's by-laws tell us its stated mission is "in particular to ensure the stable and secure operation of the Internet's unique identifier systems." Improperly managed change to these systems disrupts this stable and secure operation.

ICANN, as an international body, is responsible for the framework for policy development governing the gTLD registries and provides and enforces the contracts that allocate the responsibility of operating a registry service for the gTLDs. Of particular importance is the recognition that registries are not necessarily the most affected parties by changes in their operation.

ICANN facilitates consensus. A stable and secure Internet to date results from the established practice that changes that will affect the operational reliability of the DNS take place only after extensive discussion within the Internet technical community, so that bugs can be worked out and a consensus can emerge for or against the change, including how to incorporate it across the Internet.

Initial recommendations

1. TOR. The GNSO task force Terms of Reference identify four main tasks. The BC have propose some modification to the Out-of-scope constraints of the TOR.
2. Notice is required. Registries wishing to introduce any new services which impact the core of the DNS should be required to provide notice, full technical and administrative description/explanation, and remedy opportunities in order for a proper assessment of impact.
3. Impact self-assessment is not sufficient. It is not sufficient for registries to self-determine whether a new service is compliant with existing contracts, nor whether a new service will impact the stable and secure operation of the Internet.
4. Streamlined, clear, documented and transparent procedures (while ensuring the ability to maintain any needed documented and needed confidentiality) for prior assessment of any changes are required.
5. Appeals. An appeals process should be available if the interpretations are considered to be too onerous or if the registry operator can demonstrate that there is no significant negative impact on the Internet by the proposed service.
6. Sponsored gTLDs. Sponsors have established mechanisms within their community of interest, similar to ICANN, to develop and consider changes in the architecture or operation of their gTLD. However, matters, which affect the Internet security and stability at-large are of essence for this PDP. Distinction may be required between new registry services in restricted/sponsored TLDs and unrestricted/unsponsored gTLDs.
7. Cost. Consideration must be given to costs and how they are to be funded.

Annex 1

Procedure for use by ICANN in considering requests for consent and related contractual amendments to allow changes in the architecture or operation of a gTLD registry

The GNSO Task Force Terms of Reference identifies four main tasks.

Detailed Recommendations

(1) Develop guidelines for when approval is required to make a change based on the existing registry agreements. (for action by ICANN staff in consultation with registry operators and sponsors)

Notice should always be given to the ICANN staff on the intent to introduce new registry services.

In those cases where the registry believes that its new service will have no or minimal impact on the Internet, a streamlined process can be followed. Documentation from the registry should be technically and administratively complete, sufficient to enable a rigorous assessment of the request, at the time of submission to ICANN.

ICANN should acknowledge receipt of the request for review within 3 business days, including advising the registry if more information will be needed, and within 10 business days of receipt of a request, should advise the registry of which timeline¹ will be followed - 30 day fast track, or 90 day assessment and consultation.

Explicit Approval must be sought when:

A) a gTLD registry's action is likely to:

1. violate an existing ICANN policy

2. violate or change an explicit or implicit, accepted, de-facto or de-jure, Internet protocol, standard, practice or assumption of operation

3. affect the operational stability of other widely used existing applications and services

4. affect applications and services across multiple organisational or market boundaries

5. replace multiple existing applications with a centralised single application

OR

B) a gTLD registry's database gives it substantial market power in the gTLD market [alternate: substitute "substantial market power" with a defined % market share, eg. "more than 20% market share of the gTLD DNS."

OR

C) a gTLD registry could expect that its actions would give rise to genuine technical, competition, or legal concerns.

(2) Develop a check list of issues to consider when approving a change

A check list of relevant issues should be developed during the PDP process.

(3) Develop a process and timeline for responding to a request including "quick-check" phase, and more comprehensive phase

The objective of the process should be to provide a predictable, timely and transparent (ultimately) process.

The registry decides to introduce a new service at the registry level:

1. a) submit a request for a quick-check approval

OR

b) submit a request for a full Internet Community review by ICANN

2. A quick-check request by a registry would have the characteristics of:

a) an expectation that it will be granted.

b) including sufficient information supporting the planned change such that ICANN staff and their retained experts can fully assess the implications of the planned changes such that they could give approval.

c) being conducted entirely in confidence between the registry and ICANN.

d) being accompanied by a fee sufficient to cover the cost of undertaking the quick-check (ie. a scale of fees may be set dependent on the nature of the planned change)

3. A quick-check would be undertaken by the ICANN staff using the expertise of retained international experts in the fields of technology, competition, law and international public policy. Depending on the complexity and potential impact of the planned change, a quick-check would be expected to be completed in:

a) 30 working days - for simple or straight forward change

b) 90 working days - for a complex change

4. At the conclusion of a quick-check a report of the staff/experts considerations, findings and conclusions will be provided to the requesting registry. If the conclusion is approval of the request, the process is complete. If the conclusion is rejection or recommendation for amendments to the planed changes, then the registry has the option of:

a) forgoing the planned change

b) undertaking and committing to the recommended amendments, then implementing the amended planed change once the amendments have been approved by ICANN staff, after confirmation with appropriate experts described above.

c) reconfiguring the planned change and requesting a completely new approval

d) requesting that ICANN undertake a policy review of the planned change

e) requesting that ICANN's independent review process be instigated

5.Should the registry seek an ICANN policy review then ICANN will seek to schedule such a review by the ICANN community at the earliest possible time. Such a review would be fully transparent and time bound (time to be determined during the PDP process. 120 days is suggested). In the case of a sponsored gTLD registry, it may be more appropriate for the policy to be taken back to the sponsor's community for reconsideration.

6.Should the registry seek a review by the ICANN independent review process (see below)

7. When a change in a gTLD registry's architecture or operations are implemented the report from the ICANN "quick chec" review must be posted on both the ICANN and registry's website. Such a report may have commercially confidential information expurgated, by mutual agreement between the registry and ICANN; however, the confidential information must be provided to ICNAN, and must be available for review and consideration by experts, should they be retained by ICANN. Such experts should sign appropriate non disclosure agreements related to that confidential information. (Should the SECSAC need to review such materials, a working group of the SECSAC can be convened, and can be provided with confidentiality agreements as appropriate.)

(4) Develop a process and timeline for an appeals procedure for use by registry operators.

In order to ensure that valid business interests are not adversely affected, the appeals process should be established with a two stage time frame. One, as an expedited process that both parties must agree to and the second, a longer time frame, when the expedited process is not feasible due to complexity, or other factors. [Editorial note: e.g. introducing a new service over an extended international holiday period may introduce a matter of two weeks of needed delay in order to ensure that resources, both internal and external within ICANN, the ICANN community and within the registry, are available.]

Expedited appeals process: The registry should be responsible for preparing and presenting detailed descriptions of the service, its technical impact on the DNS, and addressing in detail, those issues that were defined by ICANN in its denial of approval to introduce the service. Such materials should be in English and should be delivered in complete detail, to the designated contact for the appeals procedure, as well as to ICANN's designated contact.

ICANN should be responsible for acknowledging the receipt of the materials, and for identifying any further or clarification that may not be included in the submission, based on the reasons for the denial.

ICANN should be responsible for identifying an appropriate neutral entity to hear the appeal, including seeking public comment on the proposed appeals process and procedures for empanelling an appeals panel.

Questions to be answered:

Who pays for the request or appeals process?

To date, ICANN has spent considerable financial resources, both internally and externally in dealing with Sitefinder. The cost of introducing new services into the registry should be borne by the registry that will benefit from the addition of the new services. There should be a set fee for convening a panel, and that fee should be assessed against the registry.

Options: The fee should be cost based and cannot include the reimbursement of ICANN's time but can include the reimbursement and funding of fees and travel for experts who are asked by ICANN to supply evaluations. Experts who are serving as volunteers to ICANN but who have established neutrality and expertise can be retained as experts for this process (including members of the SECSAC). During such time, they should not fulfil their volunteer duties.

¹ Throughout these policy recommendations where specific timeframes are noted, it is recognised that there are likely to be possible instances where the timeframes are not met. In such instances the staff must write to the registry applicant (and ICANN community if also involved) prior to the expiration of policy timeframe, clearly stating why the timeframe is not going to be met and providing an estimate of a new timeframe to completion.