[Gnso-newgtld-wg] Fourth Topical Questions: String Similarity Outstanding Questions

Mon Dec 7 17:49:32 UTC 2020

Thanks Jeff
If there is strong support in the WG to move away from the recommendation (option 1) then this should be to adopt option 2 instead, and I support Donna's reasoning.  Brand effectively are not a singular/plural of the corresponding word since they do not operate in the dictionary sense.  Further, the closely controlled registration and use provisions under Spec 13 ensure that the dotBrand registry operator is readily able to maintain responsibility for the use of second level names in the TLD.

Susan Payne
Head of Legal Policy
Com Laude | Valideus
E: susan.payne at comlaude.com<mailto:susan.payne at comlaude.com>

From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces at icann.org> On Behalf Of Donna at registry.godaddy
Sent: 04 December 2020 19:11
To: Jeff Neuman <jeff at jjnsolutions.com>; gnso-newgtld-wg at icann.org
Subject: Re: [Gnso-newgtld-wg] Fourth Topical Questions: String Similarity Outstanding Questions

Hi Jeff, all

Leaning toward 2. Ban the co-existence of Singulars and Plurals except for where either one or both of the strings are a Specification 13 (Brand TLD).

There is a reasonable case to be made that 'brands' are readily discernible by users as highlighted by the examples in your email below and as such do not represent the same challenges for user confusion and trying to hold a TLD operator to registrations that are consistent with the intended use of the TLD.

Donna

Donna Austin
Head of Registry Policy
GoDaddy Registry

From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces at icann.org<mailto:gnso-newgtld-wg-bounces at icann.org>> On Behalf Of Jeff Neuman
Sent: Thursday, December 3, 2020 9:45 AM
To: gnso-newgtld-wg at icann.org<mailto:gnso-newgtld-wg at icann.org>
Subject: [Gnso-newgtld-wg] Fourth Topical Questions: String Similarity Outstanding Questions

Notice: This email is from an external sender.

All,

This is the Fourth topical E-mail on outstanding questions being "put to the list."  The first was on Predictability, second on Applicant Support, third was the Guidebook, and this covers string similarity (Topic 24).

Remember:  We are down to the wire on this, so unless you have a VERY strong objection to these, we will put these into the document.  If you do have a big issue with the responses to these (all of which were previously discussed and in emails over the past 1.5 months), please let us know ASAP.  Only comments that provide the rationale for the objection with proposed replacement text to address the specific outstanding questions will now be considered.

Lets not let the perfect be the enemy of the good.

  1.  Intended Use Comments

     *   Comments:  Some commenters have expressed concerns about Recommendation 24.3 in that it calls for an evaluation of the "intended use" of an applied-for string to determine whether terms that appear to be the singular/plural of each other will be allowed to co-exist (our paraphrasing).

     *   WG Recommendations

                                                    i.     Recommendation 24.3.  ...Specifically, the Working Group recommends prohibiting plurals and singulars of the same word within the same language/script in order to reduce the risk of consumer confusion. For example, the TLDs .EXAMPLE74 and .EXAMPLES may not both be delegated because they are considered confusingly similar. This expands the scope of the String Similarity Review to encompass singulars/plurals of TLDs on a per-language/script basis.

           *   An application for a single/plural variation of an existing TLD or Reserved Name will not be permitted if the intended use of the applied-for string is the single/plural version of the existing TLD or Reserved Name. For example, if there is an existing TLD .SPRINGS that is used in connection with elastic objects and a new application for .SPRING that is also intended to be used in connection with elastic objects, .SPRING will not be permitted...

     *   Path Forward

                                                    i.     First, put aside for the moment the issues expressed by the Board on "content" and assume for now that we can make these recommendations.  An e-mail later will address the content / bylaws issue.

                                                   ii.     Second, most of the Working Group had little/no issue when the Plural / Singular evaluation was between two brands or a brand and a generic application.

           *   Examples:  Apple (brand) / apples (generic); Caterpillar (Brand) / caterpillars (generic); Gap (brand) / gaps (generic); Whirlpool (Brand) / whirlpools (generic).

                                                  iii.     Remember also that we have added sections to the Report to now require that applicants describe their proposed use of a TLD in their application and that the evaluators can ask Clarifying questions if they are unable to ascertain the intended use from the Applicant Responses (IG 24.4).  Finally, If both versions (singular/plural) are allowed, then both applicants (in the case where they are both applied for strings) or the 1 successful applicant (in the case where the application is for a singular/plural of an existing TLD) will have to agree to be bound by its commitment to use the TLD only in the manner in which it proposed in its application.

           *   Again, please ignore the potential Bylaws issue FOR NOW.  We promise that we will address this later.

                                                  iv.     Here are the options we have

           *   Leave the language As-Is;
           *   Ban the co-existence of Singulars and Plurals except for where either one or both of the strings are a Specification 13 (Brand TLD); or
           *   Ban the co-existence of Singulars and Plurals regardless of intended use completely.

                                                   v.     Absent agreement on either 2 or 3, we will stick with the language that we have (Option 1).  A lot of work has gone into this already so we need a good amount of support from within the Working Group to change.

Please have your comments (If any) by no later than 23:59:59 UTC on Monday, December 7, 2020.

Sincerely,

Jeff & Cheryl
SubPro Co-Chairs

________________________________
The contents of this email and any attachments are confidential to the intended recipient. They may not be disclosed, used by or copied in any way by anyone other than the intended recipient. If you have received this message in error, please return it to the sender (deleting the body of the email and attachments in your reply) and immediately and permanently delete it. Please note that the Com Laude Group does not accept any responsibility for viruses and it is your responsibility to scan or otherwise check this email and any attachments. The Com Laude Group does not accept liability for statements which are clearly the sender's own and not made on behalf of the group or one of its member entities. The Com Laude Group includes Nom-IQ Limited t/a Com Laude, a company registered in England and Wales with company number 5047655 and registered office at 28-30 Little Russell Street, London, WC1A 2HN England; Valideus Limited, a company registered in England and Wales with company number 06181291 and registered office at 28-30 Little Russell Street, London, WC1A 2HN England; Demys Limited, a company registered in Scotland with company number SC197176, having its registered office at 15 William Street, South West Lane, Edinburgh, EH3 7LL Scotland; Consonum, Inc. dba Com Laude USA and Valideus USA, headquartered at 1751 Pinnacle Drive, Suite 600, McLean, VA 22102, USA; Com Laude (Japan) Corporation, a company registered in Japan having its registered office at Suite 319,1-3-21 Shinkawa, Chuo-ku, Tokyo, 104-0033, Japan. For further information see www.comlaude.com<https://comlaude.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-newgtld-wg/attachments/20201207/7f2bf963/attachment-0001.html>