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

["Gomes, Chuck" <cgomes@xxxxxxxxxxxx>]

It seems to me that we can treat the two issues independently.  If there is 
support for the confusingly similar statement, we can send it to the Council.  
Separately, we should decide whether there is enough support for the proposed 
charter of a WG.

Chuck 

> -----Original Message-----
> From: owner-gnso-idng@xxxxxxxxx 
> [mailto:owner-gnso-idng@xxxxxxxxx] On Behalf Of Adrian Kinderis
> Sent: Thursday, February 18, 2010 4:44 AM
> To: Edmon Chung; gnso-idng@xxxxxxxxx
> Subject: RE: [gnso-idng] outstanding IDNG discussions: 1. 
> confusingly similar TLD string / 2. IDN gTLD WG Charter
> 
> 
> 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.
> 
> 
> 
>