Re: [fwd] [council] Draft terms of reference on ICANN procedure for approving contractual approvals or amendments related to the operations of a gtld registry (from: Bruce.Tonkin@xxxxxxxxxxxxxxxxxx)
Are there any further comments about this? It will be discussed and
voted on the GNSO Council tomorrow night my time. (Apologies for
not re-raising this earlier.)
Committee members should also be thinking about what we are going to
say about this on the substantial side.
--
Thomas Roessler <roessler@xxxxxxxxxxxxxxxxxx>
At-Large Advisory Committee: http://alac.info/
> ----- Forwarded message from Bruce Tonkin <Bruce.Tonkin@xxxxxxxxxxxxxxxxxx>
> -----
>
> From: Bruce Tonkin <Bruce.Tonkin@xxxxxxxxxxxxxxxxxx>
> To: council@xxxxxxxxxxxxxx
> Date: Fri, 21 Nov 2003 16:29:06 +1100
> Subject: [council] Draft terms of reference on ICANN procedure for approving
> contractual approvals or amendments related to the operations of a gtld
> registry
> X-Spam-Level:
>
> 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.
>
>
>
>
>
>
>
> ----- End forwarded message -----