Thanks for sharing this, Avri,

It sounds as though the discussion on confusing similarity is going way
beyond the guidance of the initial GNSO Council report -- to say that
"“.arigato” and “.ありがとう” read and understood as the same and thus
likely considered confusingly similar," in particular example.

The point of gTLD expansion is to enable competition among strings that
*users* can adopt as part of the identifiers / locators for their own
goods and services, not to signify their origin with a given class of
registry services.  The trademark analysis is mistaken if it assesses
everything from the after-the-dot perspective, and forgets that users
need a wide range of relatively generic options in order to create their
own string.TLD identifiers.

Hope this can add to the discussion.
--Wendy

Avri Doria wrote:
> Hi,
> 
> These two documents are up for discussion in the IDNG Drafting team iI participate in, i would be interested in NCSG feedback.
> 
> thanks
> 
> a.
> 
> 
> Begin forwarded message:
> 
> a statemet on the issue of confusingly similar:
> 
>>
>> Councilors,
>>
>> During the past months the participants in the GNSO IDN gTLD (IDNG) Drafting Team (DT) have discussed on the [log in to unmask] mailing list and in conference calls aspects of the Board's vote in Seoul to approve the IDN ccTLD fast track process as that decision relates to IDN gTLDs.
>>
>> One area of discussion which may raise a policy issue is that of the process for applying for confusingly similar gTLD strings. We would like to draw attention to two issues that may have been overlooked in the DAG regarding implementation of new gTLD regarding confusingly similar names.
>>
>> First, it appears that an application for an IDN representation of an existing or new LDH (or IDN) gTLD string could be denied because it is confusingly similar to the other TLD string.  Likewise, it seems that an application for a gTLD in one script could be denied because it is similar to an application for a version of that gTLD in another script, even if it is by the same applicant. If this is the case, then the implementation plans in the DAG may need to be clarified.  Otherwise, for example, an applicant may not apply for both “.cafe” and “.café”, or in a more illustrative example, “.arigato” and “.ありがとう” read and understood as the same and thus likely considered confusingly similar based on recommendation 2 of the GNSO new gTLD recommendations where the WTO TRIPS agreement and the 1883 Paris Convention on the Protection of Industrial Property was cited as references. 
>>
>> Second, the underlying assumption in the evaluation process as described in the DAG is that each evaluation is independent of all other evaluations.  This assumption has consequences which we suggest may not be desirable under certain situations, especially where an applicant is apply for multiple representations of a TLD string, as the case would be for IDN strings in addition to an LDH string.  Multiple applications of confusingly similar TLD strings (or TLD strings likely to cause confusion) may form a contention set. Under the current rules in DAGv3, only one application who's string is a member of a contention set may proceed towards delegation. Whether the choice is by order of creation, or amongst contemporaries, by community evaluation and/or auction, the result is the same. One member of an (extended, in the sense of including existing registries) contention set thrives. All others fail.
>>
>> This is the proper and correct end, except for cases where a TLD string is applied for by the same applicant, which is more likely to exist for applications for IDN strings than for restricted LDH (ASCII letters, digits, hyphen) strings. That case is where two, or more, applications for similar strings are advanced by a single applicant, or two or more cooperating applicants.
>>
>> The fundamental rational is that similarity causing confusion is harmful. This rational as applied by the DAG is not clear, especially for instances where similarity results in no harmful confusion, and more importantly, where "similarity" creates benefit.
>>
>> Besides the above 2 points:
>> 1.	Likelihood of IDN gTLD strings that are confusingly similar to new or existing gTLD strings
>> 2.	Benefits of having such similar gTLD strings, especially for the adoption of IDN
>>
>> The DT considered the possibility of resorting to extended evaluation for such applications, but found them to be undesirable, especially given the importance of IDN deployment for the development of the DNS and the global Internet, and the problematic situation where an applicant applies for two or more confusingly similar strings (which could result in a contention set) within a single round.
>>
>> The IDNG participants thank the Council for its time and attention to the issues raised in this document. We recommend that the Council decide whether some additional policy work or implementation clarification may be needed  to avoid what we believe are undesirable and unintended consequence described above.
>>
>>
> 
> and a proposed charter for a WG
> 
> 
> 
> ------------------------------------------------------------------------
> 
> 


-- 
Wendy Seltzer -- [log in to unmask]
phone: +1.914.374.0613
Fellow, Silicon Flatirons Center at University of Colorado Law School
Fellow, Berkman Center for Internet & Society at Harvard University
http://cyber.law.harvard.edu/seltzer.html
http://www.chillingeffects.org/
https://www.torproject.org/