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