[SubPro-IRT] Awarding of Similar Strings to Same Entity operating prior TLD - Topic 24

[Jeff Neuman]

Anne,

You are correct that the exception came from the IDN ePDP Phase 1 and there is a lengthy rationale as to why that is the case.

Having been around for the discussions back in 2005-2007/2008 as well as for the entirety of SubPro, it is not as though the subject has never come up, it has.  I remember it came up with respect to the singular/plural discussions, but was not supported at the time.

So, I would not phrase it as the policy issue of whether the same entity should be able to operate “similar” strings has not been specifically addressed, but that there has never been a consensus for an exception to the general rule (except with respect to variants).

Anyone is free to bring up the policy issue and start a new PDP on that issue again, but that would be for subsequent rounds after this next round.

Sincerely,

Jeffrey J. Neuman
Founder & CEO
JJN Solutions, LLC
+1.202.549.5079
Jeff at jjnsolutions.com
________________________________
From: SubPro-IRT <subpro-irt-bounces at icann.org> on behalf of Anne ICANN <anneicanngnso at gmail.com>
Sent: Thursday, May 23, 2024 2:05 AM
To: Lars Hoffmann <lars.hoffmann at icann.org>; Elisa Busetto <elisa.busetto at icann.org>
Cc: subpro-irt at icann.org <subpro-irt at icann.org>
Subject: Re: [SubPro-IRT] Awarding of Similar Strings to Same Entity operating prior TLD - Topic 24

So I'm thinking that this actually comes out of the Affirmation of a 2007 policy that is contained in 24.1 of the Sub Pro Final Report stating that a string that is similar to a pre-existing string cannot proceed.  But then the exception for officially designated variants applied for by the "same entity" must have come out of the IDN work in EPDP Phase 1?

So it appears that the question of an application for a similar string by the "same entity" that operates the pre-existing similar string has not been specifically addressed in policy work.

Anne

Anne Aikman-Scalese
GNSO Councilor
NomCom Non-Voting 2022-2024
anneicanngnso at gmail.com<mailto:anneicanngnso at gmail.com>


On Tue, May 21, 2024 at 2:59 PM Anne ICANN <anneicanngnso at gmail.com<mailto:anneicanngnso at gmail.com>> wrote:
Lars and Elisa,

Regarding the section of the draft AGB shown below from Topic 24, could you please point me to the specific policy Recommendation that results in the conclusion that the only exception to the String Similarity ban on a subsequent application proceeding for a similar string is the Same Entity and RZ-LGR classified Variant determination?  In other words, which PDP Policy Recommendation states that a similar string applied for by the same entity prior holder may not proceed unless the newly-applied for similar string is listed as an RZ-LGR variant?

Was it formally deliberated on and determined in policy work that a similar string should not be awarded to the same entity operating a previously-awarded TLD unless the new similar string is a "variant"?

Or are we saying that this question of a new application for a similar string to a previously-awarded TLD made by the "same entity" has not, in fact, been directly deliberated and addressed in policy work?  (As you can imagine, this relates to the GNSO Council's recent request for an Issues Report in relation to the diacritics issues.)

The AGB draft language re the only exception appears below.

Thank you,
Anne

1.4.1.
Strings Similar With Existing gTLDs or their Variant
Strings
If any applied-for gTLD string or any of its variant strings is found to be Similar to any of the existing gTLDs or any of their variant strings, the gTLD application will not be able to proceed. The exception is when the applied-for gTLD string is part of the same variant-strings-set as the existing gTLD it was found
Similar to, and the applicant is the same registry operator, then the application can proceed with evaluation (as a variant gTLD).


Anne Aikman-Scalese
GNSO Councilor
NomCom Non-Voting 2022-2024
anneicanngnso at gmail.com<mailto:anneicanngnso at gmail.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/subpro-irt/attachments/20240523/3a6603a2/attachment-0001.html>