[Gnso-newgtld-wg-wt3] Proposals on String Similarity/String Confusion Objections

[Jeff Neuman]

All,

A group of registry operators came up with some recommendations for Subsequent Procedures including recommendations on string similarity and string confusion objections.  As this is still being reviewed by the RySG as a whole it does not have any formal status yet.  That said, these recommendations apply to the subject matter for our meeting in a few hours.  Therefore, I am submitting this in my personal capacity for now.  I look forward to discussing these on the call.


************************************************************************************

Recommendation 1: String Similarity Review
It is the opinion of the String Sub-team that GNSO Policy #2 is satisfactory for the purpose of String Similarity.  GNSO Policy #2 states: “Strings must not be confusingly similar to an existing top‐level domain or a Reserved Name.”

It is our recommendation that implementation of this policy can be improved pertaining to applications received by ICANN for singular and plural strings.

More specifically, the scope of the String Similarity Review should be broadened to encompass single/plurals of TLDs on a per-language basis in addition to the existing visual similarity standard. Contention sets would be formed on a per-language basis. A dictionary will be the tool used to determine the singular and/or plural version of the string for the specific language. In this expanded process, applications for single/plural variations of each string would be placed in a contention set and applications for a single/plural variations of an existing string would not be permitted.

By way of example, if applications were submitted for the strings .gâteau, .gâteaux, .cake, and .cakes, then the strings .gâteau and .gâteux (French) would be placed in contention with one another, but not with the corresponding translations .cake and .cakes (English), which would comprise a separate contention set. Additional contention sets could continue to be formed through the String Confusion Objection Process.

Recommendation 2: String Confusion Objections
During the 2015 round, the String Confusion Objection process resulted in indirect contention situations for identical strings proposing similar use cases. For example, in one objection determination, the strings .car/.cars were determined to be confusingly similar, while in another they were determined to not be confusingly similar. This resulted in a situation where the ability or inability for the two strings to coexist depended on which party prevailed at auction.

This outcome was seen as inconsistent by many in the community (both objectors and respondents) and saw late stage intervention by the ICANN board to introduce a limited appeals process. The appeals process was only made available to the applicants who were placed in contention, and not to the party filing the objection.

We believe that these could be largely avoided by allowing a single String Confusion Objection to be filed against all applicants for a particular string, rather than requiring a unique objection to be filed against each application. We propose the following:


  *   An objector could file a single objection that would extend to all applications for an identical string.
  *   Given that an objection that encompassed several applications would still require greater work to process and review, the string confusion panel could introduce a tiered pricing structure for these sets. Each applicant for that identical string would still prepare a response to the objection.
  *   The same panel would review all documentation associated with the objection. Each response would be reviewed on its own merits to determine whether it was confusingly similar.
  *   The panel would issue a single determination that identified which applications would be in contention. Any outcome that resulted in an indirect contention would be explained as part of the response.
  *   A limited appeals process should be available to both the objectors and the respondents to handle perceived inconsistencies.

Recommendation 3: Sword Tool
We recommend that ICANN do away with the Sword Tool that was presented to applicants as part of the 2012 round. There was little correlation between the Sword Results and the actual outcomes of the String Similarity Review and String Confusion Objection Process and, thus, that the tool was more misleading to applicants than helpful.


Jeffrey J. Neuman
Senior Vice President |Valideus USA | Com Laude USA
1751 Pinnacle Drive, Suite 600
Mclean, VA 22102, United States
E: jeff.neuman at valideus.com<mailto:jeff.neuman at valideus.com> or jeff.neuman at comlaude.com<mailto:jeff.neuman at comlaude.com>
T: +1.703.635.7514
M: +1.202.549.5079
@Jintlaw


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-newgtld-wg-wt3/attachments/20170221/57241a92/attachment-0001.html>