[Gnso-epdp-idn-team] Your Input Requested: String Similarity Review Level & Rationale

[Michael Bauland]

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 at knipp.de
      Software Development        E-mail: Michael.Bauland at knipp.de

                                  Register Court:
                                  Amtsgericht Dortmund, HRB 13728

                                  Chief Executive Officers:
                                  Dietmar Knipp, Elmar Knipp