Dear Councilors, Please see the ODP Team's questions. Feel free to provide your inputs to the answers, which Jeff will put together. Regards, Philippe -------- Message d'origine -------- De : Jeff Neuman <jeff@jjnsolutions.com> Date : 11/04/2022 22:10 (GMT+01:00) À : FOUQUART Philippe INNOV/NET <philippe.fouquart@orange.com>, "Tomslin Samme-Nlar (mesumbeslin@gmail.com)" <mesumbeslin@gmail.com>, "Sebastien@registry.godaddy" <sebastien@registry.godaddy> Cc : Steve Chan <steve.chan@icann.org> Objet : FW: SubPro ODP: Policy Question Set #3 Dear GNSO Council Leadership, Please find enclosed ODP Question Set #3 from ICANN’s ODP Team. I have not yet read over the questions, but am forwarding this to you right away so that you can get it to the Council List as soon as possible. In line with our process, I have posted this document as a Google Doc found here<https://docs.google.com/document/d/1OtddNIUaAitHiJPE8pBTBcirTaDjyzPkcZY6BJmJ...>. I will then take a first cut at answers to the questions, but anyone on the Council can weigh in with comments or suggestions. Please let me know if you have any questions. Sincerely, Jeff [cid:image001.png@01D84DBE.4195F020] Jeffrey J. Neuman Founder & CEO JJN Solutions, LLC p: +1.202.549.5079 E: jeff@jjnsolutions.com<mailto:jeff@jjnsolutions.com> http://jjnsolutions.com From: SubPro-ODP <subpro-odp-bounces@icann.org> On Behalf Of Michael Karakash Sent: Monday, April 11, 2022 3:57 PM To: SubPro ODP Mailman List <subpro-odp@icann.org> Subject: [SubPro-ODP] SubPro ODP: Policy Question Set #3 Hi Jeff, I hope you are having a productive week. We recently drafted a new Policy Question Set (#3) focused on the topic of String Similarity that I am attaching to this email as well as pasting below. We are looking forward to our call scheduled for later this month and will circulate an agenda closer to the meeting date. Please don’t hesitate to reach out if you have questions or need any clarification before then. Thank you! Best, Michael Karakash SubPro ODP: Policy Question Set 3 - Topic 24: String Similarity 1. Affirmation 24.1: The Working Group affirms Recommendation 2 from the 2007 policy, which states “Strings must not be confusingly similar to an existing top-level domain or a Reserved Name.” Question: Recommendation 2 from 2007 does not allow for exceptions to the ‘confusingly similar’ requirement. In light of the outputs of Topic 24, the ODP will assume 24.1 is an affirmation with modification because the working group is adding new elements to the standard of confusing similarity. Does the Council agree with this assumption? 1. Affirmation 24.2 states: Subject to the recommendations below, the Working Group affirms the standard used in the String Similarity Review from the 2012 round to determine whether an applied-for string is “similar” to any existing TLD, any other applied-for strings, Reserved Names, and in the case of 2-character IDNs, any single character or any 2- character ASCII string. According to Section 2.2.1 of the 2012 Applicant Guidebook, “similar” means “strings so similar that they create a probability of user confusion if more than one of the strings is delegated into the root zone.” In the 2012 round, the String Similarity Panel was tasked with identifying “visual string similarities that would create a probability of user confusion. ”The Working Group affirms the visual standard for determining similarity with the updates included in the recommendations below. Question: Recommendation 24.3 introduces the concept of singular and plural to string similarity, meaning “mouse” and “mice” would now be considered confusingly similar. Therefore, does the Council agree with the ODP’s assumption that Affirmation of 24.2 is an affirmation with modification, meaning that the standard for determining string similarly is visual and, in light of Recommendation 24.3, also grammatical for subsequent rounds of new gTLDs? 1. Recommendation 24.3 states “Applications will not automatically be placed in the same contention set because they appear visually to be a single and plural of one another but have different intended uses.” Question: Does the Council agree with the ODP Team that based on this recommendation, all applications must provide an intended-use RVC? This will allow during subsequent rounds that the intended use of an applied-for string can be compared to the intended use of an existing string to determine whether it passes the string similarity review. 1. Recommendation 24.3 states “Applications will not automatically be placed in the same contention set because they appear visually to be a single and plural of one another but have different intended uses. “ Question: Does the Council agree that based on the wording of 24.3, the intended-use test is only applicable to the possible delegation of singulars/plurals not other visual or grammatical similarities? Meaning that applied for strings .example and .examples might both be delegated if they provide an RVC that indicates different intended use. However, .example (english) and .exemple (french), if determined to be visually similar, will never both be delegated. 1. Recommendation 24.3 states “The Working Group recommends using a dictionary to determine the singular and plural version of the string for the specific language.” Question: Does the Council agree that for each round dictionaries should be updated to the most recently published version and it is only that version that is authoritative for the purposes of accessing string similarity? 1. Recommendation 24.3 speaks only about singular/plural versions of the same word in the same language, not of other grammatical variations of the same word such as gender or conjugation. Question: Does the Council agree with the ODP assumption that only singular/plural versions can both be delegated if the intended use is different, not any other grammatical forms? If the Council agrees, the ODP team believes the following example of .hand below will be applicable for subsequent rounds: .hand and .hands * IF .hand and .hands are both applied-for strings in English THEN they both can be delegated if their intended use is different because they are singular/plural versions of one another. * IF .hand and .hands are both applied for strings in German THEN they would be placed in a contention set ONLY IF they deemed to be visually confusingly similar, and one may be delegated subject to the outcome of the contention set resolution. * IF .hand and .hände are both applied for strings in German THEN they can be delegated if their intended use is different because they are singular/plural of one another. * IF .hand is an applied for English string and .hands is an applied for German string then they would be placed in a contention set ONLY IF they deemed to be visually confusingly similar, and one may be delegated subject to the outcome of the contention set resolution. Question: In light of this, does the Council agree that this will likely require each application to indicate which languages/scripts they intend to use via an RVC and that those languages must always be offered for the life of the TLD? And to allow for future intended use determination, these RVCs will have to be submitted by all strings not just those in contention sets so that applications in future rounds can be assessed against existing RVCs. _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.
