Dear all, Please find below the notes from today’s meeting on Thursday, 6 January 2022 at 13:30 UTC. Please note that there are two action items for EPDP members from this call: * EPDP Team members to frame specific questions for the SSAC members and share on the mailing list by Monday, 10 January. * EPDP Members to give further thought to the possible paths for addressing charter question A7 and share additional input on the mailing list. Kind regards, Ariel, Steve, and Emily Action Items: Action Item #1: EPDP Team members to frame specific questions for the SSAC members and share on the mailing list by Monday, 10 January. Action Item #2: EPDP Members to give further thought to the possible paths for addressing charter question A7 and share additional input on the mailing list. Notes – IDNs EPDP Call – 6 January 2022 Welcome & Chair Updates · SSAC members will join the EPDP team on the call one week from today. · Reminder that this will be a sub-set of SSAC members only. Prep for session with SSAC members (see early input written from SSAC here<https://community.icann.org/download/attachments/176621266/SSAC2021-09.pdf?v...>) * The possible topics to discuss with SSAC members include their responses to A1, A2, A4, and A5, as well as their broader comment: “currently there is no DNS protocol solution that enforces equivalence (or the same behavior) of variants in the DNS. Policy makers need to understand this crucial limitation, so as not to design policies that attempt to force such equivalence.” * A1: Looking at this response in conjunction with the SSAC response to charter question a4, there may be a conflict in the text. It may be necessary to clarify what “Root LGR procedure” is intended to mean in SAC060: “The root zone must use one and only one set of rules for the Root LGR procedure.” * In SSAC’s response to A4, it sounds like SSAC suggests dual validation method where an application is valid based on IDNA2008, there should not be a reason to prohibit the application. This may open a loophole. It will allow a path for a single code point not in the RZ-LGR as long as it is IDNA2008 compliant. * A2: It may be helpful to clarify the recommended “analysis of the delegated variant labels in ccTLDs against the most current version of LGR.” Did they mean “synchronized TLDs” or perhaps “self-identified variants TLD labels by the former gTLD applicants”? Action Item #1: EPDP Team members to frame specific questions for the SSAC members and share on the mailing list by Monday, 10 January. Continued Deliberations on Topic A: Consistent Definition and Technical Utilization of RZ-LGR (Topic A working document: live version [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1I9dSd7alSvz9Z...> in Google Docs, archived versions in MS Word on wiki<https://community.icann.org/display/epdpidn/Working+Documents>) Charter question A9 * Summary of previous discussion: There does not appear to be a strong opposition to these definitions, but there could be an opportunity to streamline the list of five definitions into three. Allocated status has specific meanings to ccTLDs. Sarmad has provided examples that a ccTLD may remain in allocated status for a period of time before it has a delegated status. We are mainly discussing the gTLD definitions and context in this EPDP, so the Team may want discuss further whether to take ccTLD context into account. * The EPDP previously discussed different paths from one status to another. There was some discussion of path 5 and some examples where gTLDs and ccTLDs were terminated/removed from the root. The group may want to discuss further if it wants to highlight this path. * For discussion today: Are there any concerns about the proposed definitions on slide 5? * Question: On the withheld same entity state – what about the cases that are withheld but not withheld same entity – are they covered somewhere? * Response from staff: These definitions from the staff paper stem from the definitions in the integrated issues report. “Witheld” was in the older set of definitions. The “withheld same entity” superseded “withheld.” We may still need to discuss whether “withheld same entity” applies to existing TLDs and their variants. * If there are “withheld” cases that are not “withheld same entity”, under what status are they covered? * Comment: the definition of “withheld” should be brought forward from the old list and included with the new list, so that they are all in one place. * Comment: In everyday speak, people tend to use allocated and delegated to mean the same thing. We need to make sure the definitions cater to all users, not just those with advanced technical knowledge. We should come up with some other term to differentiate the delegated from the allocated in this list. * Response: Withheld may have different meanings in different parts of the community and in the industry. We need to be clear that these definitions are intended for a specific purpose as it relates to IDNs. If we call that out, it will be clearer for everyone. * Staff comment: When the staff report was being written in the context of other work, it was noted that the reference back to “withheld” may no longer relevant in the current context. One of the recommendations in the variant recommendations paper was that all of the variants should go to the same applicant, so rather than “withheld”, “withheld same entity" was used to reinforce that point. These definitions could be simplified to be less technical. * Comment: It’s ok to have skeletons of definitions now, but we may want to finalize the definitions later after the group has explored all the possible scenarios. * Comment: We need to ensure in the Final Report that we are consistent. There has been work done over a number of years to develop the definitions that we are reviewing, so we should take this into account. * Comment: Support removing reference to withheld” if “withheld same entity” is the only case possible. * Summary: Preliminary agreement to go forward with these definitions, making clear that the definitions are intended to serve a particular purpose. * Question: Are we going to discuss the implications of these definitions? For example, what does “allocated” implicate, for example with respect to fees? * Response: We will pick up on some of these issues in the rest of our work, but it may not be completely within our scope. These definitions will support EPDP deliberations and future work on IDNs. * Staff comment: When the terms were being drafted in the paper, the reason for defining the terms was to ensure that when the community is discussing these issues, they have a common understanding of what each term means. One additional term we use that is not included in the list is “reserved status” for reserved words. * Question: Do we need to differentiate between “reserved” or “withheld” or even “blocked”? Once might confuse the terms. We may also need to define terms like “variant” and “bundle” and other terms that come up as we go through the charter questions. * Response: The EPDP Team may consider other terms and their definitions as a “parking lot” item. Charter question A10 * Are there any additional items that the group wants to discuss with respect to status transitions? * Comment: we can’t see the implications until we do the rest of the work, but what we have now is fine for the moment. Charter question A6 * Leadership team is working on a draft recommendation. This will shared on list next week. Charter question A7 * Summary of previous discussion: The EPDP Team has recognized that the Han script is the only candidate for single character TLDs - Languages: Chinese, Japanese, Korean. It may be appropriate for the GPs working on these languages to make a recommendation regarding the criteria/list of possible single character TLDs. * We haven’t seen any recommendations or guidance from these GPs in the past on this topic, noting that they were not necessarily expected to provide any as part of their work. * If the EPDP wants to recommend that the GPs do this work, the EPDP may want to informally reach out to the GPs first. * Suggestion: We don’t know yet if applicants will apply for single character TLDs and if so, which ones are of interest. It will take a lot of work to conduct the analysis upfront. Rather than doing the work upfront, if an applicant applies for single-character TLD, they pay for an analysis as part of the application process that identifies security and stability risks, string similarity concerns, etc. * Staff comment: If this is something we want to send to GPs, we may want to establish bounds – we want to be clear about what we are asking GPs to do and where we divide the work between them and the string similarity review. * Staff comment: It is possible to do as part of the application process. If it is done beforehand, however, it is a more predictable process. * Question: Is there any previous experience we can draw on from the ccNSO that could inform this discussion? * There are two tasks: 1. Identify scripts in which single character TLDs may be appropriate 2. Identify code points that are appropriate. Is the Team comfortable with answering the first part? * Response: It seems that the EPDP Team can answer the first part but may not be in a position to address the second part. * Staff suggestion: Possible middle ground – a group with the technical capacity could suggest clear rules for what should not be allowed. Characters that are still possible can go through the proposed follow up process. For example, single stroke characters may be more confusable than multi-stroke characters. That may allow applicants to get closer to an application that will go through. * Summary: EPDP Team to explore some of the additional suggestions raised today. Action Item #2: EPDP Members to give further thought to the possible paths for addressing charter question A7 and share additional input on the mailing list. AOB * Monthly project package has been sent to council for this month. * Leadership team is reviewing the order in which we are considering the charter questions and considering whether we need to adjust the order. * Leadership is also revisiting targets for the next 12 months, including how to leverage ICANN meetings to make progress. This will be discussed further with the EPDP Team.