Re: [CCPDP4-CS-SG] NOTES | ccPDP4 Confusing Similarities SG Teleconference (12) | 22 November (14 UTC)
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@icann.org> on behalf of Joke Braeken <joke.braeken@icann.org> Date: Tuesday, 22 November 2022 at 16:37 To: "ccpdp4-cs-sg@icann.org" <ccpdp4-cs-sg@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-measur... 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@icann.org
And now with doc included😊 Kind regards, BArt From: CCPDP4-CS-SG <ccpdp4-cs-sg-bounces@icann.org> on behalf of Bart Boswinkel <bart.boswinkel@icann.org> Date: Wednesday, 23 November 2022 at 16:51 To: Joke Braeken <joke.braeken@icann.org>, "ccpdp4-cs-sg@icann.org" <ccpdp4-cs-sg@icann.org> Subject: Re: [CCPDP4-CS-SG] NOTES | ccPDP4 Confusing Similarities SG Teleconference (12) | 22 November (14 UTC) 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@icann.org> on behalf of Joke Braeken <joke.braeken@icann.org> Date: Tuesday, 22 November 2022 at 16:37 To: "ccpdp4-cs-sg@icann.org" <ccpdp4-cs-sg@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-measur... 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@icann.org
participants (1)
-
Bart Boswinkel