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.