[ALAC] Singular/Plural in new gTLDs

[Carlton Samuels]

Good catch, Dev.  But I have to tell y'all the fundamental problem is the
use of English.

They had a yen to ring fence some organic claims to 'similarity' and
clearly struggled to put it in words. IMHO, at the top of their minds was
the possibility of claims of discrimination and cultural bias.

Oh, you say you don't understand? So let me use the blunt instrument of
political incorrectness here; think the troubles some cultures have with
certain sounds [diphthongs] of the English language.

Seems the writer was struggling to settle on the contextual meaning of the
word 'probable'. Poor sod should have exhausted all the synonymic variants
before he/she made up his/her mind.

..and I am absolved by the results of the several assessments.

-Carlton


==============================
Carlton A Samuels
Mobile: 876-818-1799
*Strategy, Planning, Governance, Assessment & Turnaround*
=============================


On Thu, Sep 5, 2013 at 4:52 PM, Dev Anand Teelucksingh <devtee at gmail.com>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)
>