[ALAC] Singular/Plural in new gTLDs

[Rinalia Abdul Rahim]

They would have to be bundled and allocated to the same entity, Alan. No
other way around it.

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)
>
>