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 toplevel 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:

 

 

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@valideus.com or jeff.neuman@comlaude.com

T: +1.703.635.7514

M: +1.202.549.5079

@Jintlaw