September 2022 - Gnso-epdp-idn-team

order of variant activation / "primary" label
by Michael Bauland Sept. 19, 2022

Sept. 19, 2022

Dear colleagues, at the end of yesterday's call, we had a short discussion about the order of variant activation, which we did not have enough time to conclude. I would like to quickly summarise the argument, which I wanted to make. I think we should continue the discussion in one of the next calls, whenever it fits best. Due to the fact that variant dispositions are different, depending on which label you start with, it makes a big difference, which label you register first (if you don't want to register all at the same time). Take the real life example of the Turkish brand "*Yapı Kredi*". They are currently using the domain yapikredi.com.tr. Let's say, they would like to apply for their own TLD. For internationalisation reasons, they would like to start with ASCII version .yapikredi as a TLD string. Several years later, they would like to also register their variant TLD with the correct spelling: .yapıkredi. That's not possible, because it's a blocked variant. As a consequence, they will have to start with registering the TLD .yapıkredi, even if they do not want to use it directly, just to make sure, they don't lock themselves out of using it at all. The question is, how should such a use case be accommodated best? I see two possibilities: 1. Apply for both TLDs at the same time .yapıkredi and .yapikredi, but only activate the second one, keeping the first one inactive for years. 2. Apply for .yapikredi, but state in the application that the "main" TLD should be .yapıkredi, even though it's not applied for yet. The first approach is the simpler one, but it might incur unnecessary cost as the applicant is not sure, whether they ever want to activate the second label. The second approach would require that each application needs to define a "primary" or "main" or "starting" label, however we want to call it. I personally would support Option 2 as that would also avoid some potential inconsistencies, when a variant TLD gets retired. Similar examples also exist for other scripts, not just Latin. Best regards, Michael

4 3

Notes and action items - IDNs EPDP ICANN75 sessions
by Emily Barabas Sept. 17, 2022

Sept. 17, 2022

Dear all, Please find below the notes and action items from today’s ICANN75 sessions. Slides are attached. Kind regards, Ariel, Steve, and Emily Notes and Action Items Session 1 – Saturday 17 September 2022 at 9:00 MYT Round the Room Introductions “Chunking” Exercise * Purpose of this “chunking” exercise: divide top level and second level work, so that the report on the top level can be delivered in December 2022 and work can simultaneously happen in the CPH Tech Ops group on some of the operational implications of work at the second level. A second report on second level issues will be delivered later. * This will require an updated project plan to be delivered to the GNSO Council. * Session Deck Slide 8-9 – “Chunking” Overview * Session Deck Slide 10 – Initial Report Part 1 – Group 1 Charter Questions * Session Deck Slide 11 – Initial Report Part 1 – Group 2 Charter Questions * Session Deck Slide 12 – Initial Report Part 1 – Group 3 Charter Questions * Session Deck Slide 13 – Initial Report Part 2 – Group 4 Charter Questions * Session Deck Slide 14 – Initial Report Part 2 – Group 5 Charter Questions * Session Deck Slide 15 – Initial Report Part 2 – Group 6 &7 Charter Questions * Another consideration is that part 1 is about the new gTLD process. The Board wants to see this PDP done before they introduce more new gTLDs. Those that focus on the post-contracting phase are in group 2. * It wasn’t clear where Charter Questions F1 and F2 sat in the process, and therefore whether they fit is group 1 or group 2. * Any reactions to the proposed approach? * Comment from the Board Liaison: The Board has not discussed this. The Board does not have a position about whether there is a dependency here for new gTLD rounds. * Comment that splitting the work is a good idea and is logical. The approach gives the community visibility into the work has been done. * One topic that is not explicitly included in the charter is if and how variant relationships show up in WHOIS. The topic might belong under Charter Question a8, which is in the first “chunk” of work. We might want to seek IANA’s input on this topic. * Comment that it may be useful to develop an additional Charter Questions specifically on this topic. Action Item 1: Leadership team to coordinate with Council Liaison about when and how to inform Council that the EPDP Team needs to consider this additional topic. * Suggestion to add this topic to group 2, because only delegated TLDs have IANA records. Action Item 2: Leadership team will update project plan and produce a project change request, which it will share with the WG before sending to Council. Risk Management Methodology * There are risks associated with the introduction of IDN variants, for example risks misconnection and denial of service. * There are differences of opinion within the team about whether these are edge cases and what that means for policy development. * The leadership team is looking to introduce tools to help assess possible risks associated with potential recommendations. * Security and stability are always top of mind. The EPDP Team relies on SSAC reports and other sources to take these into account. * Some other risks are harder to assess. * Session Deck Slide 17 – Problem Statement Risk Management * Presentation: Intro to Risk Management Approach from James Caulfield from ICANN org’s Risk Management function * Risk Management Deck Slide 2 - The Nature of Risk * Risk Management Deck Slide 3 – Informed Management of Risk * Risk Management Deck Slide 4-5 – How to Articulate a Risk: Risk Title, Consequences, Existing Controls or Mitigation, Risk Rating, Proposed New or Changed Controls or Mitigation. * Risk Management Deck Slides 6- 7 – Risk Ratings: Heat maps reflecting patterns of likelihood and severity * Risk Management Deck Slide 8-9: Rating a Risk: Importance of defining the ratings associated with risk * In the policy development context, it may be helpful to use this framework: to understand the likelihood and severity, but also to consider possible mitigation measures. * This may especially be useful to reflect in the rationale of the policy recommendations. The recommendations may be considered more sound if the EPDP Team can show that is has gone through this exercise. * From one perspective, a challenge is that there may be differences of opinion within the group about what kinds of risks are severe. Some might think that an issue poses a security and stability risk to the Internet. There is no way to prove who is right and who is wrong. What do you do about that in the context of a risk analysis? * Perhaps the next step is to accept that there are differences of opinion about the impact, but in such cases, you might be able to focus on the mitigation that could be mutually agreeable. * Comment that much of risk management is subjective. It relies on professional judgement. If the group can agree on what will be the consequence of a risk, that is a good first step. At the same time, in risk management, there does need to be an ultimate decision maker. * From on one perspective, it also depends on the ICANN community’s level of risk tolerance. The EPDP Team can do the analysis, but ultimately someone needs to decide what level or risk is acceptable. * Comment that this is a good exercise for the EPDP Team. It will help with developing the rationale and potentially also help implementation. How does the group converge on understanding of consequences? * Response that often this is done through a root cause analysis. * It was noted that this approach could be used in supporting development of policy recommendations on string similarity. * Agreement that this is good way to approach the EPDP’s work. Given that the group is making new changes that impact the root it’s important to look at risks. * As a next step, if the EPDP Team agrees that they want to take this work further, a future call can be used to do a deeper dive into risk analysis. * Session Deck Slide 18: Denial of Service: Example & Illustration * Session Deck Slide 19: Misconnection: Example & Illustration * Question about how these examples are different from trademark infringement. * Response that the discussion is around string similarity and how the blocked variant may or may not be taken into account in this review. Session 2 – Saturday 17 September 2022 at 10:30 MYT Strawman Process Flow * Background * Origins from questions D1b and B4 * Purpose * Understand which elements of new gTLD process will be impacted by variants * Which how those elements must be modified * Consider level of effort * What to review and discuss * Review mapping of charter questions and prelim recommendations * Identify potential gaps * Analyze feasibility of a standalone round * Analyze feasibility of activating variants between application rounds * Is NOT a comprehensive capture of all charter questions, only charter questions/recs relative to New gTLD Application process * Chinese and Arabic gTLD Registry Operators survey – reviewing results on slides * Question about the importance of the survey results in policy making. Noted that this is a data point, not binding in any way. Recognizes that the factors that may affect decision-making are still pending, understandable that outcomes from this EPDP and SubPro implementation may be impactful. * Assumption that the general flow of the program will look generally similar. The updated process flow includes new elements as identified by SubPro. Other new addition is the inclusion of charter questions and preliminary recommendations. And finally, boxes are numbered. * Two labels possible for each box: Applicable and Specific. Applicable means that IDN variants would still be required to go through the program element. Specific means that some sort of change will need to be made to the process to accommodate IDN variants. The Specific questions will naturally likely have charter questions associated. * Pre-Program Processes from SubPro include Predictability Framework and RSP Pre-Evaluation * Reviewing application submission process impacts * Notes new impact from IGO-INGO PDP * Two new SubPro processes are “Persistent” Processes meaning they can occur at various stages of the program. This includes RVCs and PICs and Application Change Requests (including ability for .Brand to revise strings to resolve string contention). * Reviewing Initial Evaluation process impacts * Noted that - “To be consistent with other boxes that have a relationship with Rec 2.8, I think box 25 should also be 'Specific'” * Another persistent process – Limited Challenge / Appeal Mechanism * Reviewing Objection mechanisms * Reviewing Extended Evaluation * Reviewing String Contention Resolution * Reviewing contracting, pre-delegation, and delegation * Question – are there any gaps? * Potential gap within box 2 – would a different pre-del process be needed for RSPs that want to provide services for IDN variants versus those that do not intend to do so. * There are at least two models to manage primary and variants – variant as object versus variant as attribute. May need to look at this. * Is there a possibility that the backend-registry operator is unable to handle variants? It seems that this is the basis for flagging this process. * Pre-evaluation for RSPs will not include the business, policies, etc. for the Registry Operator. It would be limited to just the technical capabilities of the pre-eval. * Background on RSP pre-eval: uses same criteria as during application evaluation process. String agnostic process. It allows applicants to potentially just check a box that they will use a pre-evaluated RSP. There may be initial elements needed once the primary/IDN variants are needed. * There may be a gap for pre-delegation testing as well, similar in nature. * Potential gap for geographic names? What would happen if a variant is a geographic name. Probably not a gap as the variants would be subject to any restrictions on the primary. * Question also from other angle - variants of ISO 3166. There may be a charter question that connects to this issue. * E6: is there any reason to permit the registration of gTLDs consisting of decorated two-character Latin labels which are not variant labels of any two-letter ASCII labels? * Registry Services – reviews anything above and beyond the typical services, which could include variant management. * Question about relevance of IDN retirement processes? Seems out of scope. * There appears to be existing processes to cover this (e.g., EBERO) * What happens if only one of the delegated variants is to be retired? Can be covered in part 2 of the chunking exercise. * Moving to discussion about whether an existing TLD operator could apply in a separate program process. One option is to roll these applications into a future round. A separate process requires setting up standing up all needed infrastructure, which would be complicated under cost-recovery. * At least for the next round, there should not be a standalone round just for existing operators. This should help address cost recovery. Group will need to determine which elements would apply to just variants of existing ROs, even if combined into the next round. * What happens if a ccTLD operator applies for a gTLD IDN and IDN variants? Would they also require different requirements. * Need to consider if the variant is protected in some manner. * Haven’t yet made a decision whether variants would be allowed in the future, between the regular rounds. This question is likely about “activation” between rounds. * One of the purposes of the process flow is to help answer questions like this – can any processes be dispensed with just for activation? If enough processes can be dispensed with, it makes it more feasible. However, if almost all of the processes remain needed, standalone rounds is less practical. * Application and activation is an important distinction. It appears to some that the majority of the processes would be needed for IDN variants as at the end of the day, they are gTLDs. The string and the applicant must be evaluated, and there are other elements objections, application comment, etc. * There will three different views of the program: Applying for primary; primary and variants; just variants for an existing RO. * What also makes things challenging is that next round of the New gTLD Program is not yet established. * Would it be possible to apply for just a variant in the absence of a primary? No, the issue being raised is about an existing registry applying for/requesting activation of a variant. * Primary is not absolute – it is what the applicant wants to be the primary.

1 0

Guidelines for speakers ICANN75
by Nathalie Peregrine Sept. 14, 2022

Sept. 14, 2022

Dear all, ICANN75 will begin in a few days. For all those joining, be it on-site or remotely, please take a few moments to review the attached guidelines. Whether you are a scheduled speaker, or planning to attend sessions, these guidelines ensure your audio will be loud and clear, and that meetings can run smoothly. Thank you all! Kind regards, Nathalie

1 0

ICANN75 session agendas
by Emily Barabas Sept. 14, 2022

Sept. 14, 2022

Dear EPDP Team members, Please find below the proposed agendas for the two EPDP Team meetings scheduled to take place at ICANN75. For those who are registered for ICANN75, additional information can be found on the ICANN schedule here<https://75.schedule.icann.org/>. Kind regards, Ariel, Steve, and Emily EPDP IDN Sessions at ICANN75 Session 1<https://community.icann.org/display/epdpidn/2022-09-17+ICANN75+Session+1+ID…> Saturday, 17 September 2022, 09:00-10:00 MYT 1. Welcome and Opening Remarks (5 min) 2. Round the Room Introductions (10 min) 3. Charter Question “Chunking” - Part 1 and Part 2 of Initial Report (15 min) 4. Risk Management Methodology Presentation by ICANN org (25 min) 5. AOB (5 min) Session 2<https://community.icann.org/display/epdpidn/2022-09-17+ICANN75+Session+2+ID…> Saturday, 17 September 2022, 10:30-12:00 MYT 1. New gTLD Application Strawman Process Flow (75 min) * Mapping of Charter Questions and Preliminary Recommendations * Consideration of Potential Gaps Regarding Variant Implementation * Answering Charter Questions D1b (Part 1) and B4 * Review of RO Survey Result Highlight 2. Next Steps (10 min) 3. AOB (5 min) Emily Barabas Policy Development Support Senior Manager Internet Corporation for Assigned Names and Numbers (ICANN) Phone: +31 (0)6 84507976 www.icann.org<http://www.icann.org/>

2 1

Notes and action items - IDNs EPDP Meeting #51 - 8 September 2022
by Emily Barabas Sept. 8, 2022

Sept. 8, 2022

Dear all, Please find below the notes and action items from today’s meeting on Thursday, 8 September 2022 at 13:30 UTC. Kind regards, Ariel, Steve, and Emily Notes and Action Items IDNs EPDP Meeting #51 8 September 2022 Action Items: Action Item 1: Recommendation 3.4: Add “or Change of Control” after “Registry Transition Process” in the first sentence: “After the Registry Transition Process is completed . . ” Action Item 2: Response to Charter Question D3: Change “policies” to “requirements”, consistent with Specification 2 of the RA. Action Item 3: Response to Charter Question D3: Possible revision to bullet 1: “Existing data escrow requirements for existing gTLDs must apply to IDN gTLDs and variant labels as provided for in their RAs.” Action Item 4: Response to Charter Question D3: In bullet 2, change “provider” to “agent.” Action Item 5: Response to CQ D3: Leadership to propose language for bullet 3. This will also influence Implementation Guidance 3.9. Action Item 6: Replace “policies” with “requirements” in recommendations 3.8 and 3.9. Action Item 7: Rationale for recommendations 3.8 and 3.9: Change “enhance” to “maintain.” Action Item 8: Rationale for recommendations 3.8 and 3.9: Revise language to be consistent with updated text in bullet 3 of the Answer to Charter Question D3. Action Item 9: Rationale for Recommendation 3.2-3.3: Keep text highlighted by Dennis marked to revisit and review after the EPDP Team has resolved the string similarity issue. Notes: Welcome, Chair Updates & ICANN75 Planning * Leadership team is preparing for ICANN75 sessions. There will be three focus areas: * The “chunking exercise,” which involves breaking our work into two parts to allow us to complete a draft report for phase one focused on top level issues. The second segment will be on second level issues. * Leadership team is investigating the possibility of engaging ICANN org’s risk management function during ICANN75 to learn more about the tools this group might be able to use to conduct risk assessment. This may be able to help the group identify where there are edge cases and how to evaluate risks associated with those edge cases. * Org staff has been working on marking up the new gTLD process flow and mapping our draft recommendations to New gTLD processes. This will help us to consider whether there is anything we missed and whether anything needs adjustment. Second reading of group 3 charter questions * Google doc: https://docs.google.com/document/d/1C6xKX87w2LtN4Is0mehuRgc1GqjKmbbhT14KbvU… * Recommendation 3.4: Sarmad provided feedback that we need to make clear that the Registry Transition or Change of Control process must encompass the IDN gTLD and all its allocated and/or delegated variant gTLD label(s), if any, at the same time. Proposed redlines address this feedback. * Recommendation 3.4: Question from RySG: “Should we consider not allowing any new activation request of allocatable variant TLD labels during any transition until the process is completed, after which the successor registry operator would be the only registry operator entitle to activate any new variant labels?” Suggestion to add a recommendation that the activation requests are not allowed until the transition process is completed. * Clarification: This may be contingent to how the RO applied for the allocatable variant. If variants are only requested in rounds, this will foreclose the issue. But if we are thinking that activation of variants is possible between rounds, we might need to close this loophole. * Comment: This comment brings up an interesting point. We should look at the process flow to see if something is needed. In the interim, we should make a note of this point. This applies also to PDDRP use case. We may also look at a requested variant for which the process has not been completed, after which there is a registry transition. * Summary: We are trying to convey that during a change of control process everything is frozen. Until the registry transition is complete, a request to activate a variant that hasn’t been delegated yet or applied for yet can’t happen until the registry transition is complete. Team will make a note and revisit in analysis of process flow. * This could be an expansion of 3.4 or potentially a new recommendation. * Recommendation 3.5: Comment from Justine: Do we need to mention change of control in the text of this recommendation for consistency? Action Item 1: Recommendation 3.4: Add “or Change of Control” after “Registry Transition Process” in the first sentence: “After the Registry Transition Process is completed . . ” * Registry Transition Process may encompass Change of Control but it doesn’t hurt to add explicit reference to Change of Control. * Both can be right. At any point in time a TLD only has one registry. * RySG proposed redline edits to draft response to Charter Question D3. * Clarification: At the point the registry agreement is executed the RO starts to need to comply with the contractual requirements. * Question: If the variant isn’t delegated, the data escrow requirements would be applicable, even if they would be blank? * Response: Yes. * Question: On the issue of the term “requirements” vs. “policy”, policy has a connotation in the ICANN environment. It makes sense to use the term “requirements” to be clear about the distinction. * Comment: To the question is whether a delegated label has always been allocated, the answer is yes. However, an allocated label might not be delegated. * Question: When do data escrow obligations kick in? Is it when it is delegated legally or delegated into the root. * Response: When the RA is signed. * Comment: From the last round, ICANN compliance enforced escrow obligations when the record was in IANA. * Note: That is different from the point that the RA is signed. * Comment: Escrow is the process of saving data in case a contracted party goes out of business. Those files have no value and there is no risk before there is a record in IANA. * Question: Can we check for certain how this was done in the previous round? Did the obligation start at contract signing or when delegated to the root zone? We should stick with the same procedure. * Summary: If we are not sure about how this is enforced, maybe we just want to emphasize that the escrow requirements apply for variants the same way they apply for other TLDs. * Comment: Two situations: One where there is a new TLD and there are no record, a second scenario is a registry transition where there is a zone file. In the registry transition, the new registry will have the same obligations. Action Item 2: Response to Charter Question D3: Change “policies” to “requirements”, consistent with Specification 2 of the RA. Action Item 3: Response to Charter Question D3: Possible revision to bullet 1: “Existing data escrow requirements for existing gTLDs must apply to IDN gTLDs and variant labels as provided for in their RAs.” * In bullet 2, Dennis suggests changing “provider” to “agent” Action Item 4: Response to Charter Question D3: In bullet 2, change “provider” to “agent.” * Written input on bullet 3: Dennis suggests talking about data escrow files instead of agents. We care about the outcome. What we are saying is that Specification 2 gives the requirements about how to process the deposits. It is consistent in intent, it’s just how we talk about it. We should focus on the outcome, which is the deposit files. * Question: Does the RO have to submit different escrow files for each TLD or do they submit one file for all TLDs? Who has to separate the files? Is this of concern to us? * Response: If you look at file naming convention, the file is called using the TLD name. All variants have different TLD names. Logically, it is different files. There is no reason to upload it as a bunch. It will change procedures. * Comment: The point is that escrow data needs to be separated for each TLD. * Comment: If we are pointing as a reference the data escrow requirements, it’s about how the RO submits those files, which is on a per-TLD basis. Make clear who has an obligation to submit the file, which is the RO, on a per TLD basis. * Summary: We want to be consistent with the Spec 2 requirements, so we can just point to those requirements. * Question: Is the reference to the data escrow agent incorrect? * Response: Not sure. The data escrow has an agreement with the RO, not ICANN. It’s not clear whether our rationale will effectuate something in that agreement. What is done today is working. We don’t need to introduce new complexity. * Comment: The emphasis should be on the idea that the data should be stored in different files. * Comment: From the technical perspective, the fewer operations the better. Action Item 5: Response to CQ D3: Leadership to propose language for bullet 3. This will also influence Implementation Guidance 3.9. * Next item: Rationale for recommendations 3.8 and 3.9. Action Item 6: Replace “policies” with “requirements” in recommendations 3.8 and 3.9. * Additional RySG input: Since each gTLD in a variant set is a unique and independent entry in the root zone, each gTLD must have the same data escrow requirement to create a gTLD-specific data escrow deposit files. We are making clear that each gTLD in a set must comply individually, and since we are not creating new requirements I don't see how this practice (in the context of variants) enhances the stability of the associated domain name registrations. Action Item 7: Rationale for recommendations 3.8 and 3.9: Change “enhance” to “maintain.” Action Item 8: Rationale for recommendations 3.8 and 3.9: Revise language to be consistent with updated text in bullet 3 of the Answer to Charter Question D3. * Question: Is it even possible to have the data in a single file? * Response: At the moment, a RA covers one TLD. We have a recommendation that if you have a IDN label and variants, there can be one RA. What is the impact on the data escrow requirements? We want to be clear that in the future that if you have an RA that covers a TLD and variants, the escrow requirements need to apply to all, each with a different file. * Question: Do we know how they store the data now? * Response: We do know how it’s done now, because gTLDs have been operating for 10 years. All we are saying is that if there is a TLD with variants in the future, store it the same way but in different files. * Suggestion: It might be helpful for everyone to review Spec 2 language, which refers to multiple files. The process is working now and we shouldn’t change it. * For reference: Spec 2 Part B #4 — “ Integrity and Confidentiality. Escrow Agent will be required to (i) hold and maintain the Deposits in a secure, locked, and environmentally safe facility, which is accessible only to authorized representatives of Escrow Agent, (ii) protect the integrity and confidentiality of the Deposits using commercially reasonable measures” * Google Doc: https://docs.google.com/document/d/1RLvsyQvliafNEA9Ja1RCObywpAWfp1kTmte0WZl… * Next Item: Charter Question E5 * Rationale for Recommendation 3.2-3.3 excerpt: The EPDP Team recognized that if the Reserved Names list were to expand by including the variants, all of the added variants (almost all of which are blocked and can never be delegated to the rootzone) also need to be checked against during the String Similarity Review. It means that every applied-for gTLD string would have been compared against an enormous pool of Reserved Names. Therefore, the EPDP Team agreed that the Reserved Names list should stay as is and no variants should be added. The implementation complexity of adding variants to the Reserved Names list would have outweighed the potential security and stability benefits, if any. * Comment on the text from Dennis: We may need to revisit this part since it argues for a practical solution since blocked variants can never be delegated and they don't need be part of the string similarity process — It argues against the Hybrid Model. * Note: The EPDP team is still deliberating on the hybrid model and will soon get input on a possible risk management approach to considering this. * Dennis: This language was written before discussion of the hybrid model. Dennis found it interesting that there is a contrast between this and the hybrid model. They are not the same, but they are related. Do we need to consider the potential consistency between the approaches? Action Item 9: Rationale for Recommendation 3.2-3.3: Keep text highlighted by Dennis marked to revisit and review after the EPDP Team has resolved the string similarity issue. * The process of checking recommendations against the process flow may help us confirm that our recommendations are consistent before we put a draft report out for comment. Continue discussion of objections (Limited Public Interest, Community, and Legal Rights) * We are pausing discussion of the String Confusion Objection because it is closely tied to String Similarity evaluation, which the EPDP Team will revisit soon. We will come back to this. * There is one proposal on the table for Limited Public Interest, but options have been put forward for Community and Legal Rights Objection. * Slide 41 – Review of Small Group recommendation on Limited Public Interest Objection. * No concerns raised with the approach suggested by the small group. * Slide 42 – Review of options for recommendations from the small team on Legal Rights Objection * Slide 32 -- Additional Rationale for Option 2 * The presumption is that round 1 and 2 are in sequence and that round 2 opens after round 1 closes. * It may not be possible to draw a conclusion on this item until the WG has made a determination about the hybrid model, because the examples arguing for Option 2 draws on the hybrid model from staff’s perspective, but there is some nuance. AOB * Reminder, no call next week. Next meetings will be our sessions at ICANN75.

1 0

Post Call | IDNs EPDP Team call | Thursday, 01 September 2022
by Devan Reed Sept. 8, 2022

Sept. 8, 2022

Dear all, All recordings for the IDNs EPDP Team call held on Thursday, 08 September 2022 can be found on the agenda wiki page <https://community.icann.org/x/MwYVD> (attendance included) and the GNSO Master Calendar. <https://urldefense.com/v3/__https:/gnso.icann.org/en/group-activities/calen…> These include: * Attendance (please let me know if your name has been left off the attendance list) * Audio recording * Zoom chat archive * Zoom recording (including audio, visual, rough transcript) * Transcript For additional information, you may consult the mailing list archives <https://mm.icann.org/pipermail/gnso-epdp-idn-team/> and the main wiki page<https://community.icann.org/x/uAPpCQ>. Thank you! Kind Regards, Devan

1 0

Meeting Invitation | IDNs EPDP Team | Thursday, 06 October 2022 at 13:30 UTC
by Devan Reed Sept. 8, 2022

Sept. 8, 2022

As a reminder the meetings being held during ICANN75 will take place on Saturday, 17 September 2022 at 09:00 MYT (01:00 UTC) and Saturday, 17 September 2022 at 10:30 MYT (02:30 UTC) * ICANN75 wiki agenda pages: * Session 1: https://community.icann.org/x/FQJpD * Session 2: https://community.icann.org/x/GAJpD Find below the meeting details for the IDNs EPDP call taking place after ICANN75. ************************************************************* Dear all, The IDNs EPDP Team meeting is scheduled on Thursday, 06 October 2022 at 13:30 UTC for 90 minutes. Please click link to join the webinar: https://icann.zoom.us/j/94276275950?pwd=dG5hanFzMlpsYmh0NnFjTEQwOUV1dz09 <https://urldefense.com/v3/__https:/icann.zoom.us/j/94276275950?pwd=dG5hanFz…> Passcode: !!0tV0Wh&K For Audio only: One tap mobile : US: +13017158592,,94276275950#,,,,*5259149775# or +13126266799,,94276275950#,,,,*5259149775# Webinar ID: 942 7627 5950 Passcode: 5259149775 International numbers available: https://icann.zoom.us/u/adP1jJ0gRH <https://urldefense.com/v3/__https:/icann.zoom.us/u/adP1jJ0gRH__;!!PtGJab4!v…> If this is your first time with Zoom, please take a look here: Welcome to Zoom <https://urldefense.com/v3/__https:/gnso.icann.org/sites/default/files/polic…> Members, participants, and observers all have different access and participation directions, please read below! ALL: Before joining the call * Please send dial out requests to gnso-secs(a)icann.org<mailto:gnso-secs@icann.org> only * Please be sure you have read the ICANN Expected Standards of Behavior <https://urldefense.com/v3/__https:/www.icann.org/resources/pages/expected-s…> * Visit the Wiki agenda page: https://community.icann.org/x/PIKkD * Check your time zone: https://tinyurl.com/32wmcuvz ONLY for Members and Participants * Please join via the above Main Zoom Webinar link and staff will promote you to panelist. * Please select Everyone, when posting to the chat in order for everyone to see and to be captured afterwards. Only for Observers: * Observers will have ability to view member chat and information shared in the zoom webinar room. * Observers will not be able to use chat or raise hands. Thank you. Kind regards, Devan

1 0

15 MINUTE REMINDER | Meeting Invitation | IDNs EPDP Team | Thursday, 08 September 2022 at 13:30 UTC
by Devan Reed Sept. 8, 2022

Sept. 8, 2022

**Please note, due to apologies received for moving the IDNs EPDP Team meeting to Friday, leadership decided to hold this meeting at its original time of Thursday 08 September 2022 at 13:30 UTC. Dear all, The IDNs EPDP Team meeting is scheduled on Thursday, 08 September 2022 at 13:30 UTC for 90 minutes. Please click link to join the webinar: https://icann.zoom.us/j/94276275950?pwd=dG5hanFzMlpsYmh0NnFjTEQwOUV1dz09 <https://urldefense.com/v3/__https:/icann.zoom.us/j/94276275950?pwd=dG5hanFz…> Passcode: !!0tV0Wh&K For Audio only: One tap mobile : US: +13017158592,,94276275950#,,,,*5259149775# or +13126266799,,94276275950#,,,,*5259149775# Webinar ID: 942 7627 5950 Passcode: 5259149775 International numbers available: https://icann.zoom.us/u/adP1jJ0gRH <https://urldefense.com/v3/__https:/icann.zoom.us/u/adP1jJ0gRH__;!!PtGJab4!v…> If this is your first time with Zoom, please take a look here: Welcome to Zoom <https://urldefense.com/v3/__https:/gnso.icann.org/sites/default/files/polic…> Members, participants, and observers all have different access and participation directions, please read below! ALL: Before joining the call * Please send dial out requests to gnso-secs(a)icann.org<mailto:gnso-secs@icann.org> only * Please be sure you have read the ICANN Expected Standards of Behavior <https://urldefense.com/v3/__https:/www.icann.org/resources/pages/expected-s…> * Visit the Wiki agenda page: https://community.icann.org/x/MwYVD * Check your time zone: https://tinyurl.com/mrx4zjfr <https://urldefense.com/v3/__https:/tinyurl.com/mrx4zjfr__;!!PtGJab4!5wIpC8Q…> ONLY for Members and Participants * Please join via the above Main Zoom Webinar link and staff will promote you to panelist. * Please select Everyone, when posting to the chat in order for everyone to see and to be captured afterwards. Only for Observers: * Observers will have ability to view member chat and information shared in the zoom webinar room. * Observers will not be able to use chat or raise hands. Thank you. Kind regards, Devan

1 0

Proposed Agenda - IDN EPDP Meeting #51 - Thursday 8 September 2022 at 13:30 UTC
by Emily Barabas Sept. 8, 2022

Sept. 8, 2022

Dear all, Please find below the proposed agenda for our meeting tomorrow, Thursday 8 September 2022 at 13:30 UTC. Kind regards, Ariel, Steve, and Emily IDN EPDP Meeting #51 Proposed Agenda 1. Roll Call & SOI (2 minutes) 2. Welcome & Chair Updates (5 mins) 3. ICANN75 Planning (5 mins) 4. Second reading of group 3 charter questions (40 mins) 5. Continue discussion of objections (Limited Public Interest, Community, and Legal Rights) (35 mins) 6. AOB (3 min)

3 3

Re: [Gnso-epdp-idn-team] [gnso-secs] Meeting Invitation | IDNs EPDP Team | Thursday, 08 September 2022 at 13:30 UTC
by Devan Reed Sept. 7, 2022

Sept. 7, 2022

**Please note, due to apologies received for moving the IDNs EPDP Team meeting to Friday, leadership decided to hold this meeting at its original time of Thursday 08 September 2022 at 13:30 UTC. Dear all, The IDNs EPDP Team meeting is scheduled on Thursday, 08 September 2022 at 13:30 UTC for 90 minutes. Please click link to join the webinar: https://icann.zoom.us/j/94276275950?pwd=dG5hanFzMlpsYmh0NnFjTEQwOUV1dz09 <https://urldefense.com/v3/__https:/icann.zoom.us/j/94276275950?pwd=dG5hanFz…> Passcode: !!0tV0Wh&K For Audio only: One tap mobile : US: +13017158592,,94276275950#,,,,*5259149775# or +13126266799,,94276275950#,,,,*5259149775# Webinar ID: 942 7627 5950 Passcode: 5259149775 International numbers available: https://icann.zoom.us/u/adP1jJ0gRH <https://urldefense.com/v3/__https:/icann.zoom.us/u/adP1jJ0gRH__;!!PtGJab4!v…> If this is your first time with Zoom, please take a look here: Welcome to Zoom <https://urldefense.com/v3/__https:/gnso.icann.org/sites/default/files/polic…> Members, participants, and observers all have different access and participation directions, please read below! ALL: Before joining the call * Please send dial out requests to gnso-secs(a)icann.org<mailto:gnso-secs@icann.org> only * Please be sure you have read the ICANN Expected Standards of Behavior <https://urldefense.com/v3/__https:/www.icann.org/resources/pages/expected-s…> * Visit the Wiki agenda page: https://community.icann.org/x/MwYVD * Check your time zone: https://tinyurl.com/mrx4zjfr <https://urldefense.com/v3/__https:/tinyurl.com/mrx4zjfr__;!!PtGJab4!5wIpC8Q…> ONLY for Members and Participants * Please join via the above Main Zoom Webinar link and staff will promote you to panelist. * Please select Everyone, when posting to the chat in order for everyone to see and to be captured afterwards. Only for Observers: * Observers will have ability to view member chat and information shared in the zoom webinar room. * Observers will not be able to use chat or raise hands. Thank you. Kind regards, Devan

1 0

ICANN75 GNSO Policy Briefing Available for Download
by Julie Bisland Sept. 7, 2022

Sept. 7, 2022

Dear All, On behalf of the GNSO Team, I am happy to report that the GNSO Policy Briefing for ICANN75 is now available for download at https://go.icann.org/gnsobriefing [go.icann.org]<https://urldefense.com/v3/__https:/go.icann.org/gnsobriefing__;!!PtGJab4!6U…>. Happy reading! Best Regards, Julie -- Julie Bisland Policy Operations Sr. Coordinator (GNSO) Internet Corporation for Assigned Names and Numbers (ICANN) Skype ID: 79613b691cb8a6c1 Find out more about the GNSO by visiting: https://learn.icann.org/<https://urldefense.proofpoint.com/v2/url?u=https-3A__learn.icann.org_&d=DwM…> Follow @GNSO on Twitter: https://twitter.com/ICANN_GNSO<https://urldefense.proofpoint.com/v2/url?u=https-3A__twitter.com_ICANN-5FGN…> Transcripts and recordings of GNSO Working Group and Council events are located on the GNSO Master Calendar <https://urldefense.proofpoint.com/v2/url?u=https-3A__gnso.icann.org_en_grou…>

1 0

Reschedule EPDP Meeting to Friday, 9 September
by Ariel Liang Sept. 6, 2022

Sept. 6, 2022

Dear All, Next Thursday, there will be a conflict between the EPDP Team meeting and the Prep Week Community Update on Universal Acceptance webinar. This conflict will affect several members as well as staff. Would it be okay if we move the EPDP meeting 24 hours later, rescheduling to Friday, 9 September at 13:30 UTC? Please share on list asap if you have any concerns. In absence of objection by EOB Tuesday, 6 September, staff will update the calendar invite. Thank you for your understanding. Have a nice weekend! Best Regards, Ariel Ariel Xinyue Liang Policy Sr. Specialist Internet Corporation for Assigned Names and Numbers (ICANN)

5 4

Notes and action items - IDNs EPDP Meeting #50 - 1 September 2022
by Emily Barabas Sept. 1, 2022

Sept. 1, 2022

Dear all, Please find below the notes and action items from today’s meeting on Thursday, 1 September 2022 at 13:30 UTC. Kind regards, Ariel, Steve, and Emily Notes and Action Items - IDNs EPDP Call – 1 September 2022 Action Items Action Item 1: Leadership team to propose recommendation language to bring back to the EPDP Team for Charter Question E5 (Part 2). Action Item 2: ALAC representatives to propose a path forward on Rationale for Recommendation 2.6. Notes Welcome & Chair Updates * Update on data collection to support EPDP Team work on String Similarity: Leadership team has been considered how data could support the EPDP Team’s consideration of the hybrid model presented by the small group over the last few weeks. * Leadership team is working on gathering information about 20-30 strings from the 2012 round to see what would have happened if blocked variants were included in the String Similarity Review. This will help the EPDP Team assess the risk of variants when going through String Similarity Review and understand the costs, benefits, and operational impacts. * While the focus of the EPDP Team is on policy recommendations, it would help the group to have some understanding of the operational impacts. * We are potentially creating process for edge cases. Leadership team is exploring whether the ICANN org risk management function might be able assist with providing tools to support evaluating the risks in the context of different models. * RySG is also having internal discussions on this topic. Procedure to develop RZ-LGR did not have as a goal identifying confusable similarity. The primary goal was to identify variants that may be allocatable. Let’s not consider that the RZ-LGR as the way to identify confusable similarity but an element of that analysis. * Comment that we have to keep the door open for those who feel that they have rights or there is potential confusion with their string to engage in challenge process. * Comment that we need to take care that this not a reservation system. You shouldn’t be able to prevent someone from applying for a string because there is a string that you want to apply for in the future. * The EPDP Team will meet next week but not the following week. There will be two sessions in KL. Details about KL sessions will follow. Strings ineligible for delegation * Slide 4 – Charter Question E5 (Part 2): Should the strings ineligible for delegation be updated to include any possible variant labels? * Slide 5 – Strings Ineligible for Delegation – chart showing strings in different categories: IOC, Red Cross & Red Crescent, IGOs, and INGOs * See also https://www.icann.org/sites/default/files/packages/reserved-names/ReservedN… & https://community.icann.org/x/MpLRAw * Clarification that this refers to the top level. At the second level, these strings have been identified and we can expect the same approach at the top level. * Clarification about difference DNS Label 1 and DNS Label 2: DNS Label 2 is only applicable at the second level. * Is the expectation that the variants of the IDNs on this list would also be blocked? * Depending on the script, some might have allocatable variants, as demonstrated on the following slides, but many will be blocked. * Slide 6 – Examples – randomly selected from list of strings ineligible for delegation. * In response to comments that the Cyrillic example should have variants, clarification that the mixed scripts are filtered out of the results for this table. * Suggestion to add disclaimer that screening out mix-script labels is not normative but an option. * Staff comment that, for the final Latin example the number should actually be lower than the number presented on the slide. The number should be 2,592 blocked variant labels. * Slide 7 – How to Address Variants of Strings Ineligible for Delegation – two options: * Option 1: Keep the list of strings ineligible for delegation intact and NOT to update it to include their variants * Option 2: Keep the list of strings ineligible for delegation intact and NOT to update it to include their variants. Prevent applications for all variants of the protected strings. Variants can only be applied for by the relevant organizations AND as part of a 'set' that includes the primary string on the list. * Slide 8 – Option 1 Rationale * Slide 9 – Option 2 Rationale * Slide 10 – Considerations – factors the EPDP Team takes into account may include risk analysis, operational impact, and costs vs. benefits. * Comment that these are good questions to ask. With respect to this question: “How would such measure be perceived, taking into account the careful deliberations of IGO PDP that took years to complete?” -- * If we take this as a baseline goal to honor the IGO PDP recommendations, we want to be careful not use those recommendations as a vehicle to extend the privileges already given and not interfere with those. Perhaps the solution is do nothing and put the burden on the IGO organization to object where they believe it is appropriate to do so on the basis of confusing similarity. This perspective seems to lean towards option 1. * Question about whether the lists are meant only to protect the label or to reserve the label so that the entity will be able to use it themselves. * If the latter, we would need to block variants as well. If someone registers the variant, it prevents an entity itself from getting the string. * Clarification that they are reserved, but there is an exception procedure where the “owner” of the string can apply for it. * Do the “owners” keep that right for all time? If so, we have to block the variants. Otherwise, we may be taking away that right. This perspective leans towards option 2. * According to the RZ-LGR all variant labels in a set must be allocated to the same entity. If we allow a variant label to be allocated to a third party, the NGO or INGO will not be able to apply for the original label. If we allow that, it will eventually break the variant set. * The problem is not whether the applied for string is confusable with the string ineligible for delegation. It is that if the variant is delegated, the string “owned” by the IGO/INGO will not be available to that entity for delegation. * At the time the list was created, the RZ-LGR did not exist and was not factored in. Because the list was developed by a rigorous process, by adding the variants, there is concern that we are creating additional rights. The strings already protected are protected based on treaties and existing lists. The variants have not been pulled from an existing list. While acknowledging the problem that if a variant is applied for by a third party, you are taking away the ability for the entity to get the primary if it’s not picked up in an objection process. * Is there a middle ground without adding to the list but also providing some protection for the variants? * It could be the responsibility of the NGO/INGO itself to be responsible for monitoring when a variant is applied for, but given the length of the list of variants this could be a challenge. * The way this would be implemented in the tool, it wouldn’t enumerate all possible variant strings. The tool could include a list of strings ineligible for delegation. When someone types in a label, they can see that it is variant of one of these labels. * Suggestion to keep the list as it, but for each string we compare each applied for string and its variants with this list. * Important that we are respectful of other policy recommendations from other groups. How will it be perceived if an application is blocked due to a variant relationship and there is a perception that rights have been extended as a part of this process? * It was noted that IGOs were given the opportunity to determine the names to be on that list and have reserved (at least at the second level) different versions of their name, maybe variants, maybe not * From one perspective, whether they considered variants or not, it is not really important. ICANN granted them the right to reserve their (main) label. In order to uphold that right, we need to block all variants. * The primary focus of the IGO recommendations is preventative – to prevent the use of these strings by other entities. The exception procedure is secondary. * At the second level, rules regarding INGOs are here: https://www.icann.org/resources/pages/igo-ingo-protection-policy-2020-02-18… * Summary: Group appears to be leaning towards option 2. Action Item 1: Leadership team to propose recommendation language to bring back to the EPDP Team for Charter Question E5 (Part 2). * Staff comment that the options could include additional color. Option 1 could still include protections under Legal Rights objections, GAC Advice, GAC Early Warning, etc. Option 2 would fully block the variants. Both could potentially offer protections, but to a different degree. Second reading of Group 2 outcomes * Group 2 outcomes: https://docs.google.com/document/d/1C6xKX87w2LtN4Is0mehuRgc1GqjKmbbhT14KbvU… * See above Google Doc for comments and suggested edits from RySG and response from ALAC regarding Rationale for Recommendation 2.6. * RySG wants to emphasize that the rationale should not expand on the recommendation itself. The recommendation is about technical and operational competence, the rationale should not make an editorial note on what that means. While acknowledging the overarching goal that ALAC is putting forward, this recommendation and rationale is not the right place to reflect it. ROs don’t manage or moderate content, disputing the idea that user experience is part of operational aspects. * ALAC perspective is that there is flexibility in the exact language and where it belongs. The idea ALAC wants to capture is that there is a continuous chain between registry, registrar, reseller, and registrant. ALAC will suggest way to close the gap between the different perspectives. * ALAC may want to expand on what is meant by consistent user experience. Is the idea that if a user goes to a domain under the primary label and one under the variant that they will see the same thing? This appears to go beyond what an RO can do. With this recommendation we are trying to set up the application process and what the potential applicant can define and expect in the process and be evaluated on. The focus is technical and operational in nature. Action Item 2: ALAC representatives to propose a path forward on Rationale for Recommendation 2.6.

1 0

Post Call | IDNs EPDP Team call | Thursday, 01 September 2022
by Devan Reed Sept. 1, 2022

Sept. 1, 2022

Dear all, All recordings for the IDNs EPDP Team call held on Thursday, 01 September 2022 can be found on the agenda wiki page <https://community.icann.org/x/MAYVD> (attendance included) and the GNSO Master Calendar. <https://urldefense.com/v3/__https:/gnso.icann.org/en/group-activities/calen…> These include: * Attendance (please let me know if your name has been left off the attendance list) * Audio recording * Zoom chat archive * Zoom recording (including audio, visual, rough transcript) * Transcript For additional information, you may consult the mailing list archives <https://mm.icann.org/pipermail/gnso-epdp-idn-team/> and the main wiki page<https://community.icann.org/x/uAPpCQ>. Thank you! Kind Regards, Devan

1 0

Meeting Invitation | IDNs EPDP Team | Thursday, 08 September 2022 at 13:30 UTC
by Devan Reed Sept. 1, 2022

Sept. 1, 2022

Dear all, The IDNs EPDP Team meeting is scheduled on Thursday, 08 September 2022 at 13:30 UTC for 90 minutes. Please click link to join the webinar: https://icann.zoom.us/j/94276275950?pwd=dG5hanFzMlpsYmh0NnFjTEQwOUV1dz09 <https://urldefense.com/v3/__https:/icann.zoom.us/j/94276275950?pwd=dG5hanFz…> Passcode: !!0tV0Wh&K For Audio only: One tap mobile : US: +13017158592,,94276275950#,,,,*5259149775# or +13126266799,,94276275950#,,,,*5259149775# Webinar ID: 942 7627 5950 Passcode: 5259149775 International numbers available: https://icann.zoom.us/u/adP1jJ0gRH <https://urldefense.com/v3/__https:/icann.zoom.us/u/adP1jJ0gRH__;!!PtGJab4!v…> If this is your first time with Zoom, please take a look here: Welcome to Zoom <https://urldefense.com/v3/__https:/gnso.icann.org/sites/default/files/polic…> Members, participants, and observers all have different access and participation directions, please read below! ALL: Before joining the call * Please send dial out requests to gnso-secs(a)icann.org<mailto:gnso-secs@icann.org> only * Please be sure you have read the ICANN Expected Standards of Behavior <https://urldefense.com/v3/__https:/www.icann.org/resources/pages/expected-s…> * Visit the Wiki agenda page: https://community.icann.org/x/MwYVD * Check your time zone: https://tinyurl.com/mrx4zjfr ONLY for Members and Participants * Please join via the above Main Zoom Webinar link and staff will promote you to panelist. * Please select Everyone, when posting to the chat in order for everyone to see and to be captured afterwards. Only for Observers: * Observers will have ability to view member chat and information shared in the zoom webinar room. * Observers will not be able to use chat or raise hands. Thank you. Kind regards, Devan

1 0

15 MINUTES **REMINDER** Meeting Invitation | IDNs EPDP Team | Thursday, 01 September 2022 at 13:30 UTC
by Devan Reed Sept. 1, 2022

Sept. 1, 2022

Dear all, The IDNs EPDP Team meeting is scheduled on Thursday, 01 September 2022 at 13:30 UTC for 90 minutes. Please click link to join the webinar: https://icann.zoom.us/j/94276275950?pwd=dG5hanFzMlpsYmh0NnFjTEQwOUV1dz09 <https://urldefense.com/v3/__https:/icann.zoom.us/j/94276275950?pwd=dG5hanFz…> Passcode: !!0tV0Wh&K For Audio only: One tap mobile : US: +13017158592,,94276275950#,,,,*5259149775# or +13126266799,,94276275950#,,,,*5259149775# Webinar ID: 942 7627 5950 Passcode: 5259149775 International numbers available: https://icann.zoom.us/u/adP1jJ0gRH <https://urldefense.com/v3/__https:/icann.zoom.us/u/adP1jJ0gRH__;!!PtGJab4!v…> If this is your first time with Zoom, please take a look here: Welcome to Zoom <https://urldefense.com/v3/__https:/gnso.icann.org/sites/default/files/polic…> Members, participants, and observers all have different access and participation directions, please read below! ALL: Before joining the call * Please send dial out requests to gnso-secs(a)icann.org<mailto:gnso-secs@icann.org> only * Please be sure you have read the ICANN Expected Standards of Behavior <https://urldefense.com/v3/__https:/www.icann.org/resources/pages/expected-s…> * Visit the Wiki agenda page: https://community.icann.org/x/MAYVD * Check your time zone: https://tinyurl.com/2p8amrz2 [tinyurl.com]<https://urldefense.com/v3/__https:/tinyurl.com/2p8amrz2__;!!PtGJab4!4cWY5xE…> ONLY for Members and Participants * Please join via the above Main Zoom Webinar link and staff will promote you to panelist. * Please select Everyone, when posting to the chat in order for everyone to see and to be captured afterwards. Only for Observers: * Observers will have ability to view member chat and information shared in the zoom webinar room. * Observers will not be able to use chat or raise hands. Thank you. Kind regards, Devan

1 0