If no, please explain

Key aspects of consistency and areas for enhancement in Module 1 include: • Program Purpose and Scope: Module 1 introduces the New gTLD Program: Next Round as an evolution of Internet infrastructure, with a stated aim to foster diversity, encourage competition, and enhance the utility of the DNS. The module outlines eligibility criteria, the requirement for good faith intent, and the electronic submission process. This aligns with the overall program goals affirmed by the SubPro PDP. The AGB is specifically identified as the implementation of Board-approved consensus policy. • Applicant Journey Stages: The module describes various stages an application passes through, such as application submission, initial evaluation, dispute resolution, string contention, and transition to delegation. This structured approach contributes to predictability, which is a key element of the New gTLD Program. The Applicant Support Program (ASP), intended to provide financial and non-financial assistance to reduce barriers for qualified applicants, is integrated into the broader program framework. • Internationalized Domain Names (IDNs) and Variant Management: The AGB incorporates provisions for IDN applicants, requesting information such as IDN tables and proposed mitigation for operational or rendering problems. Module 6 further clarifies that primary and variant labels are considered the same, and additional requirements, like using the same Registry Service Provider (RSP), may apply. ◦ However, Module 1's "Information for Internationalized Domain Name Applicants" section still states that "declared variant strings will not be delegated to the applicant along with the applied-for gTLD string, nor will the applicant have any right or claim to the declared variant strings". This language reflects the 2012 program's approach. ◦ The EPDP-IDNs Phase 1 Final Report, a Board-approved output, subsequently established that the Root Zone Label Generation Rules (RZ-LGR) must be the sole authoritative source for determining valid gTLDs and calculating variant labels. Crucially, it recommended that future applicants can apply for a primary gTLD string and its allocatable variant labels in a single application, which will be processed together. It also affirmed that these allocatable variants are subject to the same application requirements and evaluation criteria as the primary string. ◦ Therefore, Module 1 could be enhanced to explicitly reflect the new paradigm for allocatable variants from the EPDP-IDNs report, ensuring clear consistency throughout the AGB regarding the current understanding of IDN variant application and delegation. This would provide a more coherent "applicant journey" for IDN TLDs, especially in light of the intent to encourage the introduction of gTLD variant labels and promote IDN registrations for a multilingual Internet. • Universal Acceptance (UA) Integration: While Module 7 mentions Universal Acceptance as a key topic covered in the AGB, Module 1, as the foundational applicant journey overview, could more proactively address UA. The implementation plan for the next round explicitly states a focus on universal acceptance of new gTLDs. To fully align with this objective and the spirit of a globally inclusive Internet: ◦ The "Good Faith Intent" section (1.1.5) could be strengthened to include explicit reference to demonstrating UA-readiness for IDN strings, such as support for Email Address Internationalization (EAI) and genuine connection to linguistic communities. ◦ The "Application Life Cycle and Timelines" (1.1) could benefit from introducing UA-readiness testing as an early milestone or expectation within the applicant journey, promoting early adoption of relevant standards. ◦ Module 1 could also cross-reference how supportive mechanisms, like the Applicant Support Program, can assist applicants in achieving UA and IDN readiness. • Clarity and Usability: The SubPro Final Report emphasized drafting the AGB with a focus on the user, prioritizing usability, clarity, and practicality, and using Plain Language standards to serve new applicants and non-native English speakers effectively. Module 1 states its goal is to offer a "clear roadmap". Feedback on previous draft sections, particularly the Application Questions, highlighted the need for improved format, language, and accessibility for non-native English speakers. While this comment was on an appendix, the principle applies strongly to Module 1 as the entry point for applicants. Ensuring that Module 1, as the comprehensive overview, is unequivocally clear and consistent in its terminology and reflects the most current policies is crucial.

If no, please explain

Based on a critical analysis of the provided sources, the language in draft Module 2: Application Submission largely reflects the wording and intent of the Board-approved recommendations from the New gTLD Subsequent Procedures Policy Development Process (SubPro PDP) Final Report and the Expedited Policy Development Process on Internationalized Domain Names (EPDP-IDNs) Phase 1. Module 2 aims to delineate the key milestones and expectations for submitting a new gTLD application, encompassing aspects such as the submission period, application limits, backup application processes, queuing, and prioritization. It also covers crucial topics like DNS Stability, Root Zone Label Generation Rules (RZ-LGR), various application and string types, fees, and change requests. Overall, the module establishes a clear procedural foundation consistent with the program's objectives. Key areas of consistency with Board-approved recommendations include: • Application Rounds and Submission Periods: The AGB's approach to assessing applications in rounds and defining the submission period (minimum of 12 and maximum of 15 weeks) aligns with SubPro PDP Affirmation with Modification 3.1 and Recommendation 16.1, respectively. • Fees and Payments: The principle of a uniform base application fee, with potential for additional fees in specific circumstances, is consistent with SubPro PDP Affirmation 15.1. • Application Queuing and Prioritization: The module's framework for randomized prioritization draws, including an acknowledgment of historical IDN prioritization, aligns with SubPro PDP Affirmation 19.1. It also recognizes that implementation must consider local laws and licensing. • Application Change Requests (ACRs): The allowance for applicants to modify applications, including the addition or modification of Registry Voluntary Commitments (RVCs), is consistent with SubPro PDP recommendations. These changes are subject to an operational comment period. • Internationalized Domain Names (IDNs) and RZ-LGR: The AGB incorporates the critical principle that the Root Zone Label Generation Rules (RZ-LGR) must be the sole authoritative source for determining valid gTLDs and calculating variant labels. The EPDP-IDNs Phase 1 Final Report mandates that one application covers both the primary gTLD string and its allocatable variant labels, which are processed together. The language has also been updated to consistently refer to "allocatable variants" in line with Board-adopted policy. Furthermore, the requirement for a single registry operator and the same Registry Service Provider (RSP) for critical functions across a primary gTLD and its variant labels is affirmed. Applied-for IDN strings must conform to IDNA 2008 and RZ-LGR. • DNS Stability Review: The process of real-time notification to applicants if their string does not meet DNS stability requirements, allowing them to choose a different string before the submission deadline, aligns with discussions and adopted approaches. A challenge process for DNS Stability review is also expected. • String Similarity Review: The approach to string similarity review, including its extension to the entire variant label set, is consistent with the intent to prevent confusingly similar strings, building on the 2012 AGB while adjusting for variant labels. Opportunities for Further Clarity and Nuanced Alignment: While the draft Module 2 generally reflects the Board-approved recommendations, there are areas where its language could be enhanced to provide greater clarity, consistency in operational flow, and a more proactive reflection of underlying policy intent, particularly concerning Universal Acceptance (UA) and the overall experience for IDN applicants, beyond mere technical compliance. • Proactive Integration of Universal Acceptance (UA) Readiness: Although the AGB acknowledges IDNs and Universal Acceptance, Module 2, as the entry point for applications, could more explicitly integrate the expectation of UA-readiness as a fundamental component from the outset. This would align more fully with the strategic goal of promoting a multilingual and inclusive Internet. While the 2012 AGB asked about IDN implementation, the next round's AGB could strengthen this by encouraging or outlining how applicants should demonstrate their commitment to UA throughout their proposed operations, including support for Email Address Internationalization (EAI) and proper rendering of characters across platforms, even before a detailed technical evaluation in later modules. This proactive emphasis would enhance predictability for all applicants, especially those targeting diverse linguistic communities. • Clarity on Registry Service Provider (RSP) Designation Timing: There appears to be an inconsistency between the draft AGB language in Module 2 and other ICANN published information regarding when applicants can designate their Registry Service Provider (RSP). Some information suggests RSP selection should occur before the submission period closes, while the AGB indicates applicants may specify their RSP(s) after submitting their applications, potentially impacting competition. Clear and consistent guidance on the precise timing and flexibility for RSP designation within the application journey would eliminate uncertainty for applicants and facilitate their planning. • Predictability and Guidance for IDN-Specific Challenges: The SubPro PDP emphasizes predictability as a core element of the New gTLD Program. While Module 2 outlines general processes, it could benefit from more explicit guidance tailored to IDN applications regarding potential challenges or unique considerations they might face during evaluation or post-delegation. This would ensure IDN applicants have a clearer roadmap for addressing linguistic nuances, script-specific issues, or potential UA-related pitfalls from the very beginning of their application journey. • Financial Incentives and Operational Support for UA/IDN Development: To truly encourage the introduction of IDN gTLDs and promote IDN registrations, Module 2 could explore how the application fee structure or the Applicant Support Program (ASP) might explicitly recognize or incentivize robust UA-readiness plans or IDN-specific outreach strategies at the application submission stage. This could include clearer pathways for applicants seeking support to achieve UA/IDN compliance, reinforcing the program's commitment to diversity and global access.

If no, please explain

Strengthen GAC and Community-Based Inputs to Address UA/IDN Risk: ◦ The draft module provides for GAC and community input channels. However, there is no explicit guidance or prompt within these mechanisms to specifically flag applications that might hinder IDN deployment or fail to meet UA-readiness principles. This includes concerns about intentional or negligent exclusion of Email Address Internationalization (EAI) support, misuse of IDN scripts, or potential fragmentation/confusion for end-users relying on UA-compliant infrastructure. Explicitly encouraging these types of public interest evaluations would align with ICANN's broader goal of promoting a multilingual Internet. 2. Explicitly Include UA/IDN Stakeholder Concerns in Standing to Object: ◦ The AGB outlines standing criteria for various objection grounds. However, the language does not explicitly empower stakeholders or groups working on Universal Acceptance, script integrity, or linguistic representation to have clear standing. Recommending that UA advocacy groups, script community organizations, and EAI stakeholders be recognized as having standing for relevant objections, particularly under Limited Public Interest or Community Objections (e.g., where lack of UA-readiness leads to accessibility discrimination or inauthentic community representation), would be a significant enhancement. 3. Mandate Consideration of UA/IDN Implications by Appeals and Expert Panels: ◦ While the module details processes for appeals and expert determinations, it does not explicitly define "impact on Universal Acceptance and linguistic accessibility" as a legitimate ground for consideration in panel deliberations. Integrating UA and IDN impact assessments into the evaluation matrix for all relevant objection types (e.g., Limited Public Interest and Community objections) would ensure that linguistic and technical accessibility issues are formally weighed during dispute resolution. 4. Enhance Application Comment Forum Design to Support Multilingual Input: ◦ The module mentions the Application Comment process. To truly foster global participation and inclusivity, the platform itself should support multilingual submissions in all UN languages and other widely-used scripts, and ensure that comment mechanisms are UA-compliant, allowing commenters to reference domain names in their native scripts. This goes beyond merely publishing comments and focuses on enabling diverse input effectively.

If no, please explain

Equitable Treatment of IDN Strings in Contention Resolution: ◦ While the EPDP-IDNs Phase 1 Final Report acknowledged string similarity for IDN variant labels and established processes for their technical evaluation, the current draft of Module 4 lacks explicit guidance on ensuring equitable treatment and fairness in resolving disputes involving IDN strings or scripts from the same language family. ◦ There is an opportunity to mandate script community consultation or direct Universal Acceptance (UA)/IDN expert input in the evaluation of string similarity decisions that impact contention sets, particularly where linguistic and cultural nuances are critical for determining confusing similarity, beyond purely visual or aural assessments. Previous discussions on String Confusion objections touched upon expert panels, but the emphasis on linguists and script specialists for contention resolution implications needs to be clearer. • Recognition of Community Representation in Community Priority Evaluation (CPE) for IDNs: ◦ Module 4 includes CPE, which prioritizes community applications. While general clarity on CPE scoring and community engagement has been a subject of public comment, there is a need to more explicitly integrate linguistic and cultural representation as a weighted criterion in CPE scoring for IDN applications. ◦ The module could be enhanced by explicitly requiring evaluators to consider an IDN applicant's Universal Acceptance preparedness and community-based deployment strategy, especially for applications involving underrepresented scripts. This goes beyond general community engagement to specific, measurable commitments to IDN and UA readiness. • Auctions and String Confusion Must Account for Script Diversity: ◦ String similarity evaluations are crucial to contention resolution. While the EPDP-IDNs team has developed examples across various scripts to inform string similarity reviews, Module 4 could be strengthened by explicitly requiring the development and publication of localized string similarity criteria for non-Latin scripts. ◦ This would involve explicit input from language/script experts and UA stakeholders to prevent disproportionate impacts on IDN applicants due to ASCII-centric assumptions in string similarity determinations that lead to contention or auction outcomes. While general expert input is considered in the overall process, the demand for localized, published criteria specific to contention resolution is a distinct point. • Prohibition of Private Resolution Should Not Deter UA-Ready Collaboration: ◦ The AGB allows for business combinations and joint ventures as forms of contention resolution, and prohibited communications have been clarified. However, Module 4 could benefit from language that explicitly encourages collaborative solutions among UA-ready or script-aligned applicants, such as forming consortia for better script coverage. ◦ This recommendation emphasizes treating such collaborations as beneficial rather than merely permissible, especially in regions with low infrastructure support for Email Address Internationalization (EAI) and IDN deployment, where collaboration may be the most viable path to widespread UA adoption and community benefit. This particular nuance and proactive encouragement for UA/IDN-centric collaboration has not been the central focus of prior discussions on private resolution.

If no, please explain

there are opportunities for enhancement and specific issues that, while broadly related to policy, have not been comprehensively addressed in prior public comments or detailed discussions with the Implementation Review Team (IRT) in the specific context of Module 5's operational language. Here are the key areas for enhancement and identified inconsistencies in Module 5: • Explicit Integration of Universal Acceptance (UA) Readiness as a Core Operational Criterion: ◦ While Module 5 outlines operational evaluation, there is a need to explicitly require applicants to demonstrate Universal Acceptance (UA) readiness. This includes detailed aspects such as support for Email Address Internationalization (EAI), correct rendering and processing of Internationalized Domain Names (IDNs) across various platforms, and integration with UA-compliant systems and partners. This goes beyond a general assessment of technical capability to embed UA as a foundational expectation for registries. ◦ This granular level of requirement for UA readiness within the operational evaluation criteria of Module 5 has not been a central point of detailed discussion in previous public comments on this specific module. • Applicant's Demonstrated IDN Competency: ◦ For applications involving IDN gTLDs or IDN variants (e.g., those under Appendix 12), the evaluation process within Module 5 should assess the applicant's linguistic competence, script handling capability, and commitment to culturally appropriate implementation. The EPDP-IDNs Phase 1 Final Report mandates that evaluation panels must include evaluators with relevant script expertise. However, Module 5 needs to explicitly define how applicants are required to demonstrate this competency themselves during the evaluation, ensuring that a lack of readiness in these areas can lead to disqualification rather than just informal assessment. • Linking Applicant Support Program (ASP) Outcomes to UA Capacity Building: ◦ The module could be enhanced by ensuring that for applicants benefiting from the Applicant Support Program (ASP), UA-readiness is treated as a supported but required deliverable within their onboarding or ramp-up timeline. ICANN could provide technical guidance or connect these applicants to qualified Registry Service Providers (RSPs) that meet UA/IDN criteria as part of their support. This specific operational linkage between financial/programmatic support and a concrete UA deliverable is a new area for explicit consideration within the AGB's evaluation framework. • Encouragement of UA-Promoting Registry Commitments as a Favorable Evaluation Factor: ◦ Evaluators in Module 5 should give additional consideration to applicants who propose Public Interest Commitments (PICs) or Registry Voluntary Commitments (RVCs) that explicitly support UA adoption. Examples include commitments to local script education, multilingual helpdesks, and EAI support for registrants. Reflecting such commitments as a "favorable factor" during the evaluation of technical capacity or risk assessment is a nuance not widely detailed in previous public comment discussions concerning Module 5 or the broader RVC/PIC framework. • Inconsistency in DNS Abuse Questions: ◦ A specific inconsistency identified is in the DNS Abuse questions within Module 5, which are noted to require documentation of government support, conflicting with the text of Question 5.2-1 in the Application Questions document. This direct conflict needs to be resolved for clarity and consistency across the AGB.

If no, please explain

Despite this general alignment, there are significant opportunities for improvement, particularly concerning the deeper and more explicit integration of Universal Acceptance (UA) and Internationalized Domain Names (IDNs) within Module 6's operational criteria. These areas, as highlighted by Nitin Walia, represent issues that, while perhaps broadly acknowledged in policy development, have not been explicitly and comprehensively addressed in prior Board decisions or through the granularity of discussion seen in previous Public Comment periods or with the Implementation Review Team (IRT) specifically within the context of Module 6's operational details. Marianne Georgelin's submission also indicates a "No" for Module 6's consistency, although her explanation refers to Module 2, suggesting a broader systemic concern rather than specific Module 6 issues. Here are the key areas for enhancement in Module 6, focusing on aspects not extensively covered or fully operationalized in prior public discussions: • Strengthen Evaluation Criteria for IDN Applications and Variant Strings: While Module 6 addresses IDNs and variants, the current draft is insufficient in evaluating an applicant's technical and linguistic preparedness to manage an IDN TLD responsibly. The EPDP-IDNs Phase 1 Final Report mandates that evaluation panels must include evaluators with relevant script expertise. However, Walia's comment goes further, advocating for a requirement that applicants themselves demonstrate linguistic competence, script handling capability, and a commitment to culturally appropriate implementation, including detailed aspects of Universal Acceptance (UA)-readiness (e.g., Email Address Internationalization (EAI) support, proper rendering of characters, and promoting IDNs in their served community). This level of explicit, applicant-demonstrated UA/IDN readiness as a direct evaluation criterion is a new and critical detail beyond previous general discussions on IDN evaluation. • Universal Acceptance (UA) as a Baseline Requirement for String Evaluation: String Similarity Evaluation (Section 6.10) and Name Collision assessments (Section 6.7) are crucial, but their UA impact is not explicitly considered. Previous public comments called for comprehensive guidance and tools for string similarity, and noted variations in definitions. The EPDP-IDNs report mentioned the possibility for panels to omit blocked variants with "manifestly low level of confusability" between scripts based on future guidelines. However, Walia specifically recommends adding UA readiness checks into the string evaluation process, such as ensuring strings are accepted and rendered correctly in common applications, and highlighting potential UA pitfalls like homoglyphs or diacritics that may fail in non-UA-ready software. He also calls for a mitigation plan for such strings, which moves beyond general risk assessment to proactive UA integration within the evaluation criteria. • Geographic and Script-Related Evaluations Must Prevent Linguistic Misappropriation: While Work Track 5 of the SubPro PDP discussed geographic names extensively, including the "in any language" standard versus a limited set of languages, it ultimately did not agree on changes to depart from the 2012 implementation. Walia's comment addresses a more specific issue: the need for the Geographic Names Review (Section 6.5) to ensure that IDN strings representing geographic terms reflect genuine community interest or involvement, especially when the applicant is not based in the linguistic region. This aims to prevent the misuse of culturally significant terms and aligns with GAC principles on sensitive names, a nuance of "linguistic misappropriation" not explicitly detailed in prior public comments on Module 6 or Work Track 5 discussions. • Registry Commitments and UA Promotion as a Favorable Evaluation Factor: Module 6 includes Public Interest Commitments (PICs) and Registry Voluntary Commitments (RVCs) (Section 6.8). While the enforceability and scope of PICs/RVCs have been subjects of Board discussion and public comment, the notion that evaluators should give additional consideration or prioritize applicants who propose PICs or RVCs that explicitly support UA adoption is a new emphasis. Examples include commitments to local script education, multilingual helpdesks, and EAI support for registrants, treated as a "favorable factor" during the evaluation of technical capacity or risk assessment. This moves beyond merely assessing commitment adherence to actively incentivizing UA-promoting initiatives. • Script-Specific Variability in String Similarity Evaluations: Building on previous calls for more comprehensive string similarity assessment, Walia emphasizes that the String Similarity Evaluation Panel (Section 6.10) should be explicitly instructed to consider script-specific orthographic and linguistic norms, not just visual similarity or ASCII logic. The NCSG previously suggested the need for "linguists and comparative language specialists" for String Confusion Objections, but ICANN's response indicated reliance on legal rights experts. Walia's recommendation for Module 6 insists that ICANN must publish a clear methodology developed with input from language/script experts and UA stakeholders to prevent disproportionate impacts on IDN applicants in contention or auction outcomes due to ASCII-centric assumptions. This calls for a more granular, linguistically informed approach to string evaluation.

If no, please explain

Here are the key areas for enhancement in Module 7, focusing on aspects not extensively detailed in previous public discussions: • Public Interest Commitments (PICs) Should Encourage UA and IDN Support: While Module 7 discusses Public Interest Commitments (PICs) and Registry Voluntary Commitments (RVCs), and the SubPro Final Report allows for RVCs in response to community input or objections, the current draft does not explicitly encourage registries to adopt commitments related to UA or IDN promotion. Nitin Walia specifically recommends that ICANN include a model PIC that encourages a registry's willingness to: operate UA-ready systems; promote multilingual access and Email Address Internationalization (EAI) adoption; and provide end-user and registrar education around IDNs. This moves beyond general enforceability of PICs/RVCs to proactively encouraging and potentially prioritizing specific UA-promoting initiatives as a favorable factor during evaluation. • Registry Agreement Terms Should Include UA Obligations: Module 7 outlines the Registry Agreement (RA), and the SubPro Final Report affirms that contractual conditions should set out operational criteria to ensure compliance with ICANN policies. However, the current draft does not explicitly mention Universal Acceptance requirements within the RA terms. Walia recommends that the RA should at a minimum: reference Universal Acceptance principles and recognize them as part of best operational practices; and require registries offering IDN TLDs to submit periodic UA-readiness self-assessments or implementation plans. This introduces a new level of specific, measurable contractual obligation for UA readiness, which goes beyond previous general policy statements that encourage UA awareness. • Post-Delegation Dispute Mechanisms Should Consider UA Impacts: Module 7 covers accountability mechanisms and dispute procedures after delegation. The Public Interest Commitment Dispute Resolution Procedure (PICDRP) addresses alleged non-compliance with PICs/RVCs. Walia suggests that a registry's failure to implement UA or support IDNs should be formally considered a breach of public interest obligations or commitments under PICDRP or other relevant dispute resolution procedures. This specific linkage of UA/IDN non-compliance to dispute resolution grounds, particularly when it undermines access for a specific language/script community, represents a more granular and explicit application of these mechanisms than previously discussed. • General AGB Principles Should Explicitly Reference UA and Linguistic Inclusion: While the AGB is intended to be available in multiple languages, and IDNs are acknowledged as an integral part of the New gTLD Program, Walia recommends that Module 7's introduction (or 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 elevates UA and linguistic inclusion to a foundational, overarching principle for the entire AGB, signalling their core importance beyond being mere policy topics or initiatives. This explicit framing within the AGB's foundational statements represents a new programmatic articulation.

If no, please explain

Here are the key areas for enhancement in Appendix 1, focusing on aspects not extensively detailed in previous public discussions or explicit in prior Board-approved recommendations concerning the direct content of application questions: • Add UA-Specific Language to Technical and Operational Questions: While Appendix 1 provides a structured set of questions, it currently misses directly assessing an applicant's commitment, readiness, and strategy for ensuring UA and supporting IDNs. Walia recommends that questions related to Registry Services (e.g., Q22 in the general template) and IDNs (e.g., Q24) should be expanded to explicitly require applicants to describe: ◦ How they will ensure Universal Acceptance-readiness in their technical operations. ◦ What provisions exist to support Email Address Internationalization (EAI), UA-compliant WHOIS, and multilingual support tools. ◦ How they will address known UA challenges in their script or user base. ◦ A specific suggested addition to Question 24 is: “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”. This level of explicit, detailed inquiry into UA readiness within application questions goes beyond prior general policy statements encouraging UA awareness or requiring basic IDN support. • Improve Evaluation of IDN Linguistic Authenticity and Community Representation: For IDN TLD applications, particularly those framed around community or culture, the application questions should delve deeper into linguistic and community connections. Walia suggests asking: ◦ 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. ◦ A 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”. This introduces a new layer of community-centric and linguistic authenticity evaluation directly into the application's required information. • Add Optional/Weighted Questions on UA Advocacy and Promotion: Walia proposes incentivizing proactive UA promotion by including questions that allow 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. This would embed a new mechanism to encourage specific UA-promoting initiatives directly through the application's scoring or evaluation, a concept not widely discussed in previous public comments on application questions (which focused more on general formatting or ownership disclosure). • Ensure Consistency Between Application Questions and Support Program (Appendix 11): While general comments about Appendix 1 did touch on the Applicant Support Program (ASP) handbook, Walia specifically recommends guiding ASP applicants to explain how the support will help them achieve UA-readiness and serve a linguistically diverse user base. He suggests cross-referencing Appendix 1 with Appendix 11, particularly for underserved applicants targeting IDN gTLDs. This focuses on a more robust and explicit alignment of financial and technical support with UA/IDN objectives within the application process.

If no, please explain

• Recognize Script-Based Community Sensitivities in Geographic Names: While the appendix deals with geographic names, Walia argues it lacks sufficient treatment for how IDN strings representing geographic terms should be evaluated. He recommends adding language to ensure that IDN geographic names: ◦ 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. This goes beyond general support documentation for geographic names (as seen in the 2012 AGB's Section 2.2.1.4.2) by focusing on the linguistic and cultural integrity of IDN geographic strings. • Encourage UA-Ready Representations of Geographic Names: Walia recommends that applicants for geographic TLDs in IDN scripts should be explicitly required to demonstrate UA-readiness of their applied-for string. This includes: ◦ 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. This introduces a new, specific technical requirement for geographic IDN applications that has not been explicitly posed in previous application questions (e.g., 2012 AGB Question 21, 23, 44 which covered general registry services and IDN support without this specific UA-readiness for geographic names). • Provide Local Authorities with UA/IDN Awareness Resources: While Appendix 2 emphasizes approval or non-objection letters from relevant authorities, Walia suggests that ICANN should also provide those authorities with a geographic UA/IDN explainer brief. This brief would help local governments understand the implications of approving an IDN TLD and be aware of potential UA gaps that could impact usability or confusion among local populations. This is a new, proactive educational outreach initiative. • Address Variant or Homoglyph Conflicts in Geographic IDN Applications: Walia recommends that when IDN strings resemble geographic names in form but differ in meaning or origin (e.g., same characters used in different scripts), Appendix 2 should include a provision for UA-aware script conflict resolution, potentially involving script panels or community experts. This level of specific detail for resolving linguistic conflicts related to geographic IDNs is a new proposed addition to the application evaluation process.

If no, please explain

Here are the key areas for enhancement in Appendix 3, focusing on aspects not previously addressed at this level of specificity: • Recognize Standing for UA/IDN Community Stakeholders: While the AGB currently outlines four grounds for objections (String Confusion, Legal Rights, Limited Public Interest, and Community Objection) and general criteria for standing, Walia recommends that the standing criteria be expanded or clarified to explicitly include groups and stakeholders actively working on Universal Acceptance, script integrity, or linguistic representation. He suggests that such groups should have standing, or at minimum be permitted to file supporting documentation or amicus briefs, especially when an application has script misuse implications or might misrepresent a linguistic community. This level of specific standing for UA/IDN advocacy groups within the objection process is a new, detailed suggestion. • Ensure Objection/Appeal Panels are Informed on IDN Linguistic and Cultural Contexts: The existing framework for selecting expert panels focuses on qualifications relevant to the objection type. Walia recommends that panels evaluating IDN-related cases should be required to consult script panels or language community representatives when string meaning, cultural sensitivity, or variant similarity is disputed. Furthermore, he suggests that ICANN publish procedural standards for selecting panelists in IDN-related cases to ensure they possess adequate language diversity and UA understanding. While the need for linguistic experts for String Confusion Objections was previously discussed (e.g., by NCSG), Walia's proposal explicitly ties this to UA understanding and broader cultural context, and suggests formalizing panel selection criteria, which goes beyond prior discussions. • Explicitly Make UA Non-Compliance a Ground for Limited Public Interest Objection: The Limited Public Interest Objection currently applies to strings deemed "contrary to generally accepted legal norms relating to morality and public order". Walia proposes that Appendix 3 should explicitly allow for Limited Public Interest Objections in instances where: ◦ The applied-for string or operational plan intentionally disregards Universal Acceptance norms. ◦ There is a risk of exclusion or harm to users relying on Email Address Internationalization (EAI) or IDNs. ◦ The applicant has misrepresented their UA-readiness or community representation in their application. This suggestion provides concrete, specific criteria related to UA that could be leveraged for public interest objections. • Integrate UA/IDN Impact Assessment into Appeal Deliberations: While the AGB outlines a process for appeals of formal objections, Walia notes that UA and IDN impact assessments are not currently part of the appeals evaluation matrix. He recommends defining "impact on Universal Acceptance and linguistic accessibility" as a legitimate ground for consideration in appellate panel deliberations, particularly under Limited Public Interest and Community objection types. This would ensure that appeals mechanisms can effectively address issues of linguistic fairness and technical readiness related to IDNs and UA.

If no, please explain

Here are the key recommendations from Nitin Walia that fall into the category of new issues for Appendix 5: • Allow for UA/IDN-Focused Financial Planning: Walia recommends that the financial template should explicitly include optional line items for projected expenses related to Universal Acceptance (UA) readiness. These include: ◦ Email Address Internationalization (EAI) implementation and integration with registrars and hosting providers. ◦ IDN outreach, education, and localization costs. ◦ Universal Acceptance testing and compliance monitoring across software stacks. He argues that these projections are crucial for applicants targeting multilingual or underserved user bases and should not be penalized as "non-standard" expenses in the financial review. • Tailor Evaluation Criteria for IDN or UA-Centric Business Models: Walia suggests that the evaluation of financial viability should not impose uniform assumptions around market behavior that may not apply to IDN TLDs or non-Latin script registries. He recommends that evaluators be instructed to: ◦ Contextualize revenue growth curves and adoption rates for IDN registries, acknowledging that they may experience slower ramp-up due to lower current UA-readiness in the ecosystem. ◦ Recognize public-good or language-preservation-oriented goals that may prioritize community adoption over near-term profitability. • Support Applicants in Developing UA-Aware Financial Plans: Walia proposes that 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 could be cross-referenced from the Applicant Support Program (Appendix 11). • Encourage Transparency and Public Interest Commitments (PICs) related to UA: If applicants propose PICs or Registry Voluntary Commitments (RVCs) related to Universal Acceptance, EAI deployment, or IDN community education, Walia recommends that they should be invited to quantify their financial support for these efforts in the business plan. He suggests that evaluators should treat these as positive signals of sustainability and responsibility, rather than solely as cost burdens.

If no, please explain

Improvements: Explicitly Recognize UA and IDN as High-Impact Change Categories: Walia recommends that changes potentially affecting: ◦ IDN variant rules. ◦ UA-readiness standards. ◦ String similarity evaluation methodologies for non-Latin scripts. ◦ Email Address Internationalization (EAI) compatibility or IDN-related registry obligations. Should be explicitly classified as high-impact (Category 2 or 3) changes within the framework. This classification would ensure that such changes trigger appropriate SPIRT involvement and public transparency. • Ensure Linguistic Diversity in SPIRT Composition and Consultations: It is recommended that ICANN commit to ensuring the 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 consultation with script panels or the Universal Acceptance Steering Group (UASG) or similar experts. • Include UA/IDN Impact Assessment in Change Evaluation Template: The Standardized Change Evaluation process within the Predictability Framework should include a dedicated question or field to assess the impact of a proposed change on Universal Acceptance or IDN operations. This could operate similarly to environmental or public interest assessments used in other regulatory contexts. • Transparent Handling of Mid-Round UA/IDN Policy Adjustments: In instances where mid-round adjustments to UA or IDN processing rules become 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 prevent penalizing applicants who acted in good faith under prior rules.

If no, please explain

Recommendations for improvement: Expand Conflict Definitions to Include UA/IDN-Related Biases or Affiliations: Walia recommends that the conflict of interest criteria 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, Email Address Internationalization (EAI) implementation assessments, or variant string handling. • Include UA/IDN Awareness in Service Provider Disclosure and Screening: It is recommended that service providers involved in string similarity decisions for IDNs, variant handling or linguistic evaluations, or 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. Walia emphasizes this is crucial given the limited pool of experts in these fields and the potential for perceived bias if roles are not properly managed. • Encourage Linguistic and Geographic Diversity Among Evaluators: To reduce systemic bias, Walia proposes that 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. • Publish a Summary of Declared UA/IDN Conflicts and Mitigations: Walia suggests that 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 aims to build trust with communities who may feel marginalized in global digital policy processes.

If no, please explain

Recommendations for improvement: Strengthen Language on Cultural and Script Neutrality: Walia recommends that the Code of Conduct should explicitly oblige service providers to: ◦ Acknowledge their own limitations or biases when handling non-Latin scripts. ◦ Refrain from applying ASCII-centric logic or assumptions to IDN evaluations. ◦ Respect and defer to script community norms where applicable, such as for variant interpretation and naming conventions. This goes beyond a general call for impartiality by specifying a need for cultural and linguistic sensitivity in evaluation conduct. • Add UA and Email Address Internationalization (EAI) Awareness to Technical Evaluation Conduct: It is recommended that evaluators assessing registry technical questions or readiness (e.g., under Appendix 2 or Modules 5/6) be expected to be familiar with Universal Acceptance best practices, including EAI. This includes avoiding penalizing applicants for using UA-compliant but less mainstream technical solutions and demonstrating equal treatment for IDN-based business models, even those with slower ramp-up projections due to UA constraints in local software ecosystems. This introduces a new layer of specificity regarding the technical expertise required and expected conduct in relation to UA and IDN readiness evaluations. • Require Disclosure of Prior Engagements in IDN/UA Policy: Walia suggests that service providers should be required to disclose their participation in policy, standards-setting, or commercial activity related to IDNs or UA (e.g., through the Universal Acceptance Steering Group (UASG) or script panels). They should also disclose any positions that might influence their assessment of a registry’s UA-readiness or IDN legitimacy. While general conflict of interest disclosures are standard, this specifically targets involvement in IDN/UA policy and technical development. • Establish a Mechanism for Community Review or Feedback on Conduct: It is proposed that ICANN allow affected communities to flag concerns about evaluator conduct or bias, particularly in cases involving language-sensitive disputes or IDN objections, and trigger a review if needed. This aims to reinforce accountability and provide a voice to linguistically marginalized or underrepresented groups, which is a more specific mechanism than existing general feedback channels.

If no, please explain

Support UA Readiness by Allowing Controlled Disclosure of Technical Contact Information: Walia recommends that the privacy framework should allow for voluntary disclosure of technical vendor names, certifications, or UA-related partners by applicants who are deploying IDN TLDs or EAI-enabled infrastructure to demonstrate their readiness. This disclosure should not be restricted by overly broad privacy interpretations, as it fosters transparency for the community and helps build trust in less-known, UA-aligned applicants. • Ensure Multilingual Access to Privacy Disclosures: To promote transparency among linguistically diverse applicants and end-users, Walia suggests that the privacy policy and all related disclosures (e.g., data retention, rights of access, contact methods) should be made available in multiple UN languages and common IDN user scripts. Furthermore, they should be written in clear, accessible language, avoiding legal jargon that could confuse non-native English speakers. • Encourage Privacy-Protective but Transparent IDN Application Processes: Walia proposes that 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, even while protecting personal data. This could be achieved by allowing aggregated or pseudonymized public disclosures of evaluation summaries involving IDN and UA-readiness criteria, and publication of script-specific objections or evaluations without disclosing personal data, enabling communities to understand precedent and ensure fairness. • Clarify Data Handling for Applicant Support and UA Advocacy Groups: Given that applicants benefiting from the Applicant Support Program, especially for IDNs, may involve collaborative submissions or multi-entity partnerships (e.g., linguistic associations, script panels, or UA outreach partners who may not be formal legal entities), ICANN should clarify how personal and organizational data from these groups will be handled.

If no, please explain

Add Language Recognizing UA and IDN Commitments as Public Benefit: Walia recommends that the Terms and Conditions should explicitly acknowledge and encourage applicants who make voluntary commitments to implement UA standards, promote multilingual Internet access, or support underserved scripts. This ensures that UA-aligned applicants do not fear legal exposure for community-beneficial initiatives, unless they breach core policy. • Prevent Disproportionate Risk to IDN Applicants from Evolving Technical Standards: The Terms and Conditions should include clauses (e.g., in Section 5 or equivalent) that do not penalize applicants whose IDN or UA readiness plans may require phased implementation based on evolving support across the global digital ecosystem. This means that if UA adoption lags in external software (like browsers or email clients), an applicant should not be considered in breach for slower registrant uptake due to these external factors. • Clarify Use of Language for Legal Commitments Across Jurisdictions: Given that 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, and include provisions acknowledging cultural/legal interpretation differences when translated. • Clarify Rights Around IDN Strings and Script Representations: Walia suggests that ICANN should explicitly affirm that applying for an IDN string does not confer broader rights over a language, script, or cultural symbol. The evaluation should consider appropriate script usage as discussed in other modules to prevent any misinterpretation that the Terms allow monopolization of a script or term via a gTLD.