Comments requested: ICANN and registries changing services

[Marc Schneiders]

Our comment is requested on the topic of ICANN and registries changing
services. The actual topic is a bit less broad. The terms of reference
below indicate what it is precisely about. These terms of reference
were made by the GNSO Council. (See earlier mail from me.)

The text of the terms of reference below is not important. Comments,
please, on the issues. The text is to define the issue. Comment may be
on everything not out of scope.

The issues report from the ICANN staff and a fax by the same are
background information. These are on the ICANN website, linked to at
the top of the news list.

Comments to this list ASAP, please. Comments will be gathered and
summarized in a statement that will then (after putting it before you
again here if there is time) go to the Council. It has to be there by
January 12... Thank you.

Marc Schneiders
-----------------------------------------------------------------------
TERMS OF REFERENCE

Title
======
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

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 TLD. 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. Under these agreements, ICANN has agreed that it
will not unreasonably withhold or delay this consent.

Some examples of where operators and sponsors must obtain ICANN's
consent include changes to the maximum fees for registry services,
changes to the list of domain names registered to the registry operator,
and certain changes to the functional or performance specifications
included in a registry agreement.

Where ICANN is required to give consent to a change, the registry
agreements require ICANN to make decisions using a timely, transparent
and predictable process.  Under the unsponsored registry agreements (e.g
.com, .net, .org, .biz, .info, .name) , 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.

With respect to sponsored gTLD (sTLD) registry agreements (e.g .aero,
.coop, and .museum), although portions of the policy-development
authority for each sTLD are delegated to the designated sTLD sponsor,
there are some situations in which an sTLD's sponsor will request
amendments to, or approvals under, the sponsorship agreement it has with
ICANN.  Although approval and amendment requests are much more common in
the case of unsponsored TLDs  than for sTLDs, the overall goals (e.g.,
predictability, timeliness, transparency) of the procedures for handling
gTLD and sTLD requests are similar, even though there are differences in
the provisions of the underlying agreements that must be observed.

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 consent or related
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 gTLDs, and the development of policies
governing the introduction of new gTLDs.

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

The procedure for handling requests for amendments of or approvals under
ccTLD sponsorship agreements.  This is outside of the scope of the GNSO,
and is the responsibility of the country-code names supporting
organization (ccNSO).


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.  This quick-look procedure may include provision to allow the
ICANN staff to obtain qualified, impartial, outside expertise.

The development of a more comprehensive process for when the
"quick-look" process used by ICANN staff results in concerns of ICANN
staff.  The process may possibly include  consultation with impartial
competition and technical experts, input from affected parties, and
public consultation.

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 more comprehensive phase.

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