RE: [gnso-idng] outstanding IDNG discussions: 1. confusingly similar TLD string / 2. IDN gTLD WG Charter

[Adrian Kinderis <adrian@xxxxxxxxxxxxxxxxxx>]

Edmon,

I follow your confusingly similar discussion and largely agree.

I do not agree at all with your IDNG BAG charter. I will fight hard to stop it. 
Existing gTLD's already have a leg up (polyopoly position and 'objection 
rights' in the DAG. Why do you deserve more? Giving you any further rights or 
preferences is simply over the top.

Thanks.

Adrian Kinderis

-----Original Message-----
From: owner-gnso-idng@xxxxxxxxx [mailto:owner-gnso-idng@xxxxxxxxx] On Behalf Of 
Edmon Chung
Sent: Thursday, 18 February 2010 8:31 PM
To: gnso-idng@xxxxxxxxx
Subject: [gnso-idng] outstanding IDNG discussions: 1. confusingly similar TLD 
string / 2. IDN gTLD WG Charter

Hi Everyone,

It seems to be becoming usual that I open with an apology for my tardiness.... 
Anyway, apologies, and here are my thoughts on the 2 outstanding issues this 
group had been considering:

1. confusingly similar TLD string applications, especially as it relates to IDN 
gTLDs
- See attached edits based on Eric's earlier draft and Chuck's edits (also 
included a clean version below for easy reference)
- Used less controversial strings as examples
- Added why we think this should be considered:
        - that such applications are likely to be plentiful and should not be 
considered based on exceptions to the process but part of the process
        - that it relates to both existing and future gTLDs

2. IDNG working group formation
- As promised earlier, will take another crack at the formation of a WG 
discussing IDN gTLD implementation.  Rather than focusing on timing (or the 
rather seemingly sensitive concept of "Fast Track"), would like to introduce a 
concept of IDNG BAG (Based on Another GTLD)
- See attached revised draft incorporating 1 above
- Key differences from previous draft:
        - not considering "Fast" track
        - potentially additions to the DAG somewhat like what we have now for 
geographical names or may be a separate parallel process
        - given 1 above, how such applications should be processed
        - parts of 1. above is incorporated in the background section of the 
charter

Hope to hear other's thoughts on the above and attached.

Edmon





PS. a clean version of 1. for easy reference:

Councilors,

During the past months the participants in the GNSO IDN gTLD (IDNG) Drafting 
Team (DT) have discussed on the gnso-idng@xxxxxxxxx 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.