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

["Edmon Chung" <edmon@xxxxxxxxxxxxx>]

Thanks for the quick response.

Perhaps the IDNG BAG should be seen in the light that it is not only about 
"existing" gTLDs, it is also about future gTLDs.
I am not proposing "special rights" and I continue to agree with the principle 
already set out in the IDN WG years ago that "special rights" or "priority" not 
be provided to existing gTLDs.
What I am saying is that there should be consideration for how these 
applications would progress through the process.  Currently the DAG lacks a 
mechanism to gracefully handle IDNG BAGs (IDN gTLDs Based on Another GTLD) be 
it an existing gTLD or a new gTLD that is being proposed.

The IDNG BAG proposal is directly a response on the confusingly similar 
discussion.

Edmon



> -----Original Message-----
> From: Adrian Kinderis [mailto:adrian@xxxxxxxxxxxxxxxxxx]
> Sent: Thursday, February 18, 2010 5:44 PM
> 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.