Thanks for circulating, Greg. All I note that we are meeting with the ALAC on Saturday, and that they wish to discuss diacritic characters/Quebec, including what the Council’s view is and “How does the Council plan to address the issue(s)” https://community.icann.org/display/atlarge/At-Large+Meetings+-+Saturday%2C+... The timing of this meeting on Saturday seems a little unfortunate, since I don’t believe Council yet has a clearly formulated and agreed view, nor have we agreed on next steps – this is not on our agenda for discussion until Wednesday. Hopefully, the meeting with the ALAC can be an opportunity to understand their position on this, and discuss possible options, since we aren’t in a position to make any commitments on what happens next – if anything. On the substantive issue, having reviewed the agenda item for Wednesday and had more opportunity to reflect on this, I am not altogether convinced that there is a problem to be solved here. * The role of the IDN EPDP is to set the rules for equivalent IDN variants, including considering same applicant provisions at both the top and second level. What is considered a variant had been determined by the relevant LGR. Although some accented characters in ASCII script have been determined to be variants by the LGR, the accented characters in issue here have not been determined not to be variants. The special IDN rules that are being developed therefore do not apply. * This therefore becomes a string similarity issue: are the strings with and without diacritic characters confusingly similar or not? The same issue arises across languages, whether one is talking about a word that is spelled similarly, e.g., the addition of an “s” in the French compared to the English, or whether one language uses an accented character and another does not. If the strings are held to be similar, following String Similarity Evaluation, then, if applied for in the same round, both go into a contention set, or, if applied for in different rounds, the later is blocked by the prior application. Just because a string is unavailable for delegation does not make it an “issue to be solved”, it is the string similarity rules working as they were designed to, in order to safeguard the public. Why do we propose now creating a separate set of rules to end-round a potential determination that it is unsafe to delegate confusingly similar strings, just because there is an accent involved? * If the strings are considered by the SSE panel NOT to be similar, then they can both go forward. In the case of the specific dot Québec example, to whom this string is delegated is then subject to further rules since Quebec is a geographic name as determined by Work Track 5, requiring governmental consent/non-objection. No-one can have that string delegated to them without the necessary support. It is also worth noting that we discussed diacritical characters in WT5 and did not make recommendations, so this is not an issue which was simply overlooked. * The same string similarity issue also arises more generally for ALL applicants: the first mover gets an advantage and blocks identical or confusingly similar strings that come later. A next round applicant might want .cat for their cat-lovers community, for example. They cannot have it because .cat has already been delegated to the Catalan community. All potential applicants understand that they cannot necessarily have their first-choice string just because they want it, but that an alternative may be an available option for them. * Overall, since this is a string similarity issue, should we not, at least, wait on the development of the planned String Similarity Guidelines before we start talking about committing Org and community resources to even considering creating (probably complex) exceptions to a set of policy rules which have only just been developed through an open-model PDP and are still being implemented? There is a session on the development of the String Similarity Guidelines on Thursday, in fact. Susan Payne Head of Legal Policy Com Laude T +44 (0) 20 7421 8250 Ext 255 [cid:image001.png@01DA02D1.27514970]<https://comlaude.com/> Follow us on Linkedin<https://t-uk.xink.io/Tracking/Index/pRkAAGVfAADw_RQA0> and YouTube<https://t-uk.xink.io/Tracking/Index/bhkAAGVfAADw_RQA0> From: council <council-bounces@gnso.icann.org> On Behalf Of DiBiase, Gregory via council Sent: Tuesday, October 10, 2023 6:23 PM To: COUNCIL@GNSO.ICANN.ORG Cc: gnso-secs@icann.org Subject: [council] Follow up on GNSO Council related meetings at ICANN78 Dear Councilors, I’m following up on the email below regarding the working document<https://docs.google.com/spreadsheets/d/1a3plNvimEJjpSUhahQPtpJU6BUXBkUKiQruv...> which includes the agendas for the various Council related meetings, such as the GNSO working sessions and joint meetings. I’d like to highlight a couple portions below (but please comment on any section of the document). First I would like to confirm the single topic suggested by the Council for the joint meeting between the ICANN Board and GNSO Council. The topic is: Preliminary discussion of Board Statement not-adopting certain SubPro recommendations. The Council’s topic(s) must be communicated to the Board by 11 October. Note, this engagement is expected to serve as at least the first meeting to discuss the Board Statement as required by Annex A, Section 9 (c) of the ICANN Bylaws, referenced in Tripti’s letter<https://gnso.icann.org/sites/default/files/policy/2023/correspondence/sinha-...> to the Council. Holding this meeting would not preclude additional discussion at a later time, as deemed necessary. In order to support this topic, the Council’s SubPro Pending Recommendations small team is concentrating on a working document<https://docs.google.com/document/d/1bumhCtJ1C3PatdsSHsl435Kk11mxGJXQ/edit> that first and foremost, identifies clarifying questions to discuss with the Board. In addition, the working document identifies which of the non-adopted recommendations that the small would like to try and modify in order to address the Board’s concerns, as well as a high-level understanding of what that modification could look like. The second reason for follow-up is to draw attention to the second GNSO Working Session where the GNSO will meet with staff from the Global Domains and Strategy (GDS) team. While the GDS team will come prepared to provide an update, it will be helpful if Councilors identify questions/comments in advance, in order to better support an active dialogue. Thanks, Greg From: council <council-bounces@gnso.icann.org<mailto:council-bounces@gnso.icann.org>> On Behalf Of Steve Chan via council Sent: Wednesday, October 4, 2023 4:51 PM To: council@gnso.icann.org<mailto:council@gnso.icann.org> Subject: [EXTERNAL] [council] GNSO Council related meetings at ICANN78 CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. Dear Councilors, For your planning purposes, please find this working document<https://docs.google.com/spreadsheets/d/1a3plNvimEJjpSUhahQPtpJU6BUXBkUKiQruv...> which includes the agendas for the various Council related meetings, such as the GNSO working sessions and joint meetings. In particular, I’d like to draw your attention to the tab for the GNSO Council/Board session which currently has one potential topic for the Council to suggest, and one Board proposed topic. The deadline to communicate topics for that Board/Council session is 11 October. The other quick comment is that the latest and greatest Council/GAC proposed agenda is included. Jeff, apologies for potentially stealing your thunder! If you have any questions or comments on any of the agendas, please share them on this list. And for the Council/Board session, please also consider whether additional topics are needed for the 60 minute session. Best, Steve Steven Chan VP, Policy Development Support & GNSO Relations Internet Corporation for Assigned Names and Numbers (ICANN) 12025 Waterfront Drive, Suite 300 Los Angeles, CA 90094-2536 Email: steve.chan@icann.org<mailto:steve.chan@icann.org> Skype: steve.chan55 Mobile: +1.310.339.4410 Find out more about the GNSO by visiting: https://learn.icann.org/<https://urldefense.proofpoint.com/v2/url?u=https-3A__learn.icann.org_&d=DwMGaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=DRa2dXAvSFpCIgmkXhFzL7ar9Qfqa0AIgn-H4xR2EBk&m=jLNFXvpu9gNdUeHi-G6sjWNCF9w4_AwhzzUDFZy2elE&s=o7Auz997kA-HPv9PHJCjFVZw7Pgo8krw4MxfqCwBrIU&e=> Follow @GNSO on Twitter: https://twitter.com/ICANN_GNSO<https://urldefense.proofpoint.com/v2/url?u=https-3A__twitter.com_ICANN-5FGNSO&d=DwMGaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=DRa2dXAvSFpCIgmkXhFzL7ar9Qfqa0AIgn-H4xR2EBk&m=jLNFXvpu9gNdUeHi-G6sjWNCF9w4_AwhzzUDFZy2elE&s=kWw4fQPNjw2lVKy1UjTxS2F0BmjEAzaDFWNmsYywbmE&e=> Transcripts and recordings of GNSO Working Group and Council events are located on the GNSO Master Calendar <https://urldefense.proofpoint.com/v2/url?u=https-3A__gnso.icann.org_en_group...> ________________________________ The contents of this email and any attachments are confidential to the intended recipient. They may not be disclosed, used by or copied in any way by anyone other than the intended recipient. If you have received this message in error, please return it to the sender (deleting the body of the email and attachments in your reply) and immediately and permanently delete it. Please note that Com Laude Group Limited (the “Com Laude Group”) does not accept any responsibility for viruses and it is your responsibility to scan or otherwise check this email and any attachments. The Com Laude Group does not accept liability for statements which are clearly the sender's own and not made on behalf of the group or one of its member entities. The Com Laude Group is a limited company registered in England and Wales with company number 10689074 and registered office at 28-30 Little Russell Street, London, WC1A 2HN England. The Com Laude Group includes Nom-IQ Limited t/a Com Laude, a company registered in England and Wales with company number 5047655 and registered office at 28-30 Little Russell Street, London, WC1A 2HN England; Valideus Limited, a company registered in England and Wales with company number 6181291 and registered office at 28-30 Little Russell Street, London, WC1A 2HN England; Demys Limited, a company registered in Scotland with company number SC197176 and registered office at 15 William Street, South West Lane, Edinburgh, EH3 7LL Scotland; Consonum, Inc. dba Com Laude USA and Valideus USA, a corporation incorporated in the State of Washington and principal office address at Suite 332, Securities Building, 1904 Third Ave, Seattle, WA 98101; Com Laude (Japan) Corporation, a company registered in Japan with company number 0100-01-190853 and registered office at 1-3-21 Shinkawa, Chuo-ku, Tokyo, 104-0033, Japan; Com Laude Domain ESP S.L.U., a company registered in Spain and registered office address at Calle Barcas 2, 2, Valencia, 46002, Spain. For further information see www.comlaude.com<https://comlaude.com/>
