Dear SSR2 RT members, The below answers have been added to the Q&A Google doc: https://docs.google.com/document/d/14eJwDGP-LvS9ltTmZoh1i19Fi0_pB2nJ4JYMsS7l... [docs.google.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_documen...>. There is now 1 outstanding question in the ICANN SSR workstream. We expect this outstanding answer this week. Review Team volunteers: Denise, Kerry-Ann, Zarko Workstream: ICANN SSR Topic 7: Perform an assessment how effectively ICANN has implemented its processes to ensure compliance regarding registrar agreements and the consensus policies. Outstanding questions: 0 Q: During the presentation in LA in October 2017, Francisco referred to internal procedures to deal with SLA monitoring cases that require follow up, please provide SSR2 with a copy? A: ICANN org’s internal operating procedures for addressing SLA monitoring cases that require follow-up can be described generally, but are not documented in a form for external publication. The procedures include detailed steps to be followed by the technical team that is on-call when responding to performance issues found in the DNS and RDDS. For example, when each service threshold is met, the procedures indicate which of the registry operator’s contacts to alert, how to alert them (e.g., via email and/or phone), and in what order they are attempted to be contacted. The procedures also describe what logs should be collected and when, to check whether there is a maintenance window scheduled for the service/TLD and whether the issue is caused by a TLD revocation. Additionally, the procedures indicate the thresholds at which escalation for a potential EBERO event are to be started. Q: What is the status of the registry service provider certification program? Is ICANN Org recommending any changes? What is the status of this issue within the Subsequent Procedures PDP? A: The Registry Service Provider (RSP) pre-approval was a topic of discussion <https://community.icann.org/download/attachments/74587868/Letter%20from%20Ry...> of a small group within the RySG. The small group delivered a recommendation<https://mm.icann.org/pipermail/gnso-newgtld-wg/2018-February/000935.html> to the Subsequent Procedures PDP working group and ICANN org provided recommended changes. It is up to the PDP WG to make its recommendations to the GNSO Council. The Subsequent Procedures working group discussed the recommendations in the course of its deliberations and formulated a set of initial recommendations that were published for public comment on 3 July 2018<https://www.icann.org/public-comments/gtld-subsequent-procedures-initial-201...>. The RSP pre-approval recommendation can be reviewed in section 2.2.6 of the Initial Report.<https://gnso.icann.org/sites/default/files/file/field-file-attach/subsequent...> Please note that the working group is developing final recommendations, which may not be the same as those found in the Initial Report. Review Team volunteers: Norm, Ram Workstream: ICANN SSR Topic 6: Perform an assessment of how effectively ICANN has implemented its processes around vetting registry operators and services concerning the New gTLD Delegation and Transition process. Outstanding questions: 0 Q: Referencing the EBERO testing of Fall, 2017 (https://schd.ws/hosted_files/icann60abudhabi2017/08/7%20EBERO%20Arias.pdf. Has the Root Cause Analysis been conducted? If so, is there a reference to the report? A: The slides referenced in the question describe the EBERO exercises conducted up to that point in time. Each of these exercises were conducted in the context of a registry that was being decommissioned, rather than cases of registry failure. ICANN org asked the registry operators involved in those exercises, who were each operating a TLD that was being decommissioned, for permission to use their TLDs to do EBERO exercises just prior to termination and removal from the root. The issues described on slides 18 and 19 are related to the internal, detailed procedures that are followed in an EBERO event. The issues identified during the exercises were minor (e.g., missing step to send email to someone) and did not require a root cause analysis. All identified issues were fixed promptly after the exercises by updating the EBERO procedures. Review Team volunteers: Russ, Laurin, Zarko Workstream: DNS SSR Topic: IDN domain names (glyph phish) Outstanding questions: 0 Q: Does ICANN support studies and research into the abuse of the DNS / URLs for phishing? If so, is there any documentation, outcome reports, etc? A: ICANN’s Office of the CTO (OCTO) provides anonymized monthly reports from the Domain Abuse Activity Reporting (DAAR)<https://www.icann.org/octo-ssr/daar> system, which monitors the amount of spam, phishing, malware, and botnet domains in the DNS. Also note Recommendation 16 from the CCT Review Team, which the ICANN Board directed<https://www.icann.org/en/system/files/files/resolutions-final-cct-recs-score...> in part to the SSR2 Review Team: Further study the relationship between specific registry operators, registrars, and DNS Security Abuse [which includes phishing] by commissioning ongoing data collection, including but not limited to, ICANN Domain Abuse Activity Reporting (DAAR) initiatives. For transparency purposes, this information should be regularly published, ideally quarterly and no less than annually, in order to be able to identify registries and registrars that need to come under greater scrutiny, investigation, and potential enforcement action by ICANN organization. Upon identifying abuse phenomena, ICANN should put in place an action plan to respond to such studies, remedy problems identified, and define future ongoing data collection. OCTO will continue to publish DAAR reports. Should the above recommendation be implemented, further studies on phishing may be carried out Q: Does ICANN liaise with the main browser manufacturers regarding URL handling, e.g. IDN display, warnings, etc? A: Liaising with browsers for IDN display and warnings relates to Universal Acceptance of domain names. The community has organized a Universal Acceptance Steering Group (UASG) to undertake these tasks, which ICANN org has been supporting. Soon after its formation, in 2015/2016 UASG found multiple issues in how browsers were handling domain names. For example, in the browsers, domain names under new top-level domains were being used as search items instead of domain names and IDNs were not being displayed correctly. UASG engaged in discussions with Google, Apple, and Microsoft to raise these issues about the respective browsers. Some discussions were also done with Mozilla. UASG performed an evaluation of browsers, detailed in its report UASG016<https://uasg.tech/wp-content/uploads/2017/09/UASG-Report-UASG016.pdf>, which tested 17 URLs in eight browsers on six different operating systems (four desktop, two mobile). A reasonable support was shown in most browsers on desktop platforms (with some challenges for domain names in right-to-left scripts) but more varied results were found in mobile platforms. See the report for further details. UASG is now considering to undertake the browser evaluation exercise again in FY20 as it reconsiders the evaluation criteria for testing these browsers (e.g. reconsider testing for open dot) and as it looks to include more Android based browsers from China. Best, Jennifer -- Jennifer Bryce MSSI Associate Project Manager Internet Corporation for Assigned Names and Numbers (ICANN) Email: jennifer.bryce@icann.org Skype: jennifer.bryce.icann www.icann.org