ICANN79 Meeting:

ICANN79 Prep Week Session: Name Collision Analysis Project Study 2 Update

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

Publications:

SAC123: Report on the Evolution of Internet Name Resolution   

...

• Focus is on handling of Urgent Requests in proposed gTLD registration data policy
• Urgent Requests refer to imminent threats to life, injury, infrastructure or child exploitation
• Proposed policy requires response to Urgent Requests in 24 hours generally
• SSAC contends proposed policy for Urgent Requests is not fit for purpose
• Definition and required response times are incompatible
• Questions if need and rationale for separate Urgent Request process is fully justified
• Existing ICANN policy and industry practices offer useful precedents
• Proposed extensions allow responses up to 7 days, not reflecting urgency
• Lack of concrete data on frequency and handling of such requests currently
• Risks reputation of ICANN multistakeholder model effectiveness 

           Recommendations:

• • Add structure to ensure Urgent Requests handled expediently
  • Tighten response time requirements to be fit for purpose
  • Gather data on Urgent Requests for future policy making

...