CBUC statement Approval process for gTLD service change Updated version
CBUC statement Approval process for gTLD service change
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."
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
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
The registry monopoly brings rewards and responsibilities
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.
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.
(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 timeline1 will be followed - 30 day fast track, or 90 day assessment and consultation.
Explicit Approval must be sought when:
(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:
(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.
1 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.