Dear all, Please find below the notes and action items from today’s meeting on 29 November 2022 at 14:00 UTC. Kind regards, Ariel, Steve, and Emily Joint Meeting: ccPDP4 IDN and GNSO IDN EPDP 29 November at 14:00 UTC High-Level Notes and Action Items Welcome to joint meeting * Agenda review Why joint session? * Slide 3: Board asked ccNSO and GNSO to coordinate their policy development efforts with respect to variant management. The respective working groups are making progress on work related to variant management for the confusing similarity validation process (ccPDP4 term) and string similarity review (GNSO EPDP term). ccNSO Perspective on Confusing Similarity and Variants * Slide 5: Scope of ccPDP4 is review, overhaul and completion of 2013 recommendations on the selection of IDN ccTLD strings. * Slide 6: Overhaul 2013 recommendations is needed to align with curent procedures under the Fast Track process (which is on-going). * Slide 7: Overhaul Confusing Similarity Validation: Goal and Criteria * Slide 8: Overhaul Confusing Similarity Validation: Base of Comparison * Slide 9: Overhaul Confusing Similarity Validation: Base of Comparison Rationale * Question: On the GNSO side, applications for IDNs will be part of the new gTLD application process. These applications will come in as part of standard rounds that also include ASCII applications. There may be up to 2000 or more applications in a round. The recommendations seek to provide guidance on processes that will handle such circumstances. How and when will applications be submitted on the cc side? * Response: Once the ccPDP4 completes its work and policy is confirmed, the application process will be kicked off. The timeframe will likely be different from the GNSO timeframe. GNSO Perspective * Slide 11-12: Background -- EPDP Team focused its discussion on variants’ role in the String Similarity Review. It considered three possible levels of comparison, and then put forward a preliminary recommendation on a “hybrid model.” * Slide 13: Three Levels of Comparison * Slide 14-15: Recommendation: Hybrid Model – note that this recommendation has not yet been finalized pending analysis of input from ICANN org on the operational implications of the recommended approach. * Slide 16: How Does the Hybrid Model Work: Arabic TLDs Example – this example includes applied-for primary strings, allocatable variants and blocked variants. * Slide 17: How Does the Hybrid Model Work: Arabic TLDs Example – each number represents a comparison that will take place. * Slide 18: Summary: Arabic TLDs Example – demonstrates the potential outcomes of such a set of comparisons. * Slide 19: Rationale for the Hybrid Model – seeks to strike the balance of reducing the total number of comparisons while mitigating the risk of failure modes. * Slide 20: Relevant Background for Consideration of Hybrid Model -- RFC 5891, RFC 6912, SAC 089, Staff Paper. * Slide 23: Misconnection: Potential Consequences – Misconnection may be more problematic than denial of service and cause more harm to the user beyond confusion and frustration, including becoming a vector for DNS abuse. · Question: ccPDP4 focused on misconnection as the primary problem that needs to be addressed from a security and stability perspective. They also looked the “no connection” (denial of service) issue. The ccPDP4 decided that it was not necessary to focus on this, given that it is not necessary to build a process around a potential mistyped or misremembered string. To what extent did the IDN EPDP decided to include this as a point of focus? · Response: IDN EPDP also considered the misconnection risk as more prominent and requiring mitigation compared to denial of service. This seems consistent with the ccPDP4’s conclusion. · Slide 26: Ongoing Deliberations on the Hybrid Model – general support from the EPDP team for the hybrid model, but some reservations have been expressed. EPDP Team requested input from ICANN org on the operational implications of this model to help the EPDP Team to understand impact of recommendations. · Question: What is the ccPDP’s policy recommendation language likely to look like? It may be acceptable for the policy recommendations to be different given that they address two different processes. · Response: The ccPDP4 has shared a document containing core recommendations on confusing similarity. One of the major differences between the two processes is that the ccPDP4 recommendations will feed into a process that is ongoing (as opposed to in rounds). A second major difference is that the cc process is more focused/limited, as summarized on slide 8. The focus is on the selected string, and its requested, delegatable variants. Delegatable Variant = Allocatable Variant that is meaningful representation of name of territory in designated language and script in which designated language is expressed. The pool of potential applicants is known and limited in the cc process. On the GNSO side, it is unknown how many applications will be received and for labels in which scripts. · The fundamental approaches seem to be the same: use of the same definitions, focusing on the potential risk of misconnection, etc. Because of differences in the processes, the specific recommendations may be different, but these differences appear to be appropriate. · As long as the recommendations are not inconsistent, there should not be any issues. If there do turn out to be inconsistencies, these will need to be explained to the Board. · Current timeline for ccPDP4 is to produce its Initial Report prior to ICANN76. · GNSO members are interested in the upcoming ccPDP4 stress test exercise, which will tentatively take place in mid-January. This will include developing scenarios and checking to see how the recommendations play out under these scenarios. The ccPDP4 will determine whether any adjustments are needed to the recommendations. Action Item: ccPDP4 to provide details of stress test sessions to IDN EPDP to allow IDN EPDP Team members to attend. Wrap-up: further coordination needed? * It was agreed that it may be helpful to meet again after the ccPDP4 has completed the stress test and before the two groups submit their respective Initial Reports (ccPDP4 tentatively to deliver Initial Report prior to ICANN76, IDN EPDP tentatively to deliver Initial Report in April 2023).