If no, please explain

Module 1 of the Draft Applicant Guidebook establishes a clear framework for the application process and aligns with most of the Board-approved recommendations stemming from the SubPro Final Report. The emphasis on application types, good faith intent, and integration of variant strings shows thoughtful evolution from the 2012 round. However, to fully meet the global vision of inclusivity and language diversity in the next round, this module must more explicitly address Universal Acceptance (UA) and promote IDNs as essential digital infrastructure for underserved communities. The following points are recommended for improvement: 1. Strengthen UA and IDN Integration in the Applicant Journey : The section introducing Internationalized Domain Names is appreciated, but the document does not frame UA-readiness as a baseline expectation for applicants seeking to serve multilingual internet users. We recommend adding a clause in the pre-submission guidance to encourage or require applicants to demonstrate how their technical and operational plans support UA-readiness, including support for EAI (Email Address Internationalization), variant handling, and acceptance of domain names in local scripts across platforms. 2. Clarify Good Faith Intent in the Context of Community Benefit and UA : Section 1.1.5 requires a "bona fide intention to operate the gTLD," which is appropriate. However, a UA/IDN-aware definition of “bona fide” should be included. For example, applications for IDN strings should demonstrate a genuine connection with the linguistic or regional communities concerned and a commitment to deploy UA-compliant infrastructure. ICANN could link this to obligations in later modules (e.g., Registry Services in Module 6, PICs in Module 7). 3. Cross-Reference Supportive Mechanisms for IDN/UA Readiness: Applicants from underserved regions or linguistic communities may face technical and financial hurdles in complying with UA best practices. Module 1 should explicitly reference the Applicant Support Program (Appendix 11) and Registry Service Provider Evaluation (Appendix 12) as vehicles for enabling UA/IDN-compliant applications. A diagram showing how an IDN applicant moves through each support mechanism would increase clarity. 4. Ensure Early Introduction of UA Awareness in Lifecycle Orientation : The lifecycle summary in Module 1.3 and 1.5 should introduce Universal Acceptance testing as a milestone to be completed before delegation. This would promote early adoption of standards and reduce friction post-delegation. Module 1 sets a strong procedural tone for the New gTLD Program: Next Round. To fully realize ICANN’s goals of diversity, equity, and global access, it must also elevate Universal Acceptance and IDN-readiness from an implied expectation to a clear, trackable component of the applicant journey.

If no, please explain

Yes, with strategic recommendations to enhance IDN and Universal Acceptance (UA) adoption. Module 2 aligns well with Board-approved recommendations and reflects meaningful progress in streamlining the application process. However, to truly deliver on the global promise of the New gTLD Program, we recommend that ICANN further prioritize Universal Acceptance (UA) readiness and IDN integration throughout the application submission process. The following refinements would help enhance accessibility, inclusivity, and long-term utility of new gTLDs for underrepresented communities: 1. Prioritization of IDNs in Application Workflow Section 2.7.3 addresses prioritization of IDN applications in the draw process, which is a welcome continuation from 2012. However, we strongly urge ICANN to explicitly recognize Universal Acceptance-readiness as a qualifying characteristic for enhanced prioritization or fast-track processing. The application system (TAMS) should validate UA-readiness indicators and highlight gaps to help applicants meet these benchmarks early. 2. Variant String Handling and UA Education While the application supports variant strings for IDNs (Section 2.1.9), more guidance should be provided on how such strings will be handled to ensure UA-readiness. We recommend that ICANN provide mandatory pre-submission training modules on UA and IDN variant handling to help applicants configure their strings and backend infrastructure with UA best practices. Educational prompts or tooltips within TAMS would increase UA compliance during application drafting. 3. Application Change Requests (ACRs) and Language/Scripts For ACRs that involve string modifications or language/script changes, the criteria (Section 2.8) should include a UA impact assessment as part of the approval process. Additionally, applicants should be encouraged to evaluate whether proposed changes strengthen or weaken IDN compatibility and UA adoption downstream. 4. Financial Incentives for UA-Ready Applicants Within the Applicant Support Program or fee structures (Section 2.3), ICANN should consider offering credits or reduced evaluation fees for applicants demonstrating pre-evaluated UA-readiness and commitment to supporting multilingual access. Module 2 demonstrates a solid procedural foundation, but it can be a powerful lever to accelerate global UA and IDN adoption by embedding specific requirements, incentives, and guidance. Strengthening this focus will help achieve the multistakeholder vision of a truly inclusive Internet where users can access, register, and navigate domain names in their native scripts without barriers.

If no, please explain

Yes, with critical recommendations to better integrate Universal Acceptance and IDN-related concerns into community and objection mechanisms. Module 3 provides a comprehensive framework for objections, appeals, and community input, aligning with the Board-approved SubPro Final Report and reflecting valuable procedural refinements. However, to maximize community benefit and uphold the multilingual vision of the New gTLD Program, it is essential that the objection and appeals processes explicitly account for Universal Acceptance (UA) and IDN-related issues. We respectfully submit the following strategic enhancements: 1. GAC and Community-Based Inputs Should Address UA/IDN Risk : While the GAC Early Warnings and GAC Consensus Advice mechanisms (Sections 3.2 and 3.3) allow for public interest evaluations, there is no specific prompt to flag applications that may hinder IDN deployment or fail to meet UA-readiness principles. ICANN should encourage GAC and community stakeholders to submit comments or objections if an application: Intentionally or negligently excludes EAI support; Misuses an IDN script in a misleading way; May cause fragmentation or confusion for end-users relying on UA-compliant infrastructure. 2. Standing to Object Should Include UA/IDN Stakeholder Concerns : The standing criteria for objection grounds (Section 3.5.2) do not explicitly empower stakeholders or groups working on Universal Acceptance, script integrity, or linguistic representation. We recommend expanding standing or at minimum including guidance that UA advocacy groups, script community organizations, and EAI stakeholders may be recognized as having standing on relevant objections, particularly under: Limited Public Interest Objections (3.5.1.3), where lack of UA-readiness may result in accessibility discrimination; Community Objections (3.5.1.4), where the proposed TLD does not represent the linguistic/script community authentically. 3. Appeals and Expert Panels Should Consider UA/IDN Implications : While the draft provides detailed process flows for appeals and expert determinations, UA and IDN impact assessments are not part of the evaluation matrix. We recommend ICANN define an "impact on Universal Acceptance and linguistic accessibility" as a legitimate ground for consideration in panel deliberations under Limited Public Interest and Community objection types (see Sections 3.5.10.3 and 3.5.10.4). 4. Application Comment Forum Design Should Support Multilingual Input Section 3.1 outlines the Application Comment process, but we urge ICANN to: Support multilingual submissions in all UN languages and other widely-used scripts; Ensure comment mechanisms are UA-compliant, allowing commenters to reference domain names in native scripts (e.g., ईमेल.भारत or 邮件.中国). While Module 3 is structurally aligned with Board directives, it must evolve to actively protect and promote Universal Acceptance and IDN adoption through its objection, appeal, and comment mechanisms. As the Internet grows more multilingual and inclusive, this module must empower the community to challenge applications that ignore or undermine these foundational priorities.

If no, please explain

Yes, with recommendations to enhance fairness, transparency, and Universal Acceptance outcomes for IDN and linguistically diverse applicants. Module 4 aligns with the Board-approved SubPro recommendations and introduces key improvements over the 2012 round, particularly in reducing reliance on private auctions and allowing for replacement strings to reduce contention. However, several areas require further refinement to ensure the equitable treatment of Internationalized Domain Name (IDN) applicants and promote outcomes that are aligned with Universal Acceptance (UA) objectives: 1. Equitable Treatment of IDN Strings in Contention Resolution : The introduction of replacement strings and recognition of variant strings is welcome. However, the contention resolution procedures lack specific guidance for resolving disputes involving IDN strings or scripts from the same language family. In many regions, linguistic variants may be viewed as distinct by native communities, yet may be grouped as "similar" for contention purposes. This risks unfairly eliminating culturally significant applications. We recommend the inclusion of script community consultation or UA/IDN expert input in the evaluation of string similarity and contention decisions involving IDNs, particularly when variant or homoglyphic confusion is cited. 2. Recognition of Community Representation in CPE for IDNs : Community Priority Evaluation (CPE) scoring should take into account linguistic and cultural representation in IDN applications (Section 4.4). For example, an applicant seeking a TLD in Devanagari or Arabic script for a well-recognized linguistic group should receive scoring weight where they demonstrate authentic representation of that language community. We recommend that Module 4 explicitly require evaluators to consider the applicant’s Universal Acceptance preparedness and community-based deployment strategy, particularly for scripts that are underrepresented or face systemic UA barriers. 3. Auctions and String Confusion Must Account for Script Diversity : Section 4.2.4 introduces string contention arising from string similarity and plural/singular disputes. However, these mechanisms must be carefully adapted for non-Latin scripts. For example, pluralization in languages like Tamil, Thai, or Hindi may not follow ASCII-like patterns, and subjective assessments of "similarity" could disproportionately affect IDN applicants. We urge ICANN to develop localized string similarity criteria with input from language/script experts and UA stakeholders, and to publish these alongside general guidelines for transparency. 4. Prohibition of Private Resolution Should Not Deter UA-Ready Collaboration : We support ICANN's move to prohibit most forms of private resolution (Section 4.2.3), but recommend clarifying that collaborative solutions among UA-ready or script-aligned applicants (e.g., forming consortia for better script coverage) should be encouraged, not penalized. In regions with low infrastructure or technical support for EAI and IDN deployment, collaboration may be the most viable path to Universal Acceptance adoption. Module 4 is directionally aligned with the community’s policy vision, but requires additional mechanisms to ensure that IDN-based and linguistically inclusive applications are evaluated fairly and transparently in contention scenarios. This will support a more equitable and multilingual expansion of the DNS, consistent with ICANN’s commitments to the global Internet community and Universal Acceptance.

If no, please explain

Yes, with important recommendations to embed Universal Acceptance (UA) and IDN-readiness into applicant evaluation criteria. Module 5 presents a structured and policy-aligned framework for applicant evaluation, including background screening and financial/operational capabilities. While the language is consistent with Board-approved recommendations, it falls short in making Universal Acceptance (UA) and IDN-readiness core components of technical and operational evaluation. If ICANN is to meet its commitments to a multilingual and inclusive Internet, these aspects must be integrated into applicant screening from the outset—not treated as optional or post-delegation considerations. 1. Introduce UA-Readiness as a Criterion in Operational Evaluation : The current operational evaluation (Section 5.2) focuses primarily on financial capacity and basic registry operation ability. We strongly recommend including a requirement for applicants to demonstrate UA-readiness, including: Email Address Internationalization (EAI) support; Correct rendering and processing of IDNs across platforms; Integration with UA-compliant systems and partners. This aligns with ICANN’s strategic goals and ensures registries are equipped to serve global users from day one. 2. Require IDN Competency Where IDNs or Variant Strings Are Applied For : If an applicant is requesting an IDN gTLD or IDN variant (including under Appendix 12), the evaluation must assess their linguistic competence, script handling capability, and commitment to culturally appropriate implementation. Lack of readiness in these areas risks failed implementations and lost trust among language communities. 3. Tie Applicant Support Program Outcomes to UA Capacity Building : For applicants benefiting from the Applicant Support Program, UA-readiness should be a supported but required deliverable within their onboarding or ramp-up timeline. ICANN could provide technical guidance or connect applicants to qualified Registry Service Providers (RSPs) that meet UA/IDN criteria. 4. Encourage Registry Commitments that Promote UA Post-Delegation: Evaluators should give additional consideration to applicants who propose Public Interest Commitments (PICs) or Registry Voluntary Commitments (RVCs) supporting UA adoption (e.g., local script education, multilingual helpdesks, EAI support for registrants). This could be reflected as a favorable factor during the evaluation of technical capacity or risk assessment. Module 5 ensures procedural integrity but needs clear policy and operational linkages to Universal Acceptance and IDN-readiness goals. Embedding these expectations in applicant evaluation will raise the baseline for the next generation of gTLD operators and better serve the global Internet community.

If no, please explain

Yes, with substantive recommendations to improve the handling of Internationalized Domain Names (IDNs), variant evaluation, and alignment with Universal Acceptance (UA) principles. Module 6 appropriately reflects the policy intent behind the SubPro Final Report by detailing how ICANN will evaluate different application types, including IDNs, brand TLDs, geographic names, and variants. The structure is robust, but from a Universal Acceptance and IDN adoption perspective, several critical areas require further strengthening to ensure the Next Round is linguistically inclusive, technically sound, and globally equitable. 1. Strengthen Evaluation Criteria for IDN Applications and Variant Strings While Section 6.1.2.5 and 6.6 address IDNs and variants, they primarily focus on procedural requirements. There is insufficient evaluation of whether the applicant is technically and linguistically equipped to responsibly manage an IDN TLD. ICANN should incorporate script-based community engagement, linguistic appropriateness checks, and a cultural sensitivity review in evaluating IDN applications, especially when multiple applicants contest similar strings in a language. Applicants should also be asked to demonstrate Universal Acceptance-readiness, including support for EAI, proper rendering of characters, and commitment to promoting IDNs in their served community. 2. Universal Acceptance (UA) as a Baseline Requirement for String Evaluation The String Similarity Evaluation (Section 6.10) and Name Collision assessments (6.7) are crucial, but their UA impact is not explicitly considered. We recommend adding UA readiness checks into the string evaluation process, such as: Ensuring applied-for strings are accepted and rendered correctly in common applications; Highlighting potential UA pitfalls (e.g., strings that use homoglyphs or diacritics that often fail in non-UA-ready software). Where necessary, such strings should require the applicant to file a mitigation plan or undergo further UA-focused evaluation. 3. Geographic and Script-Related Evaluations Must Prevent Linguistic Misappropriation The Geographic Names Review (Section 6.5) should include a requirement that IDN strings in a geographic script or language reflect community interest or involvement—especially where the applicant is not based in the linguistic region. This avoids misuse of culturally significant terms and aligns with GAC principles on sensitive names. 4. Registry Commitments and UA Promotion We support the inclusion of Public Interest Commitments (PICs) and Registry Voluntary Commitments (RVCs) in Section 6.8. However, ICANN should prioritize or highlight applications with explicit commitments to promoting Universal Acceptance. Examples include: Operating UA training programs for registrars and resellers; Providing multilingual user support and EAI-enabled infrastructure; Committing to UA compliance reporting during registry operations. 5. Consider Script-Specific Variability in String Similarity Evaluations The String Similarity Evaluation Panel (Section 6.10) should be instructed to consider script-specific orthographic and linguistic norms, not just visual similarity or ASCII logic. ICANN must publish a clear methodology and engage script/language experts during string similarity determinations involving non-Latin scripts. Module 6 is central to the success of a multilingual and UA-compliant DNS. By integrating stronger criteria around IDN responsibility, linguistic authenticity, UA-readiness, and culturally aware string handling, ICANN can make the Next Round a significant milestone in bridging the digital divide and empowering local language communities.

If no, please explain

Yes, with forward-looking recommendations to reinforce Universal Acceptance and IDN promotion within the program’s overarching governance and operational principles. Module 7 serves as the concluding framework of the Applicant Guidebook, covering general terms, accountability, Public Interest Commitments (PICs), Registry Agreements, and overarching principles. The language reflects ICANN’s policy commitments and is largely consistent with Board-approved recommendations. However, greater emphasis is needed on Universal Acceptance (UA) as a foundational principle of public benefit, particularly in registry operations and post-delegation compliance. 1. Public Interest Commitments (PICs) Should Encourage UA and IDN Support Section 7.4 discusses the submission of PICs but does not suggest or encourage registries to adopt commitments related to UA or IDN promotion. We recommend ICANN include a model PIC encouraging (or at least highlighting) the registry’s willingness to: Operate UA-ready systems; Promote multilingual access and EAI adoption; Provide end-user and registrar education around IDNs. 2. Registry Agreement Terms Should Include UA Obligations Section 7.5 outlines the Registry Agreement (RA), but there is no mention of Universal Acceptance requirements, despite growing consensus in the technical community that UA is essential to the DNS’s future. At minimum, the RA should: Reference Universal Acceptance principles and recognize them as part of best operational practices; Require registries offering IDN TLDs to submit periodic UA-readiness self-assessments or implementation plans (possibly via the RSP monitoring program). 3. Post-Delegation Dispute Mechanisms Should Consider UA Impacts The Accountability and Dispute mechanisms (Section 7.6) do not currently consider whether a registry’s failure to implement UA or support IDNs might constitute a breach of public interest obligations or commitments. We recommend that failure to adhere to declared UA/IDN-related commitments should be formally considered as part of PICDRP or RRDRP evaluations, especially when it undermines access for users in a specific language/script community. 4. General AGB Principles Should Explicitly Reference UA and Linguistic Inclusion The introduction to Module 7 and the AGB’s overall preamble should explicitly include a principle affirming ICANN's commitment to a multilingual Internet and to ensuring Universal Acceptance of all valid domain names and email addresses. This would signal to all stakeholders — applicants, RSPs, governments, and users — that UA and IDNs are not secondary technical issues, but core enablers of global digital participation. Module 7 encapsulates the governance spirit of the AGB, and as such, it should boldly articulate and embed ICANN’s responsibility to ensure Universal Acceptance, linguistic inclusivity, and equitable access across all scripts and geographies. This would set the tone not only for the Next Round but also for the Internet’s next era of growth.

If no, please explain

Yes, with specific recommendations to integrate Universal Acceptance and IDN-readiness considerations into the application questions. Appendix 1 presents a thorough and structured set of application questions aligned with the Board-approved recommendations from the SubPro Final Report. The division into baseline, registry-specific, and RSP-facilitated sections is useful. However, from a Universal Acceptance (UA) and IDN community inclusion perspective, there is a missed opportunity to directly assess an applicant’s commitment, readiness, and strategy for ensuring UA and supporting IDNs. To make the Next Round more effective, inclusive, and aligned with Internet accessibility goals, the following enhancements are proposed: 1. Add UA-Specific Language to Technical and Operational Questions Q22 (Registry Services) and Q24 (IDNs): These questions should require the applicant to describe: How they will ensure Universal Acceptance-readiness in their technical operations; What provisions exist to support EAI, UA-compliant WHOIS, and multilingual support tools; How they will address known UA challenges in their script or user base. Suggested Addition to Q24: “Describe how your registry services will support Universal Acceptance of the applied-for IDN TLD, including support for Email Address Internationalization (EAI) and user accessibility in systems reliant on this TLD.” 2. Improve Evaluation of IDN Linguistic Authenticity and Community Representation For IDN TLD applications, especially under community or cultural framing, the application should ask: Whether the applicant has engaged relevant script/language communities; Whether the applied-for string reflects authentic script usage and complies with local orthographic standards; Whether the registry will operate services in a linguistically and culturally appropriate manner. Suggested New Question (for IDN applications): “Please describe the applicant’s connection to and consultation with the script/language community associated with the applied-for IDN string, including any community endorsements or considerations regarding linguistic appropriateness.” 3. Add Optional/Weighted Questions on UA Advocacy and Promotion ICANN should consider incentivizing proactive UA promotion by allowing applicants to earn credit or recognition for: Commitments to educate registrars and end-users on UA; Plans to collaborate with local stakeholders to promote IDN awareness; Plans to publish UA implementation guides or case studies post-launch. 4. Ensure Consistency Between Application Questions and Support Program (Appendix 11) Applicants applying through the Applicant Support Program (ASP) should be guided to explain how support will help them achieve UA-readiness and serve a linguistically diverse user base. There is a strong case for cross-referencing Appendix 1 with Appendix 11, especially for underserved applicants targeting IDN gTLDs. Appendix 1’s application questions offer a solid procedural foundation but must evolve to explicitly capture applicants’ capacity and intent to enable Universal Acceptance and IDN sustainability. These additions would align the application process with ICANN’s strategic goals and enhance the diversity, usability, and effectiveness of the new gTLD space for global users.

If no, please explain

Yes, with important recommendations to ensure fairness, linguistic representation, and Universal Acceptance in the context of geographic name applications—especially in IDN scripts. Appendix 2 appropriately reflects the Board-approved recommendations and attempts to provide clearer, more transparent criteria for handling geographic names, capital cities, and subdivisions. However, the evaluation and objection process for geographic names in non-Latin scripts (IDNs) presents unique challenges that demand additional guidance to ensure linguistic authenticity, script integrity, and Universal Acceptance (UA) alignment. To promote fair access and community trust, we offer the following targeted recommendations: 1. Recognize Script-Based Community Sensitivities in Geographic Names The appendix lacks sufficient treatment of how IDN strings representing geographic terms should be evaluated for cultural or linguistic appropriateness. We recommend adding language to ensure that geographic names submitted in non-Latin scripts: Accurately reflect local usage and orthographic standards; Have support or non-objection from relevant language/script authorities or local communities, even if not legally mandated; Do not distort the meaning or identity of the referenced geography when rendered in native script. 2. Encourage UA-Ready Representations of Geographic Names Applicants for geographic TLDs in IDN scripts should be required to demonstrate UA-readiness of their applied-for string, especially where the script is underrepresented or has known technical challenges. The application materials should include: A description of how the IDN will be implemented to function properly in UA contexts; Whether the registry has planned for Email Address Internationalization (EAI) and local script rendering across web, email, and mobile ecosystems. 3. Provide Local Authorities with UA/IDN Awareness Resources While the Appendix rightly emphasizes approval or non-objection letters from relevant authorities, it is equally important to ensure those authorities: Understand the implications of approving an IDN TLD; Are aware of potential UA gaps that could impact usability or confusion among local populations. ICANN should attach to this appendix (or link to) a geographic UA/IDN explainer brief to help local governments evaluate the readiness and relevance of a proposed IDN geographic string. 4. Address Variant or Homoglyph Conflicts in Geographic IDN Applications When evaluating IDN strings that resemble geographic names in form but differ in meaning or origin (e.g., same characters used in different scripts), the appendix should include a provision for UA-aware script conflict resolution, possibly consulting script panels or community experts. Appendix 2 provides a more transparent framework for geographic names but would benefit from stronger integration of Universal Acceptance readiness, IDN linguistic integrity, and community safeguards for script-based representations. These enhancements will foster trust, reduce objections, and enable a more equitable and multilingual DNS expansion.

If no, please explain

Yes, with recommendations to improve the fairness, linguistic equity, and UA relevance of the objection and appeal processes—particularly in IDN and language/script-related cases. Appendix 3 outlines the framework for filing objections and appeals under various grounds (e.g., Limited Public Interest, Community Objection, String Confusion), and is generally aligned with Board-adopted SubPro recommendations. However, in the context of IDN applications and UA-readiness, this appendix must go further to ensure that script-based objections and community-driven concerns are given sufficient procedural visibility and standing. 1. Recognize Standing for UA/IDN Community Stakeholders The current language defining standing to object under Limited Public Interest and Community Objection does not explicitly include groups working on Universal Acceptance, script integrity, or IDN standards. We recommend expanding guidance or examples to clarify that: Language/script communities, UA advocacy groups, or IDN technical working bodies can have standing when the string or application has script misuse implications or might misrepresent a linguistic community. These groups should also be permitted to file supporting documentation or amicus briefs even if they are not the primary objector. 2. Panels Must Be Informed on IDN Linguistic and Cultural Contexts Objection and appeal panels evaluating IDN-related cases should be required to: Consult script panels or language community representatives where string meaning, cultural sensitivity, or variant similarity is disputed; Consider whether a proposed IDN string undermines community identity or violates linguistic norms, which may not be apparent from a purely visual or ASCII-based review. ICANN should publish procedural standards for selecting panelists in IDN-related cases, ensuring they include language diversity and UA understanding. 3. UA Non-Compliance Should Be Grounds for Limited Public Interest Objection The appendix should explicitly allow for Limited Public Interest Objections in cases where: The applied-for string or operational plan intentionally disregards Universal Acceptance norms; There is risk of exclusion or harm to users relying on EAI or IDNs; The applicant has misrepresented their UA-readiness or community representation in the application. 4. Appeals Mechanism Should Allow for UA and IDN-Related Reconsideration The appeals and accountability mechanisms must be equipped to address: Oversights in evaluating script-based objections; Procedural unfairness where IDN applicant communities lacked standing or representation; Evidence that UA non-readiness materially affects the public interest or technical feasibility of the string. Appendix 3 provides a strong legal structure for objections and appeals, but to support a truly multilingual and inclusive DNS ecosystem, it must explicitly protect IDN and UA-related interests, empower affected communities, and ensure panels are equipped to handle the linguistic and technical nuances of non-ASCII domain names.

If no, please explain

Yes, with recommendations to include financial modeling guidance and evaluation criteria that reflect Universal Acceptance (UA) readiness and support for IDN-based business models. Appendix 5 lays out a standardized financial template to assess the viability of applicants’ operational and business models. While it is structurally consistent with the Board-approved recommendations, it lacks sufficient consideration for applicants who are launching Internationalized Domain Name (IDN) TLDs or building UA-aligned infrastructure in linguistically underserved regions. Such applicants often face unique challenges in adoption, user education, technical investment, and community engagement, which must be reflected in financial projections and evaluation frameworks to ensure equitable access and opportunity. 1. Allow for UA/IDN-Focused Financial Planning The template should include optional line items for projected expenses related to: EAI implementation and integration with registrars and hosting providers; IDN outreach, education, and localization costs; Universal Acceptance testing and compliance monitoring across software stacks. These projections are critical for applicants targeting multilingual or underserved user bases, and should not be penalized as “non-standard” expenses in the financial review. 2. Tailor Evaluation Criteria for IDN or UA-Centric Business Models Evaluation of financial viability should not impose uniform assumptions around market behavior that may not apply to IDN TLDs or non-Latin script registries. We recommend that evaluators be instructed to: Contextualize revenue growth curves and adoption rates for IDN registries, which may experience slower ramp-up due to lower current UA-readiness; Recognize public-good or language-preservation-oriented goals that may prioritize community adoption over near-term profitability. 3. Support Applicants in Developing UA-Aware Financial Plans ICANN should provide optional guidance materials or sample UA/IDN-oriented financial projections to support applicants from emerging markets or linguistic minority groups. These materials can be cross-referenced from the Applicant Support Program (Appendix 11) and included as attachments to the financial templates. 4. Encourage Transparency and Public Interest Commitments If applicants include Public Interest Commitments (PICs) or Registry Voluntary Commitments (RVCs) related to Universal Acceptance, EAI deployment, or IDN community education, they should be invited to quantify their financial support for these efforts in the business plan. Evaluators should treat these as positive signals of sustainability and responsibility—not as cost burdens. Appendix 5 can significantly enhance fairness and inclusivity by adapting its financial modeling expectations to accommodate the realities of Universal Acceptance implementation and IDN-focused registry models. Doing so will support more diverse applicants and promote resilient multilingual DNS infrastructure.

If no, please explain

Yes, with important recommendations to explicitly address how changes affecting Universal Acceptance (UA) and IDNs will be managed within the Predictability Framework. Appendix 6 is consistent with the Board-approved recommendations and provides a much-needed structure to manage changes that may arise during the course of the application process. The inclusion of a Standardized Change Evaluation process and engagement with the SPIRT (Standing Predictability Implementation Review Team) enhances transparency and community trust. However, the language does not explicitly acknowledge the unique sensitivities of IDN or UA-related issues, which can have disproportionate impact on linguistic communities and underserved populations. 1. Explicitly Recognize UA and IDN as High-Impact Change Categories Changes that may affect the treatment of: IDN variant rules, UA-readiness standards, String similarity evaluation methodologies for non-Latin scripts, EAI compatibility or IDN-related registry obligations, should be classified as high-impact or community-impacting changes (Category 2 or 3) under the framework. This would ensure that changes to these areas trigger appropriate SPIRT involvement and public transparency. 2. Ensure Linguistic Diversity in SPIRT Composition and Consultations ICANN should commit to ensuring SPIRT includes representatives with experience in IDN deployment, script management, UA standards, and community TLDs. For changes specifically affecting IDNs or UA policies, the framework should recommend script panel consultation or input from the Universal Acceptance Steering Group (UASG) or similar experts. 3. Include UA/IDN Impact Assessment in Change Evaluation Template The Standardized Change Evaluation process should include a dedicated question or field assessing the impact of a proposed change on Universal Acceptance or IDN operations. This could follow a similar model as environmental or public interest assessments used in other regulatory contexts. 4. Transparent Handling of Mid-Round UA/IDN Policy Adjustments In cases where mid-round adjustments to UA or IDN processing rules are necessary (e.g., due to emerging security concerns or script collisions), the framework should require: Clear documentation of the change rationale; Consultation with affected applicants and communities; Guidance on mitigation or grandfathering options to avoid penalizing applicants who acted in good faith under the prior rules. Appendix 6 provides a sound structure for managing change but must incorporate clearer safeguards and procedures to address the unique impact of policy shifts on UA and IDN applicants. Doing so will ensure the Predictability Framework advances ICANN’s goals of fairness, linguistic inclusion, and technical stability.

If no, please explain

Yes, with key recommendations to ensure service provider neutrality, particularly in relation to Universal Acceptance (UA), IDN applications, and underserved linguistic communities. Appendix 7 provides a structured and transparent framework to handle potential conflicts of interest involving third-party service providers participating in the evaluation, objection resolution, or other operational aspects of the New gTLD Program. It is generally aligned with Board-approved recommendations. However, as service providers will be responsible for evaluating IDN strings, script-based objections, UA-readiness claims, and potentially contentious evaluations involving non-Latin scripts or small-language registries, it is critical that the conflict of interest process be sensitive to bias — direct or indirect — that could undermine linguistic fairness or Universal Acceptance objectives. 1. Expand Conflict Definitions to Include UA/IDN-Related Biases or Affiliations The conflict of interest criteria (Sections 2 and 3) should explicitly include: Previous work or affiliations with entities that may exhibit bias (positive or negative) toward specific IDN scripts, language communities, or UA policy positions; Business or advocacy relationships that could influence impartiality in decisions on UA-readiness, EAI implementation assessments, or variant string handling. 2. Include UA/IDN Awareness in Service Provider Disclosure and Screening Service providers who will be involved in: String similarity decisions for IDNs; Variant handling or linguistic evaluations; Registry service readiness evaluations, should be required to disclose: Any prior involvement in UA-related technical work; Any linguistic affiliations that could affect perception of impartiality; Any contracts or consulting history with major players in UA/IDN policy. This is especially important given the limited pool of experts in these fields and the potential for perceived bias if their roles are not properly managed. 3. Encourage Linguistic and Geographic Diversity Among Evaluators To reduce systemic bias, ICANN should require service providers to: Demonstrate diversity in evaluator backgrounds, including representation from non-Latin script communities, emerging markets, and minority languages; Avoid over-concentration of evaluators from a single language background or technical community. 4. Publish a Summary of Declared UA/IDN Conflicts and Mitigations ICANN should commit to publicly disclosing a high-level summary of conflict declarations and management actions taken, particularly in cases involving UA or IDN applicants. This transparency builds trust with communities who may already feel marginalized in global digital policy processes. Appendix 7 addresses structural conflicts of interest well but must evolve to recognize the nuanced risks of bias in IDN, script-specific, and UA-related evaluations. Transparent, diverse, and linguistically aware evaluation is critical to building a trusted and inclusive New gTLD Program.

If no, please explain

Yes, with recommendations to improve the neutrality and inclusivity of service provider behavior, particularly in contexts involving IDN scripts, language-sensitive TLDs, and Universal Acceptance-related evaluations. Appendix 8 outlines ethical expectations and professional boundaries for service providers engaged in the New gTLD Program. The guidelines reinforce the importance of independence, objectivity, and confidentiality — which are critical foundations. However, as more applications in the Next Round are expected to be submitted in non-Latin scripts and culturally significant IDNs, the code of conduct must evolve to address potential implicit biases, linguistic insensitivity, and Universal Acceptance-related technical gaps that could influence evaluation outcomes. 1. Strengthen Language on Cultural and Script Neutrality The current Code of Conduct emphasizes general impartiality but does not explicitly address the need for cultural and linguistic neutrality when evaluating IDN strings or community-based applications. We recommend adding language that obliges service providers to: Acknowledge their own limitations or biases in handling non-Latin scripts; Refrain from applying ASCII-centric logic or assumptions to IDN evaluations; Respect and defer to script community norms where applicable (e.g., variant interpretation, naming conventions). 2. Add UA and EAI Awareness to Technical Evaluation Conduct Evaluators assessing registry technical questions or readiness (e.g., under Appendix 2 or Modules 5/6) must be expected to: Be familiar with Universal Acceptance best practices, including Email Address Internationalization (EAI); Avoid penalizing applicants for using UA-compliant but less mainstream technical solutions; Demonstrate equal treatment for IDN-based business models, including those with slow ramp-up projections due to UA constraints in local software ecosystems. 3. Disclosure of Prior Engagements in IDN/UA Policy Service providers should be required to disclose whether they have: Participated in policy, standards-setting, or commercial activity around IDNs or UA (e.g., through UASG, script panels, or working groups); Held positions that may influence their assessment of a registry’s UA-readiness or IDN legitimacy. This enhances transparency and minimizes risks of perceived or real bias. 4. Establish Mechanism for Community Review or Feedback on Conduct Especially in cases involving language-sensitive disputes or IDN objections, ICANN should allow affected communities to flag concerns about evaluator conduct or bias, and trigger a review if needed. This reinforces accountability while giving voice to linguistically marginalized or underrepresented groups. Appendix 8 provides a solid foundation for ethical oversight but needs explicit inclusion of script sensitivity, cultural neutrality, and UA technical awareness to protect the integrity of the evaluation process for IDN applicants and multilingual Internet stakeholders.

If no, please explain

Yes, with recommendations to ensure privacy provisions are implemented in ways that do not unintentionally disadvantage IDN-based applicants or delay UA-related technical adoption. Appendix 9 reflects ICANN's continued commitment to protecting personal data in accordance with global privacy standards, including GDPR and relevant data minimization principles. This is essential for maintaining trust in the application and evaluation process. However, in the context of the Next Round’s expected growth in IDN-based, script-diverse, and community-driven applications, the privacy policy must take additional care to ensure that data collection, processing, and disclosure mechanisms support linguistic and regional inclusivity — and do not impede Universal Acceptance efforts due to over-restriction or under-disclosure. 1. Support UA Readiness by Allowing Controlled Disclosure of Technical Contact Information Applicants deploying IDN TLDs or EAI-enabled infrastructure may wish to disclose technical contact details or third-party vendor support (e.g., UA-enabling registry service providers) to demonstrate readiness. The privacy framework should: Allow voluntary disclosure of technical vendor names, certifications, or UA-related partners where appropriate; Not restrict publication of such information under overly broad privacy interpretations. This fosters transparency for the community and helps build trust in lesser-known, UA-aligned applicants. 2. Ensure Multilingual Access to Privacy Disclosures To promote transparency among linguistically diverse applicants and end-users, the privacy policy and all related disclosures (such as data retention, rights of access, and contact methods) should be: Made available in multiple UN languages and common IDN user scripts; Written in clear, accessible language, avoiding legalese that could confuse non-native English speakers. 3. Encourage Privacy-Protective but Transparent IDN Application Processes While protecting personal data, ICANN must avoid creating an opaque process where IDN community applicants or their advocates cannot identify how decisions were made, by whom, or on what technical basis. We recommend allowing: Aggregated or pseudonymized public disclosures of evaluation summaries involving IDN and UA-readiness criteria; Publication of script-specific objections or evaluations without disclosing personal data, so that communities can understand precedent and ensure fairness. 4. Clarify Data Handling for Applicant Support and UA Advocacy Groups Applicant Support Program applicants and their affiliated community organizations (especially for IDNs) may involve collaborative submissions or multi-entity partnerships. ICANN should clarify how personal and organizational data from linguistic associations, script panels, or UA outreach partners will be handled — particularly when such groups may not be formal legal entities and mostly individuals. Appendix 9 is consistent with privacy best practices, but should incorporate specific measures to ensure that privacy enforcement does not undermine transparency, equity, and Universal Acceptance support, particularly for IDN-based applicants and those serving linguistically diverse user bases.

If no, please explain

Yes, with cautionary recommendations to ensure the Terms and Conditions support rather than hinder IDN adoption and Universal Acceptance progress. Appendix 10 defines the legal and procedural framework for applicants participating in the New gTLD Program: Next Round. The language is generally consistent with Board-approved recommendations and necessary from a risk management standpoint. However, the terms currently lack references to the unique obligations, expectations, or protections related to Internationalized Domain Names (IDNs), script diversity, and Universal Acceptance (UA). As such, we recommend the following updates to ensure the Terms and Conditions enable, rather than restrict, participation from UA-focused and IDN-based applicants: 1. Add Language Recognizing UA and IDN Commitments as Public Benefit The Terms should acknowledge that applicants making voluntary commitments to implement UA standards, promote multilingual Internet access, or support underserved scripts are encouraged to do so. ICANN should confirm that such commitments, if made in good faith, will not be penalized under contract performance terms unless they breach core policy. This ensures UA-aligned applicants do not fear legal exposure for community-beneficial initiatives. 2. Prevent Disproportionate Risk to IDN Applicants from Evolving Technical Standards Clause(s) related to future changes in ICANN policies or technical standards (e.g., Section 5 or equivalent) should not penalize applicants whose IDN or UA readiness plans may require phased implementation based on evolving support across the global digital ecosystem. For example, if UA adoption lags in browser or email software, the applicant should not be held in breach for slower registrant uptake. 3. Clarify Use of Language for Legal Commitments Across Jurisdictions Many IDN applicants will operate in non-English-speaking and non-Western legal systems. The Terms should: Be made available in multiple languages, especially where required by local law; Include provisions acknowledging cultural/legal interpretation differences when translated. 4. Clarify Rights Around IDN Strings and Script Representations ICANN should explicitly affirm that applying for an IDN string does not confer broader rights over a language, script, or cultural symbol, and that evaluation will consider appropriate script usage as discussed in other modules. This prevents any misinterpretation that the Terms allow monopolization of a script or term via a gTLD. Appendix 10 is legally sound and procedurally consistent, but should be refined to ensure it does not create undue legal risk or disincentives for UA-aligned or IDN-focused applicants—particularly those working to bridge the digital divide in local languages and scripts.