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

Thu Dec 15 17:46:05 UTC 2016

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> 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
> +1.310.400.4184 <(310)%20400-4184>
> Skype: kjpritz
> WeChat: kjpritz
>
>
> _______________________________________________
> Gnso-newgtld-wg-wt2 mailing list
> 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/20161215/a12f0bd5/attachment.html>