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+21+October+2023

 

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.

 

 

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

 

 

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.