November 2022 - CCPDP4-CS-SG

Re: [CCPDP4-CS-SG] NOTES | ccPDP4 Confusing Similarities SG Teleconference (12) | 22 November (14 UTC)
by Bart Boswinkel Nov. 23, 2022

Nov. 23, 2022

Dear all, Please find included the updated version (after yesterday’s discussion) and to be discussed next week with EPDP. This document will be shared with the GNSO EPDP as well with caveat that it is still under discussion, first by the sub-groupo and then by the full group. I’ll share with the full WG as well earlier next week Kind regards, Bart From: CCPDP4-CS-SG <ccpdp4-cs-sg-bounces(a)icann.org> on behalf of Joke Braeken <joke.braeken(a)icann.org> Date: Tuesday, 22 November 2022 at 16:37 To: "ccpdp4-cs-sg(a)icann.org" <ccpdp4-cs-sg(a)icann.org> Subject: [CCPDP4-CS-SG] NOTES | ccPDP4 Confusing Similarities SG Teleconference (12) | 22 November (14 UTC) NOTES | ccPDP4 Confusing Similarities SG Teleconference (12) | 22 November (14 UTC) Comments: notes missing for agenda item 1 and 2 1. Welcome Welcome by Chair Kenny 2. Admin items, if any a. Action Items b. Meeting GNSO EPDP c. Progress Full group 3. Review of CS Document (attached) a. Intro section (2nd reading) Bart: overview of how the various terms relate to each other. Sarmad: risk mitigation appraisal is only applicable to a limited number of cases Bart: Thanks for the reminder. This is high level overview of the process Line 5-7: updated, as per suggestion by Pitinan Question for Ariel: has EPDP discussed this? Ariel: no. what was covered by SubPro was not covered by EPDP. but for the hybrid model, it states the goal on why the hybrid model was put forward Bart: might be useful to clarify how variants play out from a ccNSO perspective. Examples were updated because of the impact of variant management Ariel: similar conclusion by EPDP Bart: intent and goal are similar. Demonstrates the coordination and collaboration between GNSO and ccNSO Sarmad: also refer to SSAC’s report 89 for the sake of completeness Bart: will include a note. Also covered elsewhere Do you agree? No red marks Question by Sarmad (notes missing) Bart: will blocked variants be included in the base used to compare against. Not the requested ones. This was discussed extensively and captured in annex A. Do you agree? Caveat: we will review the part with respect to blocks. No red marks, limited green ticks Do you support line 1-28? Jiankang: for the technical panel, how to decide if the 2 strings are similar? Bart: not up to the technical panel, which looks only at tech criteria String evaluation panel will look at string similarity Jiankang; how will they decide? Bart: Let's revisit this, when we discuss section B2. this part only describes the 4 panels Jiankang: concern that if the 2 strings have visual similarity, different languages with different perspectives and understandings. Not easy for the evaluation panel to decide Have at least one Chinese native speaker in the panel in future. Suggestion for Sarmad. Bart: valid points. Going at the heart of the CS review. Knowledge of script, not necessarily language Sarmad: provision is part of the process and panel. Bart: agree. Either at the suggestion of the panel, or the requestor. If the requestor feels there needs to be script or other type of expertise on the panel, that should be taken care of Will revisit. Jiankang: ok, thank you. Bart: Do you support 1-28? Green ticks Questions regarding line 30-36? none b. Review of Process sections (second reading) Section B: Process for Confusing Similarity Validation. Sarmad: line 27. “The selected string is valid”. That hints to validity for the protocol. Might be confusing. Can we use an alternative word? Bart: validation. Is the string valid, yes or no? This is also what is currently being used in the Fast Track Process Sarmad: take it out. And say whether a selected string is not considered to be similar. Bart: Thank you. Any reactions? Will take note. Will have impact on rest of the text as well Questions on line 25-41? None Caveat: look for other language for “valid” and “validation process” Do you agree? No red marks Sarmad: procedural matter. Requestor has to respond within 3 months. If they do not do so, the string is rejected. From a practical point of view, it is probably better that the requestor confirms the end of process, closure of the application. Design the procedure as such, that both parties come to agreement. Bart: icann org not to wait indefinitely for a response. If you require a response, and people do not respond, what do you do then? It is a matter of implementation: up to icann org how to organise Sarmad: ok. That is how we implement it now. But from experience, it is slightly difficult. Bart: this allows icann org to take that decision, if there is no response. Questions regarding B 2.2.2? None B3: similarity review Was called the EPSRP. Extended Process Similarity Review Panel. Now called the similarity review panel (SRP). Do you support B3? No red marks Do you support the view that the SRP is seen as a true review, separate from the review mechanism for de-selection for instance. Should the Similarity Review be considered to be a review mechanism, specifically for similarity? No red marks B4: Risk Treatment Appraisal Bart: point by Anil some meetings ago regarding various criteria and what they meant Line 29-33: questions? None questions/comments: * B4.1. None Do you support? No red marks * B4.2. None Do you support? No red marks * B4.3. None Sarmad: confirm language. Upper case version of the string is found confusingly similar to the string. Use language from FTP. Bart: please circulate proposed language in written Sarmad: “If the DSP or EPSRP evaluation has determined that the requested string is confusingly similar in uppercase only (and not in lowercase).“ https://www.icann.org/en/system/files/files/guideline-risk-mitigation-measu… Do you support? No red marks * B4.4. None Do you support? No red marks * B4.5. None Do you support? No red marks * B4.6. Line 15-19. None (numbering needs to be adjusted) Do you support? No red marks * B4.7. None (numbering needs to be adjusted) Do you support? No red marks Detailing the procedure is a matter of implementation. FTP can be used as an example. Could provide a basis. Bart: Point by Jiankang. Ensure script expertise is available in the evaluation procedure. Suggestion to add “at the request of the requestor, and independent script expert may be added”. Jiankang: let’s discuss at the next meeting c. Open issues around invalid variants Ariel: only item the EPDP discussed. Will the joint meeting discuss this? Since it is still an open issue? Bart: depends on whether the group supports this in a 1st reading. The earlier you learn from eachother, the better Hadia: issue is related with how you do the comparison. Main difference between what the EPDP is doing and ccPDP. The answers to your questions would be different. If the EPDP would be doing the comparison the same way, comparing both would make sense. Agrees with Ariel to wait. Bart: line 24-35. Specific situation where selected string is not similar. Bart: should the SRP and Risk Mitigation be available Answer is probably no. if a variant is considered confusingly similar by the 1st panel, the review and risk mitigation should not be allowed. Reason: to avoid user confusion. Do you agree? No red marks d. CS document ready to share with GNSO EPDP Taking into account the editorial suggestions from Sarmad, do you agree that we circulate the clean version with the EPDP? caveat: some sections only discussed in one reading by ccPDP4 No red marks Bart will send document to Ariel on Wednesday 4. Next meetings a. CS Subgroup | 6 December 2022 @13:00 UTC b. Full Group | 29 November @13:00 UTC Kenny: correction. 14 UTC for both? Kim: yes. 5. AOB None 6. Adjourn Thank you all! Joke Braeken joke.braeken(a)icann.org

1 1

NOTES | ccPDP4 Confusing Similarities SG Teleconference (12) | 22 November (14 UTC)
by Joke Braeken Nov. 22, 2022

Nov. 22, 2022

NOTES | ccPDP4 Confusing Similarities SG Teleconference (12) | 22 November (14 UTC) Comments: notes missing for agenda item 1 and 2 1. Welcome Welcome by Chair Kenny 2. Admin items, if any a. Action Items b. Meeting GNSO EPDP c. Progress Full group 3. Review of CS Document (attached) a. Intro section (2nd reading) Bart: overview of how the various terms relate to each other. Sarmad: risk mitigation appraisal is only applicable to a limited number of cases Bart: Thanks for the reminder. This is high level overview of the process Line 5-7: updated, as per suggestion by Pitinan Question for Ariel: has EPDP discussed this? Ariel: no. what was covered by SubPro was not covered by EPDP. but for the hybrid model, it states the goal on why the hybrid model was put forward Bart: might be useful to clarify how variants play out from a ccNSO perspective. Examples were updated because of the impact of variant management Ariel: similar conclusion by EPDP Bart: intent and goal are similar. Demonstrates the coordination and collaboration between GNSO and ccNSO Sarmad: also refer to SSAC’s report 89 for the sake of completeness Bart: will include a note. Also covered elsewhere Do you agree? No red marks Question by Sarmad (notes missing) Bart: will blocked variants be included in the base used to compare against. Not the requested ones. This was discussed extensively and captured in annex A. Do you agree? Caveat: we will review the part with respect to blocks. No red marks, limited green ticks Do you support line 1-28? Jiankang: for the technical panel, how to decide if the 2 strings are similar? Bart: not up to the technical panel, which looks only at tech criteria String evaluation panel will look at string similarity Jiankang; how will they decide? Bart: Let's revisit this, when we discuss section B2. this part only describes the 4 panels Jiankang: concern that if the 2 strings have visual similarity, different languages with different perspectives and understandings. Not easy for the evaluation panel to decide Have at least one Chinese native speaker in the panel in future. Suggestion for Sarmad. Bart: valid points. Going at the heart of the CS review. Knowledge of script, not necessarily language Sarmad: provision is part of the process and panel. Bart: agree. Either at the suggestion of the panel, or the requestor. If the requestor feels there needs to be script or other type of expertise on the panel, that should be taken care of Will revisit. Jiankang: ok, thank you. Bart: Do you support 1-28? Green ticks Questions regarding line 30-36? none b. Review of Process sections (second reading) Section B: Process for Confusing Similarity Validation. Sarmad: line 27. “The selected string is valid”. That hints to validity for the protocol. Might be confusing. Can we use an alternative word? Bart: validation. Is the string valid, yes or no? This is also what is currently being used in the Fast Track Process Sarmad: take it out. And say whether a selected string is not considered to be similar. Bart: Thank you. Any reactions? Will take note. Will have impact on rest of the text as well Questions on line 25-41? None Caveat: look for other language for “valid” and “validation process” Do you agree? No red marks Sarmad: procedural matter. Requestor has to respond within 3 months. If they do not do so, the string is rejected. From a practical point of view, it is probably better that the requestor confirms the end of process, closure of the application. Design the procedure as such, that both parties come to agreement. Bart: icann org not to wait indefinitely for a response. If you require a response, and people do not respond, what do you do then? It is a matter of implementation: up to icann org how to organise Sarmad: ok. That is how we implement it now. But from experience, it is slightly difficult. Bart: this allows icann org to take that decision, if there is no response. Questions regarding B 2.2.2? None B3: similarity review Was called the EPSRP. Extended Process Similarity Review Panel. Now called the similarity review panel (SRP). Do you support B3? No red marks Do you support the view that the SRP is seen as a true review, separate from the review mechanism for de-selection for instance. Should the Similarity Review be considered to be a review mechanism, specifically for similarity? No red marks B4: Risk Treatment Appraisal Bart: point by Anil some meetings ago regarding various criteria and what they meant Line 29-33: questions? None questions/comments: * B4.1. None Do you support? No red marks * B4.2. None Do you support? No red marks * B4.3. None Sarmad: confirm language. Upper case version of the string is found confusingly similar to the string. Use language from FTP. Bart: please circulate proposed language in written Sarmad: “If the DSP or EPSRP evaluation has determined that the requested string is confusingly similar in uppercase only (and not in lowercase).“ https://www.icann.org/en/system/files/files/guideline-risk-mitigation-measu… Do you support? No red marks * B4.4. None Do you support? No red marks * B4.5. None Do you support? No red marks * B4.6. Line 15-19. None (numbering needs to be adjusted) Do you support? No red marks * B4.7. None (numbering needs to be adjusted) Do you support? No red marks Detailing the procedure is a matter of implementation. FTP can be used as an example. Could provide a basis. Bart: Point by Jiankang. Ensure script expertise is available in the evaluation procedure. Suggestion to add “at the request of the requestor, and independent script expert may be added”. Jiankang: let’s discuss at the next meeting c. Open issues around invalid variants Ariel: only item the EPDP discussed. Will the joint meeting discuss this? Since it is still an open issue? Bart: depends on whether the group supports this in a 1st reading. The earlier you learn from eachother, the better Hadia: issue is related with how you do the comparison. Main difference between what the EPDP is doing and ccPDP. The answers to your questions would be different. If the EPDP would be doing the comparison the same way, comparing both would make sense. Agrees with Ariel to wait. Bart: line 24-35. Specific situation where selected string is not similar. Bart: should the SRP and Risk Mitigation be available Answer is probably no. if a variant is considered confusingly similar by the 1st panel, the review and risk mitigation should not be allowed. Reason: to avoid user confusion. Do you agree? No red marks d. CS document ready to share with GNSO EPDP Taking into account the editorial suggestions from Sarmad, do you agree that we circulate the clean version with the EPDP? caveat: some sections only discussed in one reading by ccPDP4 No red marks Bart will send document to Ariel on Wednesday 4. Next meetings a. CS Subgroup | 6 December 2022 @13:00 UTC b. Full Group | 29 November @13:00 UTC Kenny: correction. 14 UTC for both? Kim: yes. 5. AOB None 6. Adjourn Thank you all! Joke Braeken joke.braeken(a)icann.org

1 0

Re: [CCPDP4-CS-SG] REMINDER: ccPDP4 Confusing Similarities SG Teleconference (12) | 22 November at 14:00 UTC
by Joke Braeken Nov. 22, 2022

Nov. 22, 2022

Dear All, Notes today will be taken here: https://docs.google.com/document/d/156mAun9iCefLVV3mhtUIXY7FDEckLVZa42eoUK7… Best regards, Joke Braeken joke.braeken(a)icann.org From: CCPDP4-CS-SG <ccpdp4-cs-sg-bounces(a)icann.org> on behalf of Kimberly Carlson <kimberly.carlson(a)icann.org> Date: Friday, 18 November 2022 at 15:35 To: "ccpdp4-cs-sg(a)icann.org" <ccpdp4-cs-sg(a)icann.org> Subject: [CCPDP4-CS-SG] REMINDER: ccPDP4 Confusing Similarities SG Teleconference (12) | 22 November at 14:00 UTC Dear all, The next ccPDP4 Confusing Similarities SG Teleconference (12) is scheduled for 22 November at 14:00 UTC. Agenda: 1. Welcome 2. Admin items, if any a. Action Items b. Meeting GNSO EPDP c. Progress Full group 1. Review of CS Document (attached) a. Intro section (2nd reading) b. Review of Process sections (second reading) c. Open issues around invalid variants d. CS document ready to share with GNSO EPDP 1. Next meetings a. CS Subgroup | 6 December 2022 @13:00 UTC b. Full Group | 29 November @13:00 UTC 1. AOB 2. Adjourn Please find the call details below: Join Zoom Meeting https://icann.zoom.us/j/95113091899?pwd=ZlFNTzFPUUV1VEwwRjdGVnFRSUlFZz09 [icann.zoom.us]<https://urldefense.com/v3/__https:/icann.zoom.us/j/95113091899?pwd=ZlFNTzFP…> Meeting ID: 951 1309 1899 Passcode: PDP4CS-#12 Wiki: https://community.icann.org/x/VIoFDQ

1 0

ccPDP4 Confusing Similarities SG Teleconference (12) | 22 November at 14:00 UTC
by Kimberly Carlson Nov. 22, 2022

Nov. 22, 2022

***STARTING IN ONE HOUR*** Dear all, The next ccPDP4 Confusing Similarities SG Teleconference (12) is scheduled for 22 November at 14:00 UTC. The agenda will be circulated prior to the call. Please find the call details below: Join Zoom Meeting https://icann.zoom.us/j/95113091899?pwd=ZlFNTzFPUUV1VEwwRjdGVnFRSUlFZz09 Meeting ID: 951 1309 1899 Passcode: PDP4CS-#12 Wiki: https://community.icann.org/x/VIoFDQ

1 0

REMINDER: ccPDP4 Confusing Similarities SG Teleconference (12) | 22 November at 14:00 UTC
by Kimberly Carlson Nov. 22, 2022

Nov. 22, 2022

Dear all, The next ccPDP4 Confusing Similarities SG Teleconference (12) is scheduled for 22 November at 14:00 UTC. Agenda: 1. Welcome 2. Admin items, if any a. Action Items b. Meeting GNSO EPDP c. Progress Full group 1. Review of CS Document (attached) a. Intro section (2nd reading) b. Review of Process sections (second reading) c. Open issues around invalid variants d. CS document ready to share with GNSO EPDP 1. Next meetings a. CS Subgroup | 6 December 2022 @13:00 UTC b. Full Group | 29 November @13:00 UTC 1. AOB 2. Adjourn Please find the call details below: Join Zoom Meeting https://icann.zoom.us/j/95113091899?pwd=ZlFNTzFPUUV1VEwwRjdGVnFRSUlFZz09 Meeting ID: 951 1309 1899 Passcode: PDP4CS-#12 Wiki: https://community.icann.org/x/VIoFDQ

2 1

ccPDP4 Confusing Similarities SG teleconference (13) | 6 December at 14:00 UTC
by Kimberly Carlson Nov. 21, 2022

Nov. 21, 2022

Dear all, The ccPDP4 Confusing Similarities SG teleconference (13) will be 6 December at 14:00 UTC. An agenda will be circulated prior to the call. Please find the call details below: Join Zoom Meeting https://icann.zoom.us/j/97082606327?pwd=V0FnNEozUzJTV2JsYjc3bFprMTJoQT09 Meeting ID: 970 8260 6327 Passcode: PDP4-CS#13 Wiki: https://community.icann.org/x/8oQ-DQ

1 0

ccPDP4 Confusing Similarities SG Teleconference (12) | 22 November at 14:00 UTC
by Kimberly Carlson Nov. 10, 2022

Nov. 10, 2022

Dear all, The next ccPDP4 Confusing Similarities SG Teleconference (12) is scheduled for 22 November at 14:00 UTC. The agenda will be circulated prior to the call. Please find the call details below: Join Zoom Meeting https://icann.zoom.us/j/95113091899?pwd=ZlFNTzFPUUV1VEwwRjdGVnFRSUlFZz09 Meeting ID: 951 1309 1899 Passcode: PDP4CS-#12 Wiki: https://community.icann.org/x/VIoFDQ

1 0

NOTES | ccPDP4 Confusing Similarities (#10) | 8 Nov 2022 (14:00 UTC)
by Joke Braeken Nov. 8, 2022

Nov. 8, 2022

ccPDP4 Confusing Similarities (#10) | 8 Nov 2022 (14:00 UTC) 1. Welcome Welcome by chair Kenny 2. Admin items, if any a. Action Items None, meeting from 2 weeks ago was canceled due to low attendance b. Meeting GNSO EPDP Bart: we scheduled a joint meeting on 29 Nov. GNSO update in terms of CS. timely for this group as well. Share the basic criteria, base for comparison, and the procedural updates from this end. Good to exchange views c. Progress Full group Kenny: full group one week ago. Bart gave an update for Review Mechanism from ccPDP3. What can be copied? Anything that needs to be amended? Bart: will re-circulate an updated version of the doc used a week ago. Looking fwd to discussion next week 3. Review of CS Document (attached) a. Intro section Bart: basic items from previous doc. Basic questions. Base for comparison We did not go over the proposed changes. There was a discussion regarding the use of py in cyrillic/latin. Example was cut-paste from IDN Fast Track proposal. Overtaken by time, due to the work by the latin script LGR. Mirjana raised this point. Also included in the text. Pitinan suggested another example. See redline. Does this address the concern raised during the previous call? Pitinan: need to check. Looks like it is capitalised. Needs to be lower case. Бе Will re-send via e-mail, calibri font Base for comparison needs to be reviewed at a later stage, see comments by Mirjana. b. Overview process Extensive part. Line 10-37 Any questions? None Line 41 Validation is the general description. Evaluation is the 1st phase, and review the 2nd phase. Line 45 to 2 FTP has currently 3 steps with respect to CS: * Step 1: DNS Stability panel (now/future: Similarity Evaluation Panel) * Step 2: EPRSP (now/future: Similarity Review Panel) * Risk mitigation (now/future: Risk Mitigation Panel) Anil: 1st review panel after evaluation. Once a panel made a report to ICANN staff. If icann staff wish it to be reviewed by the same panel. If the requester is not happy with decision of the delegation Bart: The 1st one will always happen. This is an independent panel. If a requester submits an IDN ccTLD string, the Similarity Evaluation Panel will evaluate whether it is not confusingly similar to another string. If that is the case, it will inform ICANN staff. Staff will inform the requester. It is up to the requester whether they want a review by the 2nd panel, the similarity review panel. Anil: All clear. Bart: see line 4. Requested by the requestor. All strings that are requested are submitted to the similarity evaluation panel Hadia: Does SRP always happen? Is it by choice? Bart: see also Anil’s question. Only if requested by the requestor. By choice. Logic approach? No red marks Hadia: in both cases it needs to be an independent panel. Can it be the same panel? Bart: it is in the text it is a different one, because it uses a different method This simply sets the basic structure for the 2 panels. See whether it is clear by the end of the meeting Bart: changes needed. What is currently the Extended Process, is going forward called the similarity evaluation. Discussion around Review mechanisms and CS. there was a potential that a RM which will be proposed to the community and developed under PDP3 may not be suited for similarity. RM is focusing on IFO decisions. PTI. These decisions are ICANN org decisions. Either you need to force IFO to do this, or the ccPDP3 policy needs to be adjusted. Both are a bridge too far. IFO is not equipped to do this. Even more important: all decisions from IFO related to (re)delegation require knowledge, skill, experience. Completely different than looking at CS of strings. CS is a cognitive science approach. Especially in the 2nd round. See footnote above. The 2nd panel is using a method based on findings of these groups. Do you support general logic for text in line 9 to 29? No red marks Hadia: each panel with different output. What is meant by combining the process? Bart: that is line item 30. Let’s come back to this later. Basic structure of string validation procedure. No questions or comments. Bart: suggestion to treat similarity review as a very specific review mechanism around similarity review. Do you agree? No red marks We will revisit in 2 weeks time. It will have impact on other things as well Line 30-32 Bart: this was combined under FTP Hadia: could be same organisation/people Bart: yes. To make process more efficient. Perhaps add in the notes and observations. As long as these 2 functions are covered. Notes and observations are not part of the policy itself Bart: one question still open. Introduce a review mechanism on technical validation? Currently not in place, not in the FTP. if you miss out on the technical requirements, there is the possibility to adjust and to contact icann staff before you submit a request. If you do not meet the basic technical requirements, the IDNA suite etc, then it is questionable whether you should introduce a RM. raise the question later on. Anil: regarding 1st question previous paragraph. When we talk about combining tech evaluation and CS evaluation under same panel, we cover both review together. But at the same time we talk about CS evaluation, it is a review, and a third review. Bart: only the technical review Line 26-45 Questions or comments? None Do you support the text? No red marks Anil: can we rephrase as Risk evaluation Panel? Creates confusion. Bart: reason for this. The requestor will propose to the panel how it wants to handle the risk treatment. The panel will appraise this. We could also call it the Risk Appraisal Panel. But then there is confusion on whether you talk about the process or the panel? Bart: let’s leave it for the time being. Suggestions for panel names are welcome Line 10-29 Questions? Anil: what is the experience. Is 30 days sufficient? Bart: there has never been an issue with this. Line 32-44. Section B2.2 Questions or comments? None Do you support? No red marks Line 1-26 Current language from FTP Line 28-35 Additional language. If there is an issue, then the requestor can go either to the similarity review, or the risk mitigation appraisal process. What if the requested string is confusingly similar, but one of the variants is not? Is there a hierarchy between the requested string, or the variants? Note that the variants need to be meaningful representations of the name of the territory. To think about. Anil: 1st question. Variants are defined as variant of the main string. If the main string is confusingly similar, and we consider to allocate the variant instead, then the basic principle of variants is under question. Once a principal string is declared as CS string, the string and its variants should be blocked. When the principal variant is valid, but some are not, those specific variants may not be delegated. First reaction. We can further discuss. Hadia: different perspective. What if we change our principal? See what the tool generates if you use the variant. When comparing with other strings, the output would be different. Answer to question depends on how the comparison is done, and the output. Needs to think more about. Bart: note that we talk about “requested variants”. 2 characters: * Has to be allocatable * Has to be a meaningful representation of the name of the territory Similarity review Rewrite of the 2013 basic doc and the FTP. this used to be called the EPSRP Line 12 -45 Do you support? No red marks Bart: still need to include the guideline which is currently used. Panel description and its role is new text. Let’s start with line 5-12 Any questions or comments? None Line 14-25 Questions or comments? Do you support line 5-25? No red marks Criteria to appraise risk mitigation panels: Small ccNSO and SSAC developed this. Copy-paste from that guideline doc. Necessary to include that in the policy Anil: a bit of discussion around proportionate risk. Definition about adequate. More clarification needed. Whoever is the requester, this is a stage where they received a negative evaluation from icann. When he applies, he needs to be aware what criteria need to be met. Bart: feasible to provide this? Not sure. But will be taken into consideration. To be detailed in implementation. Requester indeed needs to understand what the ccTLD manager needs to do to mitigate the risk. Combination of measures at the registry level. To be assessed by the panel. Needs to be proportionate. Not allowing the IDN ccTLD would be disproportionate. Check at the next meeting. Should be a point for detail? Reference to case study under the FTP Anil: thanks. B4.4. Detailing procedure itself. Copy and paste from current guideline. To document in policy itself how the procedure works Anil: possibility for (notes missing)? Bart: possibility that RTAP and requestor meet. Possibility for exchange of info. 9 and 10 Anil: but RTAP gives its report to requestor. Additional info or doc needed. But nowhere written that the requester can have a talk with RTAP. This is the final chance for the requestor Bart: face to face meeting? Anil: yes please. Bart: ok. Let’s discuss at the next meeting Anybody else have an opinion on Anil’s suggestion? None B4.5 2 options. String valid or invalid. Line 24-39 No questions or comments c. Review of Process sections (first reading) 1st reading was intense. 4. Next meetings a. Full Group | 15 November @14:00 UTC b. CS Subgroup | 22 November @14:00 UTC c. Full Group | 29 November @14:00 UTC – with GNSO EPDP Anil: 22 nov. meeting. postpone, as close to holiday? Joint meeting: 2 groups are aligned with respect to VM. focus on CS. Bart: since we meet on the 29th, suggestion is to meet also on 22nd. Any issues, Kim? Kim: none. 5. AOB None 6. Adjourn Thank you all. Joke Braeken joke.braeken(a)icann.org

1 0

REVISED ccPDP4 Confusing Similarities SG Teleconference (11) | 8 November at 14:00 UTC
by Kimberly Carlson Nov. 8, 2022

Nov. 8, 2022

***STARTING NOW*** Dear all, The next ccPDP4 Confusing Similarities SG Teleconference (11) is scheduled for 8 November at 14:00 UTC. The agenda will be circulated prior to the call. Please find the call details below: Join Zoom Meeting https://icann.zoom.us/j/93173467003?pwd=WnNvbmVSemhQUnVLVXpxY1BHT1Z0QT09 Meeting ID: 931 7346 7003 Passcode: PDP4-CS#11 Wiki: https://community.icann.org/x/VAbVD

1 0

REVISED ccPDP4 Confusing Similarities SG Teleconference (11) | 8 November at 14:00 UTC
by Kimberly Carlson Nov. 8, 2022

Nov. 8, 2022

***STARTING IN ONE HOUR*** Dear all, The next ccPDP4 Confusing Similarities SG Teleconference (11) is scheduled for 8 November at 14:00 UTC. The agenda will be circulated prior to the call. Please find the call details below: Join Zoom Meeting https://icann.zoom.us/j/93173467003?pwd=WnNvbmVSemhQUnVLVXpxY1BHT1Z0QT09 Meeting ID: 931 7346 7003 Passcode: PDP4-CS#11 Wiki: https://community.icann.org/x/VAbVD

1 0