[ALAC] Singular/Plural in new gTLDs

[Dev Anand Teelucksingh]

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)