Community TLD

This article is neutral, and sponsored by Neustar, the technical provider for 358 new gTLD applicants & a leading telecom information provider, learn more about their services here

ICANNWiki Gold Sponsor

A Community TLD is a regulated type of generic top level domain name (gTLD) made possible through ICANN's New gTLD Program; it is intended for community groups that are interested in operating their own TLD registry.

Community TLDs must represent a clearly delineated group or groups of people or entities. Examples could include cultural, religious, social or industry associations. The existence of the group must be clearly established. An example of a community TLD used by ICANN, is the .SUGAR TLD. This example was used by ICANN Staff to brief the Board on a proposed registry change request.

.SUGAR EXAMPLE

The registry operator of .SUGAR, a Community gTLD launched in support of the American Sugar Producers Association (ASPA), requests a Community gTLD Change to modify their registration policies to allow registration for all entities that are members of associations belonging to the newly established Global Sugar Association (GSA), having most of the world’s national sugar producer associations as members, including ASPA. Supporting documentation for this change is provided from both ASPA and GSA.

The public comments end with a lot of spam, plus one contribution by the European Sugar Beet Growers Association, ESBGA, claiming that the change would allow European sugar producers to register under this gTLD while not allowing ESBGA members to register, increasing the exposure and market power of the sugar producers to the detriment of the sugar beet growers, already being under pressure by the producers.

Community groups are given precedence for TLDs in contention; that is, if there are multiple applicants for a given string, and one of the applicants applies and proves community status, the community group is automatically given precedence to the TLD. Community status is proven through a process known as Community Priority Evaluation.

The scoring process is conceived to identify qualified community-based applications, while preventing both “false positives” (awarding undue priority to an application that refers to a “community” construed merely to get a sought-after generic word as a gTLD string) and “false negatives” (not awarding priority to a qualified community application).

This calls for a holistic approach, taking multiple criteria into account, as reflected in the process. The scoring will be performed by a panel and be based on information provided in the application plus other relevant information available (such as public information regarding the community represented). The panel may also perform independent research, if deemed necessary to reach informed scoring decisions.

See all Community Applicants in the 2012 new gTLD expansion round.

Requirements for Community TLD Applicants

Based on the gTLD Applicant Guidebook's process for Community Priority Evaluation applicants for community based gTLDs must demonstrate the following, scoring at least 14 of 16 possible points:

• Community Establishment (4 points)
  • Delineation: Demonstrate an ongoing relationship with a clearly delineated community (up to 2 points)
    • 2 points if there is a clearly delineated, organized, and pre-existing community
    • 1 point if there is a clearly delineated and pre-existing community, but not fulfilling the requirements for a score of 2.
  • Extension (up to 2 points)
    • 2 points if community of considerable size and longevity (2 points)
    • 1 point if Community of either considerable size or longevity, but not fulfilling the requirements for a score of 2

• Nexus between proposed string and community. Does the applied for a gTLD string strongly and specifically relate to the community named in the application? (4 points)
  • Nexus (up to 3 points)
    • 3 points if the String matches the name of the community or is a well-known short form or abbreviation of the community
    • 2 points if the string identifies the community, but does not qualify for a score of 3
  • Uniqueness (1 point)
    • 1 point if the string has no other significant meaning beyond identifying the community described in the application

• Registration Policies (4 points)
  • 1 point Eligibility; restricted to community members
  • 1 point Name Selection; policies include name restriction rules corresponding the the community's mission and purpose
  • 1 point Content and USe; policies include content and use rules corresponding to the community's mission and purpose
  • 1 point Enforcement; policies include specific enforcement measures

• Community Endorsement (4 points)
  • Support
    • 2 points if the applicant has multiple strong letters of support from recognized community institutions
    • 1 point if the applicant has one documented community entity supporting its application
  • Opposition
    • 2 points if there is no opposition of relevance
    • 1 point if there is opposition from only one relevant group of non-negligible size

ICANN Analysis of Community TLD Concept

ICANN has published extensive documentation explaining the background and rationale for the community TLD concept in the analyses it has published of each of seven rounds of public comment that were conducted on the applicant guidebook. Key points from those analyses are summarized here:

---

Applicant Guidebook V1 ICANN Comment Analysis:

In cases where multiple community-based applications meet comparative evaluation criteria, the other, non-community based applications that are in direct contention with the former will no longer be considered.

In cases where multiple community-based applications address the same community and meet comparative evaluation criteria, if one applications demonstrates considerably more community support, it will prevail.

In cases where multiple community-based applications meet comparative evaluation criteria, but neither has demonstrated significantly more support than the other or they represent different communities, and they cannot settle the contention amongst them, an auction will be held between these applications.

---

Applicant Guidebook V2 ICANN Comment Analysis:

Application category designation. To lodge an application as "community‐based" is a choice open to the applicant. Whether the application satisfies any criteria for this distinction is not assessed unless a community objection is lodged against it or contention resolution through comparative evaluation takes place.

No limitations on community. In view of the wide definitions of "community" that exist, community‐based applications have not been limited to not‐for‐profit activities; nor have upper geographical or member number limits been set. For example, a top‐level domain could be particularly useful, and particularly justified, for a globally spread community of considerable size.

Multiple comments suggest detailed phrasing of a definition of “community”. It should be noted that community‐based applications are not vetted in that regard in Initial Evaluation, so there is no definition needed at that stage. The significance of “community‐based” occurs at the Objection and Comparative Evaluation steps, where the corresponding criteria serve as decisive factors, rather than any definition per se. The definition suggestions brought up have been considered in the reworking of these criteria.

Community identifiers and geographical identifiers. As noted in the comments, there is a certain overlap between geographical identifiers and community identifiers as many of the former can also be regarded as and used as community identifiers. To apply the same approach as currently foreseen for certain geographical identifiers to all community identifiers, as suggested in the comments, would imply documented community endorsement as a gating factor for lodging a community‐based application. This approach could prevent conflicts but would also raise challenging issues of identifying and verifying authoritative community bodies at the initial stage of the application. Therefore the proposed position is to maintain the current approach, thus not to assess the community‐specific aspects unless such an application enters Comparative Evaluation. Community endorsement is, however, an important criterion for applications that do become subject to Comparative Evaluation.

Definition and criteria. Many comments suggested “sharpening” the community definition to make it more objective. As stated under v) above, the scoring criteria embody the requirements, rather than a definition per se, and the definition suggestions have been considered in the significant work undertaken to arrive at the most objective criteria possible. The goal of the GNSO in creating the community‐based TLD was to afford them a preference in contention situations. The result though requires the creation of labels, objection processes, compliance mechanisms and evaluations where a latitude for judgments cannot be avoided. The goal of the policy recommendation has been achieved, but with significant difficulty. ICANN is of course willing to discuss ideas for making the criteria and other aspects more objective while still meeting the goal set out by the GNSO and also facilitating a timely, predictable process.

---

Applicant Guidebook V3 ICANN Comment Analysis:

Community comment suggests the creation of several TLD categories: for example, single‐owner, country, intergovernmental organization, socio‐cultural, community and open. Depending on the category, various accommodations are suggested: for example, no requirements for an ICANN contract, or to use accredited registrars, or to follow consensus policy, or policy provisions outlined in the GAC’s ccTLD principles. Some might be restricted to not‐for‐profit status, be eligible for reduced fees, require registration restrictions, and have names reserved in anticipation of registration by certain parties.

Beyond the accommodations sought, many or all of the suggested categories seem to be variations of community‐based TLDs. The preference for community‐based TLDs in the evaluation/contention process is based on policy advice from the GNSO and is intended to ensure that community‐based applicants receive the TLD string to which their community is strongly related. Perhaps the most important aspect of the suggested categories is that an applicant within these categories does, in fact, receive the string associated with its community, and that is what the existing process is designed to do.

The community‐based definitions and descriptions in Module 1 are intended to provide guidance to applicants in noting the factors considered should the need arise for objection resolution or community priority evaluation, without pre‐judging the circumstances of particular applications.

It is important to note that the community‐based designation is made by the applicant rather than by ICANN. An examination of the various community aspects of the application occurs in the event of a community priority evaluation, in which case there is deeper inquiry into how the application meets the criteria and factors considered to demonstrate a community‐based orientation.

It is not expected that a “bulk” fee structure will be instituted for translated versions of community name strings. Applications for translated versions of the same string would undergo the complete evaluation process. It is anticipated that subsequent application rounds will enable adjustments to the fee structure based on historical costs from previous rounds, the effectiveness and efficiency of the application evaluation process, and other data as it becomes available.

Some suggested that the definition for community‐based application should explicitly preclude particular groups or scenarios. For example, there was comment that a customer base or business affiliate group should not be considered communities, and that countries or territories represented by ccTLDs should not be considered communities. In considering these suggestions, it was difficult to rule out every possible community‐based construction that would fall into one of the above. It is possible that some of these could be useful as community‐based gTLDs, and it is unclear what the basis would be to justify eliminating them from consideration. It is understood that these suggestions are made in the interest of clarity, but it was concluded after deliberation that the definition should not pre‐judge applications without consideration of the circumstances.

It is important to note that the community‐based designation is not made by ICANN, but by the applicant. This is noted along with the definition in section 1.2.3. ICANN does not evaluate whether the community named in the application is “valid,” i.e., falls into the stated definition. An examination of the various community aspects of the application occurs only in the event of a community priority evaluation or when resolving a community objection. In such cases there is deeper inquiry into how the application meets the criteria and factors considered to demonstrate a community‐based orientation.

Thus, the definitions and descriptions in Module 1 are intended to provide guidance to applicants in noting the factors weighed in looking at any particular case. It would be possible to create more specific rules of inclusion and exclusion, but this would necessitate creating an extra step in the evaluation process for ICANN to determine which applications are acceptable as community‐based. This would mean added cost, complexity and uncertainty in the process in spite of the additional rules. As the process is constructed, there is little incentive to claim to be community‐based without ability to substantiate the claim, since the application may be eliminated if it does not meet the scoring threshold in case of community priority evaluation, as well as in case of community objections, while, if succeeding, the applicant will be bound by additional community‐specific obligations in the registry agreement.

Some suggested that the definition could be enhanced in particular ways. For example, there was a suggestion that the applicant demonstrate self‐identification by community members, i.e., prove that the members it identified as part of its community would actually consider themselves part of the community as defined in the application. This is a reasonable expectation and, as is noted in the community priority criteria, there should be an awareness and recognition of a community among its members. This is an area that is examined in the community establishment criterion of the community priority evaluation.

Another suggestion was that the definition should carry some sense of ongoing accountability from the applicant to the community. This is also a helpful suggestion and in line with the intention of having the community‐specific obligations in the registry agreement as well as the post‐delegation dispute resolution mechanism. It is also partially addressed in the applicant’s response to the application question about the community‐based purpose. It may be beneficial to further articulate this in the guidebook, and this is being taken into account in revising the relevant sections.

There was concern expressed that a TLD could be awarded based on only one endorsement for an application, and a suggestion that more than one should be required. This was considered but also seemed too broad, as it is likely that there could be a community constituted where there was only one relevant endorsement, especially in case of a very structured community with a single organization representing it. The number and source of endorsements is examined in the community priority evaluation and, if relevant, in the dispute resolution process.

Finally, there was a comment that the community‐based definition should tie more closely to the distinction made between existing “sponsored” registry agreements (where the sponsor has delegated policy‐making authority) and “unsponsored” registry agreements (where policy development occurs in the ICANN process). The intention with the community‐based designation is to implement the GNSO’s policy advice on allocation methods, which does not contain the idea of varying delegated authority as with the previous “sponsored” model. Accordingly, a community‐based gTLD will not be able to replace consensus policies with its own policies but can stipulate complementary own policies regarding, for example, registration requirements.

One comment suggested eliminating the idea of community‐based applications altogether. The concept of community‐based applications comes from the GNSO’s policy recommendations on which the implementation of the New gTLD Program is based. Although they may be small or tightly focused, it is expected that community‐based TLDs will add value to the namespace in serving the needs of diverse user groups.

---

Applicant Guidebook V4 ICANN Comment Analysis:

A comment notes a potential imbalance between the requirement for at least one endorsement of a community‐based application, and the requirement that there be substantial opposition in the event of a community objection. It is intended that the application should have substantial support as well; however, this is difficult to establish based on a certain number threshold. It may well be that an applicant supported by one institution or group means substantial support for that case (e.g., a highly structured community with only one relevant institution or endorsement from the pre‐eminent institution in that area). Conversely, the standard for a successful community objection requires that the opposition be substantial so that the dispute resolution process is a consideration of the issues rather than a means for a single entity to eliminate an application. Opposition from a single entity might also be determined substantial in a given case.

Significant consideration has been given to the issue of introducing category‐based TLDs in the new gTLD process. ICANN remains a strong proponent of innovative uses of new TLDs. This is especially so in cases where TLDs can be delegated to address the needs of specific communities such as intergovernmental organizations, socio‐cultural groups and registered brands. Rather than having ICANN limit this type of innovation and identification with certain TLD models, more creativity might be spawned by allowing different groups to self‐identify the type of TLD they purport to be and promote that model among their community.

If a self‐declaration program is instituted and contractual accommodations are eliminated or minimized, fees can remain constant. Socio‐economic groups, brand holders and other groups all can be accommodated under the existing structure and self‐identify as a particular type of TLD. Over time, the market and community interests will sort TLD types – a model preferable to having ICANN make that determination a priori.

To modify the scoring for nexus (highest score also for "string is otherwise strongly associated with the community") and uniqueness ("meaning unrelated to any community would not be considered significant") as proposed by one comment would be equivalent to a considerable lowering of the winning threshold. These arguments are counterbalanced by other comments that these modifications increase the likelihood that community applications will capture generic words. While these issues are fairly close and either side can be argued, the current Guidebook scoring mechanism seems to strike the right balance between the goals to favor communities during string contention while assuring those communities are well established, identified and supportive of the application.

To add points for a multi‐stakeholder governance structure in general, or regarding policy development in particular, certainly has some merit but would add considerable complexity to the assessment and require additional compliance measures post‐delegation. The proposed position for the first round is not to modify the scoring in this way. One consideration to keep in mind is the sTLD approach, which featured such considerations, and was not retained in the New gTLD policy development outcome.

The other alternative proposals put forward, to select the highest scoring application among the winners or to add supplementary criteria in such cases, seem inappropriate since all community applications scoring above the threshold have reached a pre‐determined level as validated for preferential treatment and should be considered equal in that respect for any subsequent process step. The proposed position is not to take score differences among the winners into account nor to introduce supplementary criteria.

The comment proposing separate treatment of non‐profit organizations as applicants requests a similar preferential handling of such applicants in string contention resolution as provided for community applications. However, there is no policy ground for granting any preferential treatment in string contention situations based on the applicants' legal or organizational structures, might be subject to abuse, and the proposed position is not to modify the process in this regard.

Contrary to one commenter’s suggestions, there does not appear to be any conflict of interest in a situation where the supporter of one community application files an objection against a competing community application. Indeed, it would be inappropriate to add a rule that an objector to a gTLD application must not have any interest in any other gTLD application. A person or entity with an interest in one application who objects to another application would still be required to satisfy all of the applicable rules for standing, and meet the standards for an objection.

The question whether the objector who files a community objection must prove that there is a likelihood of detriment to the rights or legitimate interests of its associated community has been raised and addressed in connection with previous drafts of the Applicant Guidebook. ICANN does not consider that the satisfaction of other elements of the community objection (community, substantial opposition and targeting, as set out in § 3.4.4) should create a presumption of detriment. The likelihood of detriment is an independent element of the objection that must be proven by the objector. If the objector cannot prove the likelihood of detriment, there does not appear to be any reason why the objector should be entitled to block the applicant’s application. Simply not wanting another party to be the applicant or obtain the name is not sufficient to be deemed a detriment.

The complete defense to a community objection (§ 3.4.4 in fine) has also been raised and addressed in connection with previous drafts of the Applicant Guidebook. After extensive review and consideration, the complete defense has been eliminated. However, in order to prevail against a defense that an applicant would have had standing to object, objector must prove an elevated level of likely detriment.

---

Applicant Guidebook V5 ICANN Comment Analysis:

Some comments expressed concern with the use of public comment by the panel in the case of a community priority evaluation. Essentially, these suggested that the public comment forum would invite floods of comment in support of or opposition to an application in an attempt to influence the panel‘s consideration. Module 4 of the Guidebook states that: ―To be taken into account as relevant opposition, such objections or comments must be of a reasoned nature. Sources of opposition that are clearly spurious, unsubstantiated, or filed for the purpose of obstruction will not be considered relevant.‖ ICANN agrees that the public comment forum should not be used as a mathematical polling mechanism and that the instructions to the panel will make clear that quantity of comments is not in itself a deciding factor. The Guidebook is being revised to clarify this point in the area of support as well as opposition.

One commenter has suggested, in essence, that the criteria for raising a community- based objection are too narrow because a potential objector may not be able to provide evidence. If evidence is not available, then it seems appropriate that the applicant should not be required to defend against an objection. A community objector must show that: ―There is substantial opposition to the gTLD application from a significant portion of the community to which the gTLD string may be explicitly or implicitly targeted.‖ (See Guidebook, Section 3.1.1 at http://www.icann.org/en/topics/new-gtlds/draft-dispute- resolution-procedures-clean-12nov10-en.pdf.) If there is a true community and substantial opposition can be shown then an objection is valid. Otherwise it is not. Evidence is appropriately required in all types of objection proceedings. Absent evidence, no objection should stand.

One commenter seeks clarification on the term ―substantial opposition.‖ As a determination of this will result from a balancing of a variety of factors, a specific definition is difficult. However, the factors are laid out quite specifically in the Guidebook at section 3.4.4 (see http://www.icann.org/en/topics/new-gtlds/draft-dispute-resolution- procedures-clean-12nov10-en.pdf).

Some have commented on the heightened level of detriment required to prevail in an objection proceeding, while another group has expressed support for the elimination of the complete defense. These two revisions were tied together. The ultimate goal of the community-objection process is prevent the misappropriation of a community label by delegation of a TLD and to ensure that an objector cannot keep an applicant with a legitimate interest in the TLD from succeeding.

Previously, with the complete defense in place, if a community could satisfy the criteria it would otherwise need to prevail on an objection, that applicant would always prevail in an objection proceeding. It was pointed out that this could lead unintended consequences.

Example with the complete defense in place: an actual community of corrupt widget makers known for selling defective widgets applies for a community- based string, and the community of the legitimate widget makers who sell non- defective widgets objects. The corrupt widget makers could successfully lodge a complete defense, blocking the legitimate objection. This would have been the wrong result. Thus, the complete defense has been deleted from the new gTLD process.

Example, with the deletion of the complete defense: legitimate widget makers apply for a TLD and corrupt widget makers object. The objection can show simple detriment to the corrupt widget making community and block the legitimate string. This is also an unwanted consequence that must be avoided. One way to avoid this consequence was to require proof of detriment to more than just the objecting community.

ICANN is still open to alternative suggestions, but reverting back to simple detriment to the objector alone is not acceptable. Some additional detriment is required in order to block a string. We look forward to further discussion on this topic to help us arrive at a workable solution.

A comment expresses concern about gaming or inappropriate use of the community priority evaluation which may harm community-based applicants. Arriving at the best outcome in a contention situation requires careful balancing of several variables, and this is the reason that a number of factors are included in the analysis. The process is intended to support good-faith community applicants, but the outcome of any given case cannot be guaranteed. The requirement of appropriate training of and guidelines for evaluators is well taken and in line with the foreseen process.

A comment expresses concern that the uniqueness aspect of criterion 2 (Nexus) could be used to exclude some community-based applicants. This criterion is intended to offer a higher score where the analysis is straightforward and the claim of priority more obvious. This does not mean that an application featuring a non-unique name as the TLD string would be disqualified, simply that in this case the claim of priority is subject to greater interpretation and thus requires more complex analysis.

A comment suggests that Criterion 3 (Registration Policies) could inappropriately award points to an applicant for restricting registrations in the TLD. Restrictive registration policies may receive a high score in certain cases; however, this is not necessarily true in every case. The Guidebook states in the guidelines on this criterion: ― More restrictions do not automatically result in a higher score. The restrictions and corresponding enforcement mechanisms proposed by the applicant should show an alignment with the community-based purpose of the TLD and demonstrate continuing accountability to the community named in the application.

A comment suggests that name selection and content/use should be considered together in regard to criterion 3 (Registration Policies). ICANN does not see these as linked: a registry could easily allow registrants to register any name they chose, so long as the content of corresponding websites conformed to its established policies. Alternatively, a registry could also allow registrants to use names for any purpose, so long as they conformed to the name selection policies (e.g., names must be in the form of <name of organization.TLD>.

Some comments request further specification on the weighting of support and opposition in criterion 4 (Community Endorsement). The Guidebook provides guidance on the analysis that occurs in this area. The concerns about attempts to influence the outcome of a community priority evaluation by virtue of the volume of submissions favoring a particular outcome are understood. ICANN does not expect the analysis to consist merely of mathematical comparisons, or to automatically penalize applicants for objections (in which, to reach the contention resolution stage, the applicant would have prevailed) without additional consideration of the context. Specifically, the Guidebook states:

When scoring ―Opposition, previous objections to the application as well as public comments during the same application round will be taken into account and assessed in this context.

There will be no presumption that such objections or comments would prevent a score of 2 or lead to any particular score for ―Opposition. To be taken into account as relevant opposition, such objections or comments must be of a reasoned nature. Sources of opposition that are clearly spurious, unsubstantiated, or filed for the purpose of obstruction will not be considered relevant.

The Guidebook makes this point with regard to opposition, and is being revised to provide this clarification in the area of support also. Furthermore, the proposal to add ―not compatible with competition objectives is a worthwhile clarification in the explanation for criterion 4.

Some comments proposed lowering the scoring threshold for community priority evaluation from 14 to 13 points. As stated in the Guidebook:

It should be noted that a qualified community application eliminates all directly contending standard applications, regardless of how well qualified the latter may be. This is a fundamental reason for very stringent requirements for qualification of a community-based application, as embodied in the criteria below.

Another comment supported the scoring criteria and suggested that it be retained. As noted previously, it is obvious that interests and opinions diverge. No new arguments for either solution have been raised in this comment round. Some previous concerns, regarding for example the risk of failing due to unfounded obstructionist objections, have been addressed in the explanatory comments in version 4. This discussion has resulted in considerable and intensive discussions with the community. The Guidebook will keep the scoring threshold at 14 out of 16 points.

A comment suggests that fears of gaming are given a higher value in the process than trust for community-based applicants. It is in fact the intention to design a process that does not facilitate easy abuse, and this necessarily means that community-based applications must undergo some scrutiny if they are claiming a priority over other applications on this basis. This is in line with the GNSO Implementation Guideline H:

Where an applicant lays any claim that the TLD is intended to support a particular community such as a sponsored TLD, or any other TLD intended for a specified community, that claim will be taken on trust with the following exceptions:

(i) the claim relates to a string that is also subject to another application and the claim to support a community is being used to gain priority for the application

It should be recalled that no evaluation of community credentials takes place unless the community-based applicant is claiming a priority as a result of string contention.

Some comments proposed additional points for date of establishment of the TLD initiative, and documented outreach activities. As noted previously, the addition of points for "early" (although post‐New‐gTLD‐PDP‐conclusion) establishment of applicants seems inappropriate from two perspectives. First, the crucial criterion regarding "pre‐existence" is already included. Second, the "pre‐existence" criterion relates to the community, not to the applicant per se. The community is the central concept of interest here, while the entity/ies representing the community may change over time for various reasons, without dates for such changes reasonably justifying any differences in scoring. The proposed position is not to modify the scoring in this regard.

Some comments state that community-based governance mechanisms should be part of the criteria. To add points for a multi‐stakeholder governance structure in general, or regarding policy development in particular, certainly has some merit but would add considerable complexity to the assessment and require additional compliance measures post‐delegation. The community priority evaluation is not intended to be a means of requiring various types of community representation models. However, it is expected that an accountability to the community is present, as demonstrated by the other criteria (e.g., delineation of the community, registration policies, and documentation of support).

---

Applicant Guidebook V6 ICANN Comment Analysis:

As noted in previous analyses of public comments regarding the threshold for winning in Community Priority Evaluation, community views on the required score diverge, with strong arguments put forward for either 13 or 14 points as the most appropriate value. Regarding the example given in the comment, implying that two groups‘ opposition would make the applicant lose two points and likely score overall below the threshold, this will be the case if the opposition is duly reasoned and comes from sizeable groups within the addressed community - arguably a sign that the support is undermined.

However, as explained in the definitions and guidelines for criterion 4, the standards are set high for any opposition to be taken into account as relevant in order to prevent that spurious or obstructionist opposition would affect the score. The definitions and guidelines for the criteria are as important as the criteria themselves for the scoring and have been gradually developed in the light of comments like the one provided here.

In fact, the same comment on risks with opposition scoring for community applicants was submitted for an earlier AG and prompted in depth consideration and refinement of the guidelines for criterion 4. The proposed position is not to change the wording of the guidelines.

Source: http://newgtlds.icann.org/en/about/historical-documentation/matrix-comment-summaries-analyses

Applied for Community TLDs

The following TLD applications have all been filed as community applications, note that some applicants have filed two applications for the same string, one as community and one as generic. This is done defensively so that in the case that community status is denied the applicant still has a chance at obtaining the TLD. Community applications represent 4% of the total applied for strings.

1. .halal
2. .islam
3. .shia
4. .pars
5. .thai
6. .spa
7. .bbb
8. .广东
9. .pyc
10. .kids
11. .cpa
12. .madrid
13. .scot
14. .mma
15. .tennis
16. .gay
17. .tirol
18. .merck (2 community applicants)
19. .art
20. .tatar
21. .quebec
22. .gea
23. .swiss
24. .med - (2 community applicants)
25. .католик
26. كاثوليك.
27. .天主教
28. .catholic
29. .edeka
30. .eus
31. .gal
32. .gmbh
33. .ismaili
34. .lamborghini
35. .leclerc
36. .hamburg
37. .music
38. .lds
39. .art
40. .stada
41. .paris
42. .radio
43. .audi
44. .ovh
45. .gree
46. .pharmacy
47. .bank
48. .insurance
49. .webs
50. .hotel
51. .adac
52. .wien
53. .aco
54. .taxi
55. .sport
56. .bugatti
57. .ikano
58. .immo
59. .ski
60. .archi
61. .bzh
62. .ieee
63. .corsica
64. .政务
65. .eco
66. ngo
67. .ong
68. .berlin
69. .osaka
70. .versicherung
71. .shop
72. .llc
73. .inc
74. .corp
75. .llp

Potential Benefits of Operating a Community TLD

Some proposed benefits of a community TLD include:

• It will help strengthen the cultural and social identity of the group and provide an avenue for growth and increased support among its members.
• It enables the community to control their domain name space by creating their own rules and policies for registration to be able to protect and implement their community's standards and values
• It will boost the trust and confidence of its members
• The community may be recognized globally
• Members will be able to register a relevant, shorter and easy to remember domain name
• It will generate income from registration and annual renewal fees of domain names

Top-Level Domain

Generic Names Supporting Organization. Develops and recommends to the Board substantive policies relating to generic top-level domains and other responsibilities set forth in the Bylaws (ICANN Bylaws).

Governmental Advisory Committee. Considers and provides advice on the activities of ICANN as they relate to concerns of governments, particularly matters where there may be an interaction between ICANN's policies and various laws and international agreements or where they may affect public policy issues (ICANN Bylaws).

Country code top-level domain

Policy Development Process