SAC124 was published on 1 May 2024. All SSAC publications can be found at https://www.icann.org/en/ssac/publications.
SAC124: SSAC Advice on Name Collision Analysis includes the NCAP2 recommendations in the list of parsed Advice
| Recommendation | Description | Current Phase |
|---|---|---|
| Recommendation 1 | The SSAC recommends that the ICANN Board adopt and implement all the recommendations in NCAP Study Two. | Phase 2 | Understand |
| Recommendation 2 | The SSAC urges the ICANN Board to prioritize finding appropriate solutions within the proposed Name Collision Risk Assessment Framework that allow for sufficient data collection and analysis to properly inform mitigation strategies for name collisions. | Phase 2 | Understand |
| Recommendation 3 | The SSAC welcomes the engagement from ICANN Org and is committed to offer its expertise throughout the process. | Phase 2 | Understand |
Name Collision Analysis Project Study Two (NCAP2)
| Recommendation | Description | Current Phase |
|---|---|---|
| Recommendation 1 | ICANN should treat name collisions as a risk management problem | Phase 2 | Understand |
| Recommendation 2 | ICANN should adopt a consistent definition for name collision | Phase 2 | Understand |
| Recommendation 3 | ICANN should continue its education and outreach efforts to the community on the name-collision topic | Phase 2 | Understand |
| Recommendation 4.0 | ICANN should consider the need for mitigation and remediation efforts for high-risk strings | Phase 2 | Understand |
| Recommendation 4.1 | ICANN should submit .CORP, .HOME, and .MAIL through the Name Collision Risk Assessment Process | Phase 2 | Understand |
| Recommendation 5 | ICANN must support the delegation of strings in order to improve the ability to conduct a name collision risk assessment | Phase 2 | Understand |
| 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 | Phase 2 | Understand |
| Recommendation 7 | ICANN should establish a dedicated Technical Review Team function | Phase 2 | Understand |
| Recommendation 8.0 | ICANN should replace the existing Name Collision Management Framework with the recommended Name Collision Risk Assessment Framework | Phase 2 | Understand |
| Recommendation 8.1 | ICANN should not reject a TLD solely based on the volume of name collisions | Phase 2 | Understand |
| Recommendation 8.2 | ICANN should request special attention to strings with high-impact risks during the name collision assessment process | Phase 2 | Understand |
| Recommendation 8.3 | ICANN should update its public-facing name collision reporting process | Phase 2 | Understand |
| Recommendation 9.0 | ICANN should create a Collision String List | Phase 2 | Understand |
| Recommendation 9.1 | ICANN should support a mechanism that allows applicants to request a string be removed from the Collision String List | Phase 2 | Understand |
| 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 | Phase 2 | Understand |
| Recommendation 11 | ICANN should not move ahead with NCAP Study Three | Phase 2 | Understand |
