Dear all, Please find below the notes and action items from today’s meeting on Thursday, 21 April 2022 at 13:30 UTC. Kind regards, Ariel, Steve, and Emily Action Items: Action Item 1: Leadership team and staff to consider next steps on data collection regarding variants of reserved names, including blocked variants. Notes – IDNs EPDP Call – 21 April 2022 Welcome and Chair Updates * The last two weeks have focused on unwrapping the string similarity review as it relates to variants. The leadership team recognizes that there are different perspectives on this topic. * Staff sent an email to the mailing list asking members to provide a written response to the three questions provided. We will likely discuss this input on 28 April and try to reach agreement on the preferred levels. * Once these discussions are complete, we will transition to discussing other elements of the evaluation process. * The draft letter to CJK Generation Panels is ready for final review by the Working Group. This will be sent to the group for sign off before it is distributed. ccPDP4 Update * ccPDP4 launched in January 2020. The main areas of focus is to evolve the fast track process for IDN ccTLD strings. ccPDP4’s focus areas are: selection of IDN ccTLDs, management of variants, and the review process for string similarity. * The fast track process has an extended process similarity review panel. This is a second tier of string similarity review and has been used a few times. The WG is looking at that extended process. * The variant management work within the ccPDP4 is of particular interest to the EPDP. * The direction of the two groups is not identical in some respects. These areas will be highlighted in this presentation. * Topic 1: Requirements for a string and its variants – The ccPDP4 adopted RZ-LGR as authoritative source, as did the EPDP. * For IDN ccTLD strings, there are two tiers of requirements: * Tier 1 requirements (overarching) for IDN ccTLD strings: 1. The string has to be a meaningful representation of the country or territory (this is not present in gTLDs) 2. The string must be in a designated language from that country or territory – it does not dictate the languages (this is not present in gTLDs). * Tier 2 requires the string must pass RFCs, stability panel, etc. The RZ-LGR is used as a proxy for demonstrating compliance with IDNA2008 and security and stability concerns incorporated by the RZ-LGR. * When variants need to be calculated for IDN ccTLD strings they are likely subject to the same Tier 1 requirements. * Question: Will the level of divergence between the two groups be a concern when the recommendations reach the Board? * The Board is not prescribing that the policies are identical. In terms of the specifics on these items, looking through the lens of geo, communities, brands, etc. there are commonalities. There are more requirements for these strings. We have not yet converged on the details of the requirements for these special types of strings. If we apply different rules for the label vs. its variants, then it might not be consistent with the ccPDP recommendations. * Topic 2: The number of variants and whether there should be a limit -- both groups seem to be converging on not setting an arbitrary ceiling of the number of variants that can be allocated. * Topic 3: Likely changes to the RZ-LGR that would make a delegated string not in conformance with the RZ-LGR. The ccPDP is leaning towards grandfathering all existing TLDs, with one exception: If the only way to address a potential security threat is to not grandfather. The WG has not yet gotten into what could be the nature of the security threat. * The approach of the two groups appears to be fairly consistent. * Question: On the grandfathering piece, we have extensively discussed whether there would be exceptions to grandfathering and if so, what they would be. Are the liaisons relaying the discussion in this group to the ccPDP? * Response: They have not gotten into these deeper conversations. The discussions have been fluid. * Because of the Bylaws, the ccNSO policy making seeks not to dictate how operators manage their second level domains. Some ccNSO representatives do not feel that the ccPDP should look at the second level and the recommendations coming out of the Staff Paper on the second level. The variant sub-group is looking at the second level only from a technical perspective – what are the considerations the ccNSO might want to explore and how might that challenge ccNSO policies? For example, harmonization of IDN tables. * There are some nuanced differences between scope of policy development between the two groups. The goal is harmonization to the extent possible, acknowledging that it there may be challenges in some cases. Reserved Names * Overview of Charter Question E5 – slide 7 * Background on the 2012 round -- Reserved Names vs. Strings Ineligible for Delegation – slide 8 * Recent developments – recommendations from SubPro & Protection of IGO and INGO Identifiers in All gTLDs PDP and impact on the next version of the AGB – slide 9 * Question: There are three additional categories of reserved names: numeric, single and two character ASCII, single character IDN strings. How is this covered? * Response: There is a list of reserved names and there are strings ineligible for delegation. The categories mentioned in the question are covered elsewhere in the AGB. Staff will investigate and share details. * Question: Regarding IGO/INGO identifiers – today the status is that they are not available for registration at the second level, but in subsequent rounds they will also be ineligible for delegation at the top level? * Response: Confirmed. * Discussion questions – slide 10 * For discussion regarding reserved names: Is there a need to update the reserved names to include any possible variant labels? * Question: The status of IDN test strings – are they still in use? * Response: They are not currently delegated but they remain reserved: https://www.iana.org/domains/reserved. The 2012 AGB noted that there would be translations of example and text. Staff is researching to make sure the list ended up being limited to the 11 IDN “test strings”. * Question: Is there a reason to make those IDN test strings available? * Response: That is not the question for this group. This group may consider whether any variants of those strings should also be protected in addition to the strings already on the reserved list. * Comment: For the reserved names, we should block variants once the reserved names are checked for string similarity. * Comment: All the strings in the reserved names list in English/Latin Script. If the script doesn’t have allocatable variants, what are the consequences of the previous suggestion? * Clarification: The variants might come into play in string similarity. This may come back to the questions about whether string similarity review should include blocked variants. * While there are zero allocatable variants, there is still be a possibility for blocked variants. They should have been covered by the string similarity check, but they should also be included as a clear definable set of labels that are included with the reserved names. * Question: With the list of reserved names we have, has there been any calculation of what the variants are and how many reserved names that would create? * Response: This calculation has not been run but for the Latin script, the blocked list could be generated. The list could be in the thousands or tens of thousands. Usually if the label has certain vowels and about 5-6 characters it can generate a large number of blocked variants. * Comment: The number of reserved names and blocked names shouldn’t be the only criteria we should think about. If they are blocked, no one would want that. That is not hurting the market. Consider the concept of atomicity of variants. If we can preserve the atomicity without hurting the gTLD market, we should lean towards a more conservative approach. * Comment: We are potentially doing this for the long run, not just the first round but also future rounds. More strings may be added to the list and we need to consider this as well. It may not hurt to be conservative until another PDP decides to loosen the reigns. * Comment: The number of variants is of no concern. If we state that all variants are blocked, you just run the LGR tool to check if there is a variant relation. The LGR tool does not care whether the number of variants is 2 or 20,000. * Staff observation: We are exhausting the ability of the group to have a discussion on the principle level and might need data. If there is going to be a large number of variants of reserved names, how will security and stability benefits weigh against the complexity of implementing. Action Item 1: Leadership team and staff to consider next steps on data collection regarding variants of reserved names, including blocked variants. * For discussion regarding strings ineligible for delegation – Would extending preventative protections for variants * Circumvent the careful work of the IGOs PDP? * Extend rights beyond those that are expressly identified in relevant treaties? * In other words, are variants for these strings in scope for the IDN-EPDP? * Comment: We are using the term “reserved” for different things – we may need to find a way to distinguish between reservation at the top level and the second level. * Additional clarifications regarding strings ineligible for delegation: Going forward, there will be an exception procedure that would allow a party to apply for their own strings. In addition, as a clarification, these strings ineligible for delegation would not be included in the string similarity process. It is protection for the precise terms on the list and only preventing delegation of those precise strings. * Comment: It is important to make the distinction between reserved names and strings ineligible for delegation and consider that different treatment may be appropriate for the two groups. Strings ineligible for delegation are limited to exact match, so we may not be in a position to extend these rights. * Question: What needs to be considered and what does not need to be considered in looking at these questions? * Comment: On reserved names, the principle of atomicity may be a consideration, but it’s unlikely that these blocked variants are stings that people want to apply for. One consideration is the scope of the problem, but it’s not the only consideration. It is important to distinguish between the details of a reserved names vs. strings ineligible for delegation. * Comment: We could potentially look at the ineligible for delegations through a different lens. Given the sensitivities around this topic and the finite nature of this list, is there an argument/rationale for protecting variants? If not, the team may have an answer. * Question: What happens if an IGO applies for its string? Are there variants that they could potentially apply for? * Comment: If we don’t protect variants and the IGOs apply for their names, the first-come first-serve rule may not create a fair situation and the IGOs potentially won’t be able to access their variants. * Comment: If we want to reserve/block those labels for those entities, we will have to block the variants, too.