Amadeu Abril i Abril

CORE Association on its own name, but also as .quebec Registry Services Provider

INTRODUCTION

This comment refers to string similarity evaluation but is a proposed addition, not a comment on any concrete proposal listed. 

THE ISSUE: SIMILARITY WITHOUT CONFUSION.

The rules on String Similarity Evaluation claim to have as a goal to prevent user confusion between similar gTLDs. But the concrete implementation in 2012 (and nothing seems to have changed now) was, and still is, based in strict similarity. More precisely. in visual similarity between applied-for strings (betweent hemselves or in relation to other existing TLDs).

The fact, though, is that there is one specific case where similarity (in fact, near-identity) between strings is aimed, precisely, at preventing confusion, not causing it. The most clear, and real, example of such situation is PointQuébec, the Registry Operator of .quebec, applying for .québec.

Both strings are indeed very similar. But they are not technically “variants” in rules of IDN as approved. They certainly are, though, the very same thing for the vast majority of the users: not only .quebec is the English-language version of .québec, but for the overwhelming majority of users, be them French-speakers or not, IDN-aware or not, writing “labels without diacritics” is the way to go for Latin script-based languages, due to the weight of tradition.

Both strings should not coexist were 2 differtent TLDs. But the fact is that these 2 strings may and should be managed as a single TLD. That is, managed as if they were variants of one anoother. In that case, no confusion could arise. On the contrary, users would not need to guess, remember, or even bother which equivalent version of the label they should use.

RATIONALE: THE SAME ENTITIES PRINCIPLE, AS IN VARIANT TLDS

The solution to prevent confusion, and the intent PointQuébec did and still does have since 2012 for the concrete case mentioned above, is to apply the “Same Entity” or “3R Principle”: Both TLDs have to be managed by the same entity as Registry Operator, but also each second-level domain has to be sponsored by the same Registrar and allocated to the same Registrant. All these should be accompanied by the required technical and contractual guarantees.

This is the solution applied to the management of TLDs with variants, but the same rationale applies to TLDs which are equivalent variations, even if they are not variants, said in the strict technical sense.

THE SOLUTION: THE CCnSO APPROACH

The approach proposed above, that is, considering near-equivalent variations of TLDs such as an ASCII and an IDN string for the same name has already been considered by the ccnSO in the so-called "fast-track” procedure for adding IDN versions of ccTLDs. It recommends the “same entity” principle proposed here. 

See page 28 of this document

COHERENT APPROACH BETWEEN ccTLDs AND gTLDs

It is generally a good policy to treat similarly what is similar. This applies to IDN variants with respect with the described self-designated equivalent variations, but also applies tothe solutions applied by the ccNSO, as described above, and the GNSO. In this regard we would like bringing your attention to the folliwng ICANN Board of Directos Resolution:

Resolved (2019.03.14.09), the Board requests that the ccNSO and GNSO keep each other informed of the progress in developing the relevant details of their policies and procedures to ensure a consistent solution, based on the Variant TLD Recommendations, is developed for IDN variant ccTLDs and IDN variant gTLDs.

https://www.icann.org/en/board-activities-and-meetings/materials/approved-resolutions-regular-meeting-of-the-icann-board-14-03-2019-en#2.a

In the event that the DNS Stability Panel or the EPSRP determines a requested IDN ccTLD string is confusingly similar to an existing two-letter ASCII ccTLD corresponding to the same country or territory as the requesting country or territory entity, the DNS Stability Panel or the EPSRP shall document this in its report to ICANN.

If, at the time of the request or within two months after receiving the notification of the findings of the DNS Stability Panel, the requester, and, if considered necessary by ICANN, the relevant public authority, provide(s) a clarification that documents and demonstrates to ICANN that:

1. The intended manager for the requested IDN ccTLD and the manager for the existing two-letter ASCII ccTLD are one and the same entity; and

2. The intended manager shall request the delegation for the IDN ccTLD string if validated; and

3. The IDN ccTLD and ccTLD shall remain to be managed by one and the same entity, and

4. The intended manager shall agree to specific and pre-arranged conditions with the goal to mitigate the risk of user confusion as of the moment the IDN ccTLD becomes operational,

then the requested string is deemed to have passed the DNS Stability Panel evaluation.

COHERENT APPROACH BETWEEN ccTLDs AND gTLDs

It is generally a good policy to treat similarly what is similar. This applies to IDN variants with respect to the described self-designated equivalent variations, but also applies to the solutions applied by the ccNSO, as described above, and those that should be applied by the GNSO. In this regard, we would like to bring your attention to the following ICANN Board of Directos Resolution:

Resolved (2019.03.14.09), the Board requests that the ccNSO and GNSO keep each other informed of the progress in developing the relevant details of their policies and procedures to ensure a consistent solution, based on the Variant TLD Recommendations, is developed for IDN variant ccTLDs and IDN variant gTLDs.

https://www.icann.org/en/board-activities-and-meetings/materials/approved-resolutions-regular-meeting-of-the-icann-board-14-03-2019-en#2.a

PROPOSAL TO THE IDN EPDP WG

We therefore request that the following addition is made to the Phase 1 Report in its Section related to String Similarity Evaluation:

That, in case the String Similarity Evaluation Panels find that 2 TLD strings (either one applied for in the new round)s) in respect to an existing gTLD, or both applied during such new round) are similar, the evaluation decision should take into account whether both TLDs will be managed as “false variants”; that is, as self-designated equivalent variations of the same string according to the “same entity” principle. This means that were both gTLDs would be managed by the same Registry, and each self-designated equivalent variation of second-level domains would be managed by the same Registrar and allocated to the same Registrant, the decision should be that, in that case, the similarity would not lead to any confusion, and that both TLDs (both strings) could coexist under the described conditions.

The Registry proposing to manage those gTLDs should commit to the concrete conditions of such “same entity” principle, or “3Rs principle” in its TLD Registry Agreement, in an enforceable way (both in Exhibit A and Specification 11, or its equivalent Sections in the future Agreement).

Additionnally, such String Similarity Evaluation decision should be reevaluated, should the conditions under which the TLDs are managed differ from the agreed upon.

Proposal from CORE Association to add the "same entity" principle for strings which are equivalent variations without being variants technically, with respect to string similarity evaluation, in line with the ccNSO solution