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 +1.310.400.4184 Skype: kjpritz WeChat: kjpritz
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@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@kjpritz.com +1.310.400.4184 <(310)%20400-4184> Skype: kjpritz WeChat: kjpritz
_______________________________________________ Gnso-newgtld-wg-wt2 mailing list Gnso-newgtld-wg-wt2@icann.org https://mm.icann.org/mailman/listinfo/gnso-newgtld-wg-wt2
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@valideus.com<mailto:jeff.neuman@valideus.com> or jeff.neuman@comlaude.com<mailto:jeff.neuman@comlaude.com> T: +1.703.635.7514 M: +1.202.549.5079 @Jintlaw From: gnso-newgtld-wg-wt2-bounces@icann.org [mailto:gnso-newgtld-wg-wt2-bounces@icann.org] On Behalf Of Mike Rodenbaugh Sent: Thursday, December 15, 2016 5:46 PM To: Gnso-newgtld-wg-wt2@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@kjpritz.com<mailto:kurt@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@kjpritz.com<mailto:kurt@kjpritz.com> +1.310.400.4184<tel:(310)%20400-4184> Skype: kjpritz WeChat: kjpritz _______________________________________________ Gnso-newgtld-wg-wt2 mailing list Gnso-newgtld-wg-wt2@icann.org<mailto:Gnso-newgtld-wg-wt2@icann.org> https://mm.icann.org/mailman/listinfo/gnso-newgtld-wg-wt2
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 | GoDaddy™ kkreuser@godaddy.com<mailto:kkreuser@godaddy.com> 602-420-4121 (o) / 480-258-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@icann.org [mailto:gnso-newgtld-wg-wt2-bounces@icann.org] On Behalf Of Jeff Neuman Sent: Friday, December 16, 2016 2:30 AM To: Mike Rodenbaugh; Gnso-newgtld-wg-wt2@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@valideus.com<mailto:jeff.neuman@valideus.com> or jeff.neuman@comlaude.com<mailto:jeff.neuman@comlaude.com> T: +1.703.635.7514 M: +1.202.549.5079 @Jintlaw From: gnso-newgtld-wg-wt2-bounces@icann.org<mailto:gnso-newgtld-wg-wt2-bounces@icann.org> [mailto:gnso-newgtld-wg-wt2-bounces@icann.org] On Behalf Of Mike Rodenbaugh Sent: Thursday, December 15, 2016 5:46 PM To: Gnso-newgtld-wg-wt2@icann.org<mailto:Gnso-newgtld-wg-wt2@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@kjpritz.com<mailto:kurt@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@kjpritz.com<mailto:kurt@kjpritz.com> +1.310.400.4184<tel:(310)%20400-4184> Skype: kjpritz WeChat: kjpritz _______________________________________________ Gnso-newgtld-wg-wt2 mailing list Gnso-newgtld-wg-wt2@icann.org<mailto:Gnso-newgtld-wg-wt2@icann.org> https://mm.icann.org/mailman/listinfo/gnso-newgtld-wg-wt2
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@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 | GoDaddy™ kkreuser@godaddy.com <mailto:kkreuser@godaddy.com> 602-420-4121 (o) / 480-258-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@icann.org [mailto:gnso-newgtld-wg-wt2-bounces@icann.org] On Behalf Of Jeff Neuman Sent: Friday, December 16, 2016 2:30 AM To: Mike Rodenbaugh; Gnso-newgtld-wg-wt2@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@valideus.com <mailto:jeff.neuman@valideus.com> or jeff.neuman@comlaude.com <mailto:jeff.neuman@comlaude.com> T: +1.703.635.7514 M: +1.202.549.5079 @Jintlaw
From: gnso-newgtld-wg-wt2-bounces@icann.org <mailto:gnso-newgtld-wg-wt2-bounces@icann.org> [mailto:gnso-newgtld-wg-wt2-bounces@icann.org <mailto:gnso-newgtld-wg-wt2-bounces@icann.org>] On Behalf Of Mike Rodenbaugh Sent: Thursday, December 15, 2016 5:46 PM To: Gnso-newgtld-wg-wt2@icann.org <mailto:Gnso-newgtld-wg-wt2@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 <http://rodenbaugh.com/>
On Wed, Dec 14, 2016 at 6:54 PM, Kurt Pritz <kurt@kjpritz.com <mailto:kurt@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@kjpritz.com <mailto:kurt@kjpritz.com> +1.310.400.4184 <tel:(310)%20400-4184> Skype: kjpritz WeChat: kjpritz
_______________________________________________ Gnso-newgtld-wg-wt2 mailing list Gnso-newgtld-wg-wt2@icann.org <mailto:Gnso-newgtld-wg-wt2@icann.org> https://mm.icann.org/mailman/listinfo/gnso-newgtld-wg-wt2 <https://mm.icann.org/mailman/listinfo/gnso-newgtld-wg-wt2>
_______________________________________________ Gnso-newgtld-wg-wt2 mailing list Gnso-newgtld-wg-wt2@icann.org https://mm.icann.org/mailman/listinfo/gnso-newgtld-wg-wt2
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@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@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@godaddy.com <kkreuser@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@icann.org [mailto:gnso-newgtld-wg-wt2- bounces@icann.org <gnso-newgtld-wg-wt2-bounces@icann.org>] *On Behalf Of *Jeff Neuman *Sent:* Friday, December 16, 2016 2:30 AM *To:* Mike Rodenbaugh; Gnso-newgtld-wg-wt2@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@valideus.com or jeff.neuman@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@icann.org [mailto: gnso-newgtld-wg-wt2-bounces@icann.org <gnso-newgtld-wg-wt2-bounces@icann.org>] *On Behalf Of *Mike Rodenbaugh *Sent:* Thursday, December 15, 2016 5:46 PM *To:* Gnso-newgtld-wg-wt2@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@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@kjpritz.com +1.310.400.4184 <(310)%20400-4184> Skype: kjpritz WeChat: kjpritz
_______________________________________________ Gnso-newgtld-wg-wt2 mailing list Gnso-newgtld-wg-wt2@icann.org https://mm.icann.org/mailman/listinfo/gnso-newgtld-wg-wt2
_______________________________________________ Gnso-newgtld-wg-wt2 mailing list Gnso-newgtld-wg-wt2@icann.org https://mm.icann.org/mailman/listinfo/gnso-newgtld-wg-wt2
_______________________________________________ Gnso-newgtld-wg-wt2 mailing list Gnso-newgtld-wg-wt2@icann.org https://mm.icann.org/mailman/listinfo/gnso-newgtld-wg-wt2
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
participants (7)
-
Greg Shatan -
Jeff Neuman -
Kevin Kreuser -
Kurt Pritz -
Mike Rodenbaugh -
Rubens Kuhl -
Zylstra, Raymond