Dear all, Please find below the notes from today’s meeting on Thursday 30 September 2021 at 13:00 UTC. Best regards, Steve, Marika, and Emily Action Items: None Notes – IDNs EPDP Call – 30 September 2021 Welcome & Chair Updates * Chair transition: Donna will transition to Chair in the next meeting. Edmon will remain on the calls to support Donna through the transition until the end of October when he joins the ICANN Board. * ALAC reps had requested an info session on the RZ-LGR. This is likely something that would benefit the whole group. This will be scheduled for next week’s regularly scheduled call. * Session should cover procedural elements that inform deliberations on the Topic A charter questions and help the group to understand whether a challenge mechanism makes sense at a practical level. * Request: include a demo of running a string through the RZ-LGR rules to determine if it’s valid or invalid; also go through an example with variants. Make sure that members understand how it works on a practical level. * ICANN org can prepare additional presentations if additional questions come up in the future. Continue deliberations on Topic A: Consistent definition and technical utilization of RZ-LGR – question a3 * Recap from last week’s discussion of a3: The WG is considering whether a challenge mechanism should be part of the New gTLD Program. Even if the challenge is triggered as part of the program, it might still need to go through the RZ-LGR process. * Review of the text of question a4 in the charter. * Comment: Important to separate a3 and a4 because the group may want to handle them differently. * Clarification: For a3: Suggestion that this should be treated like any other DNS stability challenge. If they apply for a string that is found to be invalid, it should be run through again. If still found to be invalid, it will be kicked out and they will have to work with the RZ-LGR and they will need to apply again in the next round. If there is no RZ-LGR for that script, they should still be able to work through the application process and then the application is put on hold. This is different from a situation where RZ-LGR exists but the string is found to be invalid, it can’t be resolved within that round. * Comment: Agree that if there is no RZ-LGR, it should be possible to put the application “on ice.” There should be text that says that the process should not be unnecessarily delayed. For cases where the RZ-LGR exists but the string is invalid, it should be possible to update the technical part of the application in the same round. * Comment: In cases where the applicant challenges the evaluations decision that a string is invalid, if it’s found that there was a mistake and the RZ-LGR needs to be updated, the string should also be “put on ice” until the issue is resolved and the application should be able to move forward as part of that same round. * Comment: At this point, we don’t know how frequent the rounds will come. When rounds occur regularly it will be relatively easy to punt an application to the next round. Until that time in cases where a review of RZ-LGR is triggered as the result of a challenge, they can wait until the results of that process with the possibility of proceeding. * Comment: If a string is found to be invalid, the applicant challenges the result, it’s re-run through the process and still found to be invalid, the applicant can go through the process with the RZ-LGR panel. This could be a long process. If that application is on its own (not in a contention set), then maybe it can go on hold for a long time. But if there are other applications in the contention set, they will also be on hold for a long time, too, which is bad for predictability. SubPro recommendations anticipate continuous rounds. If this is adopted by the Board, application opportunities will happen on a regular basis. We should let the other applications in the contention set move forward and the single applicant will need to reapply. * Comment: There should be a test tool for the script so potential applicants and others can test a string ahead of time to see if it might be found to be valid. * Response: There is a tool already at https://lgrtool.icann.org/b/. This tool was developed in a different context to support Generation Panels to develop their LGR proposals, but it can still be used to validate strings in the RZ-LGR. There is an additional tool in the planning phase that is expected to be more focused on the applicant and the application process. * Question: Where no script exists, how long would it take for a script to be put into the RZ-LGR (a4)? If a challenge needs to go through the RZ-LGR process, how long would that process take (a3)? * Response: As part of the data and metrics requested by the WG, org is working to provide metrics that can inform question a3 – information related to the feasibility of a challenge mechanism. The timeframe depends on the complexity of the work that needs to be done. It could potentially take as long as the quickest addition of a new script, around a year or more, but this will be discussed more on the next call. * Question a3 addresses applications for a string in a script that is already part of the RZ-LGR and the string is found to be invalid. Question a4 is the question about applications for strings in scripts that are not in the RZ-LGR. It may be helpful to think of these as two distinct issues. * Comment on a4: The big question is whether we should accept applications in strings that are not yet in the RZ-LGR. SubPro outputs state that we should but this group will also need to form a position. * Comment: For a4, SubPro considered this issue. They considered the paper the technical group. SubPro concluded that they should be able to apply and the application should be processed to the extent possible and go through contention sets. They should not be barred from applying. This WG would need a compelling reason to overturn that. * Comment: We should wait for Sarmad’s presentation before the group takes a position on whether challenges should be possible. * As the group becomes more familiar with the specifics of the process, members may feel more comfortable taking a position. * Introduction to a5: In the RZ-LGR, some languages have a situation where by permutation many allocatable variants could be possible from a technical and linguistic perspective. Many variants could potentially be put into the root. In reality, there are usually just a few variants that are the most useful. Should we set a ceiling in policy to increase predictability? * Question: Why is there an assumption that all of the variants have to go into the root, as well? * Technically and linguistically they are generated as allocatable. That doesn’t mean that they are delegated. It may be the case that most of them don’t need to be.