Comment, please!

[Marc Schneiders]

Below the terms of reference that set the boundaries for comments on
the topic.

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.