Hi all, today was the ICANN79 Prep Week Session: Name Collision Analysis Project Study 2 Update. The slides and recording can now be found here: https://icann79.sched.com/event/1ZUzp/name-collision-analysis-project-study-.... Below you can find some background, the findings and recommendations in a nutshell: Why NCAP? 2017: ICANN Board tasked SSAC to conduct studies to present data, analysis and points of view, and provide advice to the Board on name collisions -Specific advice regarding .home/.corp/.mail -General advice regarding name collisions going forward SSACs analysis and recommendations 1. Provide means to preserve security & stability of the internet namespace 2. Analyze real-life impact of name collisions and rationale to take this seriously 3. Directly impact next TLD round FINDINGS Finding 4.1 - The definition of what is a name collision has evolved over time Finding 4.2 - Name Collision Identification and Quantification 4.2.1 - Name collisions continue to persist within the DNS 4.2.2 - There are limitations with using currently available data sources for understanding root cause and risk, or designing mitigation and remediation plans 4.2.3 - .CORP and .HOME demonstrated that high volume is an insufficient measure for analyzing the potential of high-risk impact 4.2.4 - It is possible that future name collisions may occur on the scale of .CORP, .HOME, and .MAIL 4.2.5 - It is impractical to create a do-not-apply list of strings in advance of new requests for delegation Finding 4.3 - Data Manipulation Risks 4.3.1 - There is a risk for CDM (Critical Diagnostic Measurements) data manipulation 4.3.2 - Data manipulation has ramifications beyond the technical aspects of name collision that are influenced by when analysis occurs Finding 4.4 - Quantitative and Qualitative Measurement Considerations 4.4.1 - Critical Diagnostic Measurements are structurally quantitative and benefit from supplemental qualitative information 4.4.2 - The quantitative data in CDMs can be improved Finding 4.5 - Notification to users of name collisions is a critical function and separate from assessment or remediation 4.5.1 - Controlled Interruption as a notification method is effective in some but not all instances 4.5.2 - Other methods for notification may be used but remain untested. 4.5.2 - The criteria for the use of ICANN’s name collision reporting form negatively impacted its use Finding 4.6 - Predicting the rate and scale of change in the root zone is not possible in advance of a new round of gTLDs Finding 4.7 - There is no process for emergency changes to the root zone when considering the temporary delegation of strings Finding 4.8 - The adoption of IPv6 has grown significantly since 2012 Finding 4.9 - Reserved private-use strings may mitigate the risk of name collisions over the long term but not the short term. RECOMMENDATIONS Recommendation 1 - ICANN should treat name collisions as a risk management problem. Recommendation 2 - ICANN should adopt a consistent definition for name collision Recommendation 3 - ICANN should continue its education and outreach efforts to the community on the name-collision topic Recommendation 4 - ICANN should consider the need for mitigation and remediation efforts for high-risk strings 4.1 - ICANN should submit .CORP, .HOME, and .MAIL through the Name Collision Risk Assessment Process Recommendation 5 - ICANN must support the delegation of strings in order to improve the ability to conduct a name collision risk assessment Recommendation 6 - ICANN should establish and maintain a longitudinal DNS name collision repository in order to facilitate risk assessments and help identify potential data manipulation Recommendation 7 - ICANN should establish a dedicated Technical Review Team function Recommendation 8 - ICANN should replace the existing Name Collision Management Framework with the recommended Name Collision Risk Assessment Framework 8.1 - ICANN should not reject a TLD solely based on the volume of name collisions 8.2 - ICANN should request special attention to strings with high-impact risks during the name collision assessment process 8.3 - ICANN should update its public-facing name collision reporting process Recommendation 9 - ICANN should create a Collision String List 9.1 - ICANN should support a mechanism that allows applicants to request a string be removed from the Collision String List Recommendation 10 - ICANN must develop and document a process for the emergency change related to a temporarily delegated string from the root zone due to collision risk or harms Recommendation 11 - ICANN should not move ahead with NCAP Study 3 Have a nice evening! Best, Matthias __________________________ Ing. Mag. Matthias M. Hudobnik FIP, CIPP/E, CIPT, DPO, CIS LA matthias@hudobnik.at http://www.hudobnik.at @mhudobnik