CC2 - Work Track 3
 Share
The version of the browser you are using is no longer supported. Please upgrade to a supported browser.Dismiss

View only
 
ABCDEFGHIJKLMNOPQRSTUVWXYZ
1
Community Comment 2
2
Public Comment Review Tool
3
4
3.1 Objections
5
#Comment
Contributor
WG Response
6
1The GAC Early Warning arrangements provided applicants with the earliest possible notice of potential public policy concerns with certain applications. This served the interests of both applicants and the GAC.
The GAC advised in its Toronto Communique (2012) that ICANN should bind and manage, as contractual, commitments made by applicants for new gTLDs where these commitments are in response to the GAC providing an Early Warning Advice on that application.
The GAC is interested in participating in any discussions to improve the Early Warning arrangements so that the legitimate concerns of governments, applicants and the wider community are met.
GAC
7
3.1.1 - Do you think that the policy recommendations (Recommendations 2, 3, 6, and 20) require any modifications? If so, what would you suggest?
8
1Recommendation 2 forms the basis for evaluating String Similarity and Recommendation 3 forms the basis for the Legal Rights Objection (LRO). While INTA does not recommend amendments to the Recommendations themselves, INTA does recommend that the AGB be amended to be more precise in the definitions of string similarity and trademark rights as they apply to the LRO. INTA also recommends that the AGB be amended to include fundamental principles of international trademark law (e.g., trademark fame or well-known status, doctrine of foreign equivalents, etc.).INTA
9
2The recommendations look reasonable, but it will be interesting to see how in practice they are to be implemented in a way which still gives certainty to prospective applicants – reasonable people can disagree as to whether one string is confusingly similar to another, and what is a generally acceptable legal norm relating to morality and public order.Nominet
10
3The BRG concurs with the RySG comments:
We support the identified recommendations from the 2012 round and their continued application to a future gTLD application process, with minor modifications to Recommendation 20 above to clarify what constitutes “a significant portion of the community.”  
Further, we support the continued use of objection processes to implement these recommendations. Notwithstanding, we believe that the objection process could be generally improved through a number of procedural changes to all four categories of objection proceeding.
BRG
11
4Afilias concurs with the opinions of the RySG and defers to that response.Afilias
12
5We support the identified recommendations from the 2012 round and their continued application to a future gTLD application process, with minor modifications to Recommendation 20 above to clarify what constitutes “a significant portion of the community.”
Further, we support the continued use of objection processes to implement these recommendations. Notwithstanding, we believe that the objection process could be generally improved through a number of procedural changes to all four categories of objection proceeding.
RySG
13
6The recommendation on string confusion is one that must be enhanced. Singular and plural versions of related strings proved to be problematic in the first round and must be addressed this time. Such provision should not be limited to just the addition of an S but should be more generalized as suggested in a recent Registry SG document.
That being said, as discussed in relation the ccNSO Extended Process Similarity Review Panel (EPSRP) document, for strings that are inherently confusing in their own right, but for which STRONG irrevocable policies mitigating against confusion in full domain names, delegation could be considered.
ALAC
14
3.1.2 - Do you believe that those recommendations (which led to the establishment of the String Confusion, Legal Rights, Limited Public Interest, and Community Objections grounds) were implemented effectively and in the spirit of the original policy recommendations? If no, please provide examples.
15
1Legal Objection: Applications should be binding (including Q18), so that one can not describe intended use in the application and still win a legal rights objection case based on the argument that the domain name is not yet in use… String confusion: in case of multiple applicants for same string, cases should be consolidated. ALL TLDs should list the language(s) they approach. Singular and Plurals should not be allowed in those languages targeted by the TLD operator(applicant) (and this includes already delegated/applied for strings from previous rounds – “old TLDs” would have to add the languages they target. So .HOTEL would have to list all the languages they would like to “protect” from .HOTELS. (Know this is too late in this example). But for instance plural of .HOTEL in Danish is not HOTELS but “HOTELLER” and so forth. Each TLD could be allowed to define a maximum of three languages. CPE – to be deleted – not needed if five new categories as suggested above.Jannik Skou
16
2While the objection process in the first round was generally effective, one notable flaw was the inconsistency in panel decisions for string confusion objections.
In order to address this flaw for the subsequent round we support the publication by ICANN of more detailed and objective criteria for determining string similarity, as well as a broader appeals mechanism for challenging any decisions that are perceived to fall outside of such criteria.
Both losing Objectors and Applicants must have standing to appeal the panel's decision. The language from the 2012 round vests appellate discretion solely with “Losing Applicant[s],” creating a presumption that the rights of gTLD applicants are given more weight than the rights of objectors. Inconsistencies in panel decisions may be further prevented through greater transparency in the process, namely, through publication of any evidence considered by expert panels, arbitration providers, and ICANN staff in its evaluation of objections. Additionally, for the subsequent round, we propose that any review or appeals panels be comprised of arbitrators with specific demonstrated experience in new gTLD program objections.
BC
17
3The BRG concurs with the RySG comments:
We support the general approach to implement these recommendations through an objection process. However, we note several procedural issues with the implementation of the objection procedures that could be improved in a future application process. The following recommendations are intended to address some of the related procedural deficiencies encountered during the 2012 round.
Strictly enforce objection page limits
One of the factors contributing to the high costs of objections during the 2012 round was a failure of the the panels to curb submission of additional objection documentation. As panels are paid hourly they are incentivized to accept additional documentation even if it was not strictly necessary for the purpose of evaluating the substance of the objection. Further, in some instances, attachments were used to make and support additional arguments not made in the body of the original objection, resulting in additional work and cost to respondents.
We believe that the page caps proposed are appropriate and should be more strictly enforced as part of a subsequent application procedure. To these ends,  we would welcome additional language clarifying that attachments should be limited to supporting documentation and must not be used to make additional arguments not covered within the 5,000 word/20 page limit and that, following submission of the initial objection, additional documentation will only be accepted if it is specifically requested by the Objection panel.
Allow parties to jointly determine whether to use a one or three-Expert panel
The selection of a one or three-Expert panel raises tradeoffs related to cost and consistency. While one-Expert panels are lower cost, three expert panels may be more reliable and less likely to generate concerns around inconsistent application of objection procedures or outcomes.
In light of these tradeoffs, we believe that, for all Objection types, Parties should be able to jointly determine whether to use a one or three-expert panel. In the event that the Parties fail to reach agreement the default will be to rely on a three-Expert panel.
Revise string confusion objection procedures to prevent against inconsistent outcomes encountered during the 2012 round
During the 2015 round, the String Confusion Objection process resulted in indirect contention situations for identical strings proposing similar use cases. For example, in one objection determination, the strings .car/.cars were determined to be confusingly similar, while in another they were determined to not be confusingly similar. This resulted in a situation where the ability or inability for the two strings to coexist depended on which party prevailed at auction.
This outcome was seen as inconsistent by many in the community (both objectors and respondents) and saw late stage intervention by the ICANN board to introduce a limited appeals process. The appeals process was only made available to the applicants who were placed in contention, and not to the party filing the objection.
We believe that these could be largely avoided by allowing a single String Confusion Objection to be filed against all applicants for a particular string, rather than requiring a unique objection to be filed against each application. We propose the following guidelines:
• An objector could file a single objection that would extend to all applications for an identical string.
• Given that an objection that encompassed several applications would still require greater work to process and review, the string confusion panel could introduce a tiered pricing structure for these sets.
• Each applicant for that identical string would still prepare a response to the objection.
• The same panel would review all documentation associated with the objection.
• Each response would be reviewed on its own merits to determine whether it was confusingly similar.
The panel would issue a single determination that identified which applications would be in contention. Any outcome that resulted in an indirect contention would be explained as part of the panel’s response.
A limited appeals process (as described above) would be available to both the objectors and the respondents to handle any perceived inconsistencies.
Make the costs of community objections more predictable
The costs associated with Community Objections were surprisingly high compared to other types of objections, and were hard to predict in advance of filing.  This may have been particularly problematic for communities that chose to file objections with a low probability of success.
ICANN should prioritize cost in choosing a vendor.  Costs should be transparent up front to participants in objection processes with a fixed fee absent extraordinary circumstances.
In some cases, applicants should be able to remediate impact identified in Community Objections
In the 2012 round, community objections were “all or nothing”.  Even if the impact to the affected community could be corrected by the applicants, the panel had no option but to either allow the application to proceed or to terminate it.  This made the standard to win an objection quite high, and also meant that some applications that probably could have been remediated were instead rejected.
Allow arbitrator to identify remedies or cures that would address the detriment to the community, which could be adopted by the applicant and would form a binding portion of the eventual registry agreement.
BRG
18
4Afilias concurs with the opinions of the RySG and defers to that response.Afilias
19
5We support the general approach to implement these recommendations through an objection process. However, we note several procedural issues with the implementation of the objection procedures that could be improved in a future application process. The following recommendations are intended to address some of the related procedural deficiencies encountered during the 2012 round.
Strictly enforce objection page limits
One of the factors contributing to the high costs of objections during the 2012 round was a failure of the the panels to curb submission of additional objection documentation. As panels are paid hourly they are incentivized to accept additional documentation even if it was not strictly necessary for the purpose of evaluating the substance of the objection. Further, in some instances, attachments were used to make and support additional arguments not made in the body of the original objection, resulting in additional work and cost to respondents. We believe that the page caps proposed are appropriate and should be more strictly enforced as part of a subsequent application procedure. To these ends, we would welcome additional language clarifying that attachments should be limited to supporting documentation and must not be used to make additional arguments not covered within the 5,000 word/20 page limit and that, following submission of the initial objection, additional documentation will only be accepted if it is specifically requested by the Objection panel.
Allow parties to jointly determine whether to use a one or three-Expert panel
The selection of a one or three-Expert panel raises tradeoffs related to cost and consistency. While one-Expert panels are lower cost, three expert panels may be more reliable and less likely to generate concerns around inconsistent application of objection procedures or outcomes. In light of these tradeoffs, we believe that, for all Objection types, Parties should be able to jointly determine whether to use a one or three-expert panel. In the event that the Parties fail to reach agreement the default will be to rely on a three-Expert panel.
Revise string confusion objection procedures to prevent against inconsistent outcomes encountered during the 2012 round
During the 2015 round, the String Confusion Objection process resulted in indirect contention situations for identical strings proposing similar use cases. For example, in one objection determination, the strings .car/.cars were determined to be confusingly similar, while in another they were determined to not be confusingly similar. This resulted in a situation where the ability or inability for the two strings to coexist depended on which party prevailed at auction. This outcome was seen as inconsistent by many in the community (both objectors and respondents) and saw late stage intervention by the ICANN board to introduce a limited appeals process. The appeals process was only made available to the applicants who were placed in contention, and not to the party filing the objection. We believe that these could be largely avoided by allowing a single String Confusion Objection to be filed against all applicants for a particular string, rather than requiring a unique objection to be filed against each application. We propose the following guidelines:
● An objector could file a single objection that would extend to all applications for an identical string.
● Given that an objection that encompassed several applications would still require greater work to process and review, the string confusion panel could introduce a tiered pricing structure for these sets.
● Each applicant for that identical string would still prepare a response to the objection.
● The same panel would review all documentation associated with the objection.
● Each response would be reviewed on its own merits to determine whether it was
confusingly similar.
The panel would issue a single determination that identified which applications would be in contention. Any outcome that resulted in an indirect contention would be explained as part of the panel’s response. A limited appeals process (as described above) would be available to both the objectors and the respondents to handle any perceived inconsistencies.
Make the costs of community objections more predictable
The costs associated with Community Objections were surprisingly high compared to other types of objections, and were hard to predict in advance of filing. This may have been particularly problematic for communities that chose to file objections with a low probability of success. ICANN should prioritize cost in choosing a vendor. Costs should be transparent up front to participants in objection processes with a fixed fee absent extraordinary circumstances.
In some cases, applicants should be able to remediate impact identified in Community Objections
In the 2012 round, community objections were “all or nothing”. Even if the impact to the affected community could be corrected by the applicants, the panel had no option but to either allow the application to proceed or to terminate it. This made the standard to win an objection quite high, and also meant that some applications that probably could have been remediated were instead rejected.
Allow arbitrator to identify remedies or cures that would address the detriment to the community, which could be adopted by the applicant and would form a binding portion of the eventual registry agreement.
RySG
20
6No. String confusion proved to be problematic and the potential for differing rulings on the same pairs of strings was particularly problematic. A recent report looking at defensive registrations may imply that legal rights protections were not sufficient. The entire issue of community applications and objections needs careful consideration and review.ALAC
21
3.1.3 - Do you believe there were any issues with standing requirements as defined in the Applicant Guidebook (AGB), or as carried out by the providers? Please explain.
22
1The BRG concurs with the RySG comments:
We believe that there is some lack of clarity around how objection by a “significant portion of the community,” as is referenced in Recommendation 20 of the GNSO principles, is defined. This could warrant further clarification. We note that ICANN and the Community Objection Provider established additional definitions and procedures regarding the standing to file a community objection. Per Module 4 of the Applicant Guidebook, standing required that the filer meet the following criteria:
It is an established institution with purposes beyond the gTLD application process (evaluated based upon level of global recognition of the institution;
length of time the institution has been in existence;
and public historical evidence of its existence);
It has an ongoing relationship with a clearly delineated community – (evaluated based upon the presence of mechanisms for participation, institutional purpose and regular activities that benefit of the associated community;
and the level of formal boundaries around the community.
Objectors were required to state their basis for standing, as well as grounds for objection. ICANN performed a 30-day administrative review of the objection before it proceeded to evaluation by the Dispute Resolution Provider. We believe that the administrative review process failed to weed out objections where the objection filer did not meet the conditions to establish standing to file.
We believe that standing requirements were clearly established for the other application types.
BRG
23
2Afilias concurs with the opinions of the RySG and defers to that response.Afilias
24
3We believe that there is some lack of clarity around how objection by a “significant portion of the community,” as is referenced in Recommendation 20 of the GNSO principles, is defined. This could warrant further clarification. We note that ICANN and the Community Objection Provider established additional definitions and procedures regarding the standing to file a community objection. Per Module 4 of the Applicant Guidebook, standing required that the filer meet the following criteria:
It is an established institution with purposes beyond the gTLD application process (evaluated based upon level of global recognition of the institution;
length of time the institution has been in existence;
and public historical evidence of its existence);
It has an ongoing relationship with a clearly delineated community – (evaluated based upon the presence of mechanisms for participation, institutional purpose and regular activities that benefit of the associated community;
and the level of formal boundaries around the community.
Objectors were required to state their basis for standing, as well as grounds for objection. ICANN performed a 30-day administrative review of the objection before it proceeded to evaluation by the Dispute Resolution Provider. We believe that the administrative review process failed to weed out objections where the objection filer did not meet the conditions to establish standing to file.
We believe that standing requirements were clearly established for the other application types.
RySG
25
4No.ALAC
26
3.1.4 - Do you believe there is evidence of decisions made by objection dispute panels that were inconsistent with other similar objections, the original policy recommendations, and/or the AGB? Please explain.

27
1Review of the LRO decisions in the first Round showed that demonstrating bad faith before a registry launches is virtually impossible. In addition to the three factors outlined in the AGB, LRO panels consider eight non-exhaustive factors in determining whether the applied-for string meets one or more of these three grounds for sustaining the objection. In determining intent of the Applicant, the evidence is limited to (a) the use of the applied-for gTLD string or actions by Applicant at the time of the filing of the Application in relation to the applied-for gTLD string, and (b) the Application itself. For additional background, see INTA’s analysis on the ICANN Legal Rights Objection here.
INTA recommends additional work to add additional factors directly into the AGB that would guide Applicants and LRO panels on the concepts of bad faith, including, but not limited to history of the Applicant and the individuals behind the applicant, whether the underlying trademark rights acquired by the Applicant were filed solely with respect to supporting the business of the Application.
INTA
28
2Yes. For string confusion objections, despite conditions being effectively the same, one ICDR panel came to the conclusion that .HOTEL and .HOTELS were not confusingly similar, while another determined that .PET and .PETS were confusingly similar. There were multiple other examples of such inconsistencies, e.g., .CAR and .CARS found not similar, and .GAME and .GAMES similar.
To prevent such results in future rounds, we support allowing a single String Confusion Objection to be filed against all applicants for a particular string, rather than requiring a unique objection to be filed against each application. As stated above, we would also support an appeals process with panels comprised of arbitrators with specific demonstrated experience in new gTLD program objections.
BC
29
3The BRG concurs with the RySG comments:
Yes, we believe that objection processes during the 2012 saw inconsistent outcomes, where different decisions were reached despite similar fact patterns, or where panels appeared to apply different logic and standards in arriving at their decisions.
Introduce appeals process for objections to address inconsistencies.
The perception of inconsistent outcomes led to overreliance on existing accountability mechanisms, particularly the Reconsideration Request process, which was ill suited to address the objection related issues as Reconsideration Requests are intended to address action or inaction by ICANN staff or the ICANN Board and not determinations by a third party panel. This situation was detrimental to applicants, who were left without adequate recourse mechanisms, and the ICANN Board’s Governance Committee, which was inundated by an unprecedented number of reconsideration requests that it could not process on a reasonable time frame.
It also drove the creation of post-decision mechanisms which were only made available to a narrow subset of applicants who faced the most obviously inconsistent determinations. This situation was inadequate to address the larger issues identified above. Further, these opportunities were not made available to all potentially impacted applicants, nor to both sides of the objection. For example certain inconsistent string determinations resulted in the receiving applicant who was placed in contention being able to argue their case for why their application should not be placed in contention; no comparable second opportunity was provided to the complainant to argue why the correct, consistent outcome would be for all identical applications to be placed in contention.
We believe a much better approach is to introduce the option of a narrow appeals process for all applicants where  parties that identify either a reasonable inconsistency in outcome or a specific argument as to why the panel failed to apply the proper standard.  In our response to question 3.5.2 propose below several model for a potential appeals body for consideration:
Inconsistencies were most obvious in the String Confusion Objection Process, which resulted in indirect contention situations for identical strings proposing similar use cases. For example, in one objection determination, the strings .car/.cars were determined to be confusingly similar, while in another they were determined to not be confusingly similar. This resulted in a situation where the ability or inability for the two strings to coexist depended on which party prevailed at auction.
This outcome was seen as inconsistent by many in the community (both objectors and respondents) and saw late stage intervention by the ICANN board to introduce a limited appeals process. The appeals process was only made available to the applicants who were placed in contention, and not to the party filing the objection.
The inconsistent results process has been extended to other objection results as well (e.g. .hospital (Limited Public Interest) and .Charity) community.  ICANN should strive to avoid inconsistent results for similarly situated applicants in all objections.  
Revise String Confusion Objection Process to Minimize Inconsistencies
Our recommendations for improvements to the String Confusion Objection Procedures described in question 3.1.2 and repeated below attempt to ameliorate these inconsistent outcomes.
We believe that these could be largely avoided by allowing a single String Confusion Objection to optionally be filed against all applicants for a particular string, rather than requiring a unique objection to be filed against each application. Specific recommendations for how these processes could be revised are set forth in our response to 3.1.2 .
BRG
30
4Afilias concurs with the opinions of the RySG and defers to that response.Afilias
31
5Yes, we believe that objection processes during the 2012 saw inconsistent outcomes, where different decisions were reached despite similar fact patterns, or where panels appeared to apply different logic and standards in arriving at their decisions.
Introduce appeals process for objections to address inconsistencies.
The perception of inconsistent outcomes led to overreliance on existing accountability mechanisms, particularly the Reconsideration Request process, which was ill suited to address the objection related issues as Reconsideration Requests are intended to address action or inaction by ICANN staff or the ICANN Board and not determinations by a third party panel. This situation was detrimental to applicants, who were left without adequate recourse mechanisms, and the ICANN Board’s Governance Committee, which was inundated by an unprecedented number of reconsideration requests that it could not process on a reasonable time frame. It also drove the creation of post-decision mechanisms which were only made available to a narrow subset of applicants who faced the most obviously inconsistent determinations. This situation was inadequate to address the larger issues identified above. Further, these opportunities were not made available to all potentially impacted applicants, nor to both sides of the objection. For example certain inconsistent string determinations resulted in the receiving applicant who was placed in contention being able to argue their case for why their application should not be placed in contention; no comparable second opportunity was provided to the complainant to argue why the correct, consistent outcome would be for all identical applications to be placed in contention. We believe a much better approach is to introduce the option of a narrow appeals process for all applicants where parties that identify either a reasonable inconsistency in outcome or a specific argument as to why the panel failed to apply the proper standard. In our response to question 3.5.2 propose below several model for a potential appeals body for consideration: Inconsistencies were most obvious in the String Confusion Objection Process, which resulted in indirect contention situations for identical strings proposing similar use cases. For example, in one objection determination, the strings .car/.cars were determined to be confusingly similar, while in another they were determined to not be confusingly similar. This resulted in a situation where the ability or inability for the two strings to coexist depended on which party prevailed at auction. This outcome was seen as inconsistent by many in the community (both objectors and respondents) and saw late stage intervention by the ICANN board to introduce a limited appeals process. The appeals process was only made available to the applicants who were placed in contention, and not to the party filing the objection. The inconsistent results process has been extended to other objection results as well (e.g. .hospital (Limited Public Interest) and .Charity) community. ICANN should strive to avoid inconsistent results for similarly situated applicants in all objections.
Revise String Confusion Objection Process to Minimize Inconsistencies
Our recommendations for improvements to the String Confusion Objection Procedures described in question 3.1.2 and repeated below attempt to ameliorate these inconsistent outcomes. We believe that these could be largely avoided by allowing a single String Confusion Objection to optionally be filed against all applicants for a particular string, rather than requiring a unique objection to be filed against each application. Specific recommendations for how these processes could be revised are set forth in our response to 3.1.2 .
RySG
32
3.1.5 - Are you aware of any instances where any party or parties attempted to ‘game’ the Objection procedures in the 2012 round? If so, please provide examples and any evidence you may have available.
33
1A form of gaming that attempted to take place was an effort to force a community applicant into a Community Objection when achieving “standing” for the objector was a known impossibility due to deceptive representation. The purpose for objecting appears to be related to financially burdening dotgay LLC (dotgay) and projecting fake opposition to a communitybased application for .GAY.
Both community objections against dotgay came from the same network of political organizations in the USA, one claiming to represent the national organization and one from an affiliate member organization in Dallas. The contents of each objection were similar and in many cases verbatim in wording. Having two similar objections from two sources knowing of one another is in itself suspect, especially given the potential cost to each to pursue the filings.
Potential impacts to dotgay included paying a non-refundable 5,000 euro administrative fee to the ICC per objection, tying up a deposit of 40,000 plus euros to respond to each objection, as well as creating the false impression that organized community opposition existed against the application. Consolidation of objections was never an ICC guarantee and dotgay is aware of weak excuses that prevented objections from being consolidated, even when near identical. For community applicants that don’t have deep pockets, this form of gaming could knock them out of the new gTLD program. This is especially true given the deposit required for each objection and the fact that all community objections happen simultaneously giving no opportunity to spread out the costs. Some may not be able to front hundreds of thousands of dollars to expose deceptive representation.
This form of gaming went unchecked under the current procedures. No process existed to defend against a spurious objection without first formalizing the objection and making payment to the ICC. To submit a community objection that has no hope of achieving “standing” raises serious questions of gaming, especially given the associated costs the objector (or the party financially supporting them) would be expending on an objection known to be deficient.
Example:
A community objection was filed against dotgay by a person who was fraudulently claiming to represent a community organization called GoProud. By simply writing an organization name on the ICC objection form, the opposing individual fulfilled one of the basic requirements for submitting a community objection (ie. that it come from an organization). There appears to have been no effort made by the ICC to verify truth in this representation at the time of filing. What did happen however is that the ICC used the info@goproud.org email (noted on the objection) to reach back to the objector to highlight that they had exceeded word count on the objection, asking it be corrected. The objector did not respond in time, later claiming he never received the email. The objector used an AOL email account to file the objection, and in fact never used an @goproud.org email at any point in his attempt to object.
Current procedures call for the objecting organization to be scrutinized for “standing,” but only when the panelist is assigned and the evaluation is underway. It is also unclear what actions are taken by the panelist to ensure legitimacy of the person objecting and their link/authority at the organization they claim to represent. The current flaw we identify is that individuals have the ability to use any unknowing organization’s name to object and likely have a good chance of at least forcing an applicant into paying a filing fee and deposit in order to respond.
The problem here is that by simply listing an organization on a community objection (whether large, small, significant, insignificant, real, nefarious, legal, fraudulent, etc) it is possible to force a community applicant into responding to an objection. Some standards and criteria should be applied to protect applicants from being gamed in this manner.
Fortunately in our case, the objection was rejected by the ICC because of a rule violation on word length by the objector (or the party that wrote the objection on his behalf). This initiated a series of accountability mechanisms undertaken by the objecting party that provided dotgay ample time to uncover that the GoProud organization had no knowledge their name was being used by the objector. The 5,000 euro filing fee was not paid by GoProud, nor was the individual that paid the filing fee known to the GoProud organization.
Accountability mechanisms were employed by the objector in an attempt to get his objection acknowledged by the ICC. Both the ICANN Ombudsman and ICANN Board separately engaged in efforts to provide opportunity for the objection to be accepted by the ICC, despite the rule violation and despite suspicion of fraud identified by dotgay. The ICC affirmed their prior decision to reject the objection and a Reconsideration Request was filed by the objector.
Requests by dotgay for someone (ICC or ICANN) to simply confirm authenticity of the objection with leadership at GoProud (via phone or email) were ignored by the ICC and by ICANN during the Reconsideration Request proceedings. Knowing if the objection was truly from GoProud could have quickly ended the ongoing fraudulent activity.
In the end, all responsibility was left on the community applicant to convince GoProud leadership to submit a written statement to ICANN to end the objection and highlight that GoProud’s name was being used without their authority. Having no prior knowledge or involvement with ICANN or the objection in question, the request was quite odd for dotgay to make of GoProud and required extensive time and money to help them understand what was taking place behind their backs. This is something the ICC or ICANN could have addressed
quickly through outreach, but both chose not to.
The GoProud statement provided to ICANN noted that the individual who submitted the objection had no authority to represent their organization or use their name on an objection. Eventually the NGPC rejected the objector’s Reconsideration Request, in part because of exposure dotgay brought to the situation during accountability mechanism delays. In rejecting
it, the NGPC made no mention about the objection being submitted fraudulently; instead choosing only to note that GoProud had “absolved itself from the community objection” instead of a using a more clear statement that GoProud never actually objected in the first place. Had there not been a rule violation by the objector, dotgay would have been forced into responding to a fraudulent objection in short order. Only because of unforeseen accountability delays did dotgay get provided time to investigate and reveal the fraudulent actions, but if no rule violation had occurred, dotgay would have been required to pay and respond. It should also be noted that the “free” public comment period on ICANN’s website was not used by this individual in advance of fraudulently using GoProud’s name to file an objection.
Conclusion:
More needs to be done to prevent this type of gaming, which includes immeasurable impacts of misrepresented opposition (which in our case received wide media coverage) and unnecessary expenses targeted at community applicants. If unchecked, this type of gaming will likely continue, and perhaps become more pervasive in subsequent rounds.
I am happy to share more of the details involved or point the working group to the background documents discussed in this example. Some documents and correspondences are not public because of ICANN or ICC confidentiality rules, however if needed we presume a request could be made to ICANN or the ICC to have them released for review.
Suggestions:
We believe that some preliminary steps should be implemented to screen the source of community objections so as to ensure that organizations listed on the objections are:
1. Legitimate organizations that meet basic requirements for “standing”
2. Aware & approving of the objection – via multiple contacts at the organization, using published and legitimate contact methods for the organization
3. Actively engaged & educated on the opposition and not simply surrogates for purposes of gaming
Taking these simple steps with the filing fee funds of those who filed the opposition could prevent a lot of unnecessary expense to community applicants. If additional cost to determine standing is required then a portion of the deposit could be paid by the objector to cover the costs of solidifying standing. If standing is achieved then the funds go back into their objection deposit.
By weeding out frivolous and fraudulent objections that have no chance of meeting standing requirements, before ever forcing community applicants to pay a filing fee and respond, would save everyone a lot of time, energy and money. It would also serve as a line of defense against coordinated efforts aimed at financially drowning out community applicants.
dotgay LLC
34
2Afilias concurs with the opinions of the RySG and defers to that response.Afilias
35
3While we believe that there may have been some instances of gaming objections during the 2012 round, we will defer to individual comments to raise specific examples.
We note one recommendation that we believe will reduce the likelihood of gaming generally with respect to the Community objection process:
Communities should be limited to participating in either Objections or CPE, but not both.
During the 2012 round, some entities who were involved in TLD applications took "two bites of the apple" by filing both objections and participating in CPE for the same strings. This meant that they had two opportunities to potentially defeat a competitive application. We don’t believe this matches the intent of the policy or the guidebook.
No individual entity should be able to participate in both an objection and CPE for the same string.
RySG
36
3.1.6 - Do you believe that the use of an Independent Objector (IO) is warranted in future application processes? If not, then why? If yes, then would you propose any restrictions or modifications be placed on the IO in future rounds?

37
1Yes, or you could consider the implementation of a review process involving experienced or groups of team members. Such a quality control process is used in Nominet’s Dispute Resolution Service.Nominet
38
2The Independent Objector is not warranted in future application processes.
The IO was created during implementation of the last expansion, and was not designed or approved in the GNSO policy-making process.
The IO was paid from applicant fees, but did not prove beneficial to applicants. The IO was not independent, was politically or personally motivated, and did not accomplish their stated work.
The IO filed 19 objections, won two decisions, at a million dollars per objection, with a success rate of 2% (https://newgtlds.icann.org/en/program-status/odr/determination). Two cases, .hospital and .charity, were also changed later.
BC
39
3The BRG concurs with the RySG comments:
The Independent Objector could fill an important theoretical function in its ability to relay potential objections from third parties that would not otherwise have the financial capability to do so. However, in the 2012 Round, the behavior of the Independent Objector deviated from this function; the Independent Objector appeared to have an activist agenda, rather than hearing, filtering, and advancing concerns of third parties that would otherwise not have been able to file on their own. Further, the Independent Objector’s behavior in the 2012 round raised questions of whether Conflict of Interest Procedures and other procedural guidelines were appropriately applied. We believe the following recommendations could help address issues faced related to the office of the independent objector.
Require established support for objections by the Independent Objector
In the 2012 Round the Independent Objector appeared to act on an independent agenda that was not supported by the public, nor by particular affected parties that would have not been able to file an objection. Further, the low success rate for objections filed by the Independent Objector raises questions of whether concerns raised by the objected-to strings were sufficiently clear-cut to warrant objection through this process, particularly given the high cost of this office to ICANN.
As part of the objection filing process the Independent Objector should be required to name one or more parties that initiated or support the objection but would otherwise be unable to file, in addition to meeting all other criteria for objection (e.g. affirmation that filing the objection is in the public interest).
Establish clear Conflict of Interest Procedures for the office of the Independent Objector
The 2012 round witnessed potential Conflicts of Interest related to objections filed by the Independent Objector. While the conflicts were ultimately resolved, the failure to establish clear conflict of interest guidelines for the office of the Independent Objector at the outset resulted in additional delay and cost to affected parties. The lack of clear Conflict of Interest Procedures for the office of the Independent Objector in the Applicant Guidebook contradicts with the approach taken for other independent parties engaged in the application process, including application evaluators and objection evaluation panels.
In light of this experience and in line with the overall goals of the program ICANN should implement a clear conflict of interest policy and associated procedures for the Independent Objector. The Conflict of Interest Guidelines used for application evaluators may be used as a model for these procedures.
Require Independent Objector to withdraw duplicate objections
The 2012 Applicant Guidebook provided that, absent extraordinary circumstances, the IO should not be permitted to file an objection against an application was already filed on the same ground. We strongly support the principle but do not believe it was fully adhered to by the Independent Objector, who maintained some of his objections while third party objections against the same string and on the same grounds were pending and failed to defend why this followed from extraordinary circumstances.
We urge strict adherence to this principle in a future round and recommending removing the carve out for extraordinary circumstances, as we do not believe that this standard was met or defended during the 2012 Round.
BRG
40
4Afilias concurs with the opinions of the RySG and defers to that response.Afilias
41
5The Independent Objector could fill an important theoretical function in its ability to relay potential objections from third parties that would not otherwise have the financial capability to do so. However, in the 2012 Round, the behavior of the Independent Objector deviated from this function; the Independent Objector appeared to have an activist agenda, rather than hearing, filtering, and advancing concerns of third parties that would otherwise not have been able to file on their own. Further, the Independent Objector’s behavior in the 2012 round raised questions of whether Conflict of Interest Procedures and other procedural guidelines were appropriately applied. We believe the following recommendations could help address issues faced related to the office of the independent objector. Require established support for objections by the Independent Objector
In the 2012 Round the Independent Objector appeared to act on an independent agenda that was not supported by the public, nor by particular affected parties that would have not been able to file an objection. Further, the low success rate for objections filed by the Independent Objector raises questions of whether concerns raised by the objected-to strings were sufficiently clear-cut to warrant objection through this process, particularly given the high cost of this office to ICANN. As part of the objection filing process the Independent Objector should be required to name one or more parties that initiated or support the objection but would otherwise be unable to file, in addition to meeting all other criteria for objection (e.g. affirmation that filing the objection is in the public interest). Establish clear Conflict of Interest Procedures for the office of the Independent Objector
The 2012 round witnessed potential Conflicts of Interest related to objections filed by the Independent Objector. While the conflicts were ultimately resolved, the failure to establish clear conflict of interest guidelines for the office of the Independent Objector at the outset resulted in additional delay and cost to affected parties. The lack of clear Conflict of Interest Procedures for the office of the Independent Objector in the Applicant Guidebook contradicts with the approach taken for other independent parties engaged in the application process, including application evaluators and objection evaluation panels. In light of this experience and in line with the overall goals of the program ICANN should implement a clear conflict of interest policy and associated procedures for the Independent Objector. The Conflict of Interest Guidelines used for application evaluators may be used as a model for these procedures.
Require Independent Objector to withdraw duplicate objections
The 2012 Applicant Guidebook provided that, absent extraordinary circumstances, the IO should not be permitted to file an objection against an application was already filed on the same ground. We strongly support the principle but do not believe it was fully adhered to by the Independent Objector, who maintained some of his objections while third party objections against the same string and on the same grounds were pending and failed to defend why this followed from extraordinary circumstances. We urge strict adherence to this principle in a future round and recommending removing the carve out for extraordinary circumstances, as we do not believe that this standard was met or defended during the 2012 Round.
RySG
42
6The use of an IO is still warranted. However, there were allegations of lack of objectivity in the first round and steps must be taken to ensure that the IO is beyond reproach.ALAC
43
7The Independent Objector continues to fill an important theoretical function in its ability to relay potential objections from third parties that would not otherwise have the financial capability to do so. However, in the 2012 Round, the behavior of the Independent Objector deviated from this intended function; the Independent Objector appeared to have an, activist agenda, rather than hearing, filtering, and advancing concerns of third parties that would otherwise not have been able to file on their own. Further, the Independent Objector’s behavior in the 2012 Round raised questions of whether Conflict of Interest Procedures and other procedural guidelines were appropriately applied.
Require established support for objections by the Independent Objector
Issue: In the 2012 Round the Independent Objector appeared to act on an independent agenda that was not supported by the public, nor by particular affected parties that would have not been able to file an objection. Further, the low success rate for objections filed by the Independent Objector raises questions of whether concerns raised by the objected-to strings were sufficiently clear-cut to warrant objection through this process, particularly given the high cost of this office to ICANN.
Recommendations: As part of the objection filing process the Independent Objector should be required to name one or more parties that initiated or support the objection but would otherwise be unable to file, in addition to meeting all other criteria for objection (e.g. affirmation that filing the objection is in the public interest).
Establish clear Conflict of Interest Procedures for the office of the Independent Objector
Issue: The 2012 Round witnessed potential Conflicts of Interest related to objections filed by the Independent Objector. While the conflicts were ultimately resolved, the failure to establish clear conflict of interest guidelines for the office of the Independent Objector at the outset resulted in additional delay and cost to affected parties. The lack of clear Conflict of Interest Procedures for the office of the Independent Objector in the Applicant Guidebook contradicts with the approach taken for other independent parties engaged in the application process, including application evaluators and objection evaluation panels.
Recommendation: In light of this experience and in line with the overall goals of the program ICANN should implement a clear conflict of interest policy and associated procedures for the Independent Objector. The Conflict of Interest Guidelines used for application evaluators may be used as a model for these procedures.
Require Independent Objector to withdraw duplicate objections
Issue: The 2012 Applicant Guidebook provided that, absent extraordinary circumstances, the IO should not be permitted to file an objection against an application was already filed on the same ground. We strongly support the principle but do not believe it was fully adhered to by the Independent Objector, who maintained some of his objections while third party objections against the same string and on the same grounds were pending and failed to defend why this followed from extraordinary circumstances.
Recommendation: We urge strict adherence to this principle in a future round and recommending removing the carve out for extraordinary circumstances, as we do not believe that this standard was met or defended during the 2012 Round.
RySG letter
**Note: this document was not submitted as part of CC2
44
3.1.7 - Do you believe that parties to disputes should be able to choose between 1 and 3 member panels and should the costs of objections reflect that choice?

45
1The BRG concurs with the RySG comments:
As set forth in our recommendations in response to question 3.1.2 we believe that parties should be able to jointly determine whether to use a one or three-Expert panel.
The selection of a one or three-Expert panel raises tradeoffs related to cost and consistency. While one-Expert panels are lower cost, three expert panels may be more reliable and less likely to generate concerns around inconsistent application of objection procedures or outcomes. In light of these tradeoffs, we believe that, for all Objection types, Parties should be able to jointly determine whether to use a one or three-expert panel.
In the event that the Parties fail to reach agreement the default should be to rely on a three-Expert panel.
BRG
46
2Afilias concurs with the opinions of the RySG and defers to that response.Afilias
47
3As set forth in our recommendations in response to question 3.1.2 we believe that parties should be able to jointly determine whether to use a one or three-Expert panel.
The selection of a one or three-Expert panel raises tradeoffs related to cost and consistency. While one-Expert panels are lower cost, three expert panels may be more reliable and less likely to generate concerns around inconsistent application of objection procedures or outcomes. In light of these tradeoffs, we believe that, for all Objection types, Parties should be able to jointly determine whether to use a one or three-expert panel.
In the event that the Parties fail to reach agreement the default should be to rely on a three-Expert panel.
RySG
48
4Allow parties to jointly determine whether to use a one or three-Expert panel
Issue: The selection of a one or three-Expert panel raises tradeoffs related to cost and consistency. While one-Expert panels are lower cost, three expert panels may be more reliable and less likely to generate concerns around inconsistent application of objection procedures or outcomes.
Recommendation: In light of these tradeoffs, we believe that, for all Objection types, Parties should be able to jointly determine whether to use a one or three-expert panel. In the event that the Parties fail to reach agreement the default will be to rely on a three-Expert panel.
RySG letter
**Note: this document was not submitted as part of CC2
49
3.1.8. - Is clearer guidance needed in regards to consolidation of objections? Please explain.

50
1Yes. Clearer guidance should be given for objection consolidation.
The community objection proceedings exist as the primary method for community organizations to defend against gTLD applications they deem harmful to their communities.
However, objections are only offered for a cost that some communities may find challenging to afford if faced with the reality of multiple and problematic strings/applications intersecting their communities. Objection consolidation suggested a form of financial relief, but without assurances that consolidation will be effectively utilized to keep costs from becoming a barrier to engagement, the current guidance offers no value to community objectors.
Before costs for community objections are established for subsequent rounds, clearer guidance is needed to encourage and clarify circumstances that generally and specifically warrant consolidation. DRSP’s must agree to follow such guidance and some form of quality control standards must be established. This would not only ensure community objections remain focused on serving their intended purpose of addressing potential community harm, but it would also provide guidance and predictability to community organizations that may be extending themselves to simply engage.
What should be avoided is forcing a community organization to choose between which string/application they will object to from several they find problematic simply because they cannot fund multiple objections, especially when the organization is identifying similar harm(s) in each objection submitted. This can help ensure community interest is not stripped from the community objection process simply because some communities have less wealth.
Example of how poor guidance caused unnecessary financial burden:
ILGA is a community organization that found potential harm in several applications for strings intersecting their defined community. The harm identified was consistent in each application.
Despite ILGA using near exact wording in their objections filed against three .GAY and one .LGBT applications, the DRSP decided against consolidating the objections, forcing deposits and
eventual payment of four separate objections.
The current guidance merely states that “ICANN continues to strongly encourage all of the DRSPs to consolidate matters whenever practicable," yet this was not received by the DRSP as clear or predictable guidance. In addition, the AGB says the DRSP “will weight the efficiencies in time, money, effort, and consistency” when determining consolidation, despite having any quality control in place to ensure it happens.
Although the DRSP sent an early signal that consolidation of ILGA’s objections was being considered, the DRSP then sought comment from all parties involved. Opposition from some applicants was expressed, suggesting concern that consolidation would expose financial details of their applications to others in the consolidation set. This concern had no basis since the objections had nothing to do with the financial aspect of the applications. After first deciding .LGBT would not be consolidated with .GAY, the DRSP later decided that not even the .GAY
objections would be consolidated.
However, the DRSP did decide the three .GAY and one .LGBT objection would all be handled by the same panelist, despite denying consolidation. Although it seems the DRSP weighed “efficiencies in time, money, effort, and consistency” in assigning one panelist to all objections, the cost to the community organization objecting did not match the actions of the DRSP.
All .GAY decisions from the panelist were extremely similar, perhaps the simple proof that consolidation was warranted and that it was unnecessary for ILGA to pay for each objection separately. A comparative analysis of the results shows that in most cases a simple swapping of the applicant name is the only variance in the panelist’s decisions. .GAY Objection Results: Case No. EXP/392/ICANN/9; Case No. EXP/393/ICANN/10; Case No. EXP/394/ICANN/11
Comparative Analysis of Results (by bullet points):
a. Procedure: 1-5 vary only by Applicant administrative details
b. Objector’s Position: 6-10 (only variance appears in #8 of one result because of an additional concern ILGA included in their objection against one of the applications)
c. Applicants Position: 11-12 or 11-13 (vary based on applicant response)
d. Findings: 13-31 or 14-32 are virtually verbatim for all
A review of all three .GAY objection results reveals that approximately 90% or more of the bullet points contained in each result are identical. Aside from administrative uniqueness required to properly identify the applicant in each result, there was little else that made each result distinctly different from the others.
Because only the objection decisions are publicly available it is difficult to provide illustrations for comparison here, however we believe ILGA would be willing to make their community objections public for further review if ICANN and the DRSP approve.
Although the AGB suggested that similar objections against an application could be consolidated, it did not dismiss that similar objections from one entity or against the same string could also be consolidated. The community objection process already puts great burden on community organizations seeking to defend against harm for their members and it’s made more challenging because of cost, lack of experience with ICANN processes, and ICANN imposed timelines that some community organizations (including non-profits and social service providers) are challenged to function within. If consolidation is truly intended to serve the purpose stated in the AGB, it should not be a one sided benefit that is not considerate of community organizations and the role they play in the community objection procedures. Clear guidance on consolidation, which also takes into consideration the interests and perspectives of the community organization that may be objecting, is something that requires an honest discussion and resulting predictability.
dotgay LLC
51
2The BRG concurs with the RySG comments:
While we for most objection types consolidating objections is difficult given the ability for applicants for a single string to propose vastly different business models, we believe that for string confusion objections, a model in which objections are filed against strings (consolidating all applications for that string by default) would be preferable and would ameliorate inconsistent outcomes witnessed as part of the String Confusion Objection Process.
We propose the following guidelines:
• An objector could file a single objection that would extend to all applications for an identical string.
• Given that an objection that encompassed several applications would still require greater work to process and review, the string confusion panel could introduce a tiered pricing structure for these sets.
• Each applicant for that identical string would still prepare a response to the objection.
• The same panel would review all documentation associated with the objection.
• Each response would be reviewed on its own merits to determine whether it was confusingly similar.
• The panel would issue a single determination that identified which applications would be in contention. Any outcome that resulted in an indirect contention would be explained as part of the panel’s response.
• A limited appeals process (as described above) would be available to both the objectors and the respondents to handle any perceived inconsistencies.
BRG
52
3Afilias concurs with the opinions of the RySG and defers to that response.Afilias
53
4While we for most objection types consolidating objections is difficult given the ability for applicants for a single string to propose vastly different business models, we believe that for string confusion objections, a model in which objections are filed against strings (consolidating all applications for that string by default) would be preferable and would ameliorate inconsistent outcomes witnessed as part of the String Confusion Objection Process. We propose the following guidelines:
● An objector could file a single objection that would extend to all applications for an identical string.
● Given that an objection that encompassed several applications would still require greater work to process and review, the string confusion panel could introduce a tiered pricing structure for these sets.
● Each applicant for that identical string would still prepare a response to the objection.
● The same panel would review all documentation associated with the objection.
● Each response would be reviewed on its own merits to determine whether it was confusingly similar.
● The panel would issue a single determination that identified which applications would be in contention. Any outcome that resulted in an indirect contention would be explained as part of the panel’s response.
● A limited appeals process (as described above) would be available to both the objectors and the respondents to handle any perceived inconsistencies.
RySG
54
5Allow Parties to jointly determine whether objections involving the same strings and grounds should be consolidated.
Issue: The 2012 Round allowed the Dispute Resolution Provider to determine whether objections should be consolidated without a clear standard for what situations will warrant consolidation. While a few objections were consolidated, many objections against identical strings were not. Another concern was raised by the emergence of seemingly inconsistent outcomes for highly-similar objections against identical strings that were not consolidated.
Recommendation: As the panel may have incentives or disincentives to consolidate an objection, particularly related to fees, we believe that the objector and respondent should, instead, jointly determine whether objections against identical strings and of the same objection type should be consolidated. If the Parties cannot reach an agreement as to whether the objection should be consolidated, the Dispute Resolution shall determine whether to consolidate the objection and will be expected to provide a short, written defense of its decision. Regardless of whether objections are consolidated, all objections of a single type, filed against identical strings, should be evaluated by the same Expert(s) to minimize the potential for perception of inconsistent outcomes.
RySG letter
**Note: this document was not submitted as part of CC2
55
3.1.9 - Many community members have highlighted the high costs of objections. Do you believe that the costs of objections created a negative impact on their usage? If so, do you have suggestions for improving this issue? Are there issues beyond cost that might impact access, by various parties, to objections?


56
1As suggested above, perhaps creating a better structure to community objections and associated costs is worth a look.
As noted above, for community objections all money was collected from both parties before anyone ever sat down to examine whether “standing” of the objector was even substantiated. Without “standing” there was ultimately no need to dive into the argument of the objection and engage panelists at a higher level, because panelist findings would be a moot point without standing in the current process for upholding objections.
This is especially important to note given that ICANN has told dotgay on multiple occasions that panel decisions in community objections carry no specific weight or precedent in any other contention resolution proceedings that might follow, such as CPE. Given ICANN’s view and our own experiences that followed the community objection proceedings, it seems like any community objection decision is worthless outside of the community objection process itself. If standing of the objector cannot be established then it seems there is no legitimate reason to force a panelist to even examine or rule on a community objection that lacks “standing.”
Determining “standing” up front also helps prevent any hint of fake or fraudulent opposition against a community application that could be used in the media or other mediums to negatively impact perception or opinion of the community applicant, either within the community or future evaluation processes.
Suggestion:
Given that standing was a key element in community objections, with discernable boundaries, it is a step in the process that could likely be separated from the other criteria under its own cost structure and stage in the overall community objection process. Let the objector bear the brunt of the fees until it can be established that they are legitimate and with proper standing to object. In some cases, having a stage for determination on standing as a first step also provides the community applicant with a reasonable amount of time to try and resolve the issues rooted in the opposition being charged in the formal objection, similar to the Cooperative Engagement Process (CEP) currently used at ICANN.
The current process provides little to no opportunity for community applicants to engage or react in good faith to the opposition, or properly educate the objector about the application details to avoid misunderstandings and misrepresentations contained in the objection. In our case, outreach to parties objecting to dotgay’s application was met with silence, leading us to further concerns about the authenticity of the objections. Requiring a period similar to CEP also helps weed out any fake, frivolous or fraudulent objections, and ultimately helps avoid any unnecessary costs.
dotgay LLC
57
2Costs:
We believe that the cost of objections was a barrier to access and engagement. This is based on the limited number of community objections filed by gay community groups from the hundreds that expressed ongoing concern to dotgay LLC about applications they deemed harmful to the LGBTQIA population.
In our journey of community engagement and building consensus with the .GAY community application, we received a tremendous amount of feedback from community organizations expressing deep concern and shock with the cost schedule. The organizations ranged from nonprofits, charitable causes and service provider groups to name a few, many making it clear they would be priced out of delivering filing fees and deposits in order to challenge applications they deemed harmful to members of the gay community.
Considering that future gTLD applications have the potential to raise concerns of harm in the purview of communities that are not well resourced, community objections must not price out community organizations that are willing or obliged to speak up on behalf of their members.
Not all communities have wealth and resources, so the community objection process must fully and properly consider this and address how some communities may be subject to further marginalization due to access limitations.
Although there are some features to the objection proceedings that do offer aid or relief, such as the independent objector and objection consolidation, these features are worthless unless there is awareness beyond the ICANN community and clearer guidance on when and where costs can be minimized or become less of a barrier to access. Simply making the objection proceedings and related methods of relief available does not automatically fulfil the goals of addressing harm in applications, especially if access for those expected to engage continues to be unattainable because due to lack of awareness.
Awareness:
As a community applicant that engaged with the gay community in all reaches of the globe during application development for .GAY, we consistently found ourselves being the first to bring LGBTQIA organization awareness to the new gTLD program and ICANN’s objection proceedings. Our concern is that other communities without such links to the new gTLD program will remain among the most vulnerable and the most at risk in subsequent procedures, especially if strings associated with their community are knowingly or unknowingly selected by applicants without community dialogue or full consideration of potential harm. The community objection proceedings should avoid becoming a mere dog and pony show that gives the impression that community objection is being taken seriously (for a price), and instead focus on ensuring real access for community organizations as a true instrument to mitigate harm. If only voices and concerns of wealthy community organizations are able to access, are the community objection procedures accomplishing their goals?
Since access is the critical component for objecting community parties to address perceived harm in new gTLD applications, more must be done to open that access. This includes an evaluation of the costs and opportunities that could ensure concerns from community organizations are accepted and considered, regardless of the objecting organization’s financial capabilities. Addressing and combating potential harm should not remain the priority.
dotgay LLC
58
3NABP recommends that the cost of a community-based objection be reduced to avoid being an obstacle preventing communities from filing objections. According to the recent Council of Europe report, “Applications to ICANN for Community-Based New Generic Top Level Domains (gTLDs): Opportunities and Challenges from a Human Rights Perspective,” the cost to file a community-based objection during the 2012 round amounted to “hundreds of thousands of dollars for a single objection.” The amount was even higher if the objector opted for a three person panel of evaluators.
This expense is prohibitive – especially for legitimate long-standing nonprofit communities. As stated in the Council of Europe report: “non-profits were severely limited in filing objections due to the excessive costs.” NABP supports to Council of Europe report recommendation to ICANN to “lower the costs for Community Objection” for legitimate industry associations and communities.
Further complicating the matter is that the cost to file a community-based objection was not clear because it was based on variables including the time the evaluators took to consider the matter. Nor is an approximate cost disclosed in the Applicant Guidebook. NABP supports the Council of Europe report recommendation to ICANN to “provide clarity on the expected costs for Community Objection.” It should be possible to at least provide guidance on approximate costs based on an assessment of experiences of round 1.
Rules pertaining to the objector’s standing contributed to the cost of a community-based objection being prohibitive. Established institutions associated with a clearly-defined community could file a community-based objection only as an individual organization, not jointly with other organizations in the same community. If the objector’s goal is to prove substantial opposition from a significant portion of the community, it seems logical for ICANN to allow an objection to be filed jointly by organizations within the community. For this reason, NABP supports the Council of Europe report recommendation to ICANN to “assess whether it is desirable and feasible to open up the possibility to collectively file a Community Objection.”
NABP
59
4The Consortium recommends that the cost of a community-based objection be reduced to avoid being an obstacle preventing communities from filing objections. According to the recent Council of Europe report, “Applications to ICANN for Community-Based New Generic Top Level Domains (gTLDs): Opportunities and Challenges from a Human Rights Perspective,” the cost to file a community-based objection during the 2012 round amounted to “hundreds of thousands of dollars for a single objection.” The amount was even higher if the objector opted for a three- person panel of evaluators. This expense is prohibitive – especially for legitimate long-standing nonprofit communities. As stated in the Council of Europe report: “non-profits were severely limited in filing objections due to the excessive costs.” The Consortium supports the Council of Europe report recommendation to ICANN to “lower the costs for Community Objection” for legitimate industry associations and communities.
Further complicating the matter is that the cost to file a community-based objection was not clear because it was based on variables including the time the evaluators took to consider the matter. Nor is an approximate cost disclosed in the Applicant Guidebook. The Consortium supports to Council of Europe report recommendation to ICANN to “provide clarity on the expected costs for Community Objection.” It should be possible to at least provide guidance on approximate costs based on an assessment of experiences of the 2012 round.
Rules pertaining to the objector’s standing contributed to the cost of a community-based objection being prohibitive. Established institutions associated with a clearly-defined community could file a community-based objection only as an individual organization, not jointly with other organizations in the same community. If the objector’s goal is to prove substantial opposition from a significant portion of the community, it seems logical for ICANN to allow an objection to be filed jointly by organizations within the community. For this reason, the Consortium supports the Council of Europe report recommendation to ICANN to “assess whether it is desirable and feasible to open up the possibility to collectively file a Community Objection.”
vTLD Consortium
60
5The BRG concurs with the RySG comments:
As noted in our response to question 3.1.2 The costs associated with Community Objections were surprisingly high compared to other types of objections, and were hard to predict in advance of filing. This may have been particularly problematic for communities that chose to file objections with a low probability of success.
ICANN should prioritize cost in choosing a vendor. Costs should be transparent up front to participants in objection processes with a fixed fee absent extraordinary circumstances.
We also believe that stricter enforcement of the page caps established for the objections will help to address issues related to cost. One of the factors contributing to the high costs of objections during the 2012 round was a failure of the the panels to curb submission of additional objection documentation. As panels are paid hourly they are incentivized to accept additional documentation even if it was not strictly necessary for the purpose of evaluating the substance of the objection. Further, in some instances, attachments were used to make and support additional arguments not made in the body of the original objection, resulting in additional work and cost to respondents.
We believe that the page caps proposed are appropriate and should be more strictly enforced as part of a subsequent application procedure. To these ends, we would welcome additional language clarifying that attachments should be limited to supporting documentation and must not be used to make additional arguments not covered within the 5,000 word/20 page limit and that, following submission of the initial objection, additional documentation will only be accepted if it is specifically requested by the Objection panel.
BRG
61
6Afilias concurs with the opinions of the RySG and defers to that response.Afilias
62
7As noted in our response to question 3.1.2 The costs associated with Community Objections were surprisingly high compared to other types of objections, and were hard to predict in advance of filing. This may have been particularly problematic for communities that chose to file objections with a low probability of success.
ICANN should prioritize cost in choosing a vendor. Costs should be transparent up front to participants in objection processes with a fixed fee absent extraordinary circumstances.
We also believe that stricter enforcement of the page caps established for the objections will help to address issues related to cost. One of the factors contributing to the high costs of objections during the 2012 round was a failure of the the panels to curb submission of additional objection documentation. As panels are paid hourly they are incentivized to accept additional documentation even if it was not strictly necessary for the purpose of evaluating the substance of the objection. Further, in some instances, attachments were used to make and support additional arguments not made in the body of the original objection, resulting in additional work and cost to respondents.
We believe that the page caps proposed are appropriate and should be more strictly enforced as part of a subsequent application procedure. To these ends, we would welcome additional language clarifying that attachments should be limited to supporting documentation and must not be used to make additional arguments not covered within the 5,000 word/20 page limit and that, following submission of the initial objection, additional documentation will only be accepted if it is specifically requested by the Objection panel.
RySG
63
coImplement and enforce a strict loser-pays model for all Dispute Resolution Panels.
Issue: The 2012 Round proposed that objections should follow a loser-pays model, wherein fees are refunded to the winning party. We support the use of a loser-pays model, but are concerned that it was not fully applied by all providers.
Recommendation: While most providers refunded both the panel and the flat/administrative fees, one provider opted to retain the flat upfront fees from both parties. To address this, we suggest that clarifying language be added to make clear that both the administrative and panel fees will be refunded to the prevailing party. A possible redline could read: “3.4.7 After the hearing has taken place and the panel renders its expert determination, the DRSP will refund the advance payment of costs, including both the administrative and panel fees, to the prevailing party.”
Strictly enforce objection page limits
Issue: One of the factors contributing to the high costs of objections during the 2012 round was a failure of the panels to curb submission of additional objection documentation. As panels are paid hourly they are incentivized to accept additional documentation even if it was not strictly necessary for the purpose of evaluating the substance of the objection. Further, in some instances, attachments were used to make and support additional arguments not made in the body of the original objection, resulting in additional work and cost to respondents.
Recommendation: We believe that the page caps proposed are appropriate and should be more strictly enforced as part of a subsequent application procedure. To these ends, we would welcome additional language clarifying that attachments should be limited to supporting documentation and must not be used to make additional arguments not covered within the 5,000 word/20 page limit and that, following submission of the initial objection, additional documentation will only be accepted if it is specifically requested by the Objection panel.
RySG letter
**Note: this document was not submitted as part of CC2
64
3.1.10 - Do you feel that GAC Early Warnings were helpful in identifying potential concerns with applications? Do you have suggestions on how to mitigate concerns identified in GAC Early Warnings?
65
1Yes. Whilst the GAC should not run ICANN’s policy for new gTLDs, it is important that GAC input is a formal part of the application process, and dialogue between the GAC and applicants should be encouraged to help work out solutions to public policy concerns. Nominet
66
2In the next “round”, the BC would like to see clarification around the GAC objections process and timeline for filing and addressing GAC objections.BC
67
3The BRG concurs with the RySG comments:
There seemed to be some confusion and uncertainty about the implications and consequences of a GAC Early Warning. Several steps could minimize this confusion and uncertainty in the future:  (i) change the name to GAC Member Early Warning (or something similar) to communicate clearly that the Early Warning has not been issued by the entire GAC, but, instead, by one or more GAC members; (ii) adopt and identify a clear timetable for action by the issuing GAC member(s) to provide certainty to applicants; (iii) require the issuing GAC member(s) to identify the national law(s) on which the Early Warning is based; (iv) have the issuing GAC member(s) designate the type of action(s) desired from the applicant; and (v) emphasize that the GAC Member Early Warnings have no precedential value.
BRG
68
4Afilias concurs with the opinions of the RySG and defers to that response.Afilias
69
5There seemed to be some confusion and uncertainty about the implications and consequences of a GAC Early Warning. Several steps could minimize this confusion and uncertainty in the future: (i) change the name to GAC Member Early Warning (or something similar) to communicate clearly that the Early Warning has not been issued by the entire GAC, but, instead, by one or more GAC members; (ii) adopt and identify a clear timetable for action by the issuing GAC member(s) to provide certainty to applicants; (iii) require the issuing GAC member(s) to identify the national law(s) on which the Early Warning is based; (iv) have the issuing GAC member(s) designate the type of action(s) desired from the applicant; and (v) emphasize that the GAC Member Early Warnings have no precedential value.RySG
70
3.1.11 - What improvements and clarifications should be made to GAC Advice procedures? What mitigation mechanisms are needed to respond to GAC Advice? How can timelines be made more precise? 

71
1NABP believes there was a lack of clarity and predictability with the issuance and implementation of GAC Advice that should be avoided in subsequent procedures. Introducing additional requirements in the form of GAC Advice for certain applicants midway through the evaluation process was highly disruptive and caused considerable delays and a great deal of uncertainty as to what the next steps would be and when they would take place.
To prevent delays and ambiguities in the application evaluation process, GAC Advice and the ICANN’s Board’s resulting policy decisions should be determined prior to the launch of New gTLD subsequent procedures. While this cannot necessarily be done in relation to individual potential TLD strings, it should be possible to do so in relation to particular categories where there may be sensitivity.
Understandably issues may arise that cannot be predicted, but, with regard to policy decisions for sensitive and highly regulated strings, for example, these negotiations can be conducted in advance and should be firmly established and publicized prior to new applications being accepted.
Additionally, in freezing groups of applications by category, it was apparent that the GAC had not actually read the affected applications prior to issuing its Advice. This is evidenced by the fact that the .pharmacy application already included safeguards such as those advised by the GAC. Failure of the GAC either to read the application and/or to have a process whereby misunderstandings could be clarified resulted in a substantial delay to the processing of NABP’s .pharmacy application. In subsequent rounds, if last-minute application freezes should become necessary, the GAC should ensure that it understands the application(s) in question. In addition, there should be processes introduced whereby an applicant can communicate directly with the GAC member(s) having an objection to address any misunderstandings.
NABP
72
2This is a complex area. Each case where GAC advice might be invoked will be inherently contentious and the nature of the GAC advice as failsafe for expression of public policy concerns needs to be expressed in fairly board terms and so we don’t have easy answers for improving this process.Nominet
73
3The Consortium believes there was a lack of clarity and predictability with the issuance of GAC Advice that should be avoided in subsequent rounds. Introducing additional requirements in the form of GAC Advice for certain applicants midway through the evaluation process was highly disruptive and caused considerable delays and a great deal of uncertainty as to what the next steps would be and when they would take place.
To prevent delays and ambiguities in the application evaluation process, GAC Advice and the ICANN’s Board’s resulting decisions should be determined prior to the launch of New gTLD subsequent procedures. While this cannot necessarily be done for individual potential gTLD strings, it should be possible to do so for particular categories where there may be sensitivity. Understandably issues may arise that cannot be predicted, but, regarding policy decisions for gTLDs, particularly those in sensitive and highly regulated industries, for example, these discussions can be conducted in advance, and outcomes should be firmly established and publicized prior to new applications being accepted.
vTLD Consortium
74
4One of the GNSO principles for the new gTLD program is “There must be a clear and pre-published application process using objective and measurable criteria.” The issuance of GAC advice after applications were submitted threw the entire program in the air for years and arguably violated this principle. To this day, we are still dealing with the implications from this.
Now that the community, including the GAC, has been through the 2012 round, we have a track record to look back upon and utilize. Nearly all the GAC advice pertained to all applications, or categories of applications. There were one offs, but the GAC really focused on broad categories. One would expect that advice still stands.
For the benefit of ICANN, the community and applicants, GAC advice should be developed and issued prior to the launch of the next application period (round or otherwise). This allows applicants to have the full benefit of the GAC concerns prior to expending time, energy and resources applying for new gTLDs. Some may choose to do so in contradiction of advice and others may decide not to. It is unfair for applicants who follow the Application Guidebook, which the GAC contributed to, to file an application and suddenly find their business plans upended because of unforeseen objections from the GAC.
Jim Prendergast
75
5The BRG concurs with the RySG comments:
We note several concerns that created significant uncertainty for applicants responding to GAC Advice:
GAC Advice was provided against whole categories of applications.
Though Advice was ultimately determined to apply to strings specifically listed in the Beijing Communique, the initial communique suggested that these lists were non-exhaustive, and could apply to applications not specifically referenced. This contradicts the procedures established in the Applicant Guidebook, which stated that Advice would be provided against applications.
This created confusion for applicants whose strings may exist in related industries, but were not cited, around whether advice applied to them and whether to engage advice directly.
GAC advice was provided against strings (encompassing all members of a contention set) rather than individual strings.
This also contradicts the procedures defined in the applicant guidebook. Applications for a single string may propose vastly different business models with implications for the validity of parts of the GAC Advice.
The expectation should be that applications will be reviewed and, if applicable, referenced individually as part of the GAC Advice, with these factors taken into account.
GAC Advice was non-implementable in its initial form.
This necessitated lengthy and tedious back-and-forth with the ICANN Board to reach a solution that was amenable to the GAC and technically feasible for registry operators, complicating resolution of the Advice by ICANN and registry operators and significantly drawing out the timeline to bring new gTLDs to market.
Whereas the ICANN Board was prepared to accept and take steps to address the public policy concerns raised in the GAC Beijing Communiqué, the GAC insisted on playing a prolonged role in implementation and operational matters which resulted in further unreasonable delays for all concerned. GAC Advice should be provided in such a way that provides sufficient flexibility for ICANN or the relevant community to develop policy or implementation frameworks that ensure such advice is implementable.
GAC Advice did not provide a rationale for why particular strings were included.
The failure to justify the selection of strings referenced in the GAC communique further extended the process of accepting and implementing GAC Advice. Consistent with the recommendations of the Community Working Group on Enhancing ICANN Accountability (CCWG-Accountability), advice provided against applications as part of a future application process should be accompanied by a rationale and demonstrate familiarity with the application in question.
We further note that the community has already developed several recommendations regarding the provision of GAC advice that ameliorate some of these concerns as part of the CCWG-Accountability. The requirements for the provision of GAC advice established as part of the CCWG-Accountability must apply equally to the provision of advice as part of the application process. These recommendations included the following:
That a rationale must accompany any formal advice provided to the ICANN board;
That any formal advice must be made in the absence of a formal objection from any GAC member (which must be confirmed by the GAC in providing the Advice); and
That the Board must not accept advice that compels it to act outside of its Bylaws, including its mission statement, its core values, and the prohibition of disparate treatment for similarly situated parties.
The GAC did not allow applicants an opportunity to be heard.  
An applicant whose application was the subject of GAC Advice had no opportunity to be heard by the GAC before the GAC issued its GAC Advice. Indeed, the GAC Chair refused at least one applicant’s request to be heard. Without an opportunity to be heard before the GAC issues Advice on its application, an applicant is denied a fundamental requirement of procedural fairness that is recognized under national and international law. Moreover, requiring that applicants have an opportunity to be heard by the GAC should minimize the likelihood that the GAC will issue Advice based on incorrect factual assertions or fundamental misunderstandings by GAC members. Of course, the opportunity to be heard must be meaningful in terms of both process (timing and length of presentation, for example) and substance (topics covered and GAC member attendance, for example).
BRG
76
6Afilias concurs with the opinions of the RySG and defers to that response.Afilias
77
7We note several concerns that created significant uncertainty for applicants responding to GAC Advice:
GAC Advice was provided against whole categories of applications.
Though Advice was ultimately determined to apply to strings specifically listed in the Beijing Communique, the initial communique suggested that these lists were non-exhaustive, and could apply to applications not specifically referenced. This contradicts the procedures established in the Applicant Guidebook, which stated that Advice would be provided against applications. This created confusion for applicants whose strings may exist in related industries, but were not cited, around whether advice applied to them and whether to engage advice directly.
GAC advice was provided against strings (encompassing all members of a contention set) rather than individual strings.
This also contradicts the procedures defined in the applicant guidebook. Applications for a single string may propose vastly different business models with implications for the validity of parts of the GAC Advice. The expectation should be that applications will be reviewed and, if applicable, referenced individually as part of the GAC Advice, with these factors taken into account.
GAC Advice was non-implementable in its initial form.
This necessitated lengthy and tedious back-and-forth with the ICANN Board to reach a solution that was amenable to the GAC and technically feasible for registry operators, complicating resolution of the Advice by ICANN and registry operators and significantly drawing out the timeline to bring new gTLDs to market. Whereas the ICANN Board was prepared to accept and take steps to address the public policy concerns raised in the GAC Beijing Communiqué, the GAC insisted on playing a prolonged role in implementation and operational matters which resulted in further unreasonable delays for all concerned. GAC Advice should be provided in such a way that provides sufficient flexibility for ICANN or the relevant community to develop policy or implementation frameworks that ensure such advice is implementable.
GAC Advice did not provide a rationale for why particular strings were included.
The failure to justify the selection of strings referenced in the GAC communique further extended the process of accepting and implementing GAC Advice. Consistent with the recommendations of the Community Working Group on Enhancing ICANN Accountability (CCWG-Accountability), advice provided against applications as part of a future application process should be accompanied by a rationale and demonstrate familiarity with the application in question. We further note that the community has already developed several recommendations regarding the provision of GAC advice that ameliorate some of these concerns as part of the CCWG-Accountability. The requirements for the provision of GAC advice established as part of the CCWG-Accountability must apply equally to the provision of advice as part of the application process. These recommendations included the following:
That a rationale must accompany any formal advice provided to the ICANN board;
That any formal advice must be made in the absence of a formal objection from any GAC member (which must be confirmed by the GAC in providing the Advice); and
That the Board must not accept advice that compels it to act outside of its Bylaws, including its mission statement, its core values, and the prohibition of disparate treatment for similarly situated parties.
The GAC did not allow applicants an opportunity to be heard.
An applicant whose application was the subject of GAC Advice had no opportunity to be heard by the GAC before the GAC issued its GAC Advice. Indeed, the GAC Chair refused at least one applicant’s request to be heard. Without an opportunity to be heard before the GAC issues Advice on its application, an applicant is denied a fundamental requirement of procedural fairness that is recognized under national and international law. Moreover, requiring that applicants have an opportunity to be heard by the GAC should minimize the likelihood that the GAC will issue Advice based on incorrect factual assertions or fundamental misunderstandings by GAC members. Of course, the opportunity to be heard must be meaningful in terms of both process (timing and length of presentation, for example) and substance (topics covered and GAC member attendance, for example).
RySG
78
8GAC advice in relation to gTLDs must include rationales. No comment on timelines offered.ALAC
79
9The GAC’s processes for filing formal advice – including objections to specific applications – and its rationale need to become more transparent and accountable. If there is to be a presumption that the Board will accept that advice, this should not be done blindly, without the Board first having reviewed, clarified, and agreed with the supporting rationale.
A formal Government Objection process (currently available under the Formal Objection mechanism managed by ICANN’s DRSPs) should be considered as the appropriate venue for individual GAC members to file objections to specific applications. Errors of fact made by GAC members should be open to challenge.
A clearer process should be applied to the identification of regulated and safeguard TLDs. Issues of definition and scope for such categories of TLDs, as well as whether terms identified by the GAC as falling under these lists are non-exhaustive or not, cannot be repeated in a future round, let alone under the unpredictable timelines that became a feature of the first round.
The determination of such lists by the GAC should be transparently reasoned and founded on clearly established guidelines for applicants. It is imperative that this area of new gTLD policy is settled in advance of subsequent procedures, dictated by existing laws related to TLD strings, rather than by who is applying for those strings. The GAC should not be used as a vehicle for applicants to gain a competitive advantage over others.
Valideus
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
Loading...