NOTES | ccPDP4-DS | 12 April 2022 (13 UTC)
NOTES | ccPDP4-DS | 12 April 2022 (13 UTC) 1. Welcome and roll call Welcome by Chair Anil. Apologies by Vice Chair Svitlana 2. Administrative matters a. ICANN74 sessions (full WG meeting and update to community) 2 sessions for ccPDP4 in ICANN74 (hybrid, in The Hague): * Policy Session: Consultation with broader community on the results to date First 30 min for ccPDP3-RM, remaining slot for ccPDP4 Tuesday, 14 June | 11:15-12:30 UTC No overlap with EPDP session, to avoid conflict for Anil * Full WG meeting by ccPDP4: kick-off the stress-testing. Tuesday, 14 June | 15:30-16:30 UTC Note: please pre–register for ICANN74. 8 June is a hard deadline, if you wish to attend ICANN74 (either remotely or in person) b. Action items i. Illustrate the findings ( see below item 3 b, c and d) 3. Review current practice (2nd reading) Bart: see slide deck from last meeting Slide 3: shows the extent of the confusing similarity procedures. More details available here: https://www.icann.org/resources/pages/fast-track-2012-02-25-en. BG, EU, GR. were considered to be confusingly similar. They went through the EPSRP. .eu in greek had to go through the risk mitigation panel. Anil: also evaluate the blocked strings, and the strings waiting for allocation, in EPDP. Will ccPDP4 do the same. Regarding risk mitigation. Initiated only after the requester (cctld manager) submits info to icann. Once the requested string is not passing the process Bart: both EPSRP and the risk mitigation, are initiated by the requestor/applicant. The 1st panel looks at the selected string. That panel determines the string is confusingly similar to (potential) other strings. The requester then decides to use the EPSRP (or not). Main difference between the FTP and the future IDN selection process and new gTLD process. The FTP and idn selection process are ongoing. Available since 2009. There is always the option to adjust the application, and the selected string. Sarmad: Please note that Risk Mitigation Process only applicable in one condition (and not more generally): If the DSP or EPSRP evaluation has determined that the requested string is confusingly similar in uppercase only (and not in lowercase). Bart: EPSRP uses a different methodology. At the request of the applicant or IDN ccTLD manager. The risk mitigation also at the request of the applicant. If you compare current practice under FTP with what happens under new gTLD process, although they use the same criteria of what is considered confusing similarity, are different/ Regarding Question 1: you have to compare to something. A selected string and its variants. Basis for comparison is more limited under the FTP. looking at individual characters? Or combined set of characters? EPSRP always looked at the combination. c. Basic overview of current process and subprocesses d. Results special cases: https://www.icann.org/resources/pages/epsrp-reports-2014-10-14-en e. Results to date EPSRP: https://www.icann.org/en/system/files/files/epsrp-european-union-30sep14-en.... f. Results to date Risk Mitigation Evaluation: https://www.icann.org/en/system/files/files/eu-greek-mitigation-measures-28f... SSAC and ccNSO discussed risk mitigation. This resulted in the update of the FTP. The report on how the SSAC and a ccNSO WG dealt with this, and their considerations. It builds on the principle that confusing similarity is about risk management. Confusing similarity panel in first instance: DNS Stability Panel. Combines Technical Panel and Similarity Review Panel Anil: how long does the process take for the various panels? Bart: first let’s illustrate the differences. Different methodology. Open process. If the selected string is considered confusing similar, it can be amended. EPSRP Executive summary. Sarmad: EPSRP may take up to 1 year. Risk mitigation never done before. Could be multiple months. Some dependency on the applicant to develop a plan, the review etc. First looking at strings, are 2 strings similar or not? EPSRP makes it more objective. In the 3 cases, the target string and other strings in upper and lower case, options were chosen. Experiments at university in Michigan. Experimental technique. Details are in the report. Panel of experts, evaluated the results from the experiment. Bart: resource intense, duration. This was 2nd and final reading of the current processes and sub-processes. Anil: thank you to all for the clarifications. We approach the top of the hour. Suggests we continue the discussion at the next meeting 4. Discussion on CS: a. Should Confusing Similarity review be maintained? What’s the rationale? b. Should criteria to assess confusing similarity be amended? Criteria: String confusion exists where a string so nearly resembles another visually that it is likely to deceive or cause confusion. For the likelihood of confusion to exist, it must be probable, not merely possible that confusion will arise in the mind of the average, reasonable Internet user. c. Should the 3-step approach (first review, EPSRP, Risk mitigation review) be maintained or could process be simplified? Bart quickly introduces the topic Sarmad: one more element that is now available. Work through the script-based panels for RZ-LGR. When they did variant analysis, they looked at similar characters as well. They left additional data in their proposals, very often. It is useful data, coming directly from the script community. 5. Next meetings 19 April VM SG | 14:00 UTC - 90 min duration 26 April CS SG | 13:00 UTC 3 May VM SG | 14:00 UTC - 90 min duration 10 May CS SG | 13:00 UTC 6. AOB None 7. Closure Thank you all. Bye Joke Braeken joke.braeken@icann.org
participants (1)
-
Joke Braeken