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.