[Gnso-newgtld-wg] Proposed Agenda: New gTLD Subsequent Procedures Working Group, 15 May 2017 at 15:00 UTC
Kurt Pritz
kurt at kjpritz.com
Mon May 15 13:58:29 UTC 2017
Hi Jeff:
I’ve pasted the earlier email below.
Kurt
________________
Kurt Pritz
kurt at kjpritz.com
+1.310.400.4184
Skype: kjpritz
From: gnso-newgtld-wg-wt2-bounces at icann.org [mailto:gnso-newgtld-wg-wt2-bounces at icann.org] On Behalf Of Kurt Pritz
Sent: Thursday, 15 December 2016 1:55 PM
To: gnso-newgtld-wg-wt2 at 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
> On May 15, 2017, at 2:17 PM, Jeff Neuman <jeff.neuman at comlaude.com> wrote:
>
> Thanks Kurt. Can you recirculate that article you wrote 6 months ago? It may help our discussions later today. <>
>
> Jeffrey J. Neuman
> Senior Vice President |Valideus USA | Com Laude USA
> 1751 Pinnacle Drive, Suite 600
> Mclean, VA 22102, United States
> E: jeff.neuman at valideus.com <mailto:jeff.neuman at valideus.com> or jeff.neuman at comlaude.com <mailto:jeff.neuman at comlaude.com>
> T: +1.703.635.7514
> M: +1.202.549.5079
> @Jintlaw
>
>
> From: gnso-newgtld-wg-bounces at icann.org [mailto:gnso-newgtld-wg-bounces at icann.org] On Behalf Of Kurt Pritz
> Sent: Monday, May 15, 2017 6:35 AM
> To: Steve Chan <steve.chan at icann.org>; gnso-newgtld-wg at icann.org
> Subject: Re: [Gnso-newgtld-wg] Proposed Agenda: New gTLD Subsequent Procedures Working Group, 15 May 2017 at 15:00 UTC
>
> Hi Everyone:
>
> In reading the agenda for today’s meeting, I read the spreadsheet describing the different TLD types. (See, https://docs.google.com/spreadsheets/d/1mA_hTUhLhJSsfcmoQwREtUqxykZ5KfJffzJAAhEvNlA/edit#gid=1186181551 <https://docs.google.com/spreadsheets/d/1mA_hTUhLhJSsfcmoQwREtUqxykZ5KfJffzJAAhEvNlA/edit#gid=1186181551>).
>
> It looks remarkably similar to a chart presented to the ICANN Board in 2010 or 2011 as the main argument for not adding to the categories of TLDs in the last round because they would be problematic (read, “impossible”) to implement.
>
> Even in this spreadsheet, I can argue whether most of the tick marks in the cells apply in all cases. This means that each of the many tick marks presents a significant barrier to: (1) getting through the policy discussion in a timely manner, and (2) a clean implementation.
>
> Categories of TLDs have always been problematic.
>
> 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.
>
> In the last round, the Guidebook provided for two category types: community and geographic. In my opinion, the implementation of both was problematic: look at the variances in CPE results and the difficulty with .AFRICA. This wasn’t just a process failure, the task itself was extremely difficult. Just how does an evaluation panel adjudge a government approval of a TLD application if one ministry says, ‘yes’ and the other ’no’? This sort of issue is simple compared to evaluating community applications.
>
> The introduction of a number of new gTLD categories with a number of different accommodations will lead to a complex and difficult application and evaluation process (and an expensive, complicated contractual compliance environment). It is inevitable that the future will include ongoing attempts to create policy for new categories as they are conceived.
>
> For those who want a smoothly running, fair, predictable gTLD program, the creation of categories should be avoided.
>
> Instead, the outcome of our policy discussion could be a process that remains flexible and can adapt to new business models as they are developed. An exemption process to certain contractual conditions can be created to encourage innovation while ensuring all policy goals embodied in the RA are met. Fair and flexible agreements can be written without the need, time and complexity of the creation of additional categories or separate agreements.
>
> While an exemption process 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.
>
> I wrote in more depth about this ~ 6 months ago - and would be happy to flesh out my thoughts on this again.
>
> Best regards,
>
> Kurt
>
> ________________
> Kurt Pritz
> kurt at kjpritz.com <mailto:kurt at kjpritz.com>
> +1.310.400.4184
> Skype: kjpritz
>
>
>
>
>
>
> On May 15, 2017, at 3:43 AM, Steve Chan <steve.chan at icann.org <mailto:steve.chan at icann.org>> wrote:
>
> Dear WG Members,
>
> Apologies for the late delivery. Below, please find the proposed agenda for the New gTLD Subsequent Procedures WG meeting scheduled for Monday, 15 May 2017 at 15:00 UTC for 90 minutes.
>
> 1) Welcome/SOIs
> 2) Work Track Updates
> 3) GDD Summit Recap
> 4) Drafting Team Update – Different TLD Types (https://docs.google.com/spreadsheets/d/1mA_hTUhLhJSsfcmoQwREtUqxykZ5KfJffzJAAhEvNlA/edit#gid=1186181551 <https://docs.google.com/spreadsheets/d/1mA_hTUhLhJSsfcmoQwREtUqxykZ5KfJffzJAAhEvNlA/edit#gid=1186181551>)
> 5) Community Comment 2 (CC2) Update – Public Comment available here: https://www.icann.org/public-comments/cc2-new-gtld-subsequent-procedures-2017-03-22-en <https://www.icann.org/public-comments/cc2-new-gtld-subsequent-procedures-2017-03-22-en>
> 6) ICANN59 Planning
> 7) AOB
>
> If you need a dial-out or want to send an apology, please email gnso-secs at icann.org <mailto:gnso-secs at icann.org>.
>
> Best,
> Steve
>
>
> Steven Chan
>
> Sr. Policy Manager
>
>
>
> ICANN
> 12025 Waterfront Drive, Suite 300
> Los Angeles, CA 90094-2536
>
> steve.chan at icann.org <mailto:steve.chan at icann.org>
> mobile: +1.310.339.4410
> office tel: +1.310.301.5800
> office fax: +1.310.823.8649
>
> Find out more about the GNSO by taking our interactive courses <applewebdata://310CAD3E-E244-4690-A938-C2655DD44BDE/learn.icann.org/courses/gnso> and visiting the GNSO Newcomer pages <http://gnso.icann.org/sites/gnso.icann.org/files/gnso/presentations/policy-efforts.htm#newcomers>.
>
> Follow @GNSO on Twitter: https://twitter.com/ICANN_GNSO <https://twitter.com/ICANN_GNSO>
> Follow the GNSO on Facebook: https://www.facebook.com/icanngnso/ <https://www.facebook.com/icanngnso/>
> http://gnso.icann.org/en/ <http://gnso.icann.org/en/>
>
> _______________________________________________
> Gnso-newgtld-wg mailing list
> Gnso-newgtld-wg at icann.org <mailto:Gnso-newgtld-wg at icann.org>
> https://mm.icann.org/mailman/listinfo/gnso-newgtld-wg <https://mm.icann.org/mailman/listinfo/gnso-newgtld-wg>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-newgtld-wg/attachments/20170515/b79629d9/attachment-0001.html>
More information about the Gnso-newgtld-wg
mailing list