Hello All, I have revised the attached draft to be specific about gTLDs (as the GNSO does not develop policy for cctlds). Thus I have replaced "TLD" with "gTLD" in all places. I would expect that any policy development completed by the GNSO would be a useful best practices document for the policy bodies of each cctld. Regards, Bruce Title: ====== Procedure for use by ICANN for contractual approvals or 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 gTLD. 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. 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 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 TLDs, and the development of policies governing the introduction of new gTLDs. Additional obligations on gTLD 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.