AGAT-Module2

Module 2
Evaluation Procedures
This module describes the evaluation procedures and criteria used to determine whether applied-for gTLDs are approved for delegation. All applicants will undergo an Initial Evaluation and those that do not pass all elements may request Extended Evaluation.
The first, required evaluation is the Initial Evaluation, during which ICANN assesses an applied-for gTLD string, an applicant's qualifications, and its proposed registry services.
The following assessments are performed in the Initial Evaluation:

• String Reviews
• String similarity
• Reserved names
• DNS stability
• Geographic names
• Applicant Reviews
• Demonstration of technical and operational capability
• Demonstration of financial capability
• Registry services reviews for DNS stability issues

An application must pass all these reviews to pass the Initial Evaluation. Failure to pass any one of these reviews will result in a failure to pass the Initial Evaluation.
Extended Evaluation may be applicable in cases in which an applicant does not pass the Initial Evaluation. See Section 2.3 below.
2.1 Background Screening
Background screening will be conducted in two areas:
(a) General business diligence and criminal history; and
(b) History of cybersquatting behavior.
The application must pass both background screening areas to be eligible to proceed. Background screening results are evaluated according to the criteria described in section 1.2.1. The following sections describe the process ICANN will use to perform background screening.
2.1.1General business diligence and criminal history
Applying entities that are publicly traded corporations listed and in good standing on any of the world's largest 25 stock exchanges (as listed by the World Federation of Exchanges) will be deemed to have passed the general business diligence and criminal history screening. The largest 25 will be based on the domestic market capitalization reported at the end of the most recent calendar year prior to launching each round. See http://www.world-exchanges.org/files/statistics/excel/EQUITY109.xls
Before an entity is listed on an exchange, it must undergo significant due diligence including an investigation by the exchange, regulators, and investment banks. As a publicly listed corporation, an entity is subject to ongoing scrutiny from shareholders, analysts, regulators, and exchanges. All exchanges require monitoring and disclosure of material information about directors, officers, and other key personnel, including criminal behavior. In totality, these requirements meet or exceed the screening ICANN will perform.
For applicants not listed on one of these exchanges, ICANN will submit identifying information for the entity, officers, directors, and major shareholders to an international background screening service. This service will use the criteria listed in section 1.2.1 and return results that match these criteria. Only publicly available information will be used in this inquiry.
Note that the applicant is expected to disclose potential problems in meeting the criteria in the application, and provide any clarification or explanation at the time of application submission. If any hits are returned, they will be matched with the disclosures provided by the applicant and those cases will be followed up to resolve issues of discrepancies or potential false positives.
If no hits are returned, the application will pass this portion of the background screening.
2.1.2History of cybersquatting
ICANN will screen applicants against UDRP cases and legal databases as financially feasible for data that may indicate a pattern of cybersquatting behavior pursuant to the criteria listed in section 1.2.1.
The applicant is required to make specific declarations regarding these activities in the application. If any hits are returned, the application will be matched with the disclosures provided by the applicant and those issues will be followed up to resolve issues of discrepancies or potential false positives.
If no hits are returned, the application will pass this portion of the background screening.
2.2Initial Evaluation
The Initial Evaluation consists of two types of review. Each type is composed of several elements.
String review: The first review focuses on the applied-for gTLD string to test:

• Whether the applied-for gTLD string is so similar to other strings that it would create a probability of user confusion;
• Whether the applied-for gTLD string might adversely affect DNS security or stability; and
• Whether evidence of requisite government approval is provided in the case of certain geographic names.

Applicant review: The second review focuses on the applicant to test:

• Whether the applicant has the requisite technical, operational, and financial capability to operate a registry; and
• Whether the registry services offered by the applicant might adversely affect DNS security or stability.

2.2.1String Reviews
In the Initial Evaluation, ICANN reviews every applied-for gTLD string. Those reviews are described in greater detail in the following subsections.
2.2.1.1String Similarity Review
This review involves a preliminary comparison of each applied-for gTLD string against existing TLDs, Reserved Names (see subsection 2.2.1.2), and other applied-for strings. The objective of this review is to prevent user confusion and loss of confidence in the DNS resulting from delegation of many similar strings.
Note: In this Applicant Guidebook, "similar" means strings so similar that they create a probability of user confusion if more than one of the strings is delegated into the root zone.
The visual similarity check that occurs during Initial Evaluation is intended to augment the objection and dispute resolution process (see Module 3, Dispute Resolution Procedures) that addresses all types of similarity.
This similarity review will be conducted by an independent String Similarity Panel.
2.2.1.1.1Reviews Performed
The String Similarity Panel's task is to identify visual string similarities that would create a probability of user confusion.
The panel performs this task of assessing similarities that would lead to user confusion in four sets of circumstances, when comparing:

• Applied-for gTLD strings against existing TLDs and reserved names;
• Applied-for gTLD strings against other applied-for gTLD strings;
• Applied-for gTLD strings against strings requested as IDN ccTLDs; and
• Applied-for 2-character IDN gTLD strings against:
  • Every other single character.
  • Any other 2-character ASCII string (to protect possible future ccTLD delegations).

Similarity to Existing TLDs or Reserved Names – This review involves cross-checking between each applied-for string and the lists of existing TLD strings and Reserved Names to determine whether two strings are so similar to one another that they create a probability of user confusion.
In the simple case in which an applied-for gTLD string is identical to an existing TLD or reserved name, the application system will not allow the application to be submitted.
Testing for identical strings also takes into consideration the code point variants listed in any relevant IDN table. For example, protocols treat equivalent labels as alternative forms of the same label, just as "foo" and "Foo" are treated as alternative forms of the same label (RFC 3490).
All TLDs currently in the root zone can be found at http://iana.org/domains/root/db/.
IDN tables that have been submitted to ICANN are available at http://www.iana.org/domains/idn-tables/.
Similarity to Other Applied-for gTLD Strings (String Contention Sets) – All applied-for gTLD strings will be reviewed against one another to identify any similar strings. In performing this review, the String Similarity Panel will create contention sets that may be used in later stages of evaluation. A contention set contains at least two applied-for strings identical or similar to one another. Refer to Module 4, String Contention Procedures, for more information on contention sets and contention resolution.
ICANN will notify applicants who are part of a contention set as soon as the String Similarity review is completed. (This provides a longer period for contending applicants to reach their own resolution before reaching the contention resolution stage.) These contention sets will also be published on ICANN's website.
Similarity to TLD strings requested as IDN ccTLDs – Applied-for gTLD strings will also be reviewed for similarity to TLD strings requested in the IDN ccTLD Fast Track process (see http://www.icann.org/en/topics/idn/fast-track/). Should a conflict with a prospective fast-track IDN ccTLD be identified, ICANN will take the following approach to resolving the conflict.
If one of the applications has completed its respective process before the other is lodged, that TLD will be delegated. A gTLD application that has successfully completed all relevant evaluation stages, including dispute resolution and string contention, if applicable, and is eligible for entry into a registry agreement will be considered complete, and therefore would not be disqualified by a newly-filed IDN ccTLD request. Similarly, an IDN ccTLD request that has completed evaluation (i.e., is "validated") will be considered complete and therefore would not be disqualified by a newly-filed gTLD application.
In the case where neither application has completed its respective process, where the gTLD application does not have the required approval from the relevant government or public authority, a validated request for an IDN ccTLD will prevail and the gTLD application will not be approved. The term "validated" is defined in the IDN ccTLD Fast Track Process Implementation, which can be found at http://www.icann.org/en/topics/idn.
In the case where a gTLD applicant has obtained the support or non-objection of the relevant government or public authority, but is eliminated due to contention with a string requested in the IDN ccTLD Fast Track process, a full refund of the evaluation fee is available to the applicant if the gTLD application was submitted prior to the publication of the ccTLD request.
Review of 2-character IDN strings — In addition to the above reviews, an applied-for gTLD string that is a 2-character IDN string is reviewed by the String Similarity Panel for visual similarity to:

1. Any one-character label (in any script), and
2. Any possible two-character ASCII combination.

An applied-for gTLD string that is found to be too similar to a) or b) above will not pass this review.
2.2.1.1.2 Review Methodology
The String Similarity Panel is informed in part by an algorithmic score for the visual similarity between each applied-for string and each of other existing and applied-for TLDs and reserved names. The score will provide one objective measure for consideration by the panel, as part of the process of identifying strings likely to result in user confusion. In general, applicants should expect that a higher visual similarity score suggests a higher probability that the application will not pass the String Similarity review. However, it should be noted that the score is only indicative and that the final determination of similarity is entirely up to the Panel's judgment.
The algorithm, user guidelines, and additional background information are available to applicants for testing and informational purposes. See http://icann.sword-group.com/algorithm/ Applicants will have the ability to test their strings and obtain algorithmic results through the application system prior to submission of an application.
The algorithm supports the common characters in Arabic, Chinese, Cyrillic, Devanagari, Greek, Japanese, Korean, and Latin scripts. It can also compare strings in different scripts to each other.
The panel will also take into account variant characters, as defined in any relevant language table, in its determinations. For example, strings that are not visually similar but are determined to be variant TLD strings based on an IDN table would be placed in a contention set. Variant TLD strings that are listed as part of the application will also be subject to the string similarity analysis. In the case where an applicant has listed Declared Variants in its application (see subsection 1.3.3), the panel will perform an analysis of the listed strings to confirm that the strings are variants according to the applicant's IDN table. This analysis may include comparison of applicant IDN tables with other existing tables for the same language or script, and forwarding any questions to the applicant.
The panel will examine all the algorithm data and perform its own review of similarities between strings and whether they rise to the level of string confusion. In cases of strings in scripts not yet supported by the algorithm, the panel's assessment process is entirely manual.
The panel will use a common standard to test for whether string confusion exists, as follows:
Standard for String Confusion – String confusion exists where a string so nearly resembles another visually that it is likely to deceive or cause confusion. For the likelihood of confusion to exist, it must be probable, not merely possible that confusion will arise in the mind of the average, reasonable Internet user. Mere association, in the sense that the string brings another string to mind, is insufficient to find a likelihood of confusion.
2.2.1.1.3 Outcomes of the String Similarity Review
An application that fails the String Similarity review due to similarity to an existing TLD will not pass the Initial Evaluation, and no further reviews will be available. Where an application does not pass the String Similarity review, the applicant will be notified as soon as the review is completed.An application for a string that is found too similar to another applied-for gTLD string will be placed in a contention set.An application that passes the String Similarity review is still subject to objection by an existing TLD operator or by another gTLD applicant in the current application round. That process requires that a string confusion objection be filed by an objector having the standing to make such an objection. Such category of objection is not limited to visual similarity. Rather, confusion based on any type of similarity (including visual, aural, or similarity of meaning) may be claimed by an objector. Refer to Module 3, Dispute Resolution Procedures, for more information about the objection process.
An applicant may file a formal objection against another gTLD application on string confusion grounds. Such an objection may, if successful, change the configuration of the preliminary contention sets in that the two applied-for gTLD strings will be considered in direct contention with one another (see Module 4, String Contention Procedures). The objection process will not result in removal of an application from a contention set.
2.2.1.2Reserved Names
All applied-for gTLD strings are compared with the list of top-level Reserved Names to ensure that the applied-for gTLD string does not appear on that list.
Top-Level Reserved Names List

If an applicant enters a Reserved Name as its applied-for gTLD string, the application system will recognize the Reserved Name and will not allow the application to be submitted.
In addition, applied-for gTLD strings are reviewed during the String Similarity review to determine whether they are similar to a Reserved Name. An application for a gTLD string that is identified as too similar to a Reserved Name will not pass this review.
Names appearing on the Declared Variants List (see section 1.3.3) will be posted on ICANN's website and will be treated essentially the same as Reserved Names. That is, an application for a gTLD string that is identical or similar to a string on the Declared Variants List will not pass this review.
2.2.1.3DNS Stability Review
This review determines whether an applied-for gTLD string might cause instability to the DNS. In all cases, this will involve a review for conformance with technical and other requirements for gTLD strings (labels). In some exceptional cases, an extended review may be necessary to investigate possible technical stability problems with the applied-for gTLD string.
2.2.1.3.1DNS Stability: String Review Procedure
New gTLD labels must not adversely affect the security or stability of the DNS. During the Initial Evaluation period, ICANN will conduct a preliminary review on the set of applied-for gTLD strings to:

• ensure that applied-for gTLD strings comply with the requirements provided in section 2.2.1.3.2, and
• determine whether any strings raise significant security or stability issues that may require further review.

There is a very low probability that extended analysis will be necessary for a string that fully complies with the string requirements in subsection 2.2.1.3.2 of this module. However, the string review process provides an additional safeguard if unanticipated security or stability issues arise concerning an applied-for gTLD string.
In such a case, the DNS Stability Panel will perform an extended review of the applied-for gTLD string during the Initial Evaluation period. The panel will determine whether the string fails to comply with relevant standards or creates a condition that adversely affects the throughput, response time, consistency, or coherence of responses to Internet servers or end systems, and will report on its findings.
If the panel determines that the string complies with relevant standards and does not create the conditions described above, the application will pass the DNS Stability review.
If the panel determines that the string does not comply with relevant technical standards, or that it creates a condition that adversely affects the throughput, response time, consistency, or coherence of responses to Internet servers or end systems, the application will not pass the Initial Evaluation, and no further reviews are available. In the case where a string is determined likely to cause security or stability problems in the DNS, the applicant will be notified as soon as the DNS Stability review is completed.
2.2.1.3.2String Requirements The string requirements have been revised according to revisions of RFC 1123 in progress in the IETF. See http://tools.ietf.org/html/draft-liman-tld-names-04.

ICANN will review each applied-for gTLD string to ensure that it complies with the requirements outlined in the following paragraphs.
If an applied-for gTLD string is found to violate any of these rules, the application will not pass the DNS Stability review. No further reviews are available.
Part I – Technical Requirements for all Labels (Strings) – The technical requirements for top-level domain labels follow.
1.1 The ASCII label (i.e., the label as transmitted on the wire) must be valid as specified in technical standards Domain Names: Implementation and Specification (RFC 1035), and Clarifications to the DNS Specification (RFC 2181) and any updates thereto. This includes the following:

1. 1. 1. The label must have no more than 63 characters.
      2. Upper and lower case characters are treated as identical.
   2. The ASCII label must be a valid host name, as specified in the technical standards DOD Internet Host Table Specification (RFC 952), Requirements for Internet Hosts — Application and Support (RFC 1123), and Application Techniques for Checking and Transformation of Names (RFC 3696), Internationalized Domain Names in Applications (IDNA)(RFCs 5890-5894), and any updates thereto. This includes the following:
      1. The ASCII label must consist entirely of letters (alphabetic characters a-z), or
      2. The label must be a valid IDNA A-label (further restricted as described in Part II below).

Part II – Requirements for Internationalized Domain Names – These requirements apply only to prospective top-level domains that contain non-ASCII characters. Applicants for these internationalized top-level domain labels are expected to be familiar with the IETF IDNA standards, Unicode standards, and the terminology associated with Internationalized Domain Names.

1. 1. The label must be an A-label as defined in IDNA, converted from (and convertible to) a U-label that is consistent with the definition in IDNA, and further restricted by the following, non-exhaustive, list of limitations:
      1. Must be a valid A-label according to IDNA.
      2. The derived property value of all codepoints, as defined by IDNA, must be PVALID and be accompanied by unambiguous contextual rules where necessary. It is expected that conversion tools for IDNA 2008 will be available before the Application Submission period begins, and that labels will be checked for validity under IDNA2008. In this case, labels valid under the previous version of the protocol (IDNA2003) but not under IDNA2008 will not meet this element of the requirements. Labels that are valid under both versions of the protocol will meet this element of the requirements. Labels valid under IDNA2008 but not under IDNA2003 may meet the requirements; however, applicants are strongly advised to note that the duration of the transition period between the two protocols cannot presently be estimated nor guaranteed in any specific timeframe. The development of support for IDNA2008 in the broader software applications environment will occur gradually. During that time,TLD labels that are valid under IDNA2008, but not under IDNA2003, will have limited functionality.
      3. The general category of all codepoints, as defined by IDNA, must be one of (Ll, Lo, Lm, Mn).
      4. Must be fully compliant with Normalization Form C, as described in Unicode Standard Annex #15: Unicode Normalization Forms. See also examples in http://unicode.org/faq/normalization.html.
      5. Must consist entirely of characters with the same directional property.
   2. The label must meet the relevant criteria of the ICANN Guidelines for the Implementation of Internationalised Domain Names. See http://www.icann.org/en/topics/idn/implementation-guidelines.htm. This includes the following, non-exhaustive, list of limitations:
      1. All code points in a single label must be taken from the same script as determined by the Unicode Standard Annex #24: Unicode Script Property.
      2. Exceptions to 2.2.1 are permissible for languages with established orthographies and conventions that require the commingled use of multiple scripts. However, even with this exception, visually confusable characters from different scripts will not be allowed to co-exist in a single set of permissible code points unless a corresponding policy and character table are clearly defined.

Part III - Policy Requirements for Generic Top-Level Domains – These requirements apply to all prospective top-level domain strings applied for as gTLDs.
3.1 Applied-for gTLD strings in ASCII must be composed of three or more visually distinct characters. Two-character ASCII strings are not
permitted, to avoid conflicting with current and future country codes based on the ISO 3166-1 standard.
3.2 Applied-for gTLD strings in IDN scripts must be composed of two or more visually distinct characters in the script, as appropriate. Note, however, that a two-character IDN string will not be approved if:
3.2.1 It is visually similar to any one-character label (in any script); or
3.2.2 It is visually similar to any possible two- character ASCII combination.
See the String Similarity review in subsection 2.2.1.1 for additional information on this requirement.
2.2.1.4 Geographic Names Review
Applications for gTLD strings must ensure that appropriate consideration is given to the interests of governments or public authorities in geographic names. The requirements and procedure ICANN will follow in the evaluation process are described in the following paragraphs. Applicants should review these requirements even if they do not believe their intended gTLD string is a geographic name. All applied-for gTLD strings will be reviewed according to the requirements in this section, regardless of whether the application indicates it is for a geographic name.
2.2.1.4.1Treatment of Country or Territory Names Country and territory names are excluded from the process based on advice from the Governmental Advisory Committee in recent communiqués providing interpretation of Principle 2.2 of the GAC Principles regarding New gTLDs to indicate that strings which are a meaningful representation or abbreviation of a country or territory name should be handled through the forthcoming ccPDP, and other geographic strings could be allowed in the gTLD space if in agreement with the relevant government or public authority.
Applications for strings that are country or territory names will not be approved, as they are not available under the New gTLD Program in this application round. A string shall be considered to be a country or territory name if:

1. it is an alpha-3 code listed in the ISO 3166-1 standard.
2. it is a long-form name listed in the ISO 3166-1 standard, or a translation of the long-form name in any language.
3. it is a short-form name listed in the ISO 3166-1 standard, or a translation of the short-form name in any language.
4. it is the short- or long-form name association with a code that has been designated as "exceptionally reserved" by the ISO 3166 Maintenance Agency.
5. it is a separable component of a country name designated on the "Separable Country Names List," or is a translation of a name appearing on the list, in any language. See the Annex at the end of this module.
6. It is a permutation or transposition of any of the names included in items through (v). Permutations include removal of spaces, insertion of punctuation, and addition or removal of grammatical articles like "the." A transposition is considered a change in the sequence of the long or short–form name, for example, "RepublicCzech" or "IslandsCayman."

2.2.1.4.2Geographic Names Requiring Government Support
The following types of applied-for strings are considered geographic names and must be accompanied by documentation of support or non-objection from the relevant governments or public authorities:

1. An application for any string that is a representation, in any language, of the capital city name of any country or territory listed in the ISO 3166-1 standard.

In this case, it is anticipated that the relevant government or public authority would be at the national level.

1. An application for a city name, where the applicant declares that it intends to use the gTLD for purposes associated with the city name.

City names present challenges because city names may also be generic terms or brand names, and in many cases no city name is unique. Unlike other types of geographic names, there are no established lists that can be used as objective references in the evaluation process. Thus, city names are not universally protected. However, the process does provide a means for cities and applicants to work together where desired.
An application for a city name will be subject to the geographic names requirements (i.e., will require documentation of support or non-objection from the relevant governments or public authorities) if:

1. It is clear from applicant statements within the application that the applicant will use the TLD primarily for purposes associated with the city name; and
2. The applied-for string is a city name as listed on official city documents. City governments with concerns about strings that are duplicates, nicknames or close renderings of a city name should not rely on the evaluation process as the primary means of protecting their interests in a string. Rather, a government may elect to file a formal objection to an application that is opposed by the relevant community, or may submit its own application for the string.

In the case of an application that meets conditions (a) and (b), documentation of support will be required only from the relevant government or public authority of the city named in the application.

1. An application for any string that is an exact match of a sub-national place name, such as a county, province, or state, listed in the ISO 3166-2 standard.

In this case, it is anticipated that the relevant government or public authority would be at the sub-national level, such as a state, provincial or local government or authority.

1. An application for a string listed as a UNESCO region See http://www.unesco.org/new/en/unesco/worldwide/.
   or appearing on the "Composition of macro geographical (continental) regions, geographical sub-regions, and selected economic and other groupings" list. See http://unstats.un.org/unsd/methods/m49/m49regin.htm.

In the case of an application for a string appearing on either of the lists above, documentation of support will be required from at least 60% of the respective national governments in the region, and there may be no more than one written statement of objection to the application from relevant governments in the region and/or public authorities associated with the continent or the region.
Where the 60% rule is applied, and there are common regions on both lists, the regional composition contained in the "composition of macro geographical (continental) regions, geographical sub-regions, and selected economic and other groupings" takes precedence.
An applied-for gTLD string that falls into any of 1 through 4 listed above is considered to represent a geographic name. In the event of any doubt, it is in the applicant's interest to consult with relevant governments and public authorities and enlist their support or non-objection prior to submission of the application, in order to preclude possible objections and pre-address any ambiguities concerning the string and applicable requirements.
In the event that there is more than one relevant government or public authority for the applied-for gTLD string, the applicant must provide documentation of support or non-objection from all the relevant governments or public authorities. It is anticipated that this may apply to the case of a sub-national place name.
It is the applicant's responsibility to:

• identify whether its applied-for gTLD string falls into any of the above categories; and
• determine the relevant governments or public authorities; and
• identify which level of government support is required.

The requirement to include documentation of support for certain applications does not preclude or exempt applications from being the subject of objections on community grounds (refer to subsection 3.1.1 of Module 3), under which applications may be rejected based on objections showing substantial opposition from the targeted community.
2.2.1.4.3 Documentation Requirements
The documentation of support or non-objection should include a signed letter from the relevant government or public authority. Understanding that this will differ across the respective jurisdictions, the letter could be signed by the minister with the portfolio responsible for domain name administration, ICT, foreign affairs, or the Office of the Prime Minister or President of the relevant jurisdiction; or a senior representative of the agency or department responsible for domain name administration, ICT, foreign affairs, or the Office of the Prime Minister. To assist the applicant in determining who the relevant government or public authority may be for a potential geographic name, the applicant may wish to consult with the relevant Governmental Advisory Committee (GAC) representative. See http://gac.icann.org/gac-members
The letter must clearly express the government's or public authority's support for or non-objection to the applicant's application and demonstrate the government's or public authority's understanding of the string being requested and intended use.
The letter should also demonstrate the government's or public authority's understanding that the string is being sought through the gTLD application process and that the applicant is willing to accept the conditions under which the string will be available, i.e., entry into a registry agreement with ICANN requiring compliance with consensus policies and payment of fees. (See Module 5 for a discussion of the obligations of a gTLD registry operator.)
A sample letter of support is available as an attachment to this module.
It is important to note that a government or public authority is under no obligation to provide documentation of support or non-objection in response to a request by an applicant. It is also possible that a government may withdraw its support for an application at a later time, including after the new gTLD has been delegated, if registry operator has deviated from the conditions of original support or non-objection.

2.2.1.4.4Review Procedure for Geographic Names
A Geographic Names Panel (GNP) will determine whether each applied-for gTLD string represents a geographic name, and verify the relevance and authenticity of the supporting documentation where necessary.
The GNP will review all applications received, not only those where the applicant has noted its applied-for gTLD string as a geographic name. For any application where the GNP determines that the applied-for gTLD string is a country or territory name (as defined in this module), the application will not pass the Geographic Names review and will be denied. No additional reviews will be available.
For any application where the GNP determines that the applied-for gTLD string is not a geographic name requiring government support (as described in this module), the application will pass the Geographic Names review with no additional steps required.
For any application where the GNP determines that the applied-for gTLD string is a geographic name requiring government support, the GNP will confirm that the applicant has provided the required documentation from the relevant governments or public authorities, and that the communication from the government or public authority is legitimate and contains the required content. ICANN may confirm the authenticity of the communication by consulting with the relevant diplomatic authorities or members of ICANN's Governmental Advisory Committee for the government or public authority concerned on the competent authority and appropriate point of contact within their administration for communications.
The GNP may communicate with the signing entity of the letter to confirm their intent and their understanding of the terms on which the support for an application is given.
In cases where an applicant has not provided the required documentation, the applicant will be contacted and notified of the requirement, and given a limited time frame to provide the documentation. If the applicant is able to provide the documentation before the close of the Initial Evaluation period, and the documentation is found to meet the requirements, the applicant will pass the Geographic Names review. If not, the applicant will have additional time to obtain the required documentation; however, if the applicant has not produced the required documentation by the required date (at least 90 days from the date of notice), the application will be considered incomplete and will be ineligible for further review. The applicant may reapply in subsequent application rounds, if desired, subject to the fees and requirements of the specific application rounds.
If there is more than one application for a string representing a certain geographic name as described in this section, and the applications have requisite government approvals, the applications will be suspended pending resolution by the applicants.
If an application for a string representing a geographic name is in a contention set with applications for similar strings that have not been identified as geographical names, the string contention will be settled using the string contention procedures described in Module 4.
2.2.2 Applicant Reviews
Concurrent with the applied-for gTLD string reviews described in subsection 2.2.1, ICANN will review the applicant's technical and operational capability, its financial capability, and its proposed registry services. Those reviews are described in greater detail in the following subsections.
2.2.2.1Technical/Operational Review
In its application, the applicant will respond to a set of questions (see questions 24 – 44 in the Application Form) intended to gather information about the applicant's technical capabilities and its plans for operation of the proposed gTLD.
Applicants are not required to have deployed an actual gTLD registry to pass the Technical/Operational review. It will be necessary, however, for an applicant to demonstrate a clear understanding and accomplishment of some groundwork toward the key technical and operational aspects of a gTLD registry operation. Subsequently, each applicant that passes the technical evaluation and all other steps will be required to complete a pre-delegation technical test prior to delegation of the new gTLD. Refer to Module 5, Transition to Delegation, for additional information.
2.2.2.2 Financial Review
In its application, the applicant will respond to a set of questions (see questions 45-50 in the Application Form) intended to gather information about the applicant's financial capabilities for operation of a gTLD registry and its financial planning in preparation for long-term stability of the new gTLD.
Because different registry types and purposes may justify different responses to individual questions, evaluators will pay particular attention to the consistency of an application across all criteria. For example, an applicant's scaling plans identifying system hardware to ensure its capacity to operate at a particular volume level should be consistent with its financial plans to secure the necessary equipment. That is, the evaluation criteria scale with the applicant plans to provide flexibility.
2.2.2.3Evaluation Methodology
Dedicated technical and financial evaluation panels will conduct the technical/operational and financial reviews, according to the established criteria and scoring methodology included as an attachment to this module. These reviews are conducted on the basis of the information each applicant makes available to ICANN in its response to the questions in the Application Form.
The evaluators may request clarification or additional information during the Initial Evaluation period. For each application, clarifying questions will be consolidated and sent to the applicant from each of the panels. The applicant will thus have an opportunity to clarify or supplement the application in those areas where a request is made by the evaluators. These communications will occur via the online application system, rather than by phone, letter, email, or other means. Unless otherwise noted, such communications will include a 3-week deadline for the applicant to respond. Any supplemental information provided by the applicant will become part of the application.
It is the applicant's responsibility to ensure that the questions have been fully answered and the required documentation is attached. Evaluators are entitled, but not obliged, to request further information or evidence from an applicant, and are not obliged to take into account any information or evidence that is not made available in the application and submitted by the due date, unless explicitly requested by the evaluators.
2.2.3Registry Services Review
Concurrent with the other reviews that occur during the Initial Evaluation period, ICANN will review the applicant's proposed registry services for any possible adverse impact on security or stability. The applicant will be required to provide a list of proposed registry services in its application.
2.2.3.1 Definitions
Registry services are defined as:

1. operations of the registry critical to the following tasks: the receipt of data from registrars concerning registrations of domain names and name servers; provision to registrars of status information relating to the zone servers for the TLD; dissemination of TLD zone files; operation of the registry zone servers; and dissemination of contact and other information concerning domain name server registrations in the TLD as required by the registry agreement;
2. other products or services that the registry operator is required to provide because of the establishment of a consensus policy; and
3. any other products or services that only a registry operator is capable of providing, by reason of its designation as the registry operator.

Proposed registry services will be examined to determine if they might raise significant stability or security issues. Examples of services proposed by existing registries can be found at http://www.icann.org/en/registries/rsep/. In most cases, these proposed services successfully pass this inquiry.
Registry services currently provided by gTLD registries can be found in registry agreement appendices. See http://www.icann.org/en/registries/agreements.htm.
A full definition of registry services can be found at http://www.icann.org/en/registries/rsep/rsep.html.
For purposes of this review, security and stability are defined as follows:
Security – an effect on security by the proposed registry service means (1) the unauthorized disclosure, alteration, insertion or destruction of registry data, or (2) the unauthorized access to or disclosure of information or resources on the Internet by systems operating in accordance with all applicable standards.
Stability – an effect on stability means that the proposed registry service (1) does not comply with applicable relevant standards that are authoritative and published by a well-established, recognized, and authoritative standards body, such as relevant standards-track or best current practice RFCs sponsored by the IETF, or (2) creates a condition that adversely affects the throughput, response time, consistency, or coherence of responses to Internet servers or end systems, operating in accordance with applicable relevant standards that are authoritative and published by a well-established, recognized and authoritative standards body, such as relevant standards-track or best current practice RFCs and relying on registry operator's delegation information or provisioning services.
2.2.3.2 Customary Services
The following registry services are customary services offered by a registry operator:

• Receipt of data from registrars concerning registration of domain names and name servers
• Dissemination of TLD zone files
• Dissemination of contact or other information concerning domain name registrations
• DNS Security Extensions

The applicant must describe whether any of these registry services are intended to be offered in a manner unique to the TLD.
Any additional registry services that are unique to the proposed gTLD registry should be described in detail. Directions for describing the registry services are provided at http://www.icann.org/en/registries/rsep/rrs_sample.html.
2.2.3.3 TLD Zone Contents
ICANN receives a number of inquiries about use of various record types in a registry zone, as entities contemplate different business and technical models. Permissible zone contents for a TLD zone are:

• Apex SOA record.
• Apex NS records and in-bailiwick glue for the TLD's DNS servers.
• NS records and in-bailiwick glue for DNS servers of registered names in the TLD.
• DS records for registered names in the TLD.
• Records associated with signing the TLD zone (i.e., RRSIG, DNSKEY, NSEC, and NSEC3).

An applicant wishing to place any other record types into its TLD zone should describe in detail its proposal in the registry services section of the application. This will be evaluated and could result in an extended evaluation to determine whether the service would create a risk of a meaningful adverse impact on security or stability of the DNS. Applicants should be aware that a service based on use of less-common DNS resource records in the TLD zone, even if approved in the registry services review, might not work as intended for all users due to lack of application support.
2.2.3.4 Methodology
Review of the applicant's proposed registry services will include a preliminary determination of whether any of the proposed registry services could raise significant security or stability issues and require additional consideration.
If the preliminary determination reveals that there may be significant security or stability issues (as defined in subsection 2.2.3.1) surrounding a proposed service, the application will be flagged for an extended review by the Registry Services Technical Evaluation Panel (RSTEP), see http://www.icann.org/en/registries/rsep/rstep.html). This review, if applicable, will occur during the Extended Evaluation period (refer to Section 2.3).
In the event that an application is flagged for extended review of one or more registry services, an additional fee to cover the cost of the extended review will be due from the applicant. Applicants will be advised of any additional fees due, which must be received before the additional review begins.
2.2.4 Applicant's Withdrawal of an Application
An applicant who does not pass the Initial Evaluation may withdraw its application at this stage and request a partial refund (refer to subsection 1.5 of Module 1).
2.3Extended Evaluation
An applicant may request an Extended Evaluation if the application has failed to pass the Initial Evaluation elements concerning:

• Geographic names (refer to subsection 2.2.1.4) – There is no additional fee for an extended evaluation in this instance.
• Demonstration of technical and operational capability (refer to subsection 2.2.2.1). There is no additional fee for an extended evaluation in this instance.
• Demonstration of financial capability (refer to subsection 2.2.2.2). There is no additional fee for an extended evaluation in this instance.
• Registry services (refer to subsection 2.2.3). Note that this investigation incurs an additional fee (the Registry Services Review Fee) if the applicant wishes to proceed. See Section 1.5 of Module 1 for fee and payment information.

An Extended Evaluation does not imply any change of the evaluation criteria. The same criteria used in the Initial Evaluation will be used to review the application in light of clarifications provided by the applicant.
From the time an applicant receives notice of failure to pass the Initial Evaluation, eligible applicants will have 15 calendar days to submit to ICANN the Notice of Request for Extended Evaluation. If the applicant does not explicitly request the Extended Evaluation (and pay an additional fee in the case of a Registry Services inquiry) the application will not proceed.
2.3.1Geographic Names Extended Evaluation
In the case of an application that has been identified as a geographic name requiring government support, but where the applicant has not provided evidence of support or non-objection from all relevant governments or public authorities by the end of the Initial Evaluation period, the applicant has additional time in the Extended Evaluation period to obtain and submit this documentation.
If the applicant submits the documentation to the Geographic Names Panel by the required date, the GNP will perform its review of the documentation as detailed in section 2.2.1.4. If the applicant has not provided the documentation by the required date (at least 90 days from the date of the notice), the application will not pass the Extended Evaluation, and no further reviews are available.
2.3.2Technical/Operational or Financial Extended Evaluation
The following applies to an Extended Evaluation of an applicant's technical and operational capability or financial capability, as described in subsection 2.2.2.
An applicant who has requested Extended Evaluation will again access the online application system and clarify its answers to those questions or sections on which it received a non-passing score. The answers should be responsive to the evaluator report that indicates the reasons for failure. Applicants may not use the Extended Evaluation period to substitute portions of new information for the information submitted in their original applications, i.e., to materially change the application.
An applicant participating in an Extended Evaluation on the Technical / Operational or Financial reviews will have the option to have its application reviewed by the same evaluation panelists who performed the review during the Initial Evaluation period, or to have a different set of panelists perform the review during Extended Evaluation.
The Extended Evaluation allows an additional exchange of information between the evaluators and the applicant to further clarify information contained in the application. This supplemental information will become part of the application record. Such communications will include a deadline for the applicant to respond.
ICANN will notify applicants at the end of the Extended Evaluation period as to whether they have passed. If an application passes Extended Evaluation, it continues to the next stage in the process. If an application does not pass Extended Evaluation, it will proceed no further. No further reviews are available.
2.3.3Registry Services Extended Evaluation
This section applies to Extended Evaluation of registry services, as described in subsection 2.2.3.
If a proposed registry service has been referred to the Registry Services Technical Evaluation Panel (RSTEP) for an extended review, the RSTEP will form a review team of members with the appropriate qualifications.
The review team will generally consist of three members, depending on the complexity of the registry service proposed. In a 3-member panel, the review could be conducted within 30 to 45 days. In cases where a 5-member panel is needed, this will be identified before the extended evaluation starts. In a 5-member panel, the review could be conducted in 45 days or fewer.
The cost of an RSTEP review will be covered by the applicant through payment of the Registry Services Review Fee. Refer to payment procedures in section 1.5 of Module 1. The RSTEP review will not commence until payment has been received.
If the RSTEP finds that one or more of the applicant's proposed registry services may be introduced without risk of a meaningful adverse effect on security or stability, these services will be included in the applicant's contract with ICANN. If the RSTEP finds that the proposed service would create a risk of a meaningful adverse effect on security or stability, the applicant may elect to proceed with its application without the proposed service, or withdraw its application for the gTLD. In this instance, an applicant has 15 calendar days to notify ICANN of its intent to proceed with the application. If an applicant does not explicitly provide such notice within this time frame, the application will proceed no further.
2.4Parties Involved in Evaluation
A number of independent experts and groups play a part in performing the various reviews in the evaluation process. A brief description of the various panels, their evaluation roles, and the circumstances under which they work is included in this section.
2.4.1 Panels and Roles
The String Similarity Panel will assess whether a proposed gTLD string creates a probability of user confusion due to similarity with any reserved name, any existing TLD, any requested IDN ccTLD, or any new gTLD string applied for in the current application round. This occurs during the String Similarity review in Initial Evaluation. The panel may also review IDN tables submitted by applicants as part of its work.
The DNS Stability Panel will review each applied-for string to determine whether the proposed string might adversely affect the security or stability of the DNS. This occurs during the DNS Stability String review in Initial Evaluation.
The Geographic Names Panel will review each application to determine whether the applied-for gTLD represents a geographic name, as defined in this guidebook. In the event that the string represents a geographic name and requires government support, the panel will ensure that the required documentation is provided with the application and verify that the documentation is from the relevant governments or public authorities and is authentic.
The Technical Evaluation Panel will review the technical components of each application against the criteria in the Applicant Guidebook, along with proposed registry operations, in order to determine whether the applicant is technically and operationally capable of operating a gTLD registry as proposed in the application. This occurs during the Technical/Operational reviews in Initial Evaluation, and may also occur in Extended Evaluation if elected by the applicant.
The Financial Evaluation Panel will review each application against the relevant business, financial and organizational criteria contained in the Applicant Guidebook, to determine whether the applicant is financially capable of maintaining a gTLD registry as proposed in the application. This occurs during the Financial review in Initial Evaluation, and may also occur in Extended Evaluation if elected by the applicant.
The Registry Services Technical Evaluation Panel (RSTEP) will review the proposed registry services in the application to determine if any registry services pose a risk of a meaningful adverse impact on security or stability. This occurs, if applicable, during the Extended Evaluation period.
Members of all panels are required to abide by the established Code of Conduct and Conflict of Interest guidelines included in this module.
2.4.2 Panel Selection Process
ICANN is in the process of selecting qualified third-party providers to perform the various reviews. See http://icann.org/en/topics/new-gtlds/open-tenders-eoi-en.htm.
In addition to the specific subject matter expertise required for each panel, specified qualifications are required, including:

• The provider must be able to convene – or have the capacity to convene - globally diverse panels and be able to evaluate applications from all regions of the world, including applications for IDN gTLDs.
• The provider should be familiar with the IETF IDNA standards, Unicode standards, relevant RFCs and the terminology associated with IDNs.
• The provider must be able to scale quickly to meet the demands of the evaluation of an unknown number of applications. At present it is not known how many applications will be received, how complex they will be, and whether they will be predominantly for ASCII or non-ASCII gTLDs.
• The provider must be able to evaluate the applications within the required timeframes of Initial and Extended Evaluation.

The providers will be formally engaged and announced on ICANN's website prior to the opening of the Application Submission period.
2.4.3 Code of Conduct Guidelines for Panelists
The purpose of the New gTLD Program ("Program") Code of Conduct ("Code") is to prevent real and apparent conflicts of interest and unethical behavior by any Evaluation Panelist ("Panelist").
Panelists shall conduct themselves as thoughtful, competent, well prepared, and impartial professionals throughout the application process. Panelists are expected to comply with equity and high ethical standards while assuring the Internet community, its constituents, and the public of objectivity, integrity, confidentiality, and credibility. Unethical actions, or even the appearance of compromise, are not acceptable. Panelists are expected to be guided by the following principles in carrying out their respective responsibilities. This Code is intended to summarize the principles and nothing in this Code should be considered as limiting duties, obligations or legal requirements with which Panelists must comply.
Bias -- Panelists shall:

• not advance personal agendas or non-ICANN approved agendas in the evaluation of applications;

• examine facts as they exist and not be influenced by past reputation, media accounts, or unverified statements about the applications being evaluated;

• exclude themselves from participating in the evaluation of an application if, to their knowledge, there is some predisposing factor that could prejudice them with respect to such evaluation; and

• exclude themselves from evaluation activities if they are philosophically opposed to or are on record as having made generic criticism about a specific type of applicant or application.

Compensation/Gifts -- Panelists shall not request or accept any compensation whatsoever or any gifts of substance from the Applicant being reviewed or anyone affiliated with the Applicant. (Gifts of substance would include any gift greater than USD 25 in value).
If the giving of small tokens is important to the Applicant's culture, Panelists may accept these tokens; however, the total of such tokens must not exceed USD 25 in value. If in doubt, the Panelist should err on the side of caution by declining gifts of any kind.
Conflicts of Interest -- Panelists shall act in accordance with the "New gTLD Program Conflicts of Interest Guidelines" (see subsection 2.4.3.1).
Confidentiality -- Confidentiality is an integral part of the evaluation process. Panelists must have access to sensitive information in order to conduct evaluations. Panelists must maintain confidentiality of information entrusted to them by ICANN and the Applicant and any other confidential information provided to them from whatever source, except when disclosure is legally mandated or has been authorized by ICANN. "Confidential information" includes all elements of the Program and information gathered as part of the process – which includes but is not limited to: documents, interviews, discussions, interpretations, and analyses – related to the review of any new gTLD application.
Affirmation -- All Panelists shall read this Code prior to commencing evaluation services and shall certify in writing that they have done so and understand the Code.
2.4.3.1 Conflict of Interest Guidelines for Panelists
It is recognized that third-party providers may have a large number of employees in several countries serving numerous clients. In fact, it is possible that a number of Panelists may be very well known within the registry / registrar community and have provided professional services to a number of potential applicants.
To safeguard against the potential for inappropriate influence and ensure applications are evaluated in an objective and independent manner, ICANN has established detailed Conflict of Interest guidelines and procedures that will be followed by the Evaluation Panelists. To help ensure that the guidelines are appropriately followed ICANN will:

• • • • Require each Evaluation Panelist (provider and individual) to acknowledge and document understanding of the Conflict of Interest guidelines.
      • Require each Evaluation Panelist to disclose all business relationships engaged in at any time during the past six months.
      • Where possible, identify and secure primary and backup providers for evaluation panels.
        • In conjunction with the Evaluation Panelists, develop and implement a process to identify conflicts and re-assign applications as appropriate to secondary or contingent third party providers to perform the reviews.

Compliance Period -- All Evaluation Panelists must comply with the Conflict of Interest guidelines beginning with the opening date of the Application Submission period and ending with the public announcement by ICANN of the final outcomes of all the applications from the Applicant in question.
Guidelines -- The following guidelines are the minimum standards with which all Evaluation Panelists must comply. It is recognized that it is impossible to foresee and cover all circumstances in which a potential conflict of interest might arise. In these cases the Evaluation Panelist should evaluate whether the existing facts and circumstances would lead a reasonable person to conclude that there is an actual conflict of interest.
Evaluation Panelists and Immediate Family Members:

• • • • Must not be under contract, have or be included in a current proposal to provide Professional Services for or on behalf of the Applicant during the Compliance Period.
      • Must not currently hold or be committed to acquire any interest in a privately-held Applicant.
      • Must not currently hold or be committed to acquire more than 1% of any publicly listed Applicant's outstanding equity securities or other ownership interests.
      • Must not be involved or have an interest in a joint venture, partnership or other business arrangement with the Applicant.
      • Must not have been named in a lawsuit with or against the Applicant.
      • Must not be a:
        • Director, officer, or employee, or in any capacity equivalent to that of a member of management of the Applicant;
        • Promoter, underwriter, or voting trustee of the Applicant; or
        • Trustee for any pension or profit-sharing trust of the Applicant.

Definitions--
Evaluation Panelist: An Evaluation Panelist is any individual associated with the review of an application. This includes any primary, secondary, and contingent third party Panelists engaged by ICANN to review new gTLD applications.
Immediate Family Member: Immediate Family Member is a spouse, spousal equivalent, or dependent (whether or not related) of an Evaluation Panelist.
Professional Services: include, but are not limited to legal services, financial audit, financial planning / investment, outsourced services, consulting services such as business / management / internal audit, tax, information technology, registry / registrar services.
2.4.3.2 Code of Conduct Violations
Evaluation panelist breaches of the Code of Conduct, whether intentional or not, shall be reviewed by ICANN, which may make recommendations for corrective action, if deemed necessary. Serious breaches of the Code may be cause for dismissal of the person, persons or provider committing the infraction.
In a case where ICANN determines that a Panelist has failed to comply with the Code of Conduct, the results of that Panelist's review for all assigned applications will be discarded and the affected applications will undergo a review by new panelists.
Complaints about violations of the Code of Conduct by a Panelist may be brought to the attention of ICANN via the public comment and applicant support mechanisms, throughout the evaluation period. Concerns of applicants regarding panels should be communicated via the defined support channels (see subsection 1.4.2). Concerns of the general public (i.e., non-applicants) can be raised via the public comment forum, as described in Module 1.
2.4.4 Communication Channels
Defined channels for technical support or exchanges of information with ICANN and with evaluation panels are available to applicants during the Initial Evaluation and Extended Evaluation periods. Contacting individual ICANN staff members, Board members, or individuals engaged by ICANN to perform an evaluation role in order to lobby for a particular outcome or to obtain confidential information about applications under review is not appropriate. In the interests of fairness and equivalent treatment for all applicants, any such individual contacts will be referred to the appropriate communication channels.