Dear Ariel, Emily, Steve, dear team colleagues, my preference is either Level 1 or Level 2, depending on whether new variants can be "added/applied for" outside of "application rounds". Let me explain my decision for each level. Level 3 ======= I don't think Level 3 is required. It's a lot of additional effort, but it is not really giving important input. See the following abstract and very reduced example. Applied for TLD labels: * A (with blocked variant A1) * B (with no variants) Assumption: String similarity says B and A1 are confusingly similar. However, and that's important, A and B are *not* confusingly similar (if they were this example would be irrelevant for this question). Rationale: If we go for Level 3, then only either A or B (or none) can be delegated, but not both. I see no benefit in this restriction: Obviously (by assumption) A and B won't be confused. Also A won't be able to activate the TLD label A1. Thus, in my view, it's causing unnecessary work for the string similarity review and it's keeping one applicant form getting their TLD. Level 2 ======= If we allow adding of variants outside of application rounds, we need this level, simply because we don't want the string similarity review process to be started every time a TLD operator wants to add another variant. The late addition of variants must be as smooth and simple as possible. Any checks/validations that can be executed beforehand should be. Level 1 ======= If we allow adding of variants only in the initial application process and possibly during another application round (but not any arbitrary time in between), this is my preference. It reduces the effort to a minimum. There's no need to compare any allocatable variant that has not been requested so far. Possibility is high that it never will be requested. If such a variant does get requested in a later round, well, that's like a new application, it has to compete with all existing ones on a first come first serve basis (i.e., the existing ones take precedence). I think this already answers most items, but I'll nevertheless revisit the three explicit questions.
1. Why do you believe your preferred level of review is the most appropriate?
That's explained above.
2. Based on your preferred level of review, what would be the string similarity review’s impact on preventing user confusion and security/stability issues in the DNS? In other words, how effective would string similarity review be in preventing delegation of similar strings?
It would prevent user confusing, because any delegated string would undergo the string similarity review process. Similar to my argument under "Level 3", there's no benefit in comparing strings that will never be delegated (i.e., visible in the DNS). Just because a non-delegated variant of an existing TLD is confusingly similar to another TLD shouldn't cause those TLDs themselves to be blocking each other. They are *not* confusingly similar to each other.
3. Have you considered the feasibility of implementing the string similarity review based on your preferred level? For example, the complexity and costs involved to conduct the resulting review.
Yes, I have. :-) I suggest to only compare the labels that factually could be delegated (i.e., become visible in the DNS) until the next round of TLD application starts. This is the minimum requirement and I don't think we need more (actually more would even be harmful, see my arguments above). Please let me know, if anything in my arguments are difficult to understand, I'm happy to explain in more details. Best regards, Michael PS This is my personal view. The RrSG has not expressed any view itself. -- ____________________________________________________________________ | | | knipp | Knipp Medien und Kommunikation GmbH ------- Technologiepark Martin-Schmeisser-Weg 9 44227 Dortmund Germany Dipl.-Informatiker Fon: +49 231 9703-0 Fax: +49 231 9703-200 Dr. Michael Bauland SIP: Michael.Bauland@knipp.de Software Development E-mail: Michael.Bauland@knipp.de Register Court: Amtsgericht Dortmund, HRB 13728 Chief Executive Officers: Dietmar Knipp, Elmar Knipp