[ALAC] Singular/Plural in new gTLDs

Thu Sep 5 22:01:21 UTC 2013

The confusingly similar objection results are 
interesting. Although I have not gone through 
them carefully, there are already cases where 
plural is deemed to be confusingly similar to 
singular, and I think also the opposite. And a 
case where .shop won an objection over a Chinese 
string meaning "online shopping" because the 
meaning was similar and someone who reads both 
English and Chinese could be confused. A real grab-bag.

See 
<http://images.go.adr.org/Web/AmericanArbitrationAssociation/%7B3d7531bb-c0b8-462e-ab7a-2a6572300363%7D_ICANN_DRP_StringConfusion_Objections.pdf>http://images.go.adr.org/Web/AmericanArbitrationAssociation/%7B3d7531bb-c0b8-462e-ab7a-2a6572300363%7D_ICANN_DRP_StringConfusion_Objections.pdf.

Alan

At 05/09/2013 05:52 PM, Dev Anand Teelucksingh wrote:
>Some thoughts:
>
>The AGB process should have empowered the String Similarity Panel
>during the Initial Evaluation to consider similarity as how a legal
>rights objection panel hearing a legal rights objection by an
>intergovernmental organization (IGO) would have to consider similarity
>"Whether the applied-for gTLD is identical or similar, including in
>appearance, phonetic sound or meaning, to the name or acronym of the
>objecting IGO" (Page 167 of the AGB, Section 3.5.2) and place such
>string applications in Non-Exact Match Contention Sets.
>
>And given the objective of the String Similiarity as cited in 2.2.1.1
>("to prevent user confusion and loss of confidence in the DNS
>resulting from delegation of many similiar strings" ; "“similar” means
>strings so similar that they create a probability of user confusion if
>more than one of the strings is delegated into the root"), the ALAC
>(and the IO) should have also been given standing (and funding!) to
>object to file String Confusion Objections ("The applied-for gTLD
>string is confusingly similar to an existing TLD or to another
>applied-for gTLD string in the same round of applications"), instead
>of just existing TLD operators and gTLD applicants in the gTLD
>application round.
>
>And the publishing of the String Similiarity Review a mere two weeks
>before the end of the objection period was extremely late and should
>have been published much earlier for the community to deal with this
>issue.
>
>Section 2.2.1.1.2 "Review Methodology" on page 58 of the AGB says this:
>
>The [String Similarity] panel will examine all the algorithm data and
>perform its own review of similarities between strings and whether
>they rise to the level of string confusion. In cases of strings in
>scripts not yet supported by the algorithm
>(https://icann.sword-group.com/algorithm/), the panel’s assessment
>process is entirely manual.
>
>The [String Similarity]  panel will use a common standard to test for
>whether string confusion exists, as follows:
>
>Standard for String Confusion  String confusion exists where a string
>so nearly resembles another visually that it is likely to deceive or
>cause confusion. For the likelihood of confusion to exist, it must be
>probable, not merely possible that confusion will arise in the mind of
>the average, reasonable Internet user. Mere association, in the sense
>that the string brings another string to mind, is insufficient to find
>a likelihood of confusion."
>
>This suggests that applied for strings that are of singular and plural
>forms ("mere association") are insufficient to find for similarity
>between such string applications.
>
>However, in section 2.2.1.1.3, "Outcomes of the String Similarity
>Review", there is this:
>
>"An application that passes the String Similarity review is still
>subject to objection by an existing TLD operator or by another gTLD
>applicant in the current application round.
>That process requires that a string confusion objection be filed by an
>objector having the standing to make such an objection. Such category
>of objection is not limited to visual similarity. Rather, confusion
>based on any type of similarity (including visual, aural, or
>similarity of meaning) may be claimed by an objector."
>
>Yet, the mandate of the DRSP hearing string confusion objections in
>page 165 of the AGB "3.5.1 String Confusion Objection" repeats only
>the standard for string confusion in 2.2.1.1.2 :
>"A DRSP panel hearing a string confusion objection will consider
>whether the applied-for gTLD string is likely to result in string
>confusion. String confusion exists where a string so
>nearly resembles another that it is likely to deceive or cause
>confusion. For a likelihood of confusion to exist, it must be
>probable, not merely possible that confusion will arise in the
>mind of the average, reasonable Internet user. Mere association, in
>the sense that the string brings another string to mind, is
>insufficient to find a likelihood of confusion."
>
>and not the the advice in 2.2.1.1.3. This is inconsistent and should
>be noted in a statement. Mention could also be made to note the
>ongoing confusion of the string confusion objections where certain
>singular and plural pairs are judged to be similar and others pairs
>are not.
>
>-
>Dev Anand
>
>
>On Wed, Sep 4, 2013 at 3:18 PM, Alan Greenberg 
><alan.greenberg at mcgill.ca> wrote:
> > At 04/09/2013 12:53 PM, Carlton Samuels wrote:
> >>
> >> Thanks for bringing this forth, Alan.  Yes to instigating the discussion
> >> in the community, ALAC included, as well; we 
> can always just forward Alan's
> >> note to the regional lists.
> >
> >
> > Indeed!  That is what regional folks on the ALAC list are supposed to do if
> > there is interest.
> >
> >
> >
> >>  I can agree that the accepted definition of 'confusingly similar' narrows
> >> the understanding of how perception works. But all handwringing aside, the
> >> end result is likely negative impact on the end user. So, what do we do?
> >>
> >> I read Evan's intervention closely and quite frankly, cannot find fault
> >> with his analysis, including his take on the likely result of any ALAC
> >> statement. The good thing is as Evan says; users will find alternatives to
> >> mitigate the slight.  So I will not bounce 
> the rubble. But I would support a
> >> statement in abundant surety it is for 'political correctness' rather than
> >> any expectation of meaningful change of course.
> >
> >
> > I"m sure that users will survive most things. 
> But we are supposed to be here
> > to make things better. The fact that we cannot always do that should not
> > eliminate our need to do so if we can (at least that is my take).
> >
> > Alan
> >
> >
> >> -Carlton
> >>
> >>
> >> ==============================
> >> Carlton A Samuels
> >> Mobile: 876-818-1799
> >> Strategy, Planning, Governance, Assessment & Turnaround
> >> =============================
> >>
> >>
> >> On Tue, Sep 3, 2013 at 9:02 PM, Alan Greenberg
> >> <<mailto:alan.greenberg at mcgill.ca>alan.greenberg at mcgill.ca> wrote:
> >> On 24 June 2013 as requested by the GAC, the Board New gTLD Program
> >> Committee (NGPC) considered the issue of singular and plural stings being
> >> confusingly similar and decided to let the original process stand (subject
> >> to individual objections). The record of the decision can be found at
> >> 
> <http://www.icann.org/en/groups/board/documents/minutes-new-gtld-25jun13-en.htm#2.d>http://www.icann.org/en/groups/board/documents/minutes-new-gtld-25jun13-en.htm#2.d.
> >> Of particular note is a statement issued by three Board members (George
> >> Sadowsky, Olga Madruga-Forti and Cherine 
> Chalaby) who supported the decision
> >> but regretted that, based on the Applicant Guidebook wording, they did not
> >> believe that they had the leeway to vote 
> against it. One Board member (Mike
> >> Silber) did oppose the decision.
> >>
> >>
> >> A central issue is that "confusingly similar" test relies purely on visual
> >> similarity and in the eyes of most (who were involved in the decision),
> >> adding an "S" makes it a recognizably different string.
> >>
> >> The salient part of the Applicant Guidebook
> >> 
> (<http://newgtlds.icann.org/en/applicants/agb/guidebook-full-04jun12-en.pdf>http://newgtlds.icann.org/en/applicants/agb/guidebook-full-04jun12-en.pdf)
> >> is section 2.2.1.1 of Module 2.
> >>
> >>
> >> This review involves a preliminary comparison of each applied-for gTLD
> >> string against existing TLDs, Reserved Names (see subsection 2.2.1.2), and
> >> other applied-for strings. The objective of this review is to prevent user
> >> confusion and loss of confidence in the DNS resulting from delegation of
> >> many similar strings.
> >>
> >> Note: In this Applicant Guidebook, "similar" means strings so similar that
> >> they create a probability of user confusion 
> if more than one of the strings
> >> is delegated into the root zone.
> >>
> >> The visual similarity check that occurs during Initial Evaluation is
> >> intended to augment the objection and 
> dispute resolution process (see Module
> >> 3, Dispute Resolution Procedures) that addresses all types of similarity.
> >>
> >>
> >> I believe that the NGPC decision was incorrect. The problem is the belief
> >> that "visual similarity" relies purely on what, in computer terminology,
> >> would be called "pattern matching". Pattern matching is certainly part of
> >> human perception, but it is not limited to that. At issue is whether two
> >> strings will be PERCEIVED as being 
> equivalent, and perception is a far more
> >> complex (and less understood) issue.
> >>
> >> The real issue is that if you earlier found something at hilton.hotel, or
> >> had decided that the reviews at sheraton.hotel were something you trusted,
> >> will you later remember if it was really those sites or hilton.hotels or
> >> sheraton.hotels?
> >>
> >> At best, this could be considered a means of forcing anyone who registers
> >> a domain with .hotel or .hotels to register both, and map both of them to
> >> the same site. If that were to happen, the predictions of the Intellectual
> >> Property Constituency would be borne out, 
> and all of those using these TLDs
> >> would have to make double the investment in 
> domain names (presuming this is
> >> even possible with differing rules for each TLD). But the impact on users
> >> would be minimal.
> >>
> >> But since we cannot guarantee that both TLDs will remain forever in sync,
> >> we do have a user problem. Once cannot expect the typical Internet user to
> >> be able to differentiate between two such name spaces, and therefore I
> >> believe that we have a genuine case of "confusingly similar". And one that
> >> will arguably have as much or more impact on real Internet users, the ones
> >> that we are supposed to be here to defend, 
> than any other case I can recall
> >> in my 7 year involvement with ICANN At-Large.
> >>
> >> If others on the ALAC agree, I would be happy to create a statement
> >> reflecting what I have said here, that we can, in our formal Advisory
> >> Committee role, forward as Advice to the Board.
> >>
> >> Alan
> >>
> >> _______________________________________________
> >> ALAC mailing list
> >> <mailto:ALAC at atlarge-lists.icann.org>ALAC at atlarge-lists.icann.org
> >> https://atlarge-lists.icann.org/mailman/listinfo/alac
> >>
> >> At-Large Online:
> >> <http://www.atlarge.icann.org>http://www.atlarge.icann.org
> >> ALAC Working Wiki:
> >> 
> <https://community.icann.org/display/atlarge/At-Large+Advisory+Committee+(ALAC)>https://community.icann.org/display/atlarge/At-Large+Advisory+Committee+(ALAC)
> >>
> > _______________________________________________
> > ALAC mailing list
> > ALAC at atlarge-lists.icann.org
> > https://atlarge-lists.icann.org/mailman/listinfo/alac
> >
> > At-Large Online: http://www.atlarge.icann.org
> > ALAC Working Wiki:
> > 
> https://community.icann.org/display/atlarge/At-Large+Advisory+Committee+(ALAC)
>_______________________________________________
>ALAC mailing list
>ALAC at atlarge-lists.icann.org
>https://atlarge-lists.icann.org/mailman/listinfo/alac
>
>At-Large Online: http://www.atlarge.icann.org
>ALAC Working Wiki: 
>https://community.icann.org/display/atlarge/At-Large+Advisory+Committee+(ALAC)