ICANN/GNSO GNSO Email List Archives

[council]


<<< Chronological Index >>>    <<< Thread Index >>>

[council] DRAFT2 terms of reference on ICANN procedure for approving contractual approvals or amendments related to the operations of a gtld registry

  • To: <council@xxxxxxxxxxxxxx>
  • Subject: [council] DRAFT2 terms of reference on ICANN procedure for approving contractual approvals or amendments related to the operations of a gtld registry
  • From: "Bruce Tonkin" <Bruce.Tonkin@xxxxxxxxxxxxxxxxxx>
  • Date: Wed, 26 Nov 2003 09:38:16 +1100
  • Sender: owner-council@xxxxxxxxxxxxxx
  • Thread-index: AcOzpNFdERjiIf/NRTe6XevGvGzD1w==
  • Thread-topic: DRAFT2 terms of reference on ICANN procedure for approving contractual approvals or amendments related to the operations of a gtld registry


Hello All,

I have revised the attached draft to be specific about gTLDs (as the
GNSO does not develop policy for cctlds).  Thus I have replaced "TLD"
with "gTLD" in all places.  I would expect that any policy development
completed by the GNSO would be a useful best practices document for the
policy bodies of each cctld.

Regards,
Bruce


Title:
======
Procedure for use by ICANN for contractual approvals or contractual
amendments to allow changes in the architecture or operation of a gTLD
registry

Description of Task Force:
==========================

ICANN has agreements with registry operators (for unsponsored gTLDs) and
sponsors (for sponsored gTLDs). In the agreements, ICANN designates the
operator (or sponsor) as the sole operator (or sponsoring organization)
for the gTLD. In exchange, the operator or sponsor agrees that the gTLD
registry will be operated according to various specifications, policies,
and other requirements. These agreements constrain the freedom of a gTLD
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.

Some examples of where ICANN is required to give consent include changes
to the fees for registry services, changes to the list of domain names
registered to the registry operator, and changes to the functional or
performance specifications included in a registry agreement.  Many
changes approved by ICANN in recent history have been minor and should
have been approved in under 30 days, and in other cases changes have
been more substantial, but not so substantial as to justify decision
making processes running for 6 months or longer.

Where ICANN is required to give consent to a change, registry operators
require ICANN to make decisions using a timely, transparent and
predictable process.  Under the unsponsored registry agreements, ICANN
is also required to not unreasonably restrain competition and, to the
extent feasible, promote and encourage robust competition;  and not
apply standards, policies, procedures or practices arbitrarily,
unjustifiably, or inequitably and not single out a Registry Operator for
disparate treatment unless justified by substantial and reasonable
cause.

The purpose of this policy development process is to create a policy
concerning the essential characteristics of the process by which ICANN
considers registry operator or sponsor requests for contractual
approvals or contractual amendments to allow changes in the architecture
or operation of a gTLD registry.


Out-of-scope
============

Changes to the nature of the agreements between ICANN and registry
operators (e.g removing the requirement to meet functional and
performance specifications, and replacing with a more general
requirement to ensure security and stability).  This will be the subject
of further policy development associated with the review of the current
proof of concept for new TLDs, and the development of policies governing
the introduction of new gTLDs.

Additional obligations on gTLD registry operators or gTLD sponsors
beyond what is already specified in their existing agreements.


In-scope
========

The development of a "quick-look" procedure for quick approval of
changes that do not harm the legitimate interests of third parties,
threaten stability or security, nor contravene any existing ICANN
policy.

The development of a more comprehensive process for when the
"quick-look" process used by ICANN staff results in concerns of ICANN
staff that allows ICANN to obtain qualified outside expertise, including
through consultation with competition and technical experts.

Mechanisms to protect the confidentiality of requests for contractual
approvals or contractual amendments to prevent unnecessary and premature
disclosures of proprietary commercial information to competitors.



Tasks/milestones
================

(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)

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

(3) Develop a process and timeline for responding to a request including
"quick-check" phase, and where a quick-check indicates a need for
further work - a timeline for obtaining expert advice and consultation
with significantly affected entities.

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



<<< Chronological Index >>>    <<< Thread Index >>>