[registrars] ICANN Announces the Implementation of the Process for Review of New gTLD Registry Services

["Bruce Tonkin" <Bruce.Tonkin@xxxxxxxxxxxxxxxxxx>]

From: 
http://www.icann.org/announcements/rsep-advisory-25jul06.htm


Today ICANN announces the implementation of the consensus policy for
review of new gTLD Registry Services and adoption of the Registry
Services Evaluation Process. The effective date of the Policy is 15
August 2006. The implementation of this process includes an online tool
(available for registry testing by 15 August) to facilitate submission
of requests for new registry services to ICANN.
25 July 2006


See: http://www.icann.org/registries/rsep/workflow.html for a workflow.



From: http://www.icann.org/registries/rsep/rsep.html

Registry Services Evaluation Policy 
(Posted 25 July 2006, Effective Date 15 August 2006) 

1. Definitions 

1.1 Registry Services are defined as the following: 

A. those services that are both: 

(i) operations of the registry critical to the following tasks: the
receipt of data from registrars concerning registrations of domain names
and name servers; provision to registrars of status information relating
to the zone servers for the TLD; dissemination of TLD zone files;
operation of the registry zone servers; and dissemination of contact and
other information concerning domain name server registrations in the TLD
as required by the Registry Agreement; and 

(ii) provided by the Registry Operator as of the Effective Date of the
Registry Agreement, as the case may be; 

B. other products or services that the Registry Operator is required to
provide because of the establishment of a Consensus Policy (as defined
above); 

C. any other products or services that only a registry operator is
capable of providing, by reason of its designation as the registry
operator; and 

D. material changes to any Registry Service within the scope of (A), (B)
or (C) above. (Definition comes from .NET Agreement, as specified by the
ICANN Board on 8 November 2005,
http://www.icann.org/minutes/resolutions-08nov05.htm). 


1.2 Security - An effect on security by the proposed Registry Service
shall mean (A) the unauthorized disclosure, alteration, insertion or
destruction of Registry Data, or (B) the unauthorized access to or
disclosure of information or resources on the Internet by systems
operating in accordance with all applicable standards. (Definition comes
from GNSO Recommendation, located at
http://gnso.icann.org/issues/registry-services/final-rpt-registry-approv
al-10july05.htm#5).


1.3 Stability - An effect on stability shall mean that the proposed
Registry Service (A) is not compliant with applicable relevant standards
that are authoritative and published by a well-established, recognized
and authoritative standards body, such as relevant Standards-Track or
Best Current Practice RFCs sponsored by the IETF or (B) creates a
condition that adversely affects the throughput, response time,
consistency or coherence of responses to Internet servers or end
systems, operating in accordance with applicable relevant standards that
are authoritative and published by a well-established, recognized and
authoritative standards body, such as relevant Standards-Track or Best
Current Practice RFCs and relying on Registry Operator's delegation
information or provisioning services. (Definition comes from GNSO
Recommendation, located at
http://gnso.icann.org/issues/registry-services/final-rpt-registry-approv
al-10july05.htm#5 ). 


1.4 Registry Service Technical Evaluation Panel - The Registry Service
Technical Evaluation Panel shall consist of a total of 20 persons expert
in the design, management and implementation of the complex systems and
standards-protocols utilized in the Internet infrastructure and DNS (the
"Registry Service Technical Evaluation Panel"). The members of the
Registry Service Technical Evaluation Panel will be selected by its
Chair. The Chair of the Registry Service Technical Evaluation Panel will
be a person who is agreeable to both ICANN and the registry constituency
of the supporting organizations then responsible for generic top level
domain registry policies. All members of the Registry Service Technical
Evaluation Panel and the Chair shall execute an agreement requiring that
they shall consider the issues before the panel neutrally and according
to the definitions of Security and Stability. For each matter referred
to the Registry Services Technical Evaluation Panel, the Chair shall
select no more than five members from the Registry Services Technical
Evaluation Panel to evaluate the referred matter, none of which shall
have an existing competitive, financial, or legal conflict of interest,
and with due regard to the particular technical issues raised by the
referral. (Definition comes from GNSO Recommendation, located at
http://gnso.icann.org/issues/registry-services/final-rpt-registry-approv
al-10july05.htm#5). 

 

2. Process for Consideration of Proposed Registry Services

2.1 Registry Operator or Sponsoring Organisation considers new registry
service

A Registry operator or sponsoring organisation at any time may decide to
change the architecture or operation of an existing TLD registry service
or introduce a new TLD registry service (See Implementation Note Step
1). 


2.2 Determine whether the change requires ICANN review

A gTLD registry operator or sponsoring organisation in consultation with
ICANN as described in Section 2.4 will determine whether a change to a
service would require approval based on the contract between ICANN and
the registry operator (See Implementation Note Step 1). 


2.3 Deliver to ICANN information on the proposed change

The Policy encourages proponents of a new registry service to
collaborate with ICANN prior to submission of a request for new registry
sevices. The aim of the Registry Services Evaluation Policy and approval
process is to create an environment that encourages gTLD registry
operators to discuss any changes that may impact third parties with
ICANN before they are made. 

The gTLD registry operator or sponsoring organisation should provide
ICANN with sufficient information on a change to allow ICANN to assess
whether the change should be subject to the approval process. The
information should include a technical description of the change as
would be seen by external users, and an assessment of the impact on
external users. If the registry operator or sponsoring organisation has
sought feedback from external parties and the community, details of the
process and the results of that feedback should be included. At this
stage in the process the information should be regarded by ICANN staff
as confidential (See Implementation Note Step 2). 


2.4 Preliminary Determination Period

Following written notification by Registry Operator to ICANN that
Registry Operator may make a change in a Registry Service within the
scope of the preceding paragraph: 

ICANN shall have 15 calendar days to make a "preliminary determination"
whether a Registry Service requires further consideration by ICANN
because it reasonably determines such Registry Service: (i) could raise
significant Security or Stability issues or (ii) could raise significant
competition issues. 

Registry Operator must provide sufficient information at the time of
notification to ICANN that it may implement such a proposed Registry
Service to enable ICANN to make an informed "preliminary determination."
Information provided by Registry Operator and marked "CONFIDENTIAL"
shall be treated as confidential by ICANN. Registry Operator will not
designate "CONFIDENTIAL" information necessary to describe the purpose
of the proposed Registry Service and the effect on users of the DNS. 

ICANN may seek expert advice during the preliminary determination period
(from entities or persons subject to confidentiality agreements) on the
competition, Security or Stability implications of the Registry Service
in order to make its "preliminary determination." To the extent ICANN
determines to disclose confidential information to any such experts, it
will provide notice to Registry Operator of the identity of the
expert(s) and the information it intends to convey. For Security or
Stability implications, ICANN may draw an expert from the Registry
Services Technical Evaluation Panel described in 2.4(F) below. 

If ICANN determines during the 15 calendar day "preliminary
determination" period that the proposed Registry Service, does not raise
significant Security or Stability (as defined in Sections 1.3 and 1.4),
or competition issues, Registry Operator shall be free to deploy it upon
such a determination. 

If the implementation of a proposed service requires a material change
to a Registry Agreement, the preliminary determination will be referred
to the ICANN Board (See Implementation Note Step 3-5). 


2.5 Competition issues 

In the event ICANN reasonably determines during the 15 calendar day
"preliminary determination" period that the Registry Service might raise
significant competition issues, ICANN shall refer the issue to the
appropriate governmental competition authority or authorities with
jurisdiction over the matter within five business days of making its
determination, or two business days following the expiration of such 15
day period, whichever is earlier, with notice to Registry Operator. 

Any such referral communication shall be posted on ICANN's website on
the date of transmittal. 

Following such referral, ICANN shall have no further responsibility, and
Registry Operator shall have no further obligation to ICANN, with
respect to any competition issues relating to the Registry Service. If
such a referral occurs, the Registry Operator will not deploy the
Registry Service until 45 calendar days following the referral, unless
earlier cleared by the referred governmental competition authority (See
Implementation Note Step 5). 


2.6 Security and Stability Issues 

In the event that ICANN reasonably determines during the 15 calendar day
"preliminary determination" period that the proposed Registry Service
might raise significant Stability or Security issues (as defined in
Sections 1.3 and 1.4), ICANN will refer the proposal to the Registry
Services Technical Evaluation Panel (as defined in Section 1.5) within
five business days of making its determination, or two business days
following the expiration of such 15 day period, whichever is earlier,
and simultaneously invite public comment on the proposal. 

The Registry Services Technical Evaluation Panel shall have 45 calendar
days from the referral to prepare a written report regarding the
proposed Registry Service's effect on Security or Stability (as defined
in Sections 1.2 and 1.3), which report (along with a summary of any
public comments) shall be forwarded to the ICANN Board. The report shall
set forward the opinions of the Registry Services Technical Evaluation
Panel, including, but not limited to, a detailed statement of the
analysis, reasons, and information upon which the panel has relied in
reaching their conclusions, along with the response to any specific
questions that were included in the referral from ICANN staff. Upon
ICANN's referral to the Registry Services Technical Evaluation Panel,
Registry Operator may submit additional information or analyses
regarding the likely effect on Security or Stability of the Registry
Service. 

Upon its evaluation of the proposed Registry Service, the Registry
Services Technical Evaluation Panel will report on the likelihood and
materiality of the proposed Registry Service's effects on Security or
Stability, including whether the proposed Registry Service creates a
reasonable risk of a meaningful adverse effect on Security or Stability
(See Implementation Note Steps 5-7). 


2.7 ICANN Board decision 

Following receipt of the Registry Service Technical Evaluation Panel's
report, which will be posted (with appropriate confidentiality
redactions made after consultation with Registry Operator) and available
for public comment, the ICANN Board will have 30 calendar days to reach
a decision.  In the event the ICANN Board reasonably determines that the
proposed Registry Service creates a reasonable risk of a meaningful
adverse effect on Stability or Security, Registry Operator will not
offer the proposed Registry Service. 

An unredacted version of the Registry Service Technical Evaluation
Panel's report shall be provided to Registry Operator upon the posting
of the report. The Registry Operator may respond to the report of the
Registry Service Technical Evaluation Panel or otherwise submit to the
ICANN Board additional information or analyses regarding the likely
effect on Security or Stability of the Registry Service (See
Implementation Note Steps 7-8). 

 

3. Reconsideration 

gTLD registry operators or registry sponsoring organizations affected by
an ICANN decision on a proposed new registry service may use the
existing reconsideration processes in the ICANN bylaws. 

The authoritative source for information on the Reconsideration process
is the ICANN bylaws (see Article IV: Section 2
http://www.icann.org/general/bylaws.htm#IV). The reconsideration applies
to staff actions that contradict an ICANN policy, or to an ICANN Board
action taken without consideration of material information. Information
on past reconsideration processes is available at
http://www.icann.org/committees/reconsideration.