[lac-discuss-en] Fwd: [ALAC] Singular/Plural in new gTLDs

Carlton Samuels carlton.samuels at gmail.com
Wed Sep 4 19:27:29 UTC 2013


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


---------- Forwarded message ----------
From: Alan Greenberg <alan.greenberg at mcgill.ca>
Date: Wed, Sep 4, 2013 at 8:05 AM
Subject: Re: [ALAC] Singular/Plural in new gTLDs
To: Rinalia Abdul Rahim <rinalia.abdulrahim at gmail.com>
Cc: ALAC Working List <alac at atlarge-lists.icann.org>


Thanks Rinalia.

Regarding 1, yes, is the decision were revered, it would establish some new
(or larger) contenction sets.

On blocking a name so that it is only one of the TLDs (or alternatively
bundling them together), a bit problematic if the two TLDs are operated by
different registries.

Alan


At 04/09/2013 12:53 AM, Rinalia Abdul Rahim wrote:

 Dear Alan,
>
> I support doing something about this.
>
> 2 thoughts:
> 1. A positive result of intervention on this matter where singular and
> plural strings are deemed similarly confusing (and thus not allowed) will
> result in the strings implicated to be in contention. This will no doubt
> heat up the string contention and objection resolution process. No valued
> judgment in this, just stating an observation of what to expect.
>
> 2. There is a practice in IDN variant management that can theoretically be
> applied to avoid applicants from having to "buy" two confusingly similar
> names (if the policy is not to allow singular and plural names). This is
> the practice/rule of allocating both names to an applicant and then
> blocking one of those names or allowing both names (perhaps for the price
> of one - need to check on whether they charge for the "variants" - I
> suspect not). And yes, the IP-interested folks might have something to say
> about it depending on whether they are in favor of over-protection or less.
>
> Best regards,
>
> Rinalia
> On Sep 4, 2013 12:29 PM, "Alan Greenberg" <<mailto:alan.greenberg@**
> mcgill.ca <alan.greenberg at mcgill.ca>>alan.greenberg@**mcgill.ca<alan.greenberg at mcgill.ca>>
> wrote:
> That could be done. But first I wanted to find out if there was any
> interest within the ALAC. If there is little interest, I will do something
> on my own, but with far less impact than if it is advice from the ALAC.
>
> Also note that this is an issue that is extremely time-sensitive, since if
> the issue is to be re-opened, it will have to be done very quickly.
>
> Alan
>
> At 03/09/2013 11:58 PM, Salanieta Tamanikaiwaimaro wrote:
> Dear Alan,
>
> Thank you for monitoring this space. I would suggest opening the
> discussions within the broader At Large to solicit views and feedback,
> preferably if the discussions could ensue on both the mailing list as well
> as the wiki before a statement is drafted.
>
> Kind Regards,
> Sala
>
> Sent from my iPad
>
> On Sep 4, 2013, at 2:02 PM, Alan Greenberg <<mailto:alan.greenberg@**
> mcgill.ca <alan.greenberg at mcgill.ca>>alan.greenberg@**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>
> >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>
> >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>>
> ALAC at atlarge-lists.**icann.org <ALAC at atlarge-lists.icann.org>
> > https://atlarge-lists.icann.**org/mailman/listinfo/alac<https://atlarge-lists.icann.org/mailman/listinfo/alac>
> >
> > At-Large Online: <http://www.atlarge.icann.org>**
> 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)>
> >http**s://community.icann.org/**display/atlarge/At-Large+**
> Advisory+Committee+(ALAC)<https://community.icann.org/display/atlarge/At-Large+Advisory+Committee+(ALAC)>
>
>
> ______________________________**_________________
> ALAC mailing list
> <mailto:ALAC at atlarge-lists.**icann.org <ALAC at atlarge-lists.icann.org>>
> ALAC at atlarge-lists.**icann.org <ALAC at atlarge-lists.icann.org>
> https://atlarge-lists.icann.**org/mailman/listinfo/alac<https://atlarge-lists.icann.org/mailman/listinfo/alac>
>
> At-Large Online: <http://www.atlarge.icann.org>**
> 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)>
> >http**s://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<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)<https://community.icann.org/display/atlarge/At-Large+Advisory+Committee+(ALAC)>


More information about the lac-discuss-en mailing list