Susan, I went back to the list of geoTLDs from the last round, and ".quebec" is in a unique situation, to be honest. Other strings that might have fallen into the same pattern ended up making choices that steered them away from the ssue, case in point being ".koeln", which is a corruption of "köln". We know from Universal Acceptance that the German people are used to the replacements for their accents and Eszett, so it makes sense the applicants would proceed in this way. We can also assume that deliberate choices were made by applicants in the transliteration of Sino-Tibetan and Japonic languages into Latin. As far as the limits of my knowledge go, this leaves ".quebec" alone in having made it all the way to delegation while there still being a very clear variant contained within the string and being unadressed, which is pretty vexing. In that sense, this seems to be more of a leftover case that we need to tackle than necessarily an entirely different process. Best, --- Mark W. Datysgeld Director at Governance Primer ICANN GNSO Councilor ________________________________ From: Susan Payne via council <council@gnso.icann.org> Sent: Thursday, October 19, 2023 23:01 To: COUNCIL@GNSO.ICANN.ORG Cc: gnso-secs@icann.org Subject: [council] Meeting with ALAC and Diacritic Characters

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

Follow us on Linkedin and YouTube 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 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 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 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> On Behalf Of Steve Chan via council Sent: Wednesday, October 4, 2023 4:51 PM To: 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 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 Skype: steve.chan55 Mobile: +1.310.339.4410   Find out more about the GNSO by visiting: https://learn.icann.org/ Follow @GNSO on Twitter: https://twitter.com/ICANN_GNSO Transcripts and recordings of GNSO Working Group and Council events are located on the GNSO Master Calendar  ________________________________ 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

Hi I like the examples Mark provided as it proves that the GNSO can have a separate discussion on .québec perhaps after Wednesday String Similarity Guidelines. The LGR rules have left us with a challenge by saying there are no variants in Latin alphabets, an oversimplification. Therefore as .Québec is beyond the IDN EPDP problem because it is not a variant. However, the GNSO Council will have to address this and future cases of String Similarity and it is important to recognise that String Similarity does not necessarily have to create a confusion in user's mind. We need to have a policy tool box to cater for those as well. Some examples of those are .ong and .ngo and few other gTLDs in Cyrillic language for example. Also agree with Susan that we should listen to ALAC's views to start with. Desiree -- Desiree -- Sent with [Proton Mail](https://proton.me/) secure email. ------- Original Message ------- On Friday, October 20th, 2023 at 06:14, Mark W. Datysgeld via council <council@gnso.icann.org> wrote:

Susan, I went back to the list of geoTLDs from the last round, and ".quebec" is in a unique situation, to be honest.

Other strings that might have fallen into the same pattern ended up making choices that steered them away from the ssue, case in point being ".koeln", which is a corruption of "köln". We know from Universal Acceptance that the German people are used to the replacements for their accents and Eszett, so it makes sense the applicants would proceed in this way. We can also assume that deliberate choices were made by applicants in the transliteration of Sino-Tibetan and Japonic languages into Latin.

As far as the limits of my knowledge go, this leaves ".quebec" alone in having made it all the way to delegation while there still being a very clear variant contained within the string and being unadressed, which is pretty vexing.

In that sense, this seems to be more of a leftover case that we need to tackle than necessarily an entirely different process.

Best, --- Mark W. Datysgeld Director at Governance Primer ICANN GNSO Councilor

---------------------------------------------------------------

From: Susan Payne via council <council@gnso.icann.org> Sent: Thursday, October 19, 2023 23:01 To: COUNCIL@GNSO.ICANN.ORG Cc: gnso-secs@icann.org Subject: [council] Meeting with ALAC and Diacritic Characters

...

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 LaudeT +44 (0) 20 7421 8250 Ext 255

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> On Behalf Of Steve Chan via council Sent: Wednesday, October 4, 2023 4:51 PM To: 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 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/)