NOTES | ccPDP4-IDN | 20 December 2022 (14 UTC) 1. Welcome Welcome by Kenny 2. Administrative matters a. Action items None See item 3.b. b. Meeting GNSO EPDP Hadia: discussed inconsistencies between ccPDP4 and IDN PDP. Mentioned there is divergence, and not inconsistency. * Blocked labels * Objections, depending on how CS outcomes happen Bart: 2 questions for Hadia. 1st question * You mentioned objection. What do you mean? Hadia: something like the review Bart: procedural process questions Hadia: gnso discussed what objectors can object to. Ariel: It’s the objection process in the New gTLD Program, including string confusion, legal rights, limited public interest, and community objections Confirmed by SubPro. Already existed in the 2012 round. Bart: have more in dept conversation about this Bart: 2nd question for Hadia * You mentioned the letter from the board. consistency Bart: I recall they need to be “coordinated”, not necessarily the same. What was meant by consistent and divergent Ariel: the ICANN Board further requested that the GNSO and ccNSO keep each other informed of the progress in developing the relevant details of their policies and procedures to ensure a consistent solution for IDN variant gTLDs and IDN variant ccTLDs. Consistent solution. Not necessarily “the same” Bart: agree. Same understanding Hadia: So I believe the two solutions are consistent but they do differ because of the difference in nature between gTLDs and ccTLDS c. Progress full group Kenny provides update See discussions from last week. Bart: regarding the Review Mechanism (RM). Refers to the RM developed by ccPDP3. The full group met on the 13th. The suggestion is to continue with the full group on 17 Jan. CS could then meet on 24 Jan. otherwise the full group would have 5 weeks between the meetings. Also, they are nearly done with the review. We will start end January with stress-testing. Possibly first week of February. The full group can work on the policy doc itself, and the full group or a subgroup can focus on the stress testing. Kenny: note that 31 January is Chinese NewYear. Bart: ok! Will check. This is a major holiday 3. Review CS document a. Updates after 2nd reading i.Comment of reference to SAC089, page 27 and footnote 15 Page 26. Bart: use of “validation”. Discussed on the last call. Evaluation should be validation as well Page 27. Replace standard for confusability with standard for visual confusing similarity Do you agree to replace the term? No red marks Jaap suggested to add a footnote to SAC089 Far more extensive concept than visual similarity. We focus on those here, and how to avoid them. Good to make this point. Do you agree? No red marks Page 35. Use of the word “valid”. Bart checked it against the FAst Track Process implementation plan. Suggestion is to keep it in, as suggested last time. Will delete the comment field. Jiankang proposed to include a person with a deep knowledge of the script which is under evaluation by the 1st panel. Similarity Evaluation Panel. Relatively small panel, and there might be a request for a string in a language, unfamiliar to the panelists. Suggestion is that either the requestor, or the panelist, could request to add such a person. No questions or comments by the group Today: just temperature of the room Q1. Do you agree to move the text to this specific section? Hadia: when is the panel formed? And for how long the same panel? Bart: That is a matter of implementation. Assumption: standing panel. Pool of panellists. The more we add here, the harder it will be to get people. Hadia: panlists are less familiar with the language or script Panelists with diverse experience and knowledge in languages and scripts Bart: extreme answer. Shows the issue at stake. Depends on the standard you are using. Approx 7000 languages, and 100s of scripts. Impossible to find someone familiar with string confusion, and the various languages. Experience under the Fast Track. 1st evaluation and the panel during the technical evaluation are the same. They need knowledge about the RFCs etc. leave it open for icann org to implement Hadia: understand. Bart: current structure still works and functions properly. Q2. timing of the request to appoint a specific panelist No red marks Hadia: duration on panel? Bart: matter for implementation You agreed with the principle. Does the sentence capture the notion that this extended panel will conduct the CS evaluation, and there is no room for misinterpretation? No red marks Finally, around duration. Typos to be corrected ii. Discussion impact of CS requested variant (page 39, 40) Into the weeds of the CS review See text marked in green. This was discussed twice. Hadia: would it include only the requested variants and the label itself? Bart: it would include the delegatable variants. (meaningful representation of the name of the territory). Proposal: in future a ccTLD manager could request the delegatable variants. They are only available for that specific string, and for the IDN ccTLD manager. Mirjana: in process of deciding what will be offered to the requestor, you have the primary string and some variants. No allocatable variants should be allowed, if there is CS. afterwards the situation is clear Bart: question here is. If you have a primary string that is CS, all the requested strings go. Now you have a selected string. Now you also requested allocatable variants. All or some are CS. if this is CS, should therefor the selected primary string be cancelled as well? Mirjana: no. Pitinan: in this case we consider it a sub-case for now. First case where panelist has already been delegated. Other subcase. (inaudible) 2 subcases: * Primary string is known * Primary string has already been delegated Bart: difference? Pitinan: not sure yet. Line of thinking. Bart: could be confusing. Decision tree. Hadia: agrees with Pitinan. 2 categories * Existing strings * Non-existing strings. Easy. applicant could apply for primary string, and all delegatbale strings. Should not be too many. In that case we could say if the variant tld is CS, the whole application is dismissed. Bart: push back on what was agreed before? Allow end-users more choice. It introduces risks. You try to mitigate the risks. Dis-allow something that is allowable? Ai-chin: In my opinion,They belong to the same variant set, right? So if either one leads to confusing similarities, the other variant doesn't get through. Hadia: switch primary as variant Bart: but then they would need to re-apply Mirjana: variants should be blocked that did not pass confusability. Cannot be registered. The new request for primary strings is coming. Should be tested against all allocatable, all previous strings which were in the process. Bart: clear process Ai-chin: AA belongs to the same variant set. Other variant cannot pass. Bart: to be revisited Q. selected string should pass, no matter the status of the variants. If you agree, check green marks. Ai-Chin: comment Bart: what would you do, if you have an idn cctld string. Because of the policy, yopu will request a variant string, which meets all the criteria. If one of those variants would not pass, would you invalidate the existing TLD? Ai-Chin: if you applied, you cannot pass. Bart: but if it is an existing string, and it does not have variants. Would it impact the existing TLD? Ai-Chin: the requested string cannot pass. Bart: should the existing TLD be deleted or retired, because the variant you want did not pass? Ai-Chin: needs to think about it Bart: to be revisited. Comments from Mirjana and Ai-chin to be addressed at the next call. Mirjana: no time today to discuss. Please defer to next meeting iii. Inclusion expansion SEP, page 36 b. Discussion scope base for comparison Mirjana’s note (page 28) 4. First reading consolidated document 5. Next meeting a. Full group | 17 Jan (14 UTC) b. CS subgroup | 24 Jan (14 UTC) Kenny: schedule might need to be revisited due to Chinese New Year. to be continued Joke Braeken joke.braeken@icann.org