ABCDEFGHIJKLMNOPQRSTUVWXYZ
1
Community Comment 2
2
Public Comment Review Tool
3
4
2.1 Base Registry Agreement
5
#CommentContributorWG Response
6
1Registry Agreement
Issue: The 2012 Applicant Guidebook featured a baseline version of the new gTLD Registry Agreement, but the final text of the Agreement that new gTLD applicants eventually signed differed substantially from that published version.
Recommendation: A final or near-final version of the baseline Registry Agreement should be published and made available to new gTLD applicants in advance of any future application procedures.		RySG letter
**Note: this document was not submitted as part of CC2
7
2.1.1 - The question of whether or not a single Registry Agreement is suitable is tied into the subject of different TLD categories. Throughout the working group’s discussions, there has been support for a model similar to what is currently in place: a single Registry Agreement with exemptions that allow for TLDs with different operational models (e.g., Specification 13 for Brand TLDs or Specification 12 for Community TLDs). There is also support for different Registry Agreements for different TLD categories, centered around a common, core base set of contractual requirements. Which of these models do you think would be most effective for recognizing the different operational requirements of different TLDs? Which of these models do you think would be most efficient in terms of development, implementation, and operational execution (e.g., contracting, contractual compliance, etc.)? Do you think there are any alternative options that could effectively facilitate TLDs with different operational requirements?
8
1I suggest a common core agreement and then category (see five suggested categories above) specific sections. NOTE should not be possible to change category, once delegated. (Or at least very difficult to do so).Jannik Skou
9
2Recommendations on this topic are largely contingent on policy discussion on whether there will be different TLD categories. In either event, to promote consistency and transparency, INTA advocates for a single base RA available in a single language (with approved translations available to ensure that the RA is accessible to all applicants). Having different RAs increases the risk of having different interpretations for similar provisions, or create potential roadblocks for developing new models for registry operation. A single base RA provides flexibility for applicants to modify their applications as their business models change.
Although it is likely beneficial to .Brand TLD applicants to have a tailored RA specific to this preexisting category of TLD, there are, equally, benefits to addressing brand-specific provisions by means of Specification 13, so long as changes to Specification 13 cannot be thrust upon or blocked by non-.brand members of the community. This would allow the .Brand TLD operator the flexibility (should it so choose) to open up their TLD to third party registrants outside of the limitations of Specification 13, by agreeing to remove that Specification from their contract without having to sign a completely new agreement. 		INTA
10
3Stick with the current contractual model please. It is not clear what would be gained by changing the format, and anyway it is the substantive content of the base agreement and operational schedules which should be the focus here. Nominet
11
4We would support a single uniform Registry Agreement (RA), so long as the RA contained certain addendums that may be entered into by specialized Registry Operators, e.g., .Brands, and Community TLDs.
Under such a framework, different operational models would still be taken into account, while the single RA would facilitate efficiency in development, implementation, and compliance. A single RA would also make it easier for a particular Registry Operator or a TLD to move between categories as business needs evolved.		BC
12
5If the goal of the new gTLD program is to increase competition among registry providers, then forcing everyone into a standard contract runs counter to those goals. Even with the identified specification variances, there is a limit to what registries can achieve with the current contracts.
ICANN argued in the 2012 round that managing multiple implementations of a contract would be burdensome. I disagree. ICANN has matured into a $100+ million per year organization. Contractual compliance is one of the bedrocks of the trust people place in the organization. If they need more resources to allow for multiple contracts, then a review of the existing allocations of resources should be under taken.		Jim Prendergast
13
6In its current form, the base RA is skewed towards traditional models and does not adequately reflect the new models introduced in the 2012 round. This can be a barrier for new entrants that operate distinctly different models.
Where there is a significant difference between registry models and where these different models are a sizeable proportion of registry operators, the BRG recommends customised RAs to better reflect those models and their distinct nature. In this respect, the BRG favours a customised Registry Agreement (RA) for dotBrands, to reflect the distinct differences against a traditional open and commercial registry. A significant proportion of New gTLDs were dotBrands and we anticipate continued interest in future application windows.
In the absence of a customised RA for dotBrands or other distinct and sizeable models, the BRG recommends the base agreement is stripped down to provide core provisions that are applicable to all, with the relevant specifications that define the model and variant provisions applicable to that model. The contracting parties associated with each defined model would be the parties responsible for negotiating and voting any changes to the related specification, while all registry operating under the RA would be responsible to negotiate and vote for any changes to the core base agreement.		BRG
14
7There shouldn’t be any “Brand gTLDs”—see my answer above regarding “brand gTLDs.” Likewise there would be no need for a specification 12 for “Community gTLDs” since any qualified entity (community or otherwise) meeting the financial and other qualifications, could submit their bid (which consists of the highest maximum wholesale fees to be charged (per domain name) to operate the gTLD during the 10 year period of the RA. [There is also support for different Registry Agreements for different TLD categories] NO!, [...centered around a common, core base set of contractual requirements. Which of these models do you think would be most effective for recognizing the different operational requirements of different TLDs?] 1 Base Registry Agreement for ALL new gTLDs. [Which of these models do you think would be most efficient in terms of development, implementation, and operational execution (e.g., contracting, contractual compliance, etc.)?] 1 Base Registry Agreement for ALL new gTLDs. [Do you think there are any alternative options that could effectively facilitate TLDs with different operational requirements?] 1 Base Registry Agreement for ALL new gTLDs. John Poole
15
8ICANN should have a single base registry agreement. This will ensure all registry operators are held to the requisite business and technical standards to maintain security and stability across the Internet.Afilias
16
9There has been much discussion on the Base Registry Agreement and possible provisions within four different classifications of TLD types. The question is whether there should be separate Base Agreements for different TLD Types, or one Base Agreement, for which different TLD types may request exemptions for certain non-relevant contractual obligations. The RrSG does not wish to comment on the mechanics of how this should be contractually dealt with by ICANN. However, regardless of the mechanism ICANN chooses, the process must be 100% clear and defined within the Application Guidebook or equivalent. There should not be any new “on the fly” exemptions made or new TLD types classified, once the applicant window is closed.RrSG
17
10The notion of a single Registry Agreement that contains certain clauses that may or may not be triggered based on the applicant or the nature of the TLD, versus a suite of Registry Agreements is, in reality, the same concept. That is to say that in both models certain provisions will only ever apply to certain Registry Operators or TLDs, and the core provisions of the Registry Agreement remain the same. As such neither model should be more or less effective in recognising the different operational requirements of different TLDs.
With regard to efficiency in development, implementation, and operational execution, a single Registry Agreement is the most practical. Some factors considered include: time required to develop each of Registry Agreements for each of the categories; the ability of an Registry Operator or a TLD to move between categories; the complexity of an amendment process such as that being undertaken at present where there are multiple Registry Agreements; administrative burden for ICANN and Registry Operators; predictability for ICANN, Registry Operators and the internet using public. Further, strict categorisation and inflexible agreements may, in practice, stifle competition and innovation.		RySG
18
11Support a single registry agreement to ensure, as far as possible, consistency of terms across all categories of TLDs.ALAC
19
12Categories become more relevant if there are different application criteria, obligations, or contractual provisions applied accordingly. Whilst we do not support multiple categories with different criteria, due to the complexity and lack of flexibility to develop and evolve business models that would likely result, the 2012 round did clearly establish a category of Brand TLDs, which we support. A number of Brands would have benefited from an application process and contractual provisions which better acknowledged the different drivers and priorities of a Brand TLD. Specification 13 goes some of the way here, but additional Brand-specific provisions or even a Brand-specific contract would be beneficial. An entirely separate contract for Brand TLDs requires careful consideration, however, as it has the potential to reduce the flexibility of registries. For example, if a registry operator did wish in the future to allocate names more widely, outside the limitations imposed by Specification 13, it is a simple matter to remove the Specification from the contract. With a separate Brand contract the registry operator would need to enter into a replacement contract with ICANN. The same benefits and tailoring for Brand TLD might also satisfactorily be delivered by using the specification model.Valideus
20
13We believe that a single base agreement applicable to all with specifications serving as additional contractual requirements that are required for specific registries category types would be the ideal model.NCSG
21
2.1.2 - Should further restrictions pertaining to sunrise periods, landrush, or other registry activities be developed? If so, do you have suggestions on attributes of these restrictions? Should they be incorporated into the base agreement? Should there be any restrictions established on registry pricing?
22
1INTA supports additional modifications to the RA be implemented to comply with ICANN’s duty to protect the existing legal rights of others. The GNSO made several recommendations in the 2007 Final Report that cover these topics, including that “[s]trings must not infringe the existing legal rights of others” (Recommendation 3) and that “[d]ispute resolution and challenge processes must be established prior to the start of the process” (Recommendation 12). There have been numerous issues identified by INTA and its members which are fundamental to these recommendations. Many of these appear to fall within the remit of the PDP to Review all Rights Protection Mechanisms (RPMs) in all gTLDs, such as whether the RPMs have met their goal in minimizing the cost and burden on brand owners; whether trademark protections should be extended to “mark +”; and whether a globally protected marks list should be introduced. Other issues appear either to fall within the remit of the Subsequent Procedures PDP, or there is a lack of clarity over which PDP should deal with them. These include:
a) Premium Names and Sunrise Pricing
INTA has long expressed its concern to ICANN about registry operators who are circumventing trademark Sunrise protection through “premium” names programs. In many cases, “premium” names are self-selected by registries and incorporate well-known trademarks, including arbitrary and fanciful marks. It is important to note that INTA’s concerns do not extend to permissible speech issues, including protectable trademarks that may also have another common meaning. Premium names lists, however, frequently have the effect of removing trademark names from the Sunrise registration period in spite of the fact that, under the RPM Requirements, such launch programs are not supposed to “contribute to consumer confusion or the infringement of intellectual property rights.” This can occur either because the high pricing puts them out of reach of the trademark owner and/or because premium names may be reserved by the registry for later release after the Sunrise period has ended.
As a related point, even where trademarked terms are not placed onto premium lists, many registry operators share significantly higher prices for a Sunrise registration than would be charged for the same domain name during general availability. While registry operators may argue that this is necessary in order for them to recover the cost of connecting to the Trademark Clearinghouse (TMCH), the cost of Sunrise names appears to be significantly higher than a mere cost-recovery.
INTA understands that ICANN does not actively regulate domain name pricing, but contends that the registry practice of creating “premium” names and charging excessive pricing for such names, and of charging substantially higher prices for Sunrise names generally than in GA, runs contrary to the intent and acts as an effective circumvention of the RPMs. The Sunrise period was created with the intention to protect, rather than to exploit, brand owners. It is important that consideration is given to how premium names schemes and Sunrises can be operated without undermining the RPMs and discriminating against brand owners.
b) Reserved Names
Many INTA members have reported that their trademarks have been withheld from registration by new gTLD registry operators, thereby being unavailable during the Sunrise period. Please see our further comments below. In addition, ICANN has the authority to request lists of reserved domain names but has refused to request and share such lists, which would allow brand-owners to police improper reservation of names.
c) Legal Rights Objection (LRO) Process
The LRO process currently set forth in the Applicant Guidebook is defective as it is based upon claims of infringement (which require use and it is not immediately clear how one can use a TLD they have not yet been awarded), rather than upon claims of bad faith application for a TLD and therefore does not meet the standard set forth under Policy Recommendation 3. INTA understands that there is a proposal being considered by the Subsequent Procedures Working Group and urges ICANN to seriously consider any improvements proposed by that working group. See 3.1.4. below for further comments on this issue.		INTA
23
2We do not feel that any further restrictions are necessary, and also that there shouldn’t be any ICANN restrictions on registry pricing. Nominet
24
3No. Particularly for dotBrands where this is irrelevant.BRG
25
4[Should further restrictions pertaining to sunrise periods, landrush, or other registry activities be developed?] YES. [If so, do you have suggestions on attributes of these restrictions?] YES—no warehousing, no gTLD registry operator can operate a registrar, no gTLD registry operator or any of its “affiliates” can purchase through registrars more than a total of 1000 domain names under the new gTLD for the first 12 months of general availability, and there can be no “premium pricing”—the same fee for each domain name in the gTLD. [Should they be incorporated into the base agreement?] YES. [Should there be any restrictions established on registry pricing?] Yes. See my previous answers.John Poole
26
5No. Afilias
27
6The restrictions in relation to sunrise periods, landrush, and related activities are sufficient for the TLDs currently being delegated and will be sufficient for future TLDs. Specific launch plans, dates, and terms and conditions should continue not to be included into the Registry Agreements. Any restrictions on registry pricing in addition to that which is already contained within current Registry Agreement may stifle competition and innovation.RySG
28
7Whilst a number of factors have impacted the cost to brand owners, feedback from Com Laude’s clients, and supported by the INTA Impact Study, has highlighted certain pricing practices of some new gTLD registries as being a particular concern, namely the issues of Sunrise pricing and the treatment of Premium and Reserved names. Many trademark holders have reported being offered names during the Sunrise at prices significantly higher than those for general availability, often prohibitively so. This is exacerbated where terms corresponding to the trademark, including examples where the trademark is a coined word, have been designated by some registries as Premium names, attracting even higher prices. We recognize that the matter of pricing raises difficult issues, and that all registries should not be constrained by overstrict rules to follow the same business and pricing models. Nevertheless, there is a point at which pricing ceases to be a legitimate business model in a competitive market and undermines the RPMs. This is particularly so, given the finding from the INTA Impact Study, that there is no substitutability of names in practice for brand owners because of their defensive nature. Another area of concern raised by Com Laude's brand clients is the scope that registry operators appear to have under the RPMS requirements to reserve an unlimited number of names, including names which may be recorded in the TMCH, until after the sunrise has finished. On later release from reservation these names are subject to a trademark claims process but not to the sunrise. This again has the capacity to undermine the intentions of the RPMs. We would welcome consideration by the working group of how holders of TMCH-recorded marks might be given first refusal where the name is released from reservation.
All of these issues have scope for overlap with the work of the RPMs PDP, and thus communication and liaison between the two PDPs is required.		Valideus
29
2.1.3 - Should the entire application be incorporated into the signed Registry Agreement? Should portions of the application, explicitly identified, be incorporated into the signed Registry Agreement? If changes are made between applying and executing the Registry Agreement, how should this be handled? If changes are made after executing the Registry Agreement, how should this be handled? If changes like these are contemplated, how can the needs of the community to properly consider the contents of an application be weighed against an applicant’s need to make either minor adjustments or fundamental changes to their registry?
30
1Application should be part of the RA (under SPEC 11). Restriction on Sunrise – a maximum fee (General Availability plus a max fixed amount: 300 USD) should be requested.Jannik SkouStaff note: Part of this comment appears to fit under 2.1.2
31
2The current registry agreement includes warranties to the effect that the application to ICANN was true and correct in all material respects and that would seem to be sufficient. This assumes that the public portions of the application disclose sufficient details as to the proposed use to enable whether legal rights objections etc should be filed. Post contract, ICANN already operates change control procedures.Nominet
32
3Applicants should be more transparent regarding planned pricing of domain names.
We believe the current restrictions are working well to protect registrants and Internet users. Regulations pertaining to pricing are generally outside of the scope of ICANN's remit. However, we are concerned about "predatory pricing" schemes by a couple of Registry Operators that have charged significantly higher fees for trademarked terms during Sunrise. Such practices could be potentially dealt with in the future through more explicit fraud provisions in PICs as well as regulations preventing use of TMCH data for purposes other than intended.		BCStaff note: This comment appears to fit under 2.1.2
33
4No, the application should not be incorporated into the agreement. BRG
34
5[Should the entire application be incorporated into the signed Registry Agreement?] Yes as necessary. [Should portions of the application, explicitly identified, be incorporated into the signed Registry Agreement?] Yes as necessary. [If changes are made after executing the Registry Agreement, how should this be handled? What kind of changes?] It depends. [If changes like these are contemplated, how can the needs of the community to properly consider the contents of an application be weighed against an applicant’s need to make either minor adjustments or fundamental changes to their registry?] One Base Registry Agreement. Changes requested by a registry operator, unless agreed to as a “universal” change in the Base Registry Agreement, would require ICANN to give notice, and allow any other registry operator to offer to take over the gTLD and continue operating the gTLD registry on the original terms. If no other operator was interested, changes would either be approved or denied by the ICANN Board in the global public interest, and if the registry operator did not accept the Board’s decision, the registry operator’s operation of the gTLD would terminate at ICANN’s earliest convenience.John Poole
35
6The application should not be incorporated into the Registry Agreement. ICANN should continue with the current model of utilizing a base Agreement.Afilias
36
7The entire application should not be incorporated into the signed registry agreement (neither should the applicant guidebook). Registries must retain reasonable latitude and flexibility to adapt and innovate. Overburdening a contract with hundreds of terms is a poor way to conduct business and invites interminable wish lists of regulation. The voluntary PIC model has worked fairly well (though in the 2012 round it was rushed) and a similar procedure is more likely to bear fruit: an applicant could add voluntary PICs in its application, then have a period to add more in response to any GAC/community issues.RySG
37
8Agree all relevant aspects of application should be incorporated into the Registry Agreement. This would ensure that what a proposed Registry Operator has undertaken to do is part of the agreement. Any changes should be the subject of notice with an opportunity for public comment.ALAC
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100