Kurt, Thanks for drafting the below and articulating the rationale for a single Registry Agreement. I believe that that a single Registry Agreement with the ability to forgive certain contractual provisions is the most efficient way to move forward. The process that you have outlined for a Registry Operator to seek an exemption will facilitate the smooth running of different types of TLDs without the logistical nightmare of creating and managing many different Registry Agreements. Regards, Raymond Zylstra<https://au.linkedin.com/in/raymondzylstra> Neustar Inc. / Director - Policy and Compliance Level 8, 10 Queens Road, Melbourne, Australia VIC 3004 Office +61 3 9866 3710 Mobile +61 416 177 615 / Raymond.Zylstra@neustar.biz<mailto:Raymond.Zylstra@neustar.biz> / neustar.biz<http://www.neustar.biz/> Follow Neustar: LinkedIn<http://www.linkedin.com/company/5349> / Twitter<http://www.twitter.com/neustar> Reduce your environmental footprint. Print only if necessary. ________________________________ The information contained in this email message is intended only for the use of the recipient(s) named above and may contain confidential and/or privileged information. If you are not the intended recipient you have received this email message in error and any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify us immediately and delete the original message. From: gnso-newgtld-wg-wt2-bounces@icann.org [mailto:gnso-newgtld-wg-wt2-bounces@icann.org] On Behalf Of Kurt Pritz Sent: Thursday, 15 December 2016 1:55 PM To: gnso-newgtld-wg-wt2@icann.org Subject: [Gnso-newgtld-wg-wt2] The Case for a Single Registry Agreement Hi Everyone: During past meetings of this group, we raised the possibility of creating new categories of TLD registries and separate versions of registry agreements for the next round. The primary purpose of the categories, as I understand it, is to obtain exemptions, concessions or accommodations to the registry agreement so that the TLD registries in a category can more easily / effectively / economically pursue its mission. I believe that exemptions from certain terms in the registry agreement, when appropriately and swiftly granted, will encourage innovative uses for TLD registries. While I fully support the position that TLD registries should be able to obtain exemptions from certain Registry Agreement terms based on their business model, I do not support the creation of TLD categories or different versions of the Registry Agreement a priori. The reasons for this are that: (1) categories are generally unworkable, (2) there is a more elegant way to achieve the goals of registries seeking a Registry Agreement matched to their needs, and (3) it will be faster from a policy and implementation standpoint to avoid considering many requested category suggestions. The difficulties with implementing different categories can be demonstrated by looking at past and future gTLD rounds. The single most important lesson from the 2003-04 sponsored TLD round was to avoid a system where delegation of domain name registries was predicated upon satisfying criteria associated with categories. There were ten applicants. The evaluation panel found only two of them qualified under the sponsorship criteria as applicants tried to "shoe-horn" their applications into the definition of "sponsored." We could expect the same behavior in future applications once a category definition is created. The two most notable failures in this current (2012) round of TLD delegations were the two categories described by the Applicant Guidebook: Community Priority Evaluations and the attempt to measure the requisite government approvals for geographic names. Subjective criteria used in the Community Priority Evaluations did not yield repeatable results and even the objective criteria used for geographical names yielded errors and controversies. Suggested new categories already portend a confusing landscape. Community comment in the 2012 round suggested the creation of several TLD categories, for example: single-owner, country, not-for-profit, intergovernmental organization, socio-cultural, community and open. Depending on the category, various accommodations were suggested, for example, relief from: the requirement to sign an ICANN Registry Agreement, to use accredited registrars, pay ICANN fees or to follow consensus policy, or to follow instead the policy provisions outlined in the GAC's ccTLD principles. The introduction of a number of new gTLD categories with a number of different accommodations will lead to a complex and difficult application, administration and evaluation process, in addition to a very complicated contractual compliance environment. For those who want a smoothly running, fair, predictable gTLD program, the creation of categories should be avoided. Nonetheless, fair and appropriately flexible agreements can be written without the need, time and complexity of the creation of additional categories or separate agreements. An exemption process can be created to encourage innovation while ensuring all policy goals embodied in the RA are met. The Registry Agreement was written largely to satisfy the policy goals of the new gTLD program. It is more straightforward to evaluate a registry requesting an accommodation against the policy goals of the agreement and grant the accommodation so long as the policies are not violated. For example, there is a policy that, "Strings must not cause any technical instability." A simple implementation of this policy is the data escrow requirement (with Iron Mountain and NCC Group as the lone providers) to ensure ongoing operation in case of failure. It is conceivable that a different version of .bank might have emerged with a demonstrably valuable promise that data would not leave the confines of the .bank operator, which had demonstrated diversity and security capability beyond that of the escrow providers. In that case, the policy to enhance stability would be better served by granting an exemption for the data escrow requirement to the new .bank. The new .bank should not be required to form a category in order to gain an exemption. The working group can call for the creation of a process that considers forgiving certain contractual provisions whenever such a request promotes the goals of the new gTLD program and does not obviate the policy reason for the contractual clause in question. This is not so different from a smoothly running Registry Services Evaluation Procedure (RSEP). For example, when asked for an exemption, ICANN should require demonstrable evidence that: * The exemption will further a goal of the new gTLD program (such as innovation or increased competition or choice). * The exemption does not defeat the policy goal of the contractual provision. * Stating the policy goal of the provision * Demonstrating why the exemption does not defeat the policy goal * In line with the RSEP, demonstrating no deleterious effects to stability, security, resiliency and competition. Similar to RSEP, this process should occur within a 15-day window. Just as in the RSEP, there will be similarity among applications that will become easy to administer. While it sounds complex, it is not compared to the nightmare that the new gTLD process will become, never adequately administering to an ever-increasing number of categories. The outcome of our policy discussion could result in a process that remains flexible and can adapt to new business models as they are developed. The alternative will be an ongoing attempt to create policy and implementation plans for new categories as they are conceived. This is not to say that TLD categories should be forbidden. Categories can self-form and create guiding principles, internal policies or other membership criteria. However, rather than painstakingly create policy governing the formation of specific categories and registry agreements, the group could call for an overarching process to accommodate and facilitate new business models as they develop. Thanks for taking the time to read and consider this. Sincerely, Kurt ________________ Kurt Pritz kurt@kjpritz.com<mailto:kurt@kjpritz.com> +1.310.400.4184 Skype: kjpritz WeChat: kjpritz