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

[Greg Shatan]

I would suggest the following approach, which is a slight variation on
what's being discussed (and may be no variation on what Kevin suggested):

1.  A base Registry Agreement that contains only those provisions that
would apply to all Registries, regardless of category.  This is probably
80% of the RA, if not more.
2.  A few category-specific Specifications (or Riders or Schedules or
Exhibits...), one for each previously identified and agreed-upon category
of Registry/n2TLD, which would contain all of the provisions that are not
universal, but need to apply to that particular category.  (Analytically,
open commercial, unrestricted n2TLDs* would be a "category", and their
Specification plus the base Agreement would  equal the current base
Agreement.)

This way, we go into the process with a single, coherent base RA and a few
coherent category-specific Specs (which will be highly comparable to each
other, so that the differences are readily apparent and easy for parties to
manage).  It eliminates the need to negotiate out specific provisions in
common situations, or to retrofit a bolt-on Spec like Spec 13.

It also avoids enshrining a certain type of n2TLD (and the base provisions
appropriate to that type) as the "right" ones, while branding the other
types as "deviant" n2TLDs that are only begrudgingly accommodated.  This is
consistent with one of the core policy reasons to even have the New gTLD
program -- innovation.  If further variations come up beyond the identified
categories, that can be dealt with in a change process, but it's likely
that the variation will be close to one of the known types and their Spec,
and thus changes would be more limited.

Maybe I'm acting against interest (as an attorney in private practice),
because the exemption/subtraction process would almost certainly generate
some healthy legal fees, while a prospective policy/implementation process
to create a  base/Specs set-up will almost certainly generate some more
"volunteer" hours and a lot less legal fees down the line.  But I'll forego
the future fees for the greater good.

Greg
____________

*n2TLD = new new Top Level Domain.

On Fri, Dec 16, 2016 at 1:12 PM, Rubens Kuhl <rubensk at nic.br> wrote:

>
> Although reluctant to make changes based of applicant's request, ICANN did
> made changes based on their own willing, like the .sucks increased registry
> fees which is unique to that contract.
>
>
> Rubens
>
>
>
> Em 16 de dez de 2016, à(s) 16:08:000, Kevin Kreuser <kkreuser at godaddy.com>
> escreveu:
>
> Jeff’s correct re changes and there being a reluctance, but it wasn’t due
> to the potential of complaints (bc complaints are a constant anyway).
> ICANN believed that if a change was agreed to in any RA, an amendment would
> be required for the same change to each and every RA to be fair to all
> applicants.  However, the reluctance was not due to practical difficulties
> of implementation, but rather because each and every applicant availed
> themselves of the process subject to the same terms and conditions
> negotiated and agreed through the community process.  Thus, absent
> extraordinary circumstances applicable to a particular applicant, the
> changes were rejected.
>
> I understand the arguments against the RA being one “negotiated and agreed
> through the community process,” and that the AGB contemplated *requests *for
> changes to the terms and conditions of the RA, but, ultimately, absent
> certain requests from brand TLDs generally (which had by then negotiated
> brand-specific Spec 13), no individual applicant demonstrated anything that
> justified the changes requested (especially considering hundreds of other
> similarly-situated applicants did not request, require or necessitate a
> similar concession).  Each and every request was considered and responded
> to (line item by line item), but in light of the overall process to which
> the RA came to be, no changes were incorporated in any RA (except for
> .sucks, but in that case for reasons outside the program itself).  I also
> fail to see how that could change in any regard in subsequent rounds
> because defining the justifications for exceptions would be nearly
> impossible given the variables that exist, and implementing changes across
> the entire applicant pool is a logistical nightmare.
>
> In my opinion, the better path is to have well-hashed out terms and
> conditions for the few categories that have already been identified
> (IGO/GO, Community, Brand) and perhaps also Geo.  Spec 13 was a good
> example of the effort, but the timing of its negotiation and agreement
> (post RA approval) resulted in a less than optimal resulting set of terms
> and conditions.  If the applicant-specific terms and conditions are
> drafted, negotiated and published in a process parallel to the base RA
> process, I believe the terms for each of these groups will be more
> favorable.
>
> All that said, having been intimately involved in the negotiation of each
> RA that has been executed, again, outside of .brand TLDs, there really was
> not any great outcry from the majority of applicants regarding the terms
> and conditions of the base RA (including where the applicant was an IGO/GO
> or community).  So I do think there is a bit of fixing what’s not broke
> here, and perhaps a few tweaks could make for a much more expeditious and
> efficient path to subsequent rounds, rather than a full-on negotiation of
> new terms and conditions for each.
>
> Cheers,
>
>
> *kevin kreuser*
>
> *sr. assistant general counsel | **Go**Daddy™*
>
> *kkreuser at godaddy.com <kkreuser at godaddy.com>*
>
> *602-420-4121 <(602)%20420-4121> (o) / 480-258-7957 <(480)%20258-7957> (m)*
>
> *This email message and any attachments hereto is intended for use only by
> the addressee(s) named herein and may contain confidential information. If
> you have received this email in error, please immediately notify the sender
> and permanently delete the original and any copy of this message and its
> attachments.*
>
> *From:* gnso-newgtld-wg-wt2-bounces at icann.org [mailto:gnso-newgtld-wg-wt2-
> bounces at icann.org <gnso-newgtld-wg-wt2-bounces at icann.org>] *On Behalf Of *Jeff
> Neuman
> *Sent:* Friday, December 16, 2016 2:30 AM
> *To:* Mike Rodenbaugh; Gnso-newgtld-wg-wt2 at icann.org
> *Subject:* Re: [Gnso-newgtld-wg-wt2] The Case for a Single Registry
> Agreement
>
> 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 or jeff.neuman at comlaude.com
> T: +1.703.635.7514 <(703)%20635-7514>
> M: +1.202.549.5079 <(202)%20549-5079>
> @Jintlaw
>
>
> *From:* gnso-newgtld-wg-wt2-bounces at icann.org [mailto:
> gnso-newgtld-wg-wt2-bounces at icann.org
> <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 <(415)%20738-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
>
>
> _______________________________________________
> Gnso-newgtld-wg-wt2 mailing list
> Gnso-newgtld-wg-wt2 at icann.org
> https://mm.icann.org/mailman/listinfo/gnso-newgtld-wg-wt2
>
>
>
> _______________________________________________
> 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/20161216/53e045f5/attachment-0001.html>