August 2025 - Gnso-latin-diacritics

Post Call | Latin Script Diacritics PDP | Wednesday, 27 August 2025
by Julie Bisland Aug. 27, 2025

Aug. 27, 2025

Dear all, All recordings for the Latin Script Diacritics PDP call held on Wednesday, 27 August 2025 at 13:15 UTC can be found on the agenda wiki page <https://icann-community.atlassian.net/wiki/x/AYAnG> (attendance included) and the GNSO Master calendar<https://gnso.icann.org/en/group-activities/calendar/2025>. These include: * Attendance * Audio recording * Zoom recording (including audio, visual, rough transcript, and chat.) * Transcript * Agenda and Notes/Action Items For additional information, you may consult the mailing list archives<https://lists.icann.org/hyperkitty/list/gnso-latin-diacritics@icann.org/> and the main wiki page<https://icann-community.atlassian.net/wiki/x/EwDVBg?atlOrigin=eyJpIjoiMWI2M…>. Thank you. With kind regards, Julie

1 0

Outcomes, Action Items, and Notes from Meeting #18
by John Emery Aug. 27, 2025

Aug. 27, 2025

Dear LD PDP WG, CONGRATULATIONS! We have finished the TBD items in the spreadsheet and will have no meetings for the next two weeks to allow time for the WG to review the preliminary recommendations document (to be sent in the next few days). Please see below the Outcomes, Action Items, and Notes from Meeting #18<https://icann-community.atlassian.net/wiki/x/AYAnG> on Wednesday, 27 August 2025: Meeting #18 Slides<https://icann-community.atlassian.net/wiki/spaces/gnsolsdpdp/pages/40524185…> [OUTCOMES] 1. 7.4 and 7.5 Decision to proceed in accordance with the outcome of the Board decision on EPDP-IDNs to be reviewed when Board makes a decision 2. Filled in Spreadsheet <https://docs.google.com/spreadsheets/d/1vA4BoEHaGJBpVJ4oJcEgvzJlu5zEhF9cOQO…> of relevant TBD recommendations and wrote the consensus in the decision tab [ACTION ITEMS] * The WG members need to review the Preliminary Recommendation language by 14 September [NOTES] 1. Welcome and SOIs 2. Recap of Meeting #17 * Agreement on pricing for no fees recommended and follow cost recovery principle via implementation as guided by AGB * Ariel from ICANN org for recommendations 7.4 and 7.5 Board is still in process deliberating these recommendations, they have not been formally adopted yet. ICANN finance has to conduct analysis and understand their impact. Without that, the Board cannot take action. There is some discussion on this recently, so there will hopefully be movement, but that is the reason why these have not been adopted yet. 7.4 is complicated for analysis and 7.5 is less complicated. Once that is received the WG will be updated 3. Charter Question 3 <https://urldefense.com/v3/__https:/gnso.icann.org/sites/default/files/polic…> * EPDP-IDNs P2 TBD items i.Filled in worksheet<https://docs.google.com/spreadsheets/d/1vA4BoEHaGJBpVJ4oJcEgvzJlu5zEhF9cOQO…> * 7.4 Four possibilities to decide: 1. Proceed in accordance with the outcome of the Board decision. 2. Same as a single TLD 3. Treat as separate TLDs 4. Should not be more than 2 separate TLDs (less than) * Broad discussion of options with some consensus emerging with that EPDP IDNs has been the consensus so far around number 1 * Solution 1 Vote: 5, Solution 2 Vote: 1; Solution 3 Vote 0; Solution 4 Vote: 3 * Voted for 1 for wisdom of EPDP IDNs should be the rule for this. * Steve Chan, ICANN org, In terms of drafting, maybe we could just retrofit 7.4 and 7.5 and add a clause that says, unless determined differently. Path forward could be we want to pursue 7.4 and 7.5 unless the Board determines differently for these recommendations acknowledging there is uncertainty. * No precedent set here since it was in name collisions so agreement was reached to go with option 1, but should the Board adoption happen prior to that, then we can follow up when that decision is made * 7.5 registry level transaction fee. Follow same principle as 7.4 for same outcome of EPDP-IDNs * Single contract between ICANN and registries containing more than 1 TLD suggestion is to have the same calculation for registry level transaction fees * Implementation Guidance 2: number of variants activated to the same registrant. Restrict manually activated variants, and automatically activated. There is not a suggestion to have a hard coded number here, but registries should set some upper limit for this * Registries normally set that to 4 or 5 and almost none that have more than 1-2. Should be limited to 4-5 and beyond that only gaming is possible in real terms. There is some kind of confusion among registrants. * Second level, there could be Arabic script at 2nd level together with Latin TLDs then in that case the same variant rules that exist for EPDP-IDNs. * Underlying concern here is clear that there should not be too many instances of variants. Capping the maximum and the automatic activation. Instinct to go with EPDP-IDNs as it would likely be a bigger problem there than here * Want to not allocate too many domain names to the same entity as not all are variants but some are based on the diacritic groupings * In variant case it would be a maximum of 5 with IDNs and 5 with diacritics. It would make sense to have a corresponding version here with adjusted wording. 4. Preliminary Recommendations * Back to Slides<https://icann-community.atlassian.net/wiki/spaces/gnsolsdpdp/pages/40524185…>: Charter questions Summary and Tracking overview * Saewon Lee introduced the layout of draft preliminary recommendations from the Slides<https://icann-community.atlassian.net/wiki/spaces/gnsolsdpdp/pages/40524185…>. Simply each relevant recommendation was mapped out advised by ICANN legal leading to 54 preliminary recommendations and implementation guidance. * The draft recommendations for “certain TLD types” refers to not limiting boundaries to “real words” geoTLDs and BrandTLDs and the style will talk about applications for existing TLDs applied for and new applications. * No Meetings for the following 2 weeks to complete homework on reviewing the preliminary recommendations Thank you, John R. Emery, Ph.D. Policy Development Support Senior Specialist Generic Names Supporting Organization (GNSO) Internet Corporation for Assigned Names and Numbers (ICANN) www.icann.org<http://www.icann.org>

1 0

Proposed Agenda for Meeting #18
by Saewon Lee Aug. 25, 2025

Aug. 25, 2025

Dear LD PDP WG, Please find below the proposed agenda for LD PDP WG Meeting #18 on Wednesday, 27 August 2025 at 13:15 UTC: 1. Welcome and SOIs 2. Recap of Meeting #17 * Key Outcomes and Action Items 1. Charter Question 3 [gnso.icann.org]<https://urldefense.com/v3/__https:/gnso.icann.org/sites/default/files/polic…> * Review of TBD Items 1. Initial Report: Overview of Preliminary Recommendations 2. Next Steps 3. AOB As always, the LD PDP WG Charter [gnso.icann.org]<https://urldefense.com/v3/__https:/gnso.icann.org/sites/default/files/polic…> and the Worksheet with SubPro/EPDP-IDNs Outputs [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/spreadsheets/d/1vA4BoEHa…> have been hyperlinked for your reference and the Charter Questions can be viewed on page 2. Please also see all relevant/background documents to this PDP on wiki here [icann-community.atlassian.net]<https://urldefense.com/v3/__https:/icann-community.atlassian.net/wiki/x/2wP…>. Looking forward to wrapping up TBD Items/CQ3 with you all tomorrow! Kind regards, Saewon Saewon Lee Policy Development Support Manager for GNSO Internet Corporation for Assigned Names and Numbers (ICANN) Mobile: +1 (310) 463-5541 Email: saewon.lee(a)icann.org<mailto:saewon.lee@icann.org> Skype: saewon.lee.icann Website: www.icann.org<http://www.icann.org>

1 0

Post Call | Latin Script Diacritics PDP | Wednesday, 20 August 2025
by Devan Reed Aug. 20, 2025

Aug. 20, 2025

Dear all, All recordings for the Latin Script Diacritics PDP call held on Wednesday, 20 August 2025 at 13:15 UTC can be found on the agenda wiki page <https://icann-community.atlassian.net/wiki/x/AQAnG> (attendance included) and the GNSO Master calendar<https://gnso.icann.org/en/group-activities/calendar/2025>. These include: * Attendance * Audio recording * Zoom recording (including audio, visual, rough transcript, and chat.) * Transcript * Agenda and Notes/Action Items For additional information, you may consult the mailing list archives<https://lists.icann.org/hyperkitty/list/gnso-latin-diacritics@icann.org/> and the main wiki page<https://icann-community.atlassian.net/wiki/x/EwDVBg?atlOrigin=eyJpIjoiMWI2M…>. Thank you. With kind regards, Devan

1 0

Outcomes, Action Items, and Notes from Meeting #17
by John Emery Aug. 20, 2025

Aug. 20, 2025

Dear LD PDP WG, Please see attached: Outcomes, Action Items, and Notes from Meeting #17<https://icann-community.atlassian.net/wiki/x/AQAnG> on Wednesday, 20 August 2025 Meeting #17 Slides<https://icann-community.atlassian.net/wiki/spaces/gnsolsdpdp/pages/40520908…> [OUTCOMES] 1. Agreement on pricing that there would be no output/recommendation on fees and would be based on an ICANN cost recovery principle 2. Filled in Spreadsheet <https://docs.google.com/spreadsheets/d/1vA4BoEHaGJBpVJ4oJcEgvzJlu5zEhF9cOQO…> of relevant TBD recommendations and wrote the consensus in the decision tab [ACTION ITEMS] * WG to review upcoming TBD items in the worksheet <https://docs.google.com/spreadsheets/d/1vA4BoEHaGJBpVJ4oJcEgvzJlu5zEhF9cOQO…> * Ariel Liang to get information on recommendations 7.4 and 7.5 from GDS colleagues [NOTES] 1. Welcome and SOIs 2. Recap of Meeting #16 * Not necessary to give an interim update to SO/ACs on progress. Most people are reporting back to their groups * Main goal is to avoid rejection and using the LD PDP exceptions process. In contrast, the goal of EPDP-IDNs was IDN promotion. Goal of this PDP is not IDN promotion. * Reviewed three facts on cost recovery * Slide #8 summarized discussion for the three main solutions to pricing including advantages and disadvantages for each solution * Rationale for evaluation fee estimation based on EPDP IDNs and the cost subsidy involved * Discussion on application fees: some support for options 3, 2 * Number 2 would make sense in fairness. But, applying for free could assume that we are not in a position to set the price. GNSO will not set the prices. We should not create an obstacle to preventing the PDP from working. If we want this to succeed, if feasible, what are the real cost of the evaluation? Need to bundle, but if we go the free way, it could prevent the next round * If we were to go for #2 there would have to be limits set. * To help provide some insight into what the evaluation fees covers, I would recommend reading Section 2.3.1 of the AGB: https://itp.cdn.icann.org/en/files/policy-development/new-gtld-program-next… * There is a set of FAQ related to fees for program (to be updated with new info), but this is the current info: https://newgtldprogram.icann.org/en/resources/gtld-evaluation-fee-faqs * Background: for variants it is the scripts that have allocatable variants (7 scripts) all scripts had a low allocatable (up to 4 for IDNs). Based on this understanding the estimation was made. It will be hard to make a limited estimation for Latin. Cannot make this estimation for Latin diacritic cases, 1000 latin TLDs and could have multiple diacritic versions. How many applications could come in would be much higher * Potential to add diacritics to existing Latin are exponentially more than IDNs * Current discussion shows it is difficult to apply IDNs it is a technical issue. Not the same a Latin diacritics. In Latin it is a social need, not a technical question. Applying some rules here could lead to the world being possible. Same TLD in 7 ways potential for confusion would be higher. * Agreement with Amadeu, it would be nice for more IDNs. This is a narrow exception process, not a goal to make this an encouragement. If it is free, why not? Goal is a narrow exceptions process. Avoid people willing to pay full price to get an application rejected because of current rules. Due to this problem we are making an exception that avoids this. This is not meant to be free or encouraged * It could give a slight advantage if it is based on cost recovery, if you combine the labels you don’t have to evaluate the applicant twice, there is likely to be some cost reduction to make it more attractive, but not doing something to encourage massive amounts of diacritics * Not comfortable with unlimited TLDs free from the Board perspective. Number 3 would make more sense in pricing. * Vote: Option 1 – 0; Option 2 – 2; Option 3 – 8 Consensus to move toward number 3 1. Charter Question 3 <https://urldefense.com/v3/__https:/gnso.icann.org/sites/default/files/polic…> * EPDP-IDNs P2 TBD items * Filled in worksheet<https://docs.google.com/spreadsheets/d/1vA4BoEHaGJBpVJ4oJcEgvzJlu5zEhF9cOQO…> * 3.12 Not applicable for LD PDP based on previous decision * 3.13 Makes sense to offer a discount fee and allow ICANN org to decide the discount * 3.14 Not applicable based on previous decision * 8.1 Upper limit of Latin diacritics that can be bundled together with one TLD? There may be valid reasons for variations for different languages. Should be a linguistic reason for more than one diacritic. Similar recommendation 3.5 addresses this must be a justification * This should apply to multiple diacritics. There will be requirements for justification for diacritics * 7.4 and 7.5 are still pending status at the Board deliberation level, they have not yet been adopted. Consider whether these have an impact. All the best, John R. Emery, Ph.D. Policy Development Support Senior Specialist Generic Names Supporting Organization (GNSO) Internet Corporation for Assigned Names and Numbers (ICANN) www.icann.org<http://www.icann.org>

1 0

Proposed Agenda for Meeting #17
by Saewon Lee Aug. 19, 2025

Aug. 19, 2025

Dear LD PDP WG, Please find below the proposed agenda for LD PDP WG Meeting #17 on Wednesday, 20 August 2025 at 13:15 UTC: 1. Welcome and SOIs 2. Recap of Meeting #16 * Key Outcomes and Action Items * Recap of EPDP-IDNs TBD Item (Final Rec. 3.11); Fee Options for LD PDP WG 1. Charter Question 3 [gnso.icann.org]<https://urldefense.com/v3/__https:/gnso.icann.org/sites/default/files/polic…> * Review of TBD Items 1. Next Steps 2. AOB As always, the LD PDP WG Charter [gnso.icann.org]<https://urldefense.com/v3/__https:/gnso.icann.org/sites/default/files/polic…> and the Worksheet with SubPro/EPDP-IDNs Outputs [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/spreadsheets/d/1vA4BoEHa…> have been hyperlinked for your reference and the Charter Questions can be viewed on page 2. Please also see all relevant/background documents to this PDP on wiki here [icann-community.atlassian.net]<https://urldefense.com/v3/__https:/icann-community.atlassian.net/wiki/x/2wP…>. Apologies for the delay and see you all tomorrow! Kind regards, Saewon Saewon Lee Policy Development Support Manager for GNSO Internet Corporation for Assigned Names and Numbers (ICANN) Mobile: +1 (310) 463-5541 Email: saewon.lee(a)icann.org<mailto:saewon.lee@icann.org> Skype: saewon.lee.icann Website: www.icann.org<http://www.icann.org>

1 0

Post Call | Latin Script Diacritics PDP | Wednesday, 13 August 2025
by Devan Reed Aug. 13, 2025

Aug. 13, 2025

Dear all, All recordings for the Latin Script Diacritics PDP call held on Wednesday, 13 August 2025 at 13:15 UTC can be found on the agenda wiki page <https://icann-community.atlassian.net/wiki/x/AQAvFg> (attendance included) and the GNSO Master calendar<https://gnso.icann.org/en/group-activities/calendar/2025>. These include: * Attendance * Audio recording * Zoom recording (including audio, visual, rough transcript, and chat.) * Transcript * Agenda and Notes/Action Items For additional information, you may consult the mailing list archives<https://lists.icann.org/hyperkitty/list/gnso-latin-diacritics@icann.org/> and the main wiki page<https://icann-community.atlassian.net/wiki/x/EwDVBg?atlOrigin=eyJpIjoiMWI2M…>. Thank you. With kind regards, Devan

1 0

Outcomes, Action Items, and Notes from Meeting #16 on Wednesday, 13 August 2025
by John Emery Aug. 13, 2025

Aug. 13, 2025

Dear LD PDP WG, Please see attached the Outcomes, Action Items, and Notes from Meeting #16<https://icann-community.atlassian.net/wiki/x/AQAvFg> on Wednesday, 13 August 2025: Meeting #16 Slides<https://icann-community.atlassian.net/wiki/spaces/gnsolsdpdp/pages/37217894…> [OUTCOMES] 1. Filled in Spreadsheet <https://docs.google.com/spreadsheets/d/1vA4BoEHaGJBpVJ4oJcEgvzJlu5zEhF9cOQO…> of relevant TBD recommendations and wrote the consensus in the decision tab [ACTION ITEMS] * WG to review upcoming TBD items in the worksheet <https://docs.google.com/spreadsheets/d/1vA4BoEHaGJBpVJ4oJcEgvzJlu5zEhF9cOQO…> * Leadership to discuss if there needs to be an interim update to SO/ACs on progress * Staff and leadership to make slides laying out current options for cost and inquire about cost recovery * WG to think about pricing contracts to find a resolution that is workable and that most agree to [NOTES] 1. Welcome and SOIs 2. Recap of Meeting #15 * Exceptions process decided last week explained * Query about an interim update to SO/ACs 3. Charter Question 3 <https://urldefense.com/v3/__https:/gnso.icann.org/sites/default/files/polic…> * EPDP-IDNs P2 TBD items i.Filled in worksheet<https://docs.google.com/spreadsheets/d/1vA4BoEHaGJBpVJ4oJcEgvzJlu5zEhF9cOQO…> * 8.4 timeline should apply for time from contract to delegating the TLD should be consistent. Does not make sense to make any exceptions, just follow standard process * 8.5 explanation for leaving delegation to registry decision (same time or independently) as long as total time is adhered to. * Do we need a restriction for our applicants to delegate at the same time, certain order of delegation, or up to the registry? There should not be any restriction was the consensus * Sarmad: One of the motivations behind the IDN EPDP recommendation was to clarify a primary and variant, variants do not need to wait for primary to be delegated. In this case as well, two strings tied together ASCII and diacritic, then it would be a similar case that any could proceed independently of each other * 8.10 this was decided in IDNs that variants are a property of the primary TLD and if that is removed all variants lose their connection and cannot exist. The primary holds together the variant set, when it is removed, the variant falls apart * If there is a dependency on the ASCII TLD label, then maybe something similar may need to apply especially if it is one application. * Sarmad: Beyond the technical side there is a contractual side, if there is a single contract, then the contract would normally contract a single string with a tied string as an appendix, if a string goes away then the others would have to go away as well. * There may be technical reasons for keeping the bundle unbundled, here we are trying to prevent user confusion if one disappeared, there is no user confusion. There are not good reasons for doing it, but the contractual part, unicode could change. There could be a time where the that could * Steve: The previous agreement principle of primary string is not exactly applicable. General principle if there is only 1 diacritized version left you can drop the ASCII. If there are 2 or more, then you cannot drop the ASCII. * Already the general requirement for the whole exception process is that one ASCII version must always exist. If we were to allow switching in the contract, we would need the requirement that it is only possible to drop ASCII if only a single diacritic version is left as a standalone TLD * 8.10 Remove ASCII in the case that a single diacritic exists, if more than one, it would be required to remove all but one of the diacritics * 8.11 agreement noted in worksheet * 8.13 Sarmad: if a single contract and a breech, it affects all TLDs in that contract * 3.11 4 variants for the price of one? Would be fair, but nearly impossible, there is some cost in evaluating different TLD applications and in part will have different evaluations. These bundles come from different rounds, which makes it more difficult. Two bundled TLDs should not amount to two application fees and should not be at zero cost * Allowing two TLDs to coexist, not reasonable to be free, but the goal is to make this possible at all! The exceptions process ensures that one would not be rejected and allows them to coexist. Those applications have to work on a cost recovery base, with rebate or free it would be unclear how this cost recovery would turn out or where the additional cost would apply. * Balance to incentivize and not make it costly, but can’t drive contracted parties away from wanting to be a part of this * Cost recovery principle and consideration for implementation how that looks from a financial perspective and if there is no additional fees, the it has to come from everyone else and be subsidized by other applicants would impact the program in general. Not easy to do. Promote IDNs and could have a general impact on the entire program and other applicants * Promoting IDNs and this PDP is not actually meant to promote IDNs as it is now an exceptions process to have both ASCII and diacritic one * Finishing PDP quickly no discount should be the solution and to have a fair cost recovery basis, there should not be free TLDs like in the variant case, first TLD pay full price and any additional get a discount. * Should stop comparison with EPDP, diacritics are quite different from variants. Fees also should work in a different way with a significant discount * How much does it cost in addition to the diacritic version for cost recovery? * Fees are up to ICANN based on a cost recovery basis and if they are able to provide discounts, but as a PDP we don’t know what the implementation is going to require * Discussion of wanting to have a rough estimate of the cost recovery mechanism if available. * Approach: major and important point with a lot of opinions with reasonable arguments behind them. Revisit this topic next call and prepare some slides to lay out the possible solutions: no price change, free, some reduction, up to ICANN, etc. 4. Next Steps 5. AOB Thank you, John R. Emery, Ph.D. Policy Development Support Senior Specialist Generic Names Supporting Organization (GNSO) Internet Corporation for Assigned Names and Numbers (ICANN) www.icann.org<http://www.icann.org>

1 0

Proposed Agenda for Meeting #16
by Saewon Lee Aug. 11, 2025

Aug. 11, 2025

Dear LD PDP WG, Please find below the proposed agenda for LD PDP WG Meeting #16 on Wednesday, 13 August 2025 at 13:15 UTC: 1. Welcome and SOIs 2. Recap of Meeting #15 3. Charter Question 3 [gnso.icann.org]<https://urldefense.com/v3/__https:/gnso.icann.org/sites/default/files/polic…> * Review of TBD Items 1. Next Steps 2. AOB As always, the LD PDP WG Charter [gnso.icann.org]<https://urldefense.com/v3/__https:/gnso.icann.org/sites/default/files/polic…> and the Worksheet with SubPro/EPDP-IDNs Outputs [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/spreadsheets/d/1vA4BoEHa…> have been hyperlinked for your reference and the Charter Questions can be viewed on page 2. Please also see all relevant/background documents to this PDP on wiki here [icann-community.atlassian.net]<https://urldefense.com/v3/__https:/icann-community.atlassian.net/wiki/x/2wP…>. See you all Wednesday! Kind regards, Saewon Saewon Lee Policy Development Support Manager for GNSO Internet Corporation for Assigned Names and Numbers (ICANN) Mobile: +1 (310) 463-5541 Email: saewon.lee(a)icann.org<mailto:saewon.lee@icann.org> Skype: saewon.lee.icann Website: www.icann.org<http://www.icann.org>

1 0

Notes from Meeting #15 on Wednesday 6 August 2025
by John Emery Aug. 6, 2025

Aug. 6, 2025

Dear LD PDP WG, Please see attached below the readout of Outcomes, Action Items, and Notes from Meeting #15<https://icann-community.atlassian.net/wiki/x/agAsFg> on Wednesday, 6 August 2025: Meeting #15 Slides<https://icann-community.atlassian.net/wiki/spaces/gnsolsdpdp/pages/37198244…> [OUTCOMES] 1. Applicant must decide up front which process to follow and cannot unbundle in the middle of the process 2. Filled in Spreadsheet <https://docs.google.com/spreadsheets/d/1vA4BoEHaGJBpVJ4oJcEgvzJlu5zEhF9cOQO…> of relevant TBD recommendations and wrote the consensus in the decision tab [ACTION ITEMS] * WG to review upcoming TBD items in the worksheet <https://docs.google.com/spreadsheets/d/1vA4BoEHaGJBpVJ4oJcEgvzJlu5zEhF9cOQO…> [NOTES] 1. Welcome and SOIs 2. Recap of Meeting #14 * Discussion of consensus last time looking at single application process to be further discussed today * Reviewed scope from the WG Charter to avoid user confusion and to provide clarity and certainty for potential applicants to operate the set of ASCII and diacritics * Consistent with EPDP-IDNs P1 Rec 3.4 allowing for a single application (bundle as a set) * Concern about uncertainty and to make applicants aware of exception process * Separating the application at a later stage might not be the best approach, it could also be legally problematic that suddenly one application is separated into multiple applications. * If you use the exception process then the TLDs will be handled as a bundle independently of SSR * Sarmad previously raised concern that having a bundle, but the charter clearly does not require them to be confusingly similar, only a non-negligible chance of being confusingly similar. This is well within our charter * Agreement for not having a split later in the process. * EPDP Phase 1 variant set is not made by the applicant. What would the test be to make sure that ASCII and diacritics? Similar situation for variants as the set is known upfront defined by LGR, the diacritic characters is known up front Mark’s * Edge cases brought up for SSR process for applicants in next rounds. Decisions taken are not 100% predefined. Next round exceptions process could be applied for if it was previously rejected due to SSR * Do we need a challenge process? It could be outside of the scope of our PDP * Sarmad: The motivation behind the processes are different. 1st is for strings which the applicant thinks are two different strings and managed differently. The second is a situation where the applicant considers the two strings to be the “same” or variations and they need to behave the same way. There is a different expectation inherent in the second case. Two strings representing the same thing. Option 1 and Option 2 is not just switching processes, but understanding what the two strings represent. If applicant thinks the strings are the same then the LD PDP exceptions process is correct. No motivation to switch processes * Applicant has to decide upfront if they have two labels separately, or applicant wants similar strings as a bundle. * Edge cases discussed * Possibility of dropping applied for string, in IDN-EPDP Phase 1 recommendation. If applicant submits for primary + variant, they can then withdraw the variant string, they cannot add a variant string afterwards (.Brand possible exception), there is a parallel here * Applicant has to decide upfront or decide on a path that there is some similarity in other TLD applications for community applications. If you apply as a community TLD, you have to submit all required documentation and cannot use the application change request after initial submission. Example there for requirement deciding up front how to operate the TLD. Cannot game the system by not allowing changes * Any application may be withdrawn, the question is the kind of refund depending on point in time. Should not allow to unbundle in middle of the process. * Consensus to not allow switching in the middle of the process * Edge cases should be decided once all recommendations are in place to do some test runs 3. Charter Question 3 <https://urldefense.com/v3/__https:/gnso.icann.org/sites/default/files/polic…> * EPDP-IDNs P2 TBD items i.Filled in worksheet<https://docs.google.com/spreadsheets/d/1vA4BoEHaGJBpVJ4oJcEgvzJlu5zEhF9cOQO…> * TBD 3.25 one can withdraw the applied for label if necessary. Sarmad discussed the variant side where a set of variants is a primary label for withdrawn vs. secondary, implications downstream. Reasonably strict dependence on having a primary label defining the set. In our case, there is an option to drop one or the other, there is no primary or secondary relationship. That is not the case with variants and this could have implications. At application time one should identify a primary (ASCII) with diacritic being variants * Base ASCII has to be the “primary” string, so one could not drop the base ASCII only diacritic versions * Discussion of edge cases and not applied for strings or diacritics then wanting to apply for it later. Asking for thinking afterwards that one was able to apply for a diacritic down the road and should not be allowed and can be picked up the next round * Only have to win the ASCII if they apply for two diacritics versions, if you apply for just one diacritic, the ASCII could still be mandatory, they could still keep diacritic one * Sarmad: variant side normally when you apply for a string and multiple variants. Needed to have a justification on why the variant is being applied for. One example where treatment of primary is slightly different from treatment of a variant. Primary string justification questions are only for variants. Two strings paired together in an exceptions process. Unless we have a primary identified and others associated, those rules can be applied. * 3.25 parts 1) withdraw variants, but not primary and not allowed to add any 2) exceptions for .Brand TLD. Do we want to have the same exception available in our process for .Brand? AGB there are special rules for .Brand to change the string down the road but with limitations for the label matches the brand * Some consensus that Brand TLDs may have similar priority rights to change applied for TLDs. 3.25 should be rewritten to our case, but meaning should be used for our case. * 7.9 Change of Control process. With blocked variants there are variants blocked by ICANN for SSR issues. Certain variants applied by the registry, but were not able to qualify for them and were rejected. Decisions taken for those variants remain, the same should hold true in our cases. * 7.14 all allocatable variants applied for has to have same rules as the main one. Do we want the same rules for our case. * Sarmad: apply for two strings bundled together could you say that one is a geographic or community TLD and the other is not? That is how to think of recommendation 7.14 Thank you, John R. Emery, Ph.D. Policy Development Support Senior Specialist Generic Names Supporting Organization (GNSO) Internet Corporation for Assigned Names and Numbers (ICANN) www.icann.org<http://www.icann.org>

1 0