May 2017 - comments-idn-guidelines-03mar17@icann.org

[Comments-idn-guidelines-03mar17] Registries Stakeholder Group (RySG) comments on Internationalized Domain Name (IDN) Implementation Guidelines
by svg＠milathan.ltd May 2, 2017

May 2, 2017

Please find attached, in PDF format, the Registries Stakeholder Group (RySG) comments on Internationalized Domain Name (IDN) Implementation Guidelines. In the interest of time, the RySG did not conduct a formal vote on these comments. They were circulated and debated on our mailing list, with no member expressing opposition to their submission. Please do not hesitate to contact me or any member of the RySG Executive Committee should you have any questions. Best regards, Stéphane Van Gelder RySG Vice Chair (Policy)

1 0

[Comments-idn-guidelines-03mar17] Comments from the IAB on IDN Implementation Guidelines
by Suzanne Woolf May 1, 2017

May 1, 2017

The IAB welcomes the opportunity to comment on "Guidelines for the Implementation of Internationalized Domain Names" (https://www.icann.org/en/system/files/files/draft-idn-guidelines-03mar17-en… <https://www.icann.org/en/system/files/files/draft-idn-guidelines-03mar17-en…>) As a general observation, the IAB found this document to be a good step in support of the deployment of Internationalized Domain Names in TLDs. It promotes the use of IDNs while also supporting careful specification and conservative implementation of registry and registrar policy. A few specific comments follow: Section 1.1: This is worded so that the document relies upon RFC 2119 keywords ("must," "should") but it is not, strictly speaking, a protocol document. It might be helpful to clarify that this normative language defines what it means to comply with these guidelines, but can't by itself specify protocol compliance. Section 2.1: The clear statement of support for compliance with IDNA2008 standard as a target, while also supporting a clean transition from other specifications, also seems appropriately conservative. Section 2.2 and 2.3: These sections aknowledge implicitly that there isn't always a good answer, that sometimes various combinations of a language and a script, or of possible variants, are not fully compatible across all the options and the registry simply has to make a decision. It might be helpful to state as much explicitly. Sec. 2.4, subsection 13, final paragraph: this is a sentence fragment, and not entirely clear. Is it meant as an example of the references appropriate for review to meet the guideline in the previous paragraphs for registry-side processing for IDN variants? Overall, Sec. 2.2-2.5 seem to provide a reasonable balance between clear guidance and discretion for TLDs trying to form IDN policies that support their user communities. Sec. 2.2-2.5 in the document seems to be trying to operationalize the provisions in RFC 5894 that registries have a policy and that they allow only those characters whose use they fully understand, but without quite stating that as the goal. A few words clarifying that point might help both ICANN and TLD operators in cases where it's not entirely clear how best to follow the guidelines. Respectfully submitted, Suzanne Woolf for the IAB

1 0

[Comments-idn-guidelines-03mar17] FW: [Ext] Comments from India-Internationalized Domain Name (IDN) Implementation Guidelines
by Sarmad Hussain May 1, 2017

May 1, 2017

Comments received from Govt. of India. Regards, Sarmad Hussain From: tsantosh(a)meity.gov.in [mailto:tsantosh@meity.gov.in] Sent: Monday, May 01, 2017 11:13 AM To: Sarmad Hussain <sarmad.hussain(a)icann.org> Cc: JS DeitY Rajiv Bansal; Pradeep Kumar Verma; Harish Chowdhary; shubham nixi Subject: [Ext] Comments from India-Internationalized Domain Name (IDN) Implementation Guidelines Dear Mr. Sarmad, Please find below the comments from India on Internationalized Domain Name (IDN) Implementation Guidelines https://www.icann.org/public-comments/idn-guidelines-2017-03-03-en For a diverse and global Internet where all languages and scripts can be used easily the universal acceptance for Unicode domain names (IDNs) and email addresses (EAIs) is crucial.The following are suggested. I. promote a better public understanding of the issue, countering the trend that "IDN URLs are for phishing" Rationale i. Efforts to promote universal acceptance, to stop the misuse of IDNs for fraud and phishing is essential. Just very recently, many news sources reprised a security advice that directed users to disable the display of IDN URLs in browsers, to prevent phishing by using whole-script confusable domain names: (https://www.wordfence.com/blog/2017/04/chrome-firefox-unicode-phishing/) ii. Due to the point mentioned above, IDNs would start to be widely rejected throughout the Internet. It is thus an important responsibility by ICANN to prevent these dangers. II. To free the Internet from whole-script confusables (Similar characters in diffrenet scripts) iii. To establish, a basic principle, that any two domain names that look confusable to an average Internet user must be considered variants of the same domain name and must never be registered to different registrants. i. As confusability is by definition a subjective feature, there are technical standards (i.e. Unicode TR-39) which provide an implementable definition and algorithm for detecting confusable domain names.It is advisable to implement these standards in the proposed guidelines. iv. In addition to that, allowing the registration of confusable domain names is not just hampering adoption of IDNs, but it is also creating significant financial and organizational costs to the rest of the Internet. Even before any successful phishing attack happens, software developers and Internet service providers dealing with all sorts of Internet applications are forced to take into account possible homoglyph (look-a-like characters) attacks and implement countermeasures. It is much more efficient to detect and stop these situations just once at the registry level, rather than have the entire Internet run around in circles to deal with them. v. To the specific issue of whole script confusables, point 17 of the current recommendation is a "may" rather than a "must". But if we feel that it should move to a must. Replacing “may” to must will help to stop registration of the domains like "g00gle.com", to put blocks on cyber-squatting. vi. In point 16 of the proposed draft, and to make the detection and blocking of whole-script confusables compulsory. The first sentence of point 16 should thus be replaced by the following TLD registries must apply to new registrations whole label evaluation rules that minimize whole-script confusables as determined by Unicode Technical Standard #39: Unicode Security Mechanisms; new domain names that according to those rules are whole-script confusables in respect to an existing domain name must be a) allocated to the same registrant of the existing domain name, or b) blocked from registration. III. To deal with Emojis i. There should be separate guidelines to deal with EMOJIS. E.g. https://❤❤❤.ws/ -- Warm Regards T.Santhosh Scientist 'E' / Additional Director Ministry of Electronics and Information Technology Government of India Electronics Niketan, 6 CGO Complex, New Delhi - 110003 (India) Tel: +91-11-24364741, 24301831

1 0