[ALAC] Singular/Plural in new gTLDs

Wed Sep 4 16:54:53 UTC 2013

+1. That's how I see it.

-Carlton

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

On Wed, Sep 4, 2013 at 11:48 AM, Evan Leibovitch <evan at telly.org> wrote:

> On 4 September 2013 10:44, Rinalia Abdul Rahim <
> rinalia.abdulrahim at gmail.com
> > wrote:
>
> > They would have to be bundled and allocated to the same entity, Alan. No
> > other way around it.
> >
>
>
> Not necessarily.
>
> As has been said, plurals and singulars could be added to the same
> contention set. That is, applications for ".hotels" and applications for
> ".hotel" would be grouped as if they were multiple applications for the
> same string. Any applicant that applied for both plural and singular --
> probably defensively -- could apply for a refund for one should they
> choose. That doesn't mean that the winning applicant would get both. They'd
> get the one they applied for and the other(s) would be unallocated.
>
> Having singulars and plurals of a string in parallel delegation -- even
> from the same registry -- would still be a source of consumer confusion.
>
> - Evan
>
>
>
> >
> > Best,
> >
> > Rinalia
> > On Sep 4, 2013 10:42 PM, "Alan Greenberg" <alan.greenberg at mcgill.ca>
> > wrote:
> >
> > >  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" <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 <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
> .
> > 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)
> > 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
> > > > 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)
> > >
> > >
> > _______________________________________________
> > 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)
> >
>
>
>
> --
> Evan Leibovitch
> Toronto Canada
>
> Em: evan at telly dot org
> Sk: evanleibovitch
> Tw: el56
> _______________________________________________
> 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)
>