- CCPDP4-CS-SG - lists.icann.org

ccPDP4 Confusing Similarities SG teleconference (14) | 20 December at 14:00 UTC
by Kimberly Carlson Dec. 7, 2022

Dec. 7, 2022

Dear all, The ccPDP4 Confusing Similarities SG teleconference (14) will be 20 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/96662611353?pwd=MGVmNHpYZlFkSXJIVmpId0Y3ZFdvUT09 Meeting ID: 966 6261 1353 Passcode: PDP4-CS#14 Wiki: https://community.icann.org/x/AoU-DQ

1 0

NOTES | ccPDP4 Confusing Similarities SG teleconference (13) 6 December 2022 at 14:00 UTC.
by Joke Braeken Dec. 6, 2022

Dec. 6, 2022

NOTES | ccPDP4 Confusing Similarities SG teleconference (13) 6 December 2022 at 14:00 UTC. 1. Welcome Welcome by full WG Chair Kenny 2. Admin items, if any a. Action Items Bart: all completed b. Meeting GNSO EPDP Kenny: most likely another joint meeting before ICANN76. Once a proposal is in a more final state. Bart: question by Donna, whether the members of the EPDP could participate in the full group scenario testing. c. Progress Full group Chair Anil takes over from Kenny Met 2 weeks ago. Add the work of the subgroups, and also the work by ccPDP3-RM. To be completed by ICANN76. Bart: regarding RM, some sections need a 2nd reading. Check also whether there are decisions that should be subject to a review Anil: RM is important. All, please join the full WG meeting on 13 December 3. Review of CS Document a. Updates of doc after 2nd reading 1. Comment inclusion of reference to SAC089, page 3 Bart: response to SSAC84. FTP, EPSR ccNSO suggested a change, which went through public comment. SSAC084 as response to public comment. Official way at the time, only way the SSAC could submit a public comment. Intense discussions between SSAC and ccNSO following that. Original proposal was rescinded as a result of these discussions. Both formed a joint working party which developed the risk mitigation appraisal procedure. Relevant sections in SAAC089. But overtaken in time. Unwise to overtake one remark from a document. Given the specific context and the proposed changes to the FTP, suggested is not to include a reference to SAC089. Sarmad: I suggested this pointer. Please allow me to explain why. From chat: “Confusability is a Security Concern Confusability cannot be considered in isolation from other issues related to security. Phishing and other social engineering attacks based on domain name confusion are a security problem for end users.2 As such, adding a label to the root zone that is potentially confusable violates the Inclusion Principle’s requirement that a TLD label be known to be ‘safe’.” Good reference point to share why string similarity and confusability are so important as part of the process. Add more support to it. Jaap: Sarmad cited from SAC088. That is where it comes from. Does not make sense to add it Bart: do you wish to add a reference to SAC089? 3 red marks, 1 green (by Anil) Anil: SAC089 is being used, and related to the stability of the DNS. Does not feel strong about inclusion Bart: let’s leave it open for the time being, and bring it to the full WG. keep the reference for the time being. Explain there is a mild preference by some, opposition by others. Kenny and Anil agree 2. Comment re use of word ‘VALID” in the text, page 6 Bart: used in FTP, and checked various dictionaries. Suggest to keep the language Green marks in zoom, no red marks >>> page 9 No concerns raised. No red marks Sarmad: see 2nd question. Clarification. What is suggested that is the primary label is not found confusing, and one of its variants is found confusing with another TLD (more likely gTLD) Bart: why more likely? By definition country names are excluded. Meaningful representation. Has to be the name of the country Sarmad: in case it is found confusingly similar - taken it is a rare scenario - assuming there is a population that think that those 2 variants (ccTLD primary string and the confusingly similar string), are similar enough to be almost the same. Also, there is a community which thinks the variant of the primary is the same. Bart: I am confused. Why requesting a string, by requesting a delegatable variant, you may cause that your primary or selected string is not delegated or not valid. Sarmad: recommendation in the staff report is based on the allocatable variants. Bart: it has a lot of implications by limiting the number to allocatable variants. Sarmad: we do not want a situation with 2 TLDs delegated, which are considered similar by a population of users. It will hurt both the existing and the new TLD. phishing risk. Bart: do you still support scenario 2 as proposed? 2 red marks Mirjana: scenario could be mentioned somewhere in our doc. We need to think how to resolve this loop. Kenny: need more time 3. Inclusion of expansion of the SEP, page 13,14 Bart: see suggestion by Jiankang. Evaluation panel Sarmad: as part of the 1st step, a separate panel is being created. Or 3 people to extend the panel? Bart: slight adjustment of the language in FTP. at least 3 member panel. DNS stability panel. Sarmad: 3 plus 3? Bart: no. if there is more people, ensure there is at least one person with knowledge of the script Extended panel will include at least 1 person with deep knowledge Anil: fundamental question. Requester has any option for suggesting a name in the panel? Or is it icann org? Bart: icann org contracts the panel. Has to be independent. Appointed by ICANN. External panelists. No matter the size, at least one person with knowledge. Bart: do you agree with the proposed way of handling? Sarmad: panel may suggest the same, even if the requester does not ask Bart: yes. Line 3 and 4 on page 14 Sarmad: ok Bart: do you agree (not with language), with the approach? No red marks Bart: before stability panel has reached its conclusion. Bart summarises: revisit 2nd scenario on CS. Revisit the panel bit. Full group to revisit SAC089 b. Review of Open issues around invalid variants (second reading),page 8 4. Introduction Basic with inclusion of CS (to be circulated closer to the meeting) Bart: no real change in language. Wants to show how it is included. Main section is section 4. Page 25. Still to discuss whether or not to include blocked variants in the comparison Bart asks Mirjana to explain why it needs to be included, in the next few weeks. Mirjana: likes the proposal discussed with GNSO group. Yes, gives live example in written soon. Bart: do you like the structure of the doc? No concerns by the group 5. Next meetings CS Subgroup | 20 December 2022 @14:00 UTC Full Group| 13 December 2020 @14.00 UTC 5. AOB none 6. Adjourn Thank you all. bye Joke Braeken joke.braeken(a)icann.org

1 0

Re: [CCPDP4-CS-SG] REMINDER: ccPDP4 Confusing Similarities SG teleconference (13) | 6 December at 14:00 UTC
by Joke Braeken Dec. 6, 2022

Dec. 6, 2022

Dear All, Notes today will be taken here: https://docs.google.com/document/d/1iKzIasJ03sN-E8OmdpGp7JwaD92y1GpoIojH3qJ… Best regards. Joke Braeken joke.braeken(a)icann.org<mailto:joke.braeken@icann.org> From: CCPDP4-CS-SG <ccpdp4-cs-sg-bounces(a)icann.org> on behalf of Kimberly Carlson <kimberly.carlson(a)icann.org> Date: Thursday, 1 December 2022 at 20:37 To: "ccpdp4-cs-sg(a)icann.org" <ccpdp4-cs-sg(a)icann.org> Subject: [CCPDP4-CS-SG] REMINDER: ccPDP4 Confusing Similarities SG teleconference (13) | 6 December at 14:00 UTC Dear all, As a reminder, the next ccPDP4 Confusing Similarities SG teleconference (13) will be 6 December 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 a. Updates of doc after 2nd reading * Comment inclusion of reference to SAC089, page 3 * Comment re use of word ‘VALID” in the text, page 6 * Inclusion of expansion of the SEP, page 13,14 b. Review of Open issues around invalid variants (second reading),page 8 1. Introduction Basic with inclusion of CS (to be circulated closer to the meeting) 2. Next meetings a. CS Subgroup | 20 December 2022 @14:00 UTC b. Full Group| 13 December 2020 @14.00 UTC 1. AOB 2. Adjourn Please find the call details below: Join Zoom Meeting https://icann.zoom.us/j/97082606327?pwd=V0FnNEozUzJTV2JsYjc3bFprMTJoQT09 [icann.zoom.us]<https://urldefense.com/v3/__https:/icann.zoom.us/j/97082606327?pwd=V0FnNEoz…> Meeting ID: 970 8260 6327 Passcode: PDP4-CS#13 Wiki: https://community.icann.org/x/8oQ-DQ

1 0

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

Dec. 6, 2022

**STARTING IN ONE HOUR*** 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

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

Dec. 5, 2022

Dear all, As a reminder, the next ccPDP4 Confusing Similarities SG teleconference (13) will be 6 December 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 a. Updates of doc after 2nd reading * Comment inclusion of reference to SAC089, page 3 * Comment re use of word ‘VALID” in the text, page 6 * Inclusion of expansion of the SEP, page 13,14 b. Review of Open issues around invalid variants (second reading),page 8 1. Introduction Basic with inclusion of CS (to be circulated closer to the meeting) 2. Next meetings a. CS Subgroup | 20 December 2022 @14:00 UTC b. Full Group| 13 December 2020 @14.00 UTC 1. AOB 2. Adjourn 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 1

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