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

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

Hello All,

Following the process used in the case of the WHOIS policy area, I have
attempted to derive from the issues report a terms of reference to help
the council decide on whether to undertake the policy development
process on the issue.

See below for a draft, and I welcome input and comments.  I see the
proposed issue as imposing a policy on ICANN to improve their decision
making process, and not as a process that imposes any new obligations on
registry operators (which are already bound by their existing
contracts).  It is a separate area of policy development, which should
be dealt with as part of introducing new TLDs, as to whether the
existing contracts and obligations on registry operators are
appropriate.

The ultimate goal should be to substantially improve the timeliness,
transparency and predictability of ICANN's decision making process in
this area.  The end result should improve the environment for registry
operators or gtld sponsors to make commercial decisions, and at the same
time give the community confidence that ICANN is making the right
decisions.

Regards,
Bruce Tonkin


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

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

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.

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 TLD 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 TLDs.

Additional obligations on 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.