ICANN/GNSO GNSO Email List Archives

[council]


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

[council] Re: [gtld-council] Outcome of discussion on string checks on Wed 30 Aug in Amsterdam

  • To: Council GNSO <council@xxxxxxxxxxxxxx>
  • Subject: [council] Re: [gtld-council] Outcome of discussion on string checks on Wed 30 Aug in Amsterdam
  • From: Mawaki Chango <ki_chango@xxxxxxxxx>
  • Date: Sat, 9 Sep 2006 08:01:50 -0700 (PDT)
  • Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=sbb2wCuw989VF0834OoWSEqyaIitkI2u2i5Z6xsyVc32WFLI1DJxjiSp7moRBUJs6q0DSgTW4KPqAR+IHjWCSDGpp8ctQF7A8/0pMOXBwIFckvKheWyU8w8LieySeNRlBi3gM4jlCfYiyqEtvDD/GpX055fvYgUteh8c2xaDjys= ;
  • In-reply-to: <57AD40AED823A7439D25CD09604BFB54033A9536@balius.mit>
  • Sender: owner-council@xxxxxxxxxxxxxx

I am not sure if the definition of "confusingly similar" provided
here is clear enough to avoid contentious interpretations, and if it
totally reflects the discussions in Amsterdam. To my recollection, at
the end of the discussions there was a widely shared opinion that we
should restrain the confusion criterion to typo-confusion (i.e., in
what the user can see and what s/he can imply from it).

As explained in the meeting, everything in the root servers,
including IDN, is just ASCII-based codes (coding character strings),
and I'm assuming that there is no risk for a root server to make
confusion even if the coding strings differ only by one slight
character. Thus, having no reason to assume probable massive
confusions based on the possibility of a few user's mistakes (always
possible in user behavior for whatever reasons), the security and the
stability of the Internet wouldn't be at risk here.

Mawaki


--- Bruce Tonkin <Bruce.Tonkin@xxxxxxxxxxxxxxxxxx> wrote:

> Process for string checks:
> 
> (1)   Staff will make a determination and can engage appropriate
> expert advice.
> 
> (2)   Public comment (which may include input from Governments or the
> GAC) that is specific to the criteria for a new string.   
> 
> (3)   If staff think there may be an issue, then it is put to a panel
> of experts with appropriate background.
> 
> 
> String criteria:
> 
> (a)   That the TLD string should not be confusingly similar to an
> existing TLD string.  Confusingly similar means there is a
> likelihood of
> confusion on the part of the relevant public.   
> 
> (b)   The string must not infringe the legal rights of any third
> party.
> (consistent with current requirements of Registered Name Holder -
> see
> clause 3.7.7.9 of the gTLD registrar accreditation agreement)
> 
> (c)   The string should not cause technical issues (e.g not
> .localhost, .exe etc)
> 
> (d)   The string should not be <controversial, political, cultural,
> religious terms> (develop text related to public policy issues with
> GAC)
> 
> (e)   The string should not be a reserved word.
> 
> 
> Dispute resolution:
> 
> (a) A dispute resolution process using independent arbitrators
> where
> existing registry operators could challenge a decision made by
> ICANN
> staff regarding whether or not a new gTLD string is confusingly
> similar
> to an existing gTLD string.  If a string is successfully challenged
> as
> being misleadingly similar, then no operator may subsequently
> register
> it.
> 
> (b) A dispute resolution process using independent arbitrators
> where
> existing trademark holders could challenge the string, based on
> UDRP.
> 
> 





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