ICANN ICANN Email List Archives

[gnso-idng]


<<< Chronological Index >>>    <<< Thread Index >>>

Re: [gnso-idng] 3rd Draft on Sting Similarity

  • To: gnso-idng@xxxxxxxxx
  • Subject: Re: [gnso-idng] 3rd Draft on Sting Similarity
  • From: Avri Doria <avri@xxxxxxx>
  • Date: Mon, 14 Dec 2009 09:00:26 +0100

hi,

thanks for all the changes.  I think it is fine except for one small quibble in 
the last sentence indicated below.

thanks

a.

On 13 Dec 2009, at 18:10, Eric Brunner-Williams wrote:

> 
> 
> 3rd draft version
> 
> I've removed the examples, both meaningful and cooperative, and made what I 
> understand to be the changes suggested by Avri.
> 
> 
> ===
> Councilors,
> 
> During the past weeks the participants in the gnso-idng@xxxxxxxxx mailing 
> list (IDNG) have discussed, on the mailing list and in conference calls, 
> aspects of the situation which exists following the Board's vote at Seoul.
> 
> One area of discussion which raises a policy issue is confusingly similar 
> strings. Because this seems an area where the obvious right thing has already 
> been done we need to draw attention to two aspects which have been overlooked.
> 
> In pseudo-haiku, the problem we present to the Council is:
> 
> two strings
> one meaning
> one applicant
> ouch!
> 
> 
> cooperation
> considered
> harmfull
> ouch!
> 
> 
> First, the current definition of "similar" is now more complex than "visual 
> similarity", and to some appears to include "meaning", which may be so broad 
> a definition as to create more ills than it cures.
> 
> Second, the underlying assumption in the evaluation process is that each 
> evaluation is independent of all other evaluations, even if they are from the 
> same or associated applicants.
> 
> These, a rule (about a string in an application) and a meta-rule (about all 
> applications), have a consequence which we suggest is not desirable.
> 
> 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 one case which is more likely 
> to exist for applications for IDN strings than for restricted 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 confusion is harmful. This rational is not 
> universally correct. There are instances where confusion results in no harm, 
> and more importantly, where "confusion" creates benefit.
> 
> It is possible that applicants for two or more similar strings could, upon 
> failure, resort to extended evaluation, where the cause of the failure is 
> similarity with an existing TLD. Present registries seeking similar IDN 
> delegations could simply cost in the extended evaluation cost as part of the 
> application cost. This is inelegant, but not fatally so.
> 
> Unfortunately, for applicants simply seeking two or more delegations with 
> similar meaning, independent of script, initial evaluation failure and 
> extended evaluation are not available. The contention set consisting of two 
> strings and one actual applicant go to auction, with absurd outcome from the 
> business perspective, and tragic outcome from the language perspective, as 
> one script choice eliminates all others, for some meaning defined 
> construction of "similarity".
> 
> The IDNG participants thank the Council for its time and attention 
> considering its initial work product.

Actually the JIG charter was it first work product.
I suggest either cutting this sentence after 'attention,'
or replace 'considering .... product' with 'considering this issue'

> 
> 
> This ends the 3rd draft. Listees, edit to your heart's content.
> 
> Eric
> 
> 
> 





<<< Chronological Index >>>    <<< Thread Index >>>

Privacy Policy | Terms of Service | Cookies Policy