Hello All,
Here is the updated terms of reference following the council call.
Significant Changes are:
- inserted the term "consent" into the title
- added paragraph regarding sponsored gTLDs (extracted from FAQ)
- adjusted sentence regarding quick-look procedure in In-scope section
to allow possibility of using outside expertise (result will be
determined by policy process, but the discussion is in-scope)
- adjusted sentence regarding comprehensive procedure in In-scope
section to include the possibility of consultation with affected
parties, and public consultation (again result to be determined by
policy process, but the discussion is in-scope)
- added under Out-of-scope section that the procedures for cctlds are
out-of-scope (this is implied in use of gtld throughout and also that
the GNSO has no responsibility for cctlds, but just to be sure I have
made it explicit)
- adjusted sentence under task (3) to avoid repeating material in the
in-scope and avoid problem raised about implying consultation only with
outside experts (ie avoid pre-judging the outcome of the policy
development, but the discussion is in-scope as described in the in-scope
section). This is consistent with the changes in the In-scope section
discussed during the call.
Regards,
Bruce Tonkin
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.
