[Gnso-newgtld-wg-wt2] The Case for a Single Registry Agreement

Jeff Neuman jeff.neuman at comlaude.com
Fri Dec 16 09:30:12 UTC 2016


I also personally believe there is a reluctance of ICANN staff to grant any exemptions for fear of those exemptions being complained about by other parties who believe they are similarly situated.  So, while I sympathize with Kurt’s statements, as we have seen in the past, ICANN does not ever grant exemptions.  For those involved in the Specification 13 18-month debates, they know the pain of getting simple changes to the agreement which made sense to the entire community.  We also know that ICANN made NO other changes to the legal agreements based on the rationale that it did not grant such exemptions to everyone else and it had to treat everyone equally.  Thus, the default was NO changes.

How do we change that?

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-wt2-bounces at icann.org [mailto:gnso-newgtld-wg-wt2-bounces at icann.org] On Behalf Of Mike Rodenbaugh
Sent: Thursday, December 15, 2016 5:46 PM
To: Gnso-newgtld-wg-wt2 at icann.org
Subject: Re: [Gnso-newgtld-wg-wt2] The Case for a Single Registry Agreement

I agree with Kurt on this, but would add a few comments for consideration as well.  The last round did teach us that categories will be gamed, especially re so-called "community" applications, if there is benefit to fitting the category (i.e. priority over non-community applications).  On the other hand, the "brand" category did become well-defined, and Spec 13 proved sensible, repeatable and not subject to gaming.  Unfortunately ICANN does not have a "smoothly running" RSEP process, and even the Spec 13 process got bogged down for individual brands in many cases.  I think that is a staffing issue, perhaps, and ICANN should commit to processing Spec 13 and any other sensible, repeatable category exemptions in a more timely manner.  But generally I agree that it makes more sense to have a uniform, base Registry Agreement, and then have defined category exemptions that are easily implementable once they are agreed by the community -- but most importantly, these should be limited and should not provide any advantage in the application process.


Mike Rodenbaugh
RODENBAUGH LAW
tel/fax:  +1.415.738.8087
http://rodenbaugh.com

On Wed, Dec 14, 2016 at 6:54 PM, Kurt Pritz <kurt at kjpritz.com<mailto:kurt at kjpritz.com>> wrote:
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 at kjpritz.com<mailto:kurt at kjpritz.com>
+1.310.400.4184<tel:(310)%20400-4184>
Skype: kjpritz
WeChat: kjpritz


_______________________________________________
Gnso-newgtld-wg-wt2 mailing list
Gnso-newgtld-wg-wt2 at icann.org<mailto:Gnso-newgtld-wg-wt2 at icann.org>
https://mm.icann.org/mailman/listinfo/gnso-newgtld-wg-wt2

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-newgtld-wg-wt2/attachments/20161216/560621f8/attachment-0001.html>


More information about the Gnso-newgtld-wg-wt2 mailing list