[IDN-WG] Call for public comments to the Reference Label Generation Rulesets (LGRs) for the Second Level

[Bill Jouris]

 Hi Justine, 
Please forgive the slow response.
I think that there are several points in this document which At Large may wish to address. 
   
   - The document says 


The gTLD registry operators may consult these reference LGRs while they design their IDN tables to promote consistency. A registry would choose the set of code points and associated variant code points and rules which best serves its end users.  [emphasis added]


That is, there is no requirement that a registry block the registration of domain names where the proposed SLD differs from an existing registered domain name only by a variant code point.  That is a recipe for DNS Abuse. Note also that, when considering whether to block a variant domain name, the economic incentives for the registries are entirely in favor of allowing the registration.  

   
   - The various Script References were developed for TLDs by various language Generation Panels.  They therefore have a number of serious flaws when it comes to variants.  


   
   - Numerals (0 thru 9) are excluded, because they cannot be used in TLDs.  However, numeral 0 is quite similar to the circle glyphs which occur in at least a half dozen languages.  Numeral 1 is quite similar to the vertical line glyphs which also occur in multiple scripts.  And Numeral 3 is quite similar to the Latin Letter Ezh (ʒ). 
   - Numerous code points are included in the MSR, but are not part of the repertoires developed by the language Generation Panels.  They are also, therefore, not considered for possible variants.  But because they are included in the MSR they can be used in SLDs. 
   - The definition of "variant" was kept extremely narrow for the Generation Panels.  The rationale for this was that extremely similar, but not identical, cases would be considered by the Similarity Review Panel.  But nothing similar is even suggested by this document.  Not are these "confusables" even mentioned, let alone any restriction suggested.



   
   - The implication appears to be that, in making judgments about SLDs, the registries all have sufficient expertise in the various scripts to identify similarities.  Both within a script and between scripts.  The chances that, for example, a registry for a Chinese language TLD would have sufficient expertise in Armenian to notice conflicts with a Greek SLD are basically nil.  Similarly a registry for English names is unlikely to have the expertise to notice conflicts between Chinese and Japanese names.  Once we get into scripts like Georgian and Lao, the situation only gets worse. 

I believe that:  a) A much broader definition of variants is required for SLDs. b) A detailed listing of those variants should then be included here (given the unsuitability of the lists in the Reference LGRs).c) the blocking of variants should be mandatory, not left to the registries. 
Bill Jouris
    On Thursday, August 27, 2020, 06:37:27 AM PDT, Justine Chew <justine.chew.icann at gmail.com> wrote:  
 
 Folks,

Does anyone have anything to raise for or contribute to the call for public
comments?

https://www.icann.org/public-comments/reference-lgrs-second-level-2020-08-24-en


Thanks,

*Justine Chew*
Member, At-Large Advisory Committee (ALAC) 2019-2021
Internet Corporation for Assigned Names and Numbers (ICANN)
https://atlarge.icann.org/
------
_______________________________________________
IDN-WG mailing list
IDN-WG at atlarge-lists.icann.org
https://atlarge-lists.icann.org/mailman/listinfo/idn-wg

IDN WG Wiki: https://community.icann.org/display/atlarge/At-Large+IDN+Policy
_______________________________________________
By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.