Sorry, you need to enable JavaScript to visit this website.

Advice to the ICANN Board

The page below shows recent advice sent to the ICANN Board by ICANN’s Security and Stability Advisory Committee and At-Large Advisory Committee and how the ICANN Board has addressed or is addressing each recommendation. Use the search to filter the list by keyword, and click any row to see more details about each item.

Important note: The current tool is in development. A more complete version ultimately tracking all advice to the ICANN Board, including advice received from the various Advisory Committees, as well as inputs from the ICANN Supporting Organizations and public forums, will be rolled out at future ICANN public meetings. ICANN plans to add additional features and tracking functionalities to the tool. All comments and suggestions are welcome: please email [email protected].

Search:

Date Topic Title Recommendation Action taken by Board Additional information Group Reference Current Status Group Acknowledged Date Completed or Closed URL for full info
20140912 Bylaws ALAC Statement on the Proposed Bylaws Changes Regarding Consideration of GAC Advice The ALAC salutes the Board's continued effort on the implementation of the ATRT1 and ATRT2 recommendations, specifically recommendation 11 of the ATRT1 and 6.5 of the ATRT2.
Notwithstanding, the ALAC is concerned that the proposed Bylaws changes regarding consideration of GAC advice by the Board may derive in an unbalanced weight to the GAC's advice compared to that of the other ACs or the policies proposed by each of the SOs.
Moreover, the ALAC observes a trend in the Internet Governance ecosystem that tends to push towards giving increased power to governments. The proposed Bylaws changes regarding consideration of GAC advice would add to this trend that we consider undesirable.
Considering that the BGRI has already designed a "Process for consultations between the [Board] and the [GAC]," the ALAC calls the Board to reconsider the proposed bylaws changes and continue to foster equal footing among all participants of the ICANN community.
If the Board is to implement this Bylaw change, the ALAC advises the Board to fully implement recommendation 9.1 of ATRT2 in the same round of Bylaw changes. This would preserve the delicate balance of advice coming from the ALAC, SSAC and RSSAC alongside the GAC.
The ALAC is confident that the Board will continue to implement the recommendations of the ATRT1 and ATRT2 in a way that safeguards the principles of the multi-stakeholder model, more specifically those that help bring balance among participants.		 The Board is considering the public comments received on the proposed bylaws change and has not taken action. AL-ALAC-ST-0914-01-00-EN Open ALAC www.atlarge.icann.org/correspondence/correspondence-12sep14-en.htm
20140731 New gTLDs ALAC Statement on the Report: Supporting the Domain Name Industry in Underserved Regions The ALAC strongly supports the concept of supporting the DNI in underserved regions but notes that simply increasing the DNI without corresponding increases in demand will not be helpful.
The evolution of DNI programs should adhere to the following principles: 1) While increasing DNI penetration, the standards of suppliers should not be lowered; 2) education at all levels is key; 3) the processes to become a registrar should be clarified and simplified with training and support; 4) the demands placed on registrars should be reasonable based on local cost-of-living and related financial constraints; 5) the second new gTLD round should give preference to applicants from developing economies and undertake an outreach program to ensure a better understanding; and 6) technical and legal supports should be provided to new gTLD applicants in underserved regions.		 AL-ALAC-ST-0714-02-01-EN Ongoing ALAC www.atlarge.icann.org/correspondence/correspondence-12sep14-en.htm
20140626 Future of Multi-Stakeholder Models (MSM) The 2nd At-Large Summit (ATLAS II) Final Declaration -- Future of Multi-Stakeholder Models R-1. ICANN should continue to support outreach programmes that engage a broader audience, in order to reinforce participation from all stakeholders.
R-2. ICANN should increase support (budget, staff) to programmes having brought valuable members to the community.
R-3. ICANN should continue to shape an accountability model reaching not only Board members but all parts of the ICANN community, in order to develop a more transparent and productive environment.
R-4. ICANN should study the possibility of enhancing and increasing the role of Liaisons between its different Advisory Committees and Supporting Organizations (AC/SOs) to do away with the “silo culture”.
R-5. ICANN should examine how best to ensure that end-users remain at the heart of the accountability process in all aspects pertaining to the transition of stewardship of the IANA function.
R-6. ICANN’s MSM should serve as the reference in encouraging all participants (individuals or parties) to declare and update existing or potential conflicts-of-interest, each time a vote takes place or consensus is sought.
R-7. A periodic review of ICANN's MSM should be performed to ensure that the processes and the composition of ICANN’s constituent parts adequately address the relevant decision-making requirements in the Corporation.
R-8. The ALAC has the duty to keep track of action taken on all of the above recommendations.		 The Board in its September 9 2014 resolution acknowledges the Final ATLAS II Declaration, and extends its congratulations on the successful Summit held during ICANN 50 in London; affirms the significance of the ATLAS II Summit and its outcomes as valuable input from the At-Large community of individual Internet users towards strengthening ICANN; expresses its appreciation for the tremendous effort made by the At-Large community in delivering the At-Large Summit, the Final ATLAS II Declaration and the post-ATLAS II implementation activities. Finally the Board looks forward to following up with the ALAC on any inputs that are provided to the Board resulting from the Final ATLAS II Declaration. https://www.icann.org/resources/board-material/resolutions-2014-09-09-en#3.e The "Declaration" is formal advice by the ALAC. Its strength surpasses the strength of an ALAC Statement since on ALAC Statements, a subset of the At-Large Community work on the Statement on behalf of the whole community while the Declaration had direct input from 150 At-Large Structure Representatives. AL-ATLAS-02-DCL-01-01-EN Ongoing ALAC 20140626 community.icann.org/display/atlarge/ATLAS+II+Thematic+Group+on+the+Future+of+Multistakeholder+Models
20140626 The Globalization of ICANN The 2nd At-Large Summit (ATLAS II) Final Declaration -- 'The Globalization of ICANN R-9. ICANN should open regional offices with a clear strategy, subject to a cost-benefit analysis, focusing on the areas where the access to the Internet is growing, and where such growth is more likely to occur.
R-10. The next evolution of language services must adopt further extension of live scribing for all meetings and generally extend the current interpretation and translation processes and make translation available in a timely manner.
R-11. ICANN must implement a range of services to facilitate access according to various criteria (gender; cultural diversity) and user needs (disabilities, etc…).
R-12. In collaboration with At-Large Structures, ICANN should put in place campaigns to raise awareness and extend education programmes across underrepresented regions.
R-13. ICANN should review the overall balance of stakeholder representation to ensure that appropriate consideration is given to all views, proportionally to their scope and relevance.
R-14. ICANN should adjust its contractual framework to minimize conflict between its requirements and relevant national laws.
R-15. ICANN should examine the possibility of modifying its legal structure befitting a truly global organization, and examine appropriate legal and organizational solutions.
R-16. ICANN needs to improve their direct communications regardless of time zones.
R-17. ICANN needs to be sensitive to the fact that social media are blocked in certain countries and, in conjunction with technical bodies, promote credible alternatives.		 The Board in its September 9 2014 resolution acknowledges the Final ATLAS II Declaration, and extends its congratulations on the successful Summit held during ICANN 50 in London; affirms the significance of the ATLAS II Summit and its outcomes as valuable input from the At-Large community of individual Internet users towards strengthening ICANN; expresses its appreciation for the tremendous effort made by the At-Large community in delivering the At-Large Summit, the Final ATLAS II Declaration and the post-ATLAS II implementation activities. Finally the Board looks forward to following up with the ALAC on any inputs that are provided to the Board resulting from the Final ATLAS II Declaration. https://www.icann.org/resources/board-material/resolutions-2014-09-09-en#3.e The "Declaration" is formal advice by the ALAC. Its strength surpasses the strength of an ALAC Statement since on ALAC Statements, a subset of the At-Large Community work on the Statement on behalf of the whole community while the Declaration had direct input from 150 At-Large Structure Representatives. AL-ATLAS-02-DCL-01-01-EN Ongoing ALAC 20140626 atlas.icann.org/150-representatives-70-countries-5-ralos-1-declaration
20140626 Global Internet: The User Perspective The 2nd At-Large Summit (ATLAS II) Final Declaration -- Global Internet: The User Perspective R-18. Support end-users to take part in policy development.
R-19. Eliminate barriers to participation and engagement with ICANN processes and practices.
R-20. Input the user perspective, wherever necessary, to advance accountability, transparency and policy development within ICANN.
R-21. Encourage public campaigns on using the Internet for education, information, creativity and empowerment.		 The Board in its September 9 2014 resolution acknowledges the Final ATLAS II Declaration, and extends its congratulations on the successful Summit held during ICANN 50 in London; affirms the significance of the ATLAS II Summit and its outcomes as valuable input from the At-Large community of individual Internet users towards strengthening ICANN; expresses its appreciation for the tremendous effort made by the At-Large community in delivering the At-Large Summit, the Final ATLAS II Declaration and the post-ATLAS II implementation activities. Finally the Board looks forward to following up with the ALAC on any inputs that are provided to the Board resulting from the Final ATLAS II Declaration. www.icann.org/resources/board-material/resolutions-2014-09-09-en#3.e The "Declaration" is formal advice by the ALAC. Its strength surpasses the strength of an ALAC Statement since on ALAC Statements, a subset of the At-Large Community work on the Statement on behalf of the whole community while the Declaration had direct input from 150 At-Large Structure Representatives. AL-ATLAS-02-DCL-01-01-EN Ongoing ALAC 20140626 atlas.icann.org/150-representatives-70-countries-5-ralos-1-declaration
20140626 ICANN Transparency and Accountability The 2nd At-Large Summit (ATLAS II) Final Declaration -- ICANN Transparency and Accountability R-22. Members of the general public should be able to participate in ICANN on an issue-by-issue basis. Information on the ICANN website should, where practical, be in clear and non-technical language.
R-23. The roles and jurisdiction of the Ombudsman should be expanded. The ICANN website should provide a clear and simple way for the public to make complaints.
R-24. Both the areas of the Ombudsman and Contractual Compliance should report regularly on the complaints they received, resolved, pending resolution and actions taken to address issues raised by unresolved complaints.
R-25. To enhance ICANN's community effort on building a culture of Transparency and Accountability, as called for in the recommendations of ATRT2, oversight of the Board's decisions now requires an effective mechanism of checks and balances, capable of providing true multi-stakeholder oversight and effective remedies.		 The Board in its September 9 2014 resolution acknowledges the Final ATLAS II Declaration, and extends its congratulations on the successful Summit held during ICANN 50 in London; affirms the significance of the ATLAS II Summit and its outcomes as valuable input from the At-Large community of individual Internet users towards strengthening ICANN; expresses its appreciation for the tremendous effort made by the At-Large community in delivering the At-Large Summit, the Final ATLAS II Declaration and the post-ATLAS II implementation activities. Finally the Board looks forward to following up with the ALAC on any inputs that are provided to the Board resulting from the Final ATLAS II Declaration. www.icann.org/resources/board-material/resolutions-2014-09-09-en#3.e The "Declaration" is formal advice by the ALAC. Its strength surpasses the strength of an ALAC Statement since on ALAC Statements, a subset of the At-Large Community work on the Statement on behalf of the whole community while the Declaration had direct input from 150 At-Large Structure Representatives. AL-ATLAS-02-DCL-01-01-EN Ongoing ALAC 20140626 atlas.icann.org/150-representatives-70-countries-5-ralos-1-declaration
20140626 At-Large Community Engagement in ICANN The 2nd At-Large Summit (ATLAS II) Final Declaration -- At-Large Community Engagement in ICANN R-26. Current policy management processes within ICANN are insufficient. ICANN must implement a workable Policy Management Process System, available for use across the SO/ACs, in order to:
  • enhance Knowledge Management,
  • improve the effectiveness of all ICANN volunteer communities,
  • improve cross-community policy-specific activity,
  • enhance policy development metrics,
  • facilitate multilingual engagement,
  • create a taxonomy of policy categories,
  • provide policy development history as an aid for newcomers.
R-27. The Board must implement ATRT2 Recommendation 9.1, regarding Formal Advice from Advisory Committees.
R-28. The ALAC should work with all RALOs and ALSes to map the current expertise and interests in their membership, to identify Subject Matter Experts and facilitate policy communication.
R-29. The ALAC should implement an automated system for tracking topics of interest currently being discussed among the various RALOs, and accessible by everyone.
R-30. For each Public Comment process, SOs and ACs should be adequately resourced to produce impact statements.
R-31. ICANN and the ALAC should investigate the use of simple tools and methods to facilitate participation in public comments, and the use of crowdsourcing.
R-32. ICANN should ensure that all acronyms, terminology in its materials are clearly defined in simpler terms.
R-33. The ALAC should arrange more At-Large Capacity Building Webinars.
R-34. In collaboration with the global Internet user community, the ALAC shall reiterate the link between the fundamental rights of Internet users, and the Public Interest.
R-35. The ICANN Board should hold a minimum of one conference call with the At-Large Community in between ICANN Public Meetings.
R-36. The At-Large Community should envisage conference calls with other ACs and SOs in between ICANN public meetings to improve collaboration and engagement.
R-37. Additional logistical support from ICANN is needed to improve the At-Large wiki.
R-38. ICANN should ensure that its Beginner Guides are easily accessible.
R-39. ICANN should encourage “open data” best practices that foster re-use of the information by any third party.
R-40. ICANN should offer a process similar to the Community Regional Outreach Pilot Program (CROPP), but applicable to short lead-time budget requests not related to travel.
R-41. The ALAC should work with the ICANN Board in seeking additional sources of funding for At-Large activities.
R-42. ICANN should enable annual face-to-face RALO assemblies, either at ICANN regional offices or in concert with regional events.
R-43. RALOs should encourage their inactive ALS representatives to comply with ALAC minimum participation requirements.		 The Board in its September 9 2014 resolution acknowledges the Final ATLAS II Declaration, and extends its congratulations on the successful Summit held during ICANN 50 in London; affirms the significance of the ATLAS II Summit and its outcomes as valuable input from the At-Large community of individual Internet users towards strengthening ICANN; expresses its appreciation for the tremendous effort made by the At-Large community in delivering the At-Large Summit, the Final ATLAS II Declaration and the post-ATLAS II implementation activities. Finally the Board looks forward to following up with the ALAC on any inputs that are provided to the Board resulting from the Final ATLAS II Declaration. www.icann.org/resources/board-material/resolutions-2014-09-09-en#3.e The "Declaration" is formal advice by the ALAC. Its strength surpasses the strength of an ALAC Statement since on ALAC Statements, a subset of the At-Large Community work on the Statement on behalf of the whole community while the Declaration had direct input from 150 At-Large Structure Representatives. AL-ATLAS-02-DCL-01-01-EN Ongoing ALAC 20140626 atlas.icann.org/150-representatives-70-countries-5-ralos-1-declaration
20140523 Board Compensation ALAC Statement on Board Member Compensation The ALAC wishes to go on record as strongly supporting the comment submitted by Alan Greenberg - forum.icann.org/lists/comments-bylaws-amend-compensation-02may14/msg00003.html AL-ALAC-ST-0614-01-00-EN Open ALAC www.atlarge.icann.org/correspondence/correspondence-12jun14-en.htm
20140516 Strategy ALAC Statement on the ICANN Strategy Panels: ICANN's Role in the Internet Governance Ecosystem The ALAC strongly supports the report from the Panel on ICANN's Role in the Internet Governance Ecosystem, particularly its conclusion that 'the multistakeholder model is by far preferable and should be elaborated and reinforced'.
The diagram on Governance, grouped into the Logical layer and Infrastructure Layer is a very helpful way to conceptualize Internet governance issues.
The Panel's discussions under the following headings also have some very useful pointers on directions for ICANN's new role in: Globalize not internationalize, Consolidation and simplification of root-zone management, and a web of affirmation of commitments.
Globalizing the process of accountability through a web of relationships and suggesting accountability panels is indeed a potential way forward but only if a panel can provide recourse. The ALAC has concerns about the practical workability of this scenario but is ready to assist.		 AL-ALAC-ST-0514-02-01-EN ALAC www.atlarge.icann.org/correspondence/correspondence-16may14-en.htm
20140516 Strategy ALAC Statement on the ICANN Strategy Panels: Public Responsibility Framework The ALAC strongly supports the report from the Panel on Public Responsibility Framework.
This Panel is a useful reminder of the ways ICANN has started to globalize its activities, but real assistance and support for participation in ICANN is a critical element in the globalization of ICANN and Internet Governance.
The issue is additional funding for those unable to self fund real participation in ICANN. There may be other models for funding participation that do not rely on the 'contracted parties' model that can ensure all parties have equal seats at the table.		 AL-ALAC-ST-0514-03-01-EN ALAC
20140516 Strategy ALAC Statement on the ICANN Strategy Panels: Identifier Technology Innovation The ALAC strongly supports the report from the Panel on Identifier Technology Innovation. Indeed, the report provides valuable insights and recommendations for future identifier technology developments.
ALAC is surprised that the recommendations of the Panel do not include any acknowledgement or recommendations about the threats to the DNS.
A key missing recommendation should have been made that there should be a coordinated risk management program concerning the DNS itself.		 AL-ALAC-ST-0514-05-01-EN ALAC www.atlarge.icann.org/correspondence/correspondence-4-16may14-en.htm
20140516 Strategy ALAC Statement on the ICANN Strategy Panels: Multistakeholder Innovation The ALAC supports the report from the Panel on Multistakeholder Innovation with some reservations.
This panel is a useful reminder of the need to reach beyond the 'usual suspects' with suggestions on how new techniques and technologies can be used to support global engagement.
However, we are concern that some of the suggestions, such as crowdsourcing, for obtaining broad-based input may be seen as alternatives to existing methods of reaching consensus on issues. New techniques should not be seen as replacing the valuable policy processes of collaboration and dialogue. Crowdsourcing for policy input risks breaking the truly bottom-up policy development.
We suggest the development and use of tools to assist participation for those whose voice should be heard but do not communicate, or not communicate easily in the English language.
Ultimately, multistakeholder innovation should be targeted at enabling widespread participation at grassroots level as opposed to encouraging counter-arguments at top level.		 AL-ALAC-ST-0514-04-01-EN ALAC www.atlarge.icann.org/correspondence/correspondence-6-16may14-en.htm
20140421 Strategy ALAC Statement on the ICANN Future Meetings Strategy The ALAC supports the recommendations of the Meeting Strategy Working Group report.
The differentiation of the 3 annual meetings would improve the geographic rotation, minimize the number of conflicting sessions, facilitate cross community interactions, increase concentrated policy work, engage with local Internet communities, and increase thematic, regional or language-based interactions.
The ALAC also appreciates very much that visa deliverance becomes one of the main criteria for the selection of the meetings venue.
The ALAC suggests that 1) local availability of an open Internet be added to the selection criteria, 2) venues without facilities for the disabled communities shouldn't be considered, and 3) video coverage of meetings uses cameras and camera-work (pan and zoom) instead of a stationary Webcam.
The ALAC welcomes the recommendation not restricting rotation of any meeting to ICANN hub cities.		 AL-ALAC-ST-0414-01-00-EN ALAC
20140327 IANA ALAC Statement on the Announcement Regarding the Transition of the Stewardship of the IANA Functions The ALAC welcomes the announcement recently made by the National Telecommunications and Information Authority (NTIA) and celebrates the designation of ICANN as the organization in charge of convening the global stakeholders to develop a proposal to transition the stewardship over the IANA functions by designing a multistakeholder mechanism
We expect that the design process will be open and inclusive allowing the various communities, within and outside of ICANN, to be properly considered and taken into account by adequately incorporating and addressing their concerns and thoughts in the final outcome of this collaborative effort.
The ALAC believes that the end user community has a vital role in the Internet governance ecosystem and must be a part of any process going forward.
We call on ICANN leadership to ensure that any mechanism that replaces the stewardship over the IANA functions is based on enhancing the multistakeholder model, maintaining the security, stability and resiliency of the Internet's DNS, and several other principles and requirements.
We commit to contributing to the process so that any outcome is a result of a bottom-up, consensus driven and multistakeholder effort in which the interests of the end users are properly taken into account.		 AL-ALAC-ST-0314-06-00-EN ALAC www.atlarge.icann.org/correspondence/correspondence-27mar14-en.htm
20140327 New gTLDs ALAC Statement on the Mitigating the Risk of DNS Namespace Collisions The ALAC welcomes the publication of the "Mitigating the Risk of DNS Namespace Collisions" study report by JAS Global Advisors but notes that at this stage, this report is incomplete.
The ALAC notes the assumption on page 3 that "The modalities, risks, and etiologies of the inevitable DNS namespace collisions in the new TLD namespaces will resemble the collisions that already occur routinely in other parts of the DNS.
The ALAC supports Recommendation 1 which proposes that the TLDs .corp, .home and .mail be permanently reserved for internal use, but considers that there are other potential TLD strings in high use in internal networks that should also be considered for reservation.
The ALAC considers that Recommendation 3 sets too high a barrier for the application of emergency response options. In deeming that these responses be limited to situations which present a "clear and present danger to human life", this ignores a broad range of scenarios which may have huge detrimental impact.
The ALAC reaffirms its view that security and stability should be paramount in the ongoing introduction of new TLDs and that the interests of Internet users, whether they be registrants of domain names in the new TLDs or users who are impacted by disruption to the smooth operation of internal networks, should be safeguarded.		 AL-ALAC-ST-0314-05-00-EN ALAC www.atlarge.icann.org/correspondence/correspondence-2-27mar14-en.htm
20140314 Bylaws ALAC Follow-up Statement on the Technical Liaison Group Bylaws Revisions Topic: Bylaws The ALAC is responding to the ICANN Board resolution regarding "Technical Liaison Group Bylaws Revisions" and its accompanying rationale dated 7 February 2014. The ALAC had submitted a Statement on the Proposed Bylaws Changes Regarding the Technical Liaison Group [PDF, 231 KB] on 16 December 2013.
The ALAC has two concerns: 1) The removal of the Technical Liaison Group (TLG) delegate to the Nominating Committee (NomCom); and 2) the rationale of removing volunteer positions to save ICANN money.
Removing the TLG delegate from the Nominating Committee (NomCom) weakens the coverage and undermines the inclusion of the Internet community in ICANN's governance processes. Having a person of technical expertise (such as the TLG delegate) on the NomCom aids the NomCom to: 1) recruit persons with technical expertise for positions in ICANN's structures; 2) Evaluate candidates' technical expertise being considered by the NomCom for positions in ICANN's structures; and 3) select the best candidates for positions in ICANN's structures.
The ALAC is very disappointed with the ICANN Board's rationale that the removal of the TLG Liaison to the ICANN Board and the TLG delegate to the NomCom "is anticipated to have a positive fiscal impact on ICANN" and "will provide a financial savings to ICANN". It contradicts the rationale given by the ICANN Board in its September 28 2013 Board resolution which stated, "This action is not anticipated to have a fiscal impact on ICANN." It disparages the volunteers, not only those that have served on the TLG as liaisons to the Board or as delegates to the NomCom, but the multi-stakeholder volunteers (especially those not financed by industry players) in ICANN.		 AL-ALAC-ST-0314-03-00-EN ALAC www.atlarge.icann.org/correspondence/correspondence-14mar14-en.htm
20140307 ICANN Transparency and Accountability ALAC Statement on the Second Accountability and Transparency Review Team (ATRT 2) Final Report & Recommendations We advise the ICANN Board to: (1) Place equal emphasis on recommendations and observations, and address key issues outlined in the observations indicated in Appendix B and C of the report in advance of the next WHOIS and Security, Stability and Resiliency (SSR) reviews; and (2) Take measures to improve future reviews by ensuring that review processes are accorded sufficient time for a thorough and effective assessment and to ensure that ICANN is better prepared organizationally to support the review process.
We believe that the Board should examine both Recommendations and Observations in the ATRT2 report with equal diligence. A careful examination of the Observations laid out in Appendix B and C on the reviews of the WHOIS Review Team and the Security, Stability and Resiliency Review Team implementation reveals serious issues requiring Board attention. Developing new recommendations on these topics are outside of the ATRT2 scope, but the issues remain within the purview of the Board. Ignoring these issues at this stage will likely worsen the problems in a few years' time. We recommend that the issues be addressed now through appropriate mechanisms.
The ATRT2 report includes a section on its review work experience in Appendix E. This section highlights observations and recommendations on "Improving Future Reviews" for the next Accountability and Transparency Review Team (ATRT3). We note with concern that the ATRT1 and the ATRT2 processes had less than 12 full months to undertake their review and that this affected their work. Given the importance of the review process, we recommend that ICANN be better prepared organizationally to support future reviews and that the ATRT3 be provided with a full year (12 months) for its review work, even if review commencement is delayed.		 AL-ALAC-ST-0314-01-00-EN ALAC www.atlarge.icann.org/correspondence/correspondence-07mar14-en.htm
20140307 New gTLDs ALAC Statement on the Proposed Review Mechanism to Address Perceived Inconsistent Expert Determinations on String Confusion Objections The ALAC supports the details of the process described, but recommends that it be widened to include cases such as the various .shop objections where the objected-to strings were not identical, but the results were just as inconsistent. Moreover, the ALAC notes that it has previously made statements to this effect (https://community.icann.org/download/attachments/2261148/AL-ALAC-ST-0913-04-01-EN.pdf?api=v2) and deeply regrets that it has taken ICANN so long to react to the overall situation that it must now choose to accept many of the other seemingly illogical results. One of the ALAC's prime responsibilities in ICANN is to protect the interests of individual Internet users, and the delegation of confusingly similar TLDs does not meet the needs of these users. AL-ALAC-ST-0314-02-00-EN ALAC www.atlarge.icann.org/correspondence/correspondence-2-07mar14-en.htm
20140307 ICANN Transparency and Accountability ALAC Statement on the Second Accountability and Transparency Review Team (ATRT 2) Final Report & Recommendations We advise the ICANN Board to: (1) Place equal emphasis on recommendations and observations, and address key issues outlined in the observations indicated in Appendix B and C of the report in advance of the next WHOIS and Security, Stability and Resiliency (SSR) reviews; and (2) Take measures to improve future reviews by ensuring that review processes are accorded sufficient time for a thorough and effective assessment and to ensure that ICANN is better prepared organizationally to support the review process.
We believe that the Board should examine both Recommendations and Observations in the ATRT2 report with equal diligence. A careful examination of the Observations laid out in Appendix B and C on the reviews of the WHOIS Review Team and the Security, Stability and Resiliency Review Team implementation reveals serious issues requiring Board attention. Developing new recommendations on these topics are outside of the ATRT2 scope, but the issues remain within the purview of the Board. Ignoring these issues at this stage will likely worsen the problems in a few years' time. We recommend that the issues be addressed now through appropriate mechanisms.
The ATRT2 report includes a section on its review work experience in Appendix E. This section highlights observations and recommendations on "Improving Future Reviews" for the next Accountability and Transparency Review Team (ATRT3). We note with concern that the ATRT1 and the ATRT2 processes had less than 12 full months to undertake their review and that this affected their work. Given the importance of the review process, we recommend that ICANN be better prepared organizationally to support future reviews and that the ATRT3 be provided with a full year (12 months) for its review work, even if review commencement is delayed.		 AL-ALAC-ST-0314-01-00-EN ALAC www.atlarge.icann.org/correspondence/correspondence-07mar14-en.htm
20140307 New gTLDs ALAC Statement on the Proposed Review Mechanism to Address Perceived Inconsistent Expert Determinations on String Confusion Objections The ALAC supports the details of the process described, but recommends that it be widened to include cases such as the various .shop objections where the objected-to strings were not identical, but the results were just as inconsistent. Moreover, the ALAC notes that it has previously made statements to this effect (https://community.icann.org/download/attachments/2261148/AL-ALAC-ST-0913-04-01-EN.pdf?api=v2) and deeply regrets that it has taken ICANN so long to react to the overall situation that it must now choose to accept many of the other seemingly illogical results. One of the ALAC's prime responsibilities in ICANN is to protect the interests of individual Internet users, and the delegation of confusingly similar TLDs does not meet the needs of these users. AL-ALAC-ST-0314-02-00-EN ALAC www.atlarge.icann.org/correspondence/correspondence-2-07mar14-en.htm
20140226 Compliance ALAC Statement on the Related-Issue Compliance Submission Process ICANN Contractual Compliance (CC) accepts complaints either on a one-by-one basis using web-based submission tools, or for selected partners, using a bulk-submission process. The ALAC understanding is that regardless of the submission vehicle, each complaint is reviewed on its merits and processed individually.
However, this methodology is not suitable when the subject of a complaint is not an individual occurrence, but a more wide-spread problem that affects multiple gTLD registrations.
Just as the UDRP allows multiple related disputes to be filed in the same single complaints, CC should allow multiple, related issues to be raised in a single complaint.
If such a process were created, the workload of CC could be better controlled, and substantive issues could be resolved quicker and earlier than by using today's methodology alone.
It is reasonable that, at least at the start, the use of such a "related complaint" submission process be used only by those with whom ICANN can develop a good working relationship, and possibly accreditation for the existing bulk-submission tool could be used to determine who could use the new process.
This recommendation is being submitted to CC on behalf of the At-Large Advisory Committee, and the ALAC believes that it is to all parties' mutual advantage that we have the opportunity to further investigate such a process with Contractual Compliance.		 AL-ALAC-ST-0214-03-00-EN ALAC www.atlarge.icann.org/correspondence/correspondence-26feb14-en.htm
20140131 New gTLDs ALAC Statement on the Proposal for a Specification 13 to the ICANN Registry Agreement to Contractually Reflect Certain Limited Aspects of ".Brand" New gTLDs The ALAC has no input on the details of Specification 13, but wishes to go on record as objecting to the creation of a new category of gTLD at this point, when earlier decisions were made to not have categories of TLDs supporting community, geographic and other similar classes of gTLD. AL-ALAC-ST-0114-04-00-EN ALAC www.atlarge.icann.org/correspondence/correspondence-31jan14-en.htm
20140131 Strategy ALAC Statement on ICANN's Draft Vision, Mission & Focus Areas for a Five-Year Strategic Plan The At-Large Advisory Committee considers the submitted "ICANN Draft Vision, Mission, and Focus Areas for a Five Years Strategic Plan" a comprehensive document addressing all the aspects of a future strategic plan.
The ALAC supports the ICANN vision as stipulated. Nevertheless, as the most important concern today is about the security of Internet and the trust in the Internet, the ALAC would prefer to include those aspects of trust and security in the paragraph describing the ICANN Vision in this way: "…to support a single, open, and globally interoperable Internet with a secure and trusted DNS". The same should be done in all focus areas paragraphs each time the unique and open Internet is mentioned.
The ALAC recommends that it is necessary to add another bold point to the "Developing a world-class public responsibility framework" focus area section: "Engage and develop the End-Users community globally for full involvement in policy development and decision making processes." The ALAC finds the other elements of the focus Areas well expressed and detailed. It appreciates this preliminary work to prepare for a future-oriented and concerted 5 years strategic plan and strongly supports that process.		 AL-ALAC-ST-0114-05-00-EN ALAC www.atlarge.icann.org/correspondence/correspondence-2-31jan14-en.htm
20140115 Geographic regions ALAC Statement on the Request For Written Community Feedback - Geographic Regions Working Group Recommendations The ALAC supports the recommendation for ICANN to adopt a more rigorous approach by re-defining a clear and consistent classification framework that assigns countries and territories to regions. Nevertheless, it would be helpful if the way and the criteria for such re-definition were suggested.
The ALAC strongly supports that ICANN must acknowledge the Sovereignty and right of self-determination of States to let them choose their region of allocation and request, if they so desire, a move to another geographic region.
When we speak about geography, we are speaking about regions, and the ALAC doesn't believe that the geographic regions could be in any case built on other consideration than the regional one. The cultural and linguistic diversity are important but can't impact the geographic regions framework. If we want it to be regions plus culture plus language, we have to call it diversity, not geographic regions.
The ALAC supports the recommendation to amend the bylaws to modify the present requirement for review of the Geographic Regions from three years period to five.		 AL-ALAC-ST-0114-03-00-EN ALAC www.atlarge.icann.org/correspondence/correspondence-15jan14-en.htm
20140114 DNS security ALAC Statement on the DNS Security & Stability Analysis The ALAC adopts the Report submitted by the co-chairs of the DSSA WG, as the Final Report of the DSSA WG in accordance with section 2.4 of its charter;
The Chair of the ALAC is requested to inform the ccNSO, GNSO, NRO and SSAC co-chairs of the DSSA WG of adoption of the Report by the ALAC;
The Chair of the ALAC is also requested to inform the chairs of the other participating SO's and AC's (GNSO, ccNSO, NRO and SSAC);
The ALAC agrees with but notes with significant regret the recommendation to not proceed with phase 2 as noted in the co-chair's letter; and The ALAC thanks and congratulates all, and in particular the co-chairs of the WG: Olivier Crépin-LeBlond (ALAC), Joerg Schweiger (.DE, ccNSO), Mikey O'Connor (GNSO), James Galvin (SSAC) and Mark Kosters (NRO) and all volunteers and staff who helped with this effort.		 AL-ALAC-ST-0114-02-00-EN ALAC www.atlarge.icann.org/correspondence/correspondence-15jan14-en.htm
20131216 Bylaws ALAC Statement on the Proposed Bylaws Changes Regarding the Technical Liaison Group The ALAC supports the intent of the proposed bylaw changes to increase the availability of technical advice to the Board as well as the effectiveness of the Technical Liaison Group. It is clear that the current modus operandi is not working and that it has not brought any benefit to ICANN in terms of advice. However, the ALAC is concerned that the order in which the changes are presented is out of line with the original recommendations of the Board technical relations WG findings.
The ALAC understands that the proposal is not to disband the TLG altogether but to remove the TLG position from the ICANN Board. We call on the ICANN Board to make sure, in the substitution of the TLG position in the Board, that it be structurally replaced by constant access to the necessary technical competence, not only through a structured, distance consultation.
The ALAC considers the actual elimination of the position of a technical liaison to the ICANN Board should not occur until, at least, a mechanism to seek regular advice from the Technical Liaison Group (TLG) be founded. This capability should be a permanent one and, provide for the ability of the technical constituencies to provide advice to the Board on an ongoing basis and not merely when requests are made.
The ALAC is concerned that the proposed changes in the bylaws removes the TLG from appointing a delegate to the Nominating Committee. Given the concerns of having persons on the Board with sufficient technical expertise, this change should NOT be supported and the TLG should continue to be able to select a delegate to serve on the Nominating Committee.		 The Board voted the bylaws revisions as they were posted for public commen on 7 February 2014 https://www.icann.org/resources/board-material/resolutions-2014-02-07-en#1.c.
With respect to the comment regarding strengthening of TLG advisory mechanism, the Board addressed this issue on 28 September 2013 in resolution 2013.09.28.15.
With respect to the concern regarding outreach to the technical communities, each of the four G15 organizations that make up the TLG are engaged in ongoing community outreach efforts. The removal of a TLG delegate from the NomCom does not prevent these organizations from continuing with their efforts and they are encouraged to continue those efforts.
https://www.icann.org/public-comments/bylaws-amend-tlg-2013-10-30-en		 AL-ALAC-ST-1213-01-00-EN ALAC www.atlarge.icann.org/correspondence/correspondence-16dec13-en.htm
20131121 WHOIS ALAC Statement on the Thick Whois Policy Development Process (PDP) Recommendations for Board Consideration The ALAC strongly supports the recommendation of the Final Report on the Thick Whois Policy Development Process for all gTLD registries to use the 'Thick' Whois mode.
It is a position that the ALAC has supported, beginning with its response to the Preliminary Report and reflected in the ALAC Statement on the Preliminary Issue Report on 'Thick' Whois expressing 'extreme disappointment' that Verisign was not required to use a 'Thick' Whois model for .com when that ICANN-registry agreement was up for renewal.
The ALAC would note that similar privacy issues are addressed by most existing registries and all registrars including movement of data from one jurisdiction to another.		 AL-ALAC-ST-1113-05-00-EN ALAC www.atlarge.icann.org/correspondence/correspondence-21nov13-en.htm
20131121 ICANN Transparency and Accountability ALAC Statement on the Second Accountability and Transparency Review Team (ATRT 2) Draft Report & Recommendations The ALAC appreciates the publication of the ATRT2 Draft Recommendations for Public Comment.
The ALAC views the Affirmation of Commitments' mandate for periodic organizational review and the work of the ATRT2 are crucial for enhancing, on a continuous basis, the culture and practice of accountability and transparency throughout ICANN.
We agree with the ATRT2's general Recommendations that, in moving forward, ICANN needs to:
  • Establish clear metrics and benchmarks against which improvements in accountability and transparency can be measured;
  • Communicate clearly and consistently about its accountability and transparency mechanisms and performance; and
  • Improve and prioritize its AoC Review processes.
 AL-ALAC-ST-1113-04-00-EN ALAC www.atlarge.icann.org/correspondence/correspondence-3-21nov13-en.htm
20131121 Board governance ALAC Statement on the Policy & Implementation Working Group There must be a methodology to recognize when a decision will impact the community, and such decisions must involve a bottom-up process in addressing those decisions.
The processes must be designed to be time-sensitive – unending debate should not be an option.
There must be a way to come to closure when the community is divided, and this should not simply give executive powers to ICANN Staff.
One of the key question that must be resolved is what part should the Board play in taking action if the community is divided. This question is one of the reasons that the ALAC believes that this should have been a Board-led initiative, but the fact that it isn't does not remove the importance of the question.		 AL-ALAC-ST-1113-03-00-EN ALAC www.atlarge.icann.org/correspondence/correspondence-2-21nov13-en.htm
20131113 PICS ALAC Statement on the Revised Public Interest Commitments Dispute Resolution Procedure (PICDRP) The ALAC appreciates the radical changes made to the PICDRP in response to the comments of the first draft. The process seems far more appropriate for addressing potential harms caused by a registry's failure to honor the Public Interest Commitment aspects of their registry agreements. However, the ALAC still firmly believes that this process does not address the PUBLIC INTEREST aspect of Public Interest Commitments.
There must be a provision for allowing reports of PIC violations, and particularly substantive PIC violations without the need to demonstrate harm.
A significant aspect of the PIC is to ensure registrant and Internet user trust in the TLD, and to disallow reports of the perceived loss of that trust greatly lessens the benefit of the PIC, and could serve to make them completely ineffective.
The ALAC also offers the following more specific comments on the terms within the PICDRP:
  • The use of the undefined term "good standing" is both vague and inappropriate. If there are criteria under which ICANN will decide to not follow up on a report, they must be clearly stated and subject to appeal.
  • There should be no requirement for interaction between a Reporter and Registry if the complaint issues identified in the report are factually identifiable; there is no need to negotiate evidence-based issues.
  • Although perhaps obvious to some, it should be explicit that the Standing Panel will include one or more members with clear understanding of Public Interest issues.
 AL-ALAC-ST-1113-02-00-EN ALAC www.atlarge.icann.org/correspondence/correspondence-13nov13-en.htm
20131101 New gTLDs ALAC Statement on the Draft Final Report on Protection of IGO and INGO Identifiers in All gTLDs The ALAC is particularly concerned that granting blocking-level protections may prohibit other reasonable uses of the same strings and the ALAC is not satisfied that the exception procedures outlined in the report would be effective.
This being the case, it may be important to consider the principles that guided the ALAC, in our participation in the activities that led to this report, and that the ALAC believes should guide ICANN in considering any special protections.
  • ICANN should grant special protection to organizations that further the public interest and in particular, those with a strong track record of humanitarian activities. However, such protections should only be granted where there is a history or reasonable expectation that the lack of protections would lead to the misrepresentation of the organizations, fraud, deliberate confusion, or other malfeasance.
  • Such protections, when granted, should not unreasonably impinge on the ability of others with a valid right to use the protected string, from registering such names for uses which do not negatively impact the protected organization nor use to the protected name with the intent to deceive users. Formal trademarks should not be necessary to demonstrate such a right.
  • The procedures used to grant the protection exceptions identified in number 2 must be both inexpensive and fast.
  • No top level protections are necessary. Existing or new objection processes are sufficient.
 AL-ALAC-ST-1113-01-02-EN ALAC www.atlarge.icann.org/correspondence/correspondence-01nov13-en.htm
20130927 Risk Management ALAC Statement on the DNS Risk Management Framework Report The fact that a risk management framework exists and is utilized to force rigor into the consideration of risk would be an important outcome.
However, the ALAC deplores that the framework that is proposed is the proprietary and business-oriented Risk Management methodology ISO31000 framework whilst the DNS Security and Stability Analysis (DSSA) Working Group had proposed the use of the Open Standard NIST 800-30 methodology.
The ALAC also questions the use of a business methodology applied to the DNS.
The ALAC deplores that at this point in time, the proposed Framework is far from being detailed at a more granular level.
The ALAC is disappointed that the Framework as proposed in the Final Report has not built in any substantial way on the work undertaken by the DSSA Working Group apart from mentioning its work.		 AL-ALAC-ST-0913-05-00-EN ALAC www.atlarge.icann.org/correspondence/correspondence-27sep13-en.htm
20130916 New gTLDs ALAC Statement on the Confusingly Similar gTLDs The ALAC advises the Board to revisit the issue of new TLD strings, which are singular and plural versions of the same word, and ensure that ICANN does not delegate strings that are virtually certain to create confusion among Internet users and therefore result in loss of faith in the DNS.
The ALAC advises the Board to review the objection decision system with multiple panels that leads to inconsistency and not only review the obvious case of .cam/.com where conflicting objection decisions have forced such review;
The ALAC advises the Board to determine a viable way forward which will not create unwarranted contention sets nor delegate multiple TLDs destined to ensure user confusion and implicit loss of faith in the DNS.		 AL-ALAC-ST-0913-04-01-EN ALAC www.atlarge.icann.org/correspondence/correspondence-16sep13-en.htm
20130909 New gTLDs ALAC Statement on the Community Priority Evaluation (CPE) Guidelines Update from ICANN The ALAC welcomes the proposal of "Community Priority Evaluation (CPE) Guidelines" prepared by The Economist Intelligence Unit (EIU).
The ALAC notes with satisfaction that the EIU has transposed the Applicant Guidebook Criteria into Evaluation Guidelines for what is intended to be an evidence-based evaluation process.
The ALAC supports the need for comprehensive community assessment to ensure the legitimacy of applicants and the long- term sustainability of their value proposals.
Without re-opening the debate on the Applicant Guidebook Guidelines themselves, the ALAC has several recommendations and observations to make based on the document within this Statement.		 AL-ALAC-ST-0913-01-00-EN ALAC www.atlarge.icann.org/correspondence/correspondence-2-09sep13-en.htm
20130827 New gTLDs ALAC Statement on the Proposal to Mitigate Name Collision Risks The ALAC welcomes the completion and publication of the "Name Collisions in the DNS" [PDF, 3.34 MB] study report by Interisle Consulting Group and the subsequent response by ICANN in "New gTLD Collision Risk Management Proposal [PDF, 166 KB]."
The ALAC wishes to reiterate its previous Advice to the Board that, in pursuing mitigation actions to minimize residual risk, especially for those strings in the "uncalculated risk" category, ICANN must assure that such residual risk is not transferred to third parties such as current registry operators, new gTLD applicants, registrants, consumers and individual end users. In particular, the direct and indirect costs associated with proposed mitigation actions should not have to be borne by registrants, consumers and individual end users.
The ALAC remains concerned that this matter is being dealt with at such a late stage of the New gTLD Process. The ALAC urges the Board to investigate how and why this crucial issue could have been ignored for so long and how similar occurrences may be prevented in the future.		 AL-ALAC-ST-0813-04-00-EN ALAC www.atlarge.icann.org/correspondence/correspondence-27aug13-en.htm
20140606 New gTLDs SSAC Comment Concerning JAS Phase One Report on Mitigating the Risk of DNS Namespace Collisions Operational Recommendation 1: The Internet Corporation for Assigned Names and Numbers (ICANN) should expand the range of situations that would trigger an emergency response, for example national security, emergency preparedness, critical infrastructure, key economic processes, commerce, and the preservation of law and order.     SAC066 Open SSAC     https://www.icann.org/en/system/files/files/sac-066-en.pdf
20140606 New gTLDs SSAC Comment Concerning JAS Phase One Report on Mitigating the Risk of DNS Namespace Collisions Operational Recommendation 2: Instead of a single controlled interruption period, ICANN should introduce rolling interruption periods, broken by periods of normal operation, to allow affected end-user systems to continue to function during the 120-day test period with less risk of catastrophic business impact.     SAC066 Open SSAC     https://www.icann.org/en/system/files/files/sac-066-en.pdf
20140606 New gTLDs SSAC Comment Concerning JAS Phase One Report on Mitigating the Risk of DNS Namespace Collisions Operational Recommendation 3: ICANN should perform an evaluation of potential notification approaches against at least the requirements provided by the SSAC prior to implementing any notification approach.     SAC066 Open SSAC     https://www.icann.org/en/system/files/files/sac-066-en.pdf
20140606 New gTLDs SSAC Comment Concerning JAS Phase One Report on Mitigating the Risk of DNS Namespace Collisions Operational Recommendation 4: ICANN should implement a notification approach that accommodates Internet Protocol Version 6 (IPv6)-only hosts as well as IP Version 4 (IPv4)-only or dual-stack hosts.     SAC066 Open SSAC     https://www.icann.org/en/system/files/files/sac-066-en.pdf
20140606 New gTLDs SSAC Comment Concerning JAS Phase One Report on Mitigating the Risk of DNS Namespace Collisions Operational Recommendation 5: ICANN should provide clarity to registries on the rules and the method of allocation of blocked names after the conclusion of the test period.     SAC066 Open SSAC     https://www.icann.org/en/system/files/files/sac-066-en.pdf
20140606 New gTLDs SSAC Comment Concerning JAS Phase One Report on Mitigating the Risk of DNS Namespace Collisions Strategic Recommendation 1: ICANN should consider not taking any actions solely based on the JAS Phase One Report. If action is planned to be taken before the entire report is published, communications to the community should be provided to indicate this clearly.     SAC066 Open SSAC     https://www.icann.org/en/system/files/files/sac-066-en.pdf
20140606 New gTLDs SSAC Comment Concerning JAS Phase One Report on Mitigating the Risk of DNS Namespace Collisions Strategic Recommendation 2: ICANN should in due course publish information about not yet disclosed issues.     SAC066 Open SSAC     https://www.icann.org/en/system/files/files/sac-066-en.pdf
20140606 New gTLDs SSAC Comment Concerning JAS Phase One Report on Mitigating the Risk of DNS Namespace Collisions Strategic Recommendation 3: ICANN should seek to provide stronger justification for extrapolating findings based on one kind of measurement or data gathering to other situations.     SAC066 Open SSAC     https://www.icann.org/en/system/files/files/sac-066-en.pdf
20140218 DNS ABUSE SSAC Advisory on DDoS Attacks Leveraging DNS Infrastructure Recommendation 1: ICANN should help facilitate an Internet-wide community effort to reduce the number of open resolvers and networks that allow network spoofing.
This effort should involve measurement efforts and outreach and cooperation in relevant technical fora involving network operators worldwide, but will not have an operational component. ICANN should support this effort with adequate staffing and funding. Such a program should cover at least the following topics:
  1. Collect, create, and organize material that will assist in the implementation of recommendations 2-5 below. This would include:
    1. On an annual basis, publish and widely disseminate a report on the number and extent of open recursive DNS servers.
    2. On an annual basis, publish and widely disseminate a report on the extent of networks that allow network spoofing.
    3. Create and maintain an information portal with links to educational material, to be complemented by ICANN staff and community subject-matter expert contributions.
    4. Inform how certain products (e.g., CPE devices) can play a significant role in DNS amplification attacks.
    5. Publish a regular (at least annual) advisory/report on the state-of-the art-mechanisms to identify or otherwise prevent amplification and reflection attacks, and ensure that such an advisory/report is widely disseminated in the Internet community.
    6. Provide an annual report on the work accomplished.
  2. Coordinate with the Internet community to popularize and support recommendations 2-5 below. This coordination should include exploration of whether operational requirements regarding open resolvers and the prevention of network spoofing can be incorporated into regulatory compliance frameworks and certification regimes.
     SAC065 Open SSAC 2/24/14 TBC www.icann.org/en/groups/ssac/documents/sac-065-en.pdf
20140218 DNS ABUSE SSAC Advisory on DDoS Attacks Leveraging DNS Infrastructure Recommendation 2: All types of network operators should take immediate steps to prevent network address spoofing. This involves:
  1. Implement network ingress filtering, as described in BCP38 and SAC004, to restrict packet-level forgery to the greatest extent possible;
  2. Disclose the extent of their implementation of network ingress filtering to the Internet community as a means of encouraging broader and more effective use of ingress filtering.
     SAC065 Open SSAC 2/24/14 TBC www.icann.org/en/groups/ssac/documents/sac-065-en.pdf
20140218 DNS ABUSE SSAC Advisory on DDoS Attacks Leveraging DNS Infrastructure Recommendation 3: Recursive DNS server operators should take immediate steps to secure open recursive DNS servers. This involves:
  1. Identify unmanaged open recursive DNS servers operating in the network and take immediate steps to restrict access to these servers in order to prevent abuse.
  2. Follow SAC008 Recommendation 3 to (1) disable open recursion on name servers from external sources and (2) only accept DNS queries from trusted sources to assist in reducing amplification vectors for DNS DDoS attacks.
  3. DNS Application Service Providers should take all reasonable steps to prevent abusive use of their open resolvers so that they are not targets of abuse. This would include continuous monitoring for anomalous behavior, limiting or blocking known abuse queries (e.g., ripe.net ANY); tracking likely target victim IPs (attacks reported or addresses of heavily targeted servers) and restricting or disallowing responses to those IPs; and sharing information with similar operators to coordinate efforts to quell such attacks.
     SAC065 Open SSAC 2/24/14 TBC www.icann.org/en/groups/ssac/documents/sac-065-en.pdf
20140218 DNS ABUSE SSAC Advisory on DDoS Attacks Leveraging DNS Infrastructure Recommendation 4: Authoritative DNS server operators should investigate deploying authoritative response rate limiting. This involves:
  1. Investigate mechanisms to deter DNS amplification attacks (e.g., Response Rate Limiting (RRL) in DNS server software), and implement those that are appropriate for their environment;
  2. Encourage DNS software vendors to provide such capabilities; and
  3. Frequently review the state of the art of such mechanisms and update their environment as necessary.
     SAC065 Open SSAC 2/24/14 TBC www.icann.org/en/groups/ssac/documents/sac-065-en.pdf
20140218 DNS ABUSE SSAC Advisory on DDoS Attacks Leveraging DNS Infrastructure Recommendation 5: DNS operators should put in place operational processes to ensure that their DNS software is regularly updated and communicate with their software vendors to keep abreast of latest developments. This should minimally include:
  1. Audit and update operational practices as necessary to ensure that a process is in place to systematically perform DNS software updates on both an on-going and an emergency basis; and
  2. Encourage DNS software vendors to implement and refine the relevant capabilities at reasonable cost in system resources.
     SAC065 Open SSAC 2/24/14 TBC www.icann.org/en/groups/ssac/documents/sac-065-en.pdf
20140218 DNS ABUSE SSAC Advisory on DDoS Attacks Leveraging DNS Infrastructure Recommendation 6: Manufacturers and/or configurators of customer premise networking equipment, including home networking equipment, should take immediate steps to secure these devices and ensure that they are field upgradable when new software is available to fix security vulnerabilities, and aggressively replacing the installed base of non-upgradeable devices with upgradeable devices. This minimally involves:
  1. Ensuring that the default configuration on these devices does not implement an unmanaged open recursive DNS resolver;
  2. Providing updates and patches for their equipment to keep the installed base of networking equipment up-to-date to address current security threats, or as a necessary alternative replacing non-updatable equipment with appropriately configured devices;
  3. Ensuring that large-scale participants in purchasing of customer premise networking equipment (e.g., ISPs, government procurement, large enterprises) insist that networking equipment meet the standards discussed in this document.
     SAC065 Open SSAC 2/24/14 TBC www.icann.org/en/groups/ssac/documents/sac-065-en.pdf
20140213 DNS security SSAC Advisory on DNS “Search List” Processing Recommendation 1: The SSAC invites all ICANN Supporting Organizations and Advisory Committees, the IETF, and the DNS operations community to consider the following proposed behavior for search list processing and comment on its correctness, completeness, utility and feasibility.
  1. Administrators (including DHCP server administrators) should configure the search list explicitly, and must not rely on or use implicit search lists; Where DNS parameters such as the domain search list have been manually configured, these parameters should not be overridden by DHCP.
  2. When a user enters a single label name, that name may be subject to search list processing if a search list is specified, but must never be queried in the DNS in its original single-label form.
  3. When a user queries a hostname that contain two or more labels separated by dots, such as www.server, applications and resolvers must query the DNS directly. Search lists must not be applied even if such names do not resolve to an address (A/AAAA). Therefore www.server is always a FQDN.
     SAC064 Open SSAC 2/24/14 TBC www.icann.org/en/groups/ssac/documents/sac-064-en.pdf
20140213 DNS security SSAC Advisory on DNS “Search List” Processing Recommendation 2: The SSAC recommends ICANN staff to work with the DNS community and the IETF to encourage the standardization of search list processing behavior.     SAC064 Open SSAC 2/24/14 TBC www.icann.org/en/groups/ssac/documents/sac-064-en.pdf
20140213 DNS security SSAC Advisory on DNS “Search List” Processing Recommendation 3: In the context of mitigating name collisions, ICANN should consider the following steps to address search list processing behavior.
  1. Commission additional research studies to further understand the cause of invalid queries to the root zone and the significance of search list processing as a contributor to those queries.
  2. Communicate to system administrators that search list behaviors currently implemented in some operating systems will cause collision with names provisioned under the newly delegated top-level domains. Such communication should complement the current ICANN effort in this area with findings and recommendations from this report.
     SAC064 Open SSAC 2/24/14 TBC www.icann.org/en/groups/ssac/documents/sac-064-en.pdf
20131107 Root system SSAC Advisory on DNSSEC Key Rollover in the Root Zone Recommendation 1. Internet Corporation for Assigned Names and Numbers (ICANN) staff, in coordination with the other Root Zone Management Partners (United States Department of Commerce, National Telecommunications and Information Administration (NTIA), and Verisign), should immediately undertake a significant, worldwide communications effort to publicize the root zone KSK rollover motivation and process as widely as possible. The ICANN Board passed a resolution on 21 Nov 2013 that, amongst others, "directs ICANN’s President and CEO to have the advice provided in SAC063 evaluated, and to produce a recommendation to the Board regarding the acceptance of that advice, no later than 90 days from the adoption of this resolution", and; directs — in the instances where ICANN recommends that the advice be accepted — ICANN’s President and CEO to have the feasibility and costs of implementing the advice evaluated, and to provide an implementation plan with timelines and high-level milestones for review by the Board, no later than 120 days from the adoption of this resolution. ICANN staff is evaluating these recommendations as mandated in its 21 November 2013 resolution http://www.icann.org/en/groups/board/documents/resolutions-21nov13-en.htm#1.a and will share its results by 17 February 2014. In the instances where ICANN recommends that the advice be accepted — ICANN will evaluate the feasibility and costs of implementation, and provide an implementation plan with timelines and high-level milestones for review by the Board, no later than 21 March 2014. SAC063 Ongoing SSAC 11/8/13 TBC www.icann.org/en/groups/ssac/documents/sac-063-en.pdf
20131107 Root system SSAC Advisory on DNSSEC Key Rollover in the Root Zone Recommendation 2: ICANN staff should lead, coordinate, or otherwise encourage the creation of a collaborative, representative testbed for the purpose of analyzing behaviors of various validating resolver implementations, their versions, and their network environments (e.g., middle boxes) that may affect or be affected by a root KSK rollover, such that potential problem areas can be identified, communicated, and addressed. The ICANN Board passed a resolution on 21 Nov 2013 that, amongst others, "directs ICANN’s President and CEO to have the advice provided in SAC063 evaluated, and to produce a recommendation to the Board regarding the acceptance of that advice, no later than 90 days from the adoption of this resolution", and; directs — in the instances where ICANN recommends that the advice be accepted — ICANN’s President and CEO to have the feasibility and costs of implementing the advice evaluated, and to provide an implementation plan with timelines and high-level milestones for review by the Board, no later than 120 days from the adoption of this resolution. ICANN staff is evaluating these recommendations as mandated in its 21 November 2013 resolution http://www.icann.org/en/groups/board/documents/resolutions-21nov13-en.htm#1.a and will share its results by 17 February 2014. In the instances where ICANN recommends that the advice be accepted — ICANN will evaluate the feasibility and costs of implementation, and provide an implementation plan with timelines and high-level milestones for review by the Board, no later than 21 March 2014. SAC063 Ongoing SSAC 11/8/13 TBC www.icann.org/en/groups/ssac/documents/sac-063-en.pdf
20131107 Root system SSAC Advisory on DNSSEC Key Rollover in the Root Zone Recommendation 3: ICANN staff should lead, coordinate, or otherwise encourage the creation of clear and objective metrics for acceptable levels of “breakage” resulting from a key rollover. The ICANN Board passed a resolution on 21 Nov 2013 that, amongst others, "directs ICANN’s President and CEO to have the advice provided in SAC063 evaluated, and to produce a recommendation to the Board regarding the acceptance of that advice, no later than 90 days from the adoption of this resolution", and; directs — in the instances where ICANN recommends that the advice be accepted — ICANN’s President and CEO to have the feasibility and costs of implementing the advice evaluated, and to provide an implementation plan with timelines and high-level milestones for review by the Board, no later than 120 days from the adoption of this resolution. ICANN staff is evaluating these recommendations as mandated in its 21 November 2013 resolution http://www.icann.org/en/groups/board/documents/resolutions-21nov13-en.htm#1.a and will share its results by 17 February 2014. In the instances where ICANN recommends that the advice be accepted — ICANN will evaluate the feasibility and costs of implementation, and provide an implementation plan with timelines and high-level milestones for review by the Board, no later than 21 March 2014. SAC063 Ongoing SSAC 11/8/13 TBC www.icann.org/en/groups/ssac/documents/sac-063-en.pdf
20131107 Root system SSAC Advisory on DNSSEC Key Rollover in the Root Zone Recommendation 4: ICANN staff should lead, coordinate, or otherwise encourage the development of rollback procedures to be executed when a rollover has affected operational stability beyond a reasonable boundary. The ICANN Board passed a resolution on 21 Nov 2013 that, amongst others, "directs ICANN’s President and CEO to have the advice provided in SAC063 evaluated, and to produce a recommendation to the Board regarding the acceptance of that advice, no later than 90 days from the adoption of this resolution", and; directs — in the instances where ICANN recommends that the advice be accepted — ICANN’s President and CEO to have the feasibility and costs of implementing the advice evaluated, and to provide an implementation plan with timelines and high-level milestones for review by the Board, no later than 120 days from the adoption of this resolution. ICANN staff is evaluating these recommendations as mandated in its 21 November 2013 resolution http://www.icann.org/en/groups/board/documents/resolutions-21nov13-en.htm#1.a and will share its results by 17 February 2014. In the instances where ICANN recommends that the advice be accepted — ICANN will evaluate the feasibility and costs of implementation, and provide an implementation plan with timelines and high-level milestones for review by the Board, no later than 21 March 2014. SAC063 Ongoing SSAC 11/8/13 TBC www.icann.org/en/groups/ssac/documents/sac-063-en.pdf
20131107 Root system SSAC Advisory on DNSSEC Key Rollover in the Root Zone 5: ICANN staff should lead, coordinate, or otherwise encourage the collection of as much information as possible about the impact of a KSK rollover to provide input to planning for future rollovers. The ICANN Board passed a resolution on 21 Nov 2013 that, amongst others, "directs ICANN’s President and CEO to have the advice provided in SAC063 evaluated, and to produce a recommendation to the Board regarding the acceptance of that advice, no later than 90 days from the adoption of this resolution", and; directs — in the instances where ICANN recommends that the advice be accepted — ICANN’s President and CEO to have the feasibility and costs of implementing the advice evaluated, and to provide an implementation plan with timelines and high-level milestones for review by the Board, no later than 120 days from the adoption of this resolution. ICANN staff is evaluating these recommendations as mandated in its 21 November 2013 resolution http://www.icann.org/en/groups/board/documents/resolutions-21nov13-en.htm#1.a and will share its results by 17 February 2014. In the instances where ICANN recommends that the advice be accepted — ICANN will evaluate the feasibility and costs of implementation, and provide an implementation plan with timelines and high-level milestones for review by the Board, no later than 21 March 2014. SAC063 Ongoing SSAC 11/8/13 TBC www.icann.org/en/groups/ssac/documents/sac-063-en.pdf
20131107 New gTLDs SSAC Advisory Concerning the Mitigation of Name Collision Risk Recommendation 1: ICANN should work with the wider Internet community, including at least the IAB and the IETF, to identify (1) what strings are appropriate to reserve for private namespace use and (2) what type of private namespace use is appropriate (i.e., at the TLD level only or at any additional lower level). The ICANN Board passed a resolution on 21 Nov 2013 that, "directs ICANN’s President and CEO to have the advice provided in SAC062 evaluated, and to produce a recommendation to the Board regarding the acceptance of that advice, no later than 90 days from the adoption of this resolution"; directs — in the instances where ICANN recommends that the advice be accepted — ICANN’s President and CEO to have the feasibility and costs of implementing the advice evaluated, and to provide an implementation plan with timelines and high-level milestones for review by the Board, no later than 120 days from the adoption of this resolution.
In addition, the Board (2013.11.21.16) adopted the NGPC recommendations: "(1) the ICANN Board Risk Committee expressly reviews name collision matters and reports back to the Board, and continues to review and report at regular intervals; (2) the Board directs the ICANN President and CEO to develop a long-term plan to manage name collision at the root; and (3) the Board directs the ICANN President and CEO to work with the community to develop a long-term plan to retain and measure root-server data"		 ICANN staff is evaluating these recommendations as mandated in its 21 November 2013 resolution http://www.icann.org/en/groups/board/documents/resolutions-21nov13-en.htm#1.a and will share its results by 17 February 2014. In the instances where ICANN recommends that the advice be accepted — ICANN will evaluate the feasibility and costs of implementation, and provide an implementation plan with timelines and high-level milestones for review by the Board, no later than 21 March 2014. SAC062 Ongoing SSAC 11/8/13 TBC www.icann.org/en/groups/ssac/documents/sac-062-en.pdf
20131107 New gTLDs SSAC Advisory Concerning the Mitigation of Name Collision Risk Recommendation 2: ICANN should explicitly consider the following questions regarding trial delegation and clearly articulate what choices have been made and why as part of its decision as to whether or not to delegate any TLD on a trial basis:
  • Purpose of the trial: What type of trial is to be conducted? What data are to be collected?
  • Operation of the trial: Should ICANN (or a designated agent) operate the trial or should the applicant operate it?
  • Emergency Rollback: What are the emergency rollback decision and execution procedures for any delegation in the root, and have the root zone partners exercised these capabilities?
  • Termination of the trial: What are the criteria for terminating the trial (both normal and emergency criteria)? What is to be done with the data collected? Who makes the decision on what the next step in the delegation process is?
 The ICANN Board passed a resolution on 21 Nov 2013 that, "directs ICANN’s President and CEO to have the advice provided in SAC062 evaluated, and to produce a recommendation to the Board regarding the acceptance of that advice, no later than 90 days from the adoption of this resolution"; directs — in the instances where ICANN recommends that the advice be accepted — ICANN’s President and CEO to have the feasibility and costs of implementing the advice evaluated, and to provide an implementation plan with timelines and high-level milestones for review by the Board, no later than 120 days from the adoption of this resolution.
In addition, the Board (2013.11.21.16) adopted the NGPC recommendations: "(1) the ICANN Board Risk Committee expressly reviews name collision matters and reports back to the Board, and continues to review and report at regular intervals; (2) the Board directs the ICANN President and CEO to develop a long-term plan to manage name collision at the root; and (3) the Board directs the ICANN President and CEO to work with the community to develop a long-term plan to retain and measure root-server data"		 ICANN staff is evaluating these recommendations as mandated in its 21 November 2013 resolution http://www.icann.org/en/groups/board/documents/resolutions-21nov13-en.htm#1.a and will share its results by 17 February 2014. In the instances where ICANN recommends that the advice be accepted — ICANN will evaluate the feasibility and costs of implementation, and provide an implementation plan with timelines and high-level milestones for review by the Board, no later than 21 March 2014. SAC062 Ongoing SSAC 11/8/13 TBC www.icann.org/en/groups/ssac/documents/sac-062-en.pdf
20131107 New gTLDs SSAC Advisory Concerning the Mitigation of Name Collision Risk Recommendation 3: ICANN should explicitly consider under what circumstances un-delegation of a TLD is the appropriate mitigation for a security or stability issue. In the case where a TLD has an established namespace, ICANN should clearly identify why the risk and harm of the TLD remaining in the root zone is greater than the risk and harm of removing a viable and in-use namespace from the DNS. Finally, ICANN should work in consultation with the community, in particular the root zone management partners, to create additional processes or update existing processes to accommodate the potential need for rapid reversal of the delegation of a TLD The ICANN Board passed a resolution on 21 Nov 2013 that, "directs ICANN’s President and CEO to have the advice provided in SAC062 evaluated, and to produce a recommendation to the Board regarding the acceptance of that advice, no later than 90 days from the adoption of this resolution"; directs — in the instances where ICANN recommends that the advice be accepted — ICANN’s President and CEO to have the feasibility and costs of implementing the advice evaluated, and to provide an implementation plan with timelines and high-level milestones for review by the Board, no later than 120 days from the adoption of this resolution.
In addition, the Board (2013.11.21.16) adopted the NGPC recommendations: "(1) the ICANN Board Risk Committee expressly reviews name collision matters and reports back to the Board, and continues to review and report at regular intervals; (2) the Board directs the ICANN President and CEO to develop a long-term plan to manage name collision at the root; and (3) the Board directs the ICANN President and CEO to work with the community to develop a long-term plan to retain and measure root-server data"		 ICANN staff is evaluating these recommendations as mandated in its 21 November 2013 resolution http://www.icann.org/en/groups/board/documents/resolutions-21nov13-en.htm#1.a and will share its results by 17 February 2014. In the instances where ICANN recommends that the advice be accepted — ICANN will evaluate the feasibility and costs of implementation, and provide an implementation plan with timelines and high-level milestones for review by the Board, no later than 21 March 2014. SAC062 Ongoing SSAC 11/8/13 TBC www.icann.org/en/groups/ssac/documents/sac-062-en.pdf
20130913 New gTLDs ALAC Statement on Confusingly Similar gTLDS The ALAC advises the Board to revisit the issue of new TLD strings, which are singular and plural versions of the same word, and ensure that ICANN does not delegate strings that are virtually certain to create confusion among Internet users and therefore result in loss of faith in the DNS. The NGPC Chair responded that in their ongoing deliberations, the NGPC and the ICANN Generic Domains Division will continue to monitor the objection determinations made by expert panels as well as continue to consider the issues raised by the “At-Large Statement on the Confusingly Similar gTLDs”. AL-ALAC-ST-0913-04-00-EN Ongoing ALAC 9/16/13 TBC http://atlarge.icann.org/correspondence/correspondence-16sep13-en.htm
20130913 New gTLDs ALAC Statement on Confusingly Similar gTLDS The ALAC advises the Board to review the objection decision system with multiple panels that leads to inconsistency and not only review the obvious case of .cam/.com where conflicting objection decisions have forced such review. The NGPC Chair responded that in their ongoing deliberations, the NGPC and the ICANN Generic Domains Division will continue to monitor the objection determinations made by expert panels as well as continue to consider the issues raised by the “At-Large Statement on the Confusingly Similar gTLDs”. AL-ALAC-ST-0913-04-00-EN Ongoing ALAC 9/16/13 TBC http://atlarge.icann.org/correspondence/correspondence-16sep13-en.htm
20130913 New gTLDs ALAC Statement on Confusingly Similar gTLDS The ALAC advises the Board to determine a viable way forward which will not create unwarranted contention sets nor delegate multiple TLDs destined to ensure user confusion and implicit loss of faith in the DNS. The NGPC Chair responded that in their ongoing deliberations, the NGPC and the ICANN Generic Domains Division will continue to monitor the objection determinations made by expert panels as well as continue to consider the issues raised by the “At-Large Statement on the Confusingly Similar gTLDs”. AL-ALAC-ST-0913-04-00-EN Ongoing ALAC 9/16/13 TBC http://atlarge.icann.org/correspondence/correspondence-16sep13-en.htm
20130906 Domain Name Registration Data SSAC Comment on ICANN's Initial Report from the Expert Working Group on gTLD Directory Services Recommendation 1: The ICANN Board should explicitly defer any other activity (within ICANN's remit) directed at finding a 'solution' to 'the WHOIS problem' until the registration data policy has been developed and accepted in the community. ICANN's Board requested that ICANN's President & CEO form the Expert Working Group (EWG) to help resolve deadlock within the ICANN community on how to replace the current WHOIS system with a next-generation gTLD directory service that better meets the needs of today's & tomorrow's Internet. The EWG hopes to publish its Final Report by October 2013 for delivery to ICANN's CEO and Board to serve as a foundation for new gTLD consensus policy development, and contractual negotiations, as appropriate.
There has been no specific action by the Board on this topic to date.		 The Expert Working Group (EWG) is working on developing a registration data policy. It is conducting other activities in parallel rather than sequentially. These include developing a framework and protocol; studying a successor directory service to WHOIS; improving registration data accuracy; investigating validation techniques, and strengthening compliance. SAC061 Ongoing SSAC 9/9/13 TBC http://www.icann.org/en/groups/ssac/documents/sac-061-en.pdf
20130906 Domain Name Registration Data SSAC Comment on ICANN's Initial Report from the Expert Working Group on gTLD Directory Services Recommendation 2: The ICANN Board should ensure that a formal security risk assessment of the registration data policy be conducted as an input into the Policy Development Process. There has been no specific action by the Board on this topic to date. The Expert Working Group (EWG) expects to derive initial recommendations but recommends that risk analysis be performed on each data element. Comment is requested on how this risk analysis should be conducted, who should conduct it, and criteria by which each data element should be classified. SAC061 Ongoing SSAC 9/9/13 TBC http://www.icann.org/en/groups/ssac/documents/sac-061-en.pdf
20130906 Domain Name Registration Data SSAC Comment on ICANN's Initial Report from the Expert Working Group on gTLD Directory Services Recommendation 3: SSAC recommends that the EWG state more clearly its positions on specific questions of data availability. There has been no specific action by the Board on this topic to date. The Expert Working Group (EWG) is considering SAC061 and questions of data availability and purpose-driven data access and disclosure. SAC061 Ongoing SSAC 9/9/13 TBC
20130906 Domain Name Registration Data SSAC Comment on ICANN's Initial Report from the Expert Working Group on gTLD Directory Services Recommendation 4: The SSAC suggests that the EWG address this recommendation from SAC058: SSAC Report on Domain Name Registration Data Validation: As the ICANN community discusses validating contact information, the SSAC recommends that the following meta-questions regarding the costs and benefits of registration data validation should be answered:
  • What data elements need to be added or validated to comply with requirements or expectations of different stakeholders?
  • Is additional registration processing overhead and delay an acceptable cost for improving accuracy and quality of registration data?
  • Is higher cost an acceptable outcome for improving accuracy and quality?
  • Would accuracy improve if the registration process were to provide natural persons with privacy protection upon completion of multi-factored validation?
 There has been no specific action by the Board on this topic to date. In addition the Expert Working Group (EWG) is conducting analysis on additional validation methods and is considering SAC058. SAC061 Ongoing SSAC 9/9/13 TBC
20130809 New gTLDs ALAC Statement on the Preferential Treatment for Community Applications in String Contention The ALAC call on ICANN to review all 688 applications currently in contention and provide preferential treatment to applications that meet the characteristics of community applications. On 09/21/2013, the Chair of the NGPC responded to ALAC that implementing the ALAC’s advice would represent a change to the policies and procedures established in the Applicant Guidebook. In the interest of fairness to all applicants, it would not be appropriate to re-evaluate applications that chose not to self-designate as community-based applications. As such, all applications will be considered based on their current designations. AL-ALAC-ST-0813-02-00-EN Closed ALAC 8/22/13 TBC http://atlarge.icann.org/correspondence/correspondence-2-09aug13-en.htm
20130809 New gTLDs ALAC Statement on community expertise in community priority evaluation The ALAC has concerns about the sufficiency of community expertise in panels that evaluate new gTLD community applications. On 09/30/2013, the Chair of the NGPC responded to some of the concerns raised by ALAC, stating that the Community Priority Evaluation (CPE) Panel firm was selected via a public procurement process. AL-ALAC-ST-0813-03-00-EN Ongoing ALAC 8/11/13 TBC http://atlarge.icann.org/correspondence/correspondence-09aug13-en.htm
20130809 New gTLDs ALAC Statement on community expertise in community priority evaluation The ALAC stands ready to offer appropriate ICANN community volunteers to serve as panel members or advisors. On 09/30/2013, the Chair of the NGPC stated that the NGPC appreciated the offer made by the ALAC to provide community volunteers to serve as Panel members or advisors, but determined that it would not be appropriate to introduce external parties to the EIU (Economic Intelligence Unit)’s evaluation process. AL-ALAC-ST-0813-03-00-EN Ongoing ALAC 8/22/13 TBC http://atlarge.icann.org/correspondence/correspondence-09aug13-en.htm
20130723 IDN Active Variant TLDs Regarding ICANN's Report on Examining the User Experience Implications of Active Variant TLDs: The root zone must use one and only one set of Label Generation Rules (LGR). The ICANN Board continues to monitor the implementation of IDN variant TLDs through the IDN Variants Working Group it set up in 2010. This group advises ICANN staff on the implementation of IDN variant TLDs, including the implementation of an IDN LGR for the root zone. ICANN fully agrees with this recommendation and the IDN LGR procedure will implement this recommendation SAC060 Ongoing SSAC TBC TBC http://www.icann.org/en/groups/ssac/documents/sac-060-en.pdf
20130723 IDN Active Variant TLDs ICANN must maintain a secure, stable, and objective process to resolve cases in which some members of the community (e.g., an applicant for a TLD) do not agree with the result of the Label Generation Rules (LGR) calculations. There is currently no objection process for members of the community who do not agree with the result of the Label Generation Rules (LGR) calculations. However, each release of the integrated IDN LGR will be open to public comments prior to publication. ICANN appeal procedures include contacting the ombudsman or the potential for use of the reconsideration request process, when appropriate. SAC060 Open SSAC TBC TBC http://www.icann.org/en/groups/ssac/documents/sac-060-en.pdf
20130723 IDN Active Variant TLDs ICANN should concentrate foremost on the rules for the root zone (versus rules for TLD registry operators). ICANN fully agrees with this recommendation and the IDN LGR procedure will implement this recommendation. SAC060 Ongoing SSAC TBC TBC http://www.icann.org/en/groups/ssac/documents/sac-060-en.pdf
20130723 IDN Active Variant TLDs ICANN should coordinate and encourage adoption of these rules at the second and higher levels as a starting point by:
  • Updating the IDN Implementation Guidelines;
  • Maintaining and publishing a central repository of rules for second-level domain labels (2LDs) for all Top Level Domains (TLDs); and
  • Conducting specific training and outreach sessions
 ICANN agrees with these recommendations. In the last quarter of 2013, ICANN staff are focusing on the implementation of the LGR procedure for the root zone. Once the process is fully implemented, staff will focus on implementing these recommendations. The IANA functions maintain a repository of IDN tables, which may in the future serve as the recommended central repository. SAC060 Ongoing SSAC TBC TBC http://www.icann.org/en/groups/ssac/documents/sac-060-en.pdf
20130723 IDN Active Variant TLDs Be very conservative with respect to the code points that are permitted in root zone labels. ICANN fully agrees with this recommendation and the IDN LGR procedure is designed to follow a conservative and minimalist approach to maintain the security and stability of the root zone. SAC060 Ongoing SSAC TBC TBC http://www.icann.org/en/groups/ssac/documents/sac-060-en.pdf
20130723 IDN Active Variant TLDs Because the removal of a delegation from the root zone can have significant non-local impact, new rules added to a LGR must, as far as possible, be backward compatible so that new versions of the LGR do not produce results that are incompatible with historical (existent) activations. ICANN fully agrees with this recommendation and backwards compatibility will be one of the main considerations the Integration Panel has to take into account in each release of the IDN LGR. SAC060 Ongoing SSAC TBC TBC http://www.icann.org/en/groups/ssac/documents/sac-060-en.pdf
20130723 IDN Active Variant TLDs Should ICANN decide to implement safeguards, it should distinguish two types of failure modes when a user expects a variant to work, but it is not implemented: denial of service versus misconnection. ICANN plans to take this recommendation into account in the future. It should be noted that this issue is not part of the remit of the IDN variant programme. SAC060 Open SSAC TBC TBC http://www.icann.org/en/groups/ssac/documents/sac-060-en.pdf
20130723 IDN Active Variant TLDs A process should be developed to activate variants from allocatable variants in LGR. ICANN fully agrees with this recommendation and the entire project n°7 of the variant program is dedicated to developing the processes to handle variant mechanisms, including the life cycle of a variant label. SAC060 Ongoing SSAC TBC TBC http://www.icann.org/en/groups/ssac/documents/sac-060-en.pdf
20130723 IDN Active Variant TLDs ICANN must ensure that Emergency Back-End Registry Operator (EBERO) providers support variant TLDs, and that parity exists for variant support in all relevant systems and functions associated with new TLD components. This recommendation has been implemented. All EBERO providers support variant TLDs; there is parity for variant support in all relevant systems and functions. SAC060 Closed SSAC TBC TBC http://www.icann.org/en/groups/ssac/documents/sac-060-en.pdf
20130723 IDN Active Variant TLDs The current rights protection regime associated with the Trademark Clearinghouse (TMCH) process is susceptible to homographic attacks. The roles of the involved parties, specifically registrars, registries, and TMCH, related to matching must be made clear. Supporting documentation regarding the TMCH has been made available including testing processes and rights protection requirements. Signed Mark Data (SMD) Testing files have been made available and are intended to help Registries and Registrars in their integration efforts with the Trademark Clearinghouse in advance of delegation. SAC060 Ongoing SSAC TBC TBC http://www.icann.org/en/groups/ssac/documents/sac-060-en.pdf
20130723 IDN Active Variant TLDs When registries calculate variant sets for use in validation during registration, such calculations must be done against all of the implemented LGRs covering the script in which the label is applied for. ICANN plans to take this recommendation into account in the future. It should be noted that ICANN's direct remit is limited to the root zone. SAC060 Ongoing SSAC TBC TBC http://www.icann.org/en/groups/ssac/documents/sac-060-en.pdf
20130723 IDN Active Variant TLDs The matching algorithm for TMCH must be improved. This recommendation has not been implemented yet. SAC060 Open SSAC TBC TBC http://www.icann.org/en/groups/ssac/documents/sac-060-en.pdf
20130723 IDN Active Variant TLDs The TMCH must add support for IDN variant TLDs. Particularly during the TM Claims service, a name registered under a TLD that has allocated variant TLDs should trigger trademark holder notifications for the registration of the name in all of its allocated variant TLDs. TBC SAC060 Open SSAC TBC TBC http://www.icann.org/en/groups/ssac/documents/sac-060-en.pdf
20130723 IDN Active Variant TLDs ICANN should ensure that the number of strings that are activated is as small as possible. ICANN fully agrees with this recommendation and the number of strings that may become activated as a result of the LGR procedure should be minimal, as the procedure is designed to follow a conservative and minimalist approach to variant labels. SAC060 Ongoing SSAC TBC TBC http://www.icann.org/en/groups/ssac/documents/sac-060-en.pdf
20130607 DNS security ALAC Statement to the Board Regarding Security and Stability Implications of New gTLDs The ALAC urges the Board to closely monitor the work being done by the ICANN Security Team with the CAB (Certificate Authorities and Browsers) Forum and ensure the Board’s decisions are informed by the progress of this work to reduce risk. At its meeting on 7 October 2013, the ICANN Board New gTLD Program Committee (NGPC) adopted a resolution proposing a path foward for dealing with potential namespace collisions. AL-ALAC-ST-0513-02-00-EN Ongoing ALAC TBC TBC http://www.icann.org/en/groups/board/documents/resolutions-new-gtld-07oct13-en.htm
20130607 DNS security ALAC Statement to the Board Regarding Security and Stability Implications of New gTLDs The ALAC urges the Board to take full consideration of relevant SSAC advice and recommendations to ensure that residual risk is minimized and specifically that residual risk is not transferred to third parties such as current registry operators, new gTLD applicants, registrants, consumers and individual end users. At its meeting on 13 August 2013, the ICANN Board New gTLD Program Committee (NGPC) adopted a resolution affirming that "dotless domain names" are prohibited. AL-ALAC-ST-0513-02-00-EN Ongoing ALAC TBC TBC http://www.icann.org/en/news/announcements/announcement-30aug13-en.htm
20130418 Root system Advice on how “interdisciplinary studies of security and stability implications from expanding the root zone more than an order of magnitude should be carried out and whom else should be consulted.” The SSAC recommends those issues that previous public comment periods have suggested were inadequately explored as well as issues related to cross-functional interactions of the changes brought about by root zone growth should be examined. The SSAC believes the use of experts with experience outside of the fields on which the previous studies relied would provide useful additional perspective regarding stubbornly unresolved concerns about the longer-term management of the expanded root zone and related systems. It may be feasible for ICANN and the Board to direct one or several of the Strategy Panels to consider specific questions if SSAC were to submit them, so that the expert panels could study and offer perspectives other than (different from) those offered by members fields represented in prior studies. This advice is being taken into account by ICANN. SAC059 Ongoing SSAC TBC TBC http://www.icann.org/en/groups/ssac/documents/sac-059-en.pdf
20130327 Domain Name Registration Data SSAC Report on Domain Name Registration Data Validation The SSAC recommends that the ICANN community should consider adopting the terminology outlined in this report in documents and discussions. The adoption of this language is in progress and extends beyond the ICANN community in which the ICANN WHOIS EWG, the Application Guidebook, the new gTLD registry agreement and the 2013 RAA incorporate terminology used within the SAC058. IETF work on a successor protocol for WHOIS ("WEIRDS") that also adopts this language c.f. tools. http://datatracker.ietf.org/wg/weirds/charter/: This should assure that when the protocol is adopted, the new terminology will replace the old. An open question remains as to whether distinguishing existing services as "whois" from future "directory services" may be more beneficial than a wholesale substitution of the new terminology. SAC058 Ongoing SSAC TBC TBC http://www.icann.org/en/groups/ssac/documents/sac-058-en.pdf
20130327 Domain Name Registration Data SSAC Report on Domain Name Registration Data Validation As the ICANN community discusses validating contact information, the SSAC recommends that the following meta-questions regarding the costs and benefits of registration data validation should be answered The Board adopted the new 2013 RAA that includes some validation of contact information. The fact that this is incorporated as an obligation on registrars is testimony that SSAC recommendations have influenced the Board, ICANN and community. Many of these questions are being addressed in the Expert Working Group (EWG)'s work and are anticipated to be part of the policy questions posed within a future policy development process (PDP) by the gNSO. SAC058 Ongoing SSAC TBC TBC http://www.icann.org/en/groups/ssac/documents/sac-058-en.pdf
20130327 Domain Name Registration Data SSAC Report on Domain Name Registration Data Validation The SSAC recommends that the ICANN community should seek to identify validation techniques that can be automated and to develop policies that incent the development and deployment of those techniques. The use of automated techniques may necessitate an initial investment but the long-term improvement in the quality and accuracy of registration data will be substantial. The Board adopted the new 2013 RAA that includes some validation of contact information. The EWG is conducting analysis on additional validation methods and is considering SAC058. ICANN staff invited Chris Davis from the Secure Domain Foundation to present research and a pilot API for validating postal addresses on 10 October 2013 to members of the WHOIS EWG and ICANN staff/executives. This work was presented at an APWG conference in September 2013. SAC058 Ongoing SSAC TBC TBC http://www.icann.org/en/groups/ssac/documents/sac-058-en.pdf
20130315 DNS ABUSE Advisory on Internal Name Certificates The ICANN Security Team should immediately develop and execute a risk mitigation plan re: Internal Name Certificates Measures were incorporated into the New gTLD collision occurrence management plan adopted by the NGPC - see NGPC Resolution for Addressing the Consequences of Name Collisions http://www.icann.org/en/news/announcements/announcement-08oct13-en.htm This work was undertaken by ICANN staff including the Security Team. ICANN has coordinated mitigation efforts with the CA/Browser forum. Specifically,
  1. ICANN worked with the Certificate Authority Browser Forum (CA/B Forum), which passed Ballot 96 at its annual meeting to address the concern. Ballot 96 calls for Certification Authorities (CAs) to stop issuing certificates that end in an applied‐for‐gTLD string within 30 days of ICANN signing the contract with the registry operator, and revoke any existing certificates within 120 days of ICANN signing the contract with the registry operator. [COMPLETED]
  2. ICANN developed and published a coordinated disclosure policy on 11 March 2013 based on industry best practices (http://www.icann.org/en/about/staff/security/vulnerability‐disclosure‐11mar13‐en.pdf). [COMPLETED]
  3. On 15 March 2013, ICANN notified new gTLD applicants and browser vendors about the potential issues with internal name certificates, and further discussed the issue during public sessions at the ICANN Beijing meeting 7‐11 April 2013. [COMPLETED]
  4. ICANN developed a notification service to CAs and browser vendors alerting them of the applied‐for‐gTLD strings as well as contracting milestone for each string. [COMPLETED]
  5. ICANN intends to take the following actions to address residual risks that may remain with the internal name certificates issue:
  6. Work with browsers to reach out to CAs who are not on the CA / Browser forum but are in browser’s CA certification program. To date, Mozilla has requested all of its CAs to abide by ballot 96 by 15 September, 2013. ICANN is actively working with others. [COMPLETED]
  7. Commission a study, through a third party, on the number of invalid queries to the root zone and potential impacts to the applied‐for new gTLD strings. In addition, the commissioned study would provide ICANN with recommendations on which strings represent high collision risks and steps ICANN should take moving forward to address these strings. The recommendations were presented to the Board for acceptance, and once implemented, are expected to manage and mitigate the concerns expressed by the SSAC. [COMPLETED]
 SAC057 Complete SSAC TBC TBC http://www.icann.org/en/groups/ssac/documents/sac-057-en.pdf
20121009 DNS SECURITY SSAC Advisory on Impacts of Content Blocking via the Domain Name System SAC 056 concludes that "Governments and others should take these issues into consideration and fully understand the technical implications when developing policies that depend upon the DNS to block or otherwise filter Internet content" SAC 056 is an Advisory that contains no recommendations that require Board action. Staff and SSAC members have provided outreach to governments by publishing several articles in trade journals (listed in SAC 056) which in some respects helps raise government and private sector awareness. SAC056 Complete SSAC TBC TBC http://www.icann.org/en/groups/ssac/documents/sac-056-en.pdf
20120914 WHOIS WHOIS: Blind Men And An Elephant ICANN CEO to create a domain name policy committee that includes the highest level of executive management An Expert Working Group (EWG) that includes ICANN's CEO and the Chair of the ICANN Board was created at the request of the Board to find a replacement to Whois. ICANN had convened a cross-functional team of executive managers to implement the improvements to Whois. SSAC raises important questions. WHOIS - in new terminology becomes a protocol (RDAP), directory service (RDDS or RDS) and registration data set definition. To satisfy SSAC's recommendations, several pieces must come together: (1) IETF must complete the RDAP and schema (happening), (2) Multistakeholder consensus policy must agree on data set and service definition policies. This is a long-horizon set of projects. The technical elements require the cooperation of multiple communities (ICANN, RIRs, IETF, registry operators). The policy elements include multi-stakeholder issues (access, validation, data set definition, adoption/incorporation into contracts). SAC055 Complete SSAC TBC TBC http://www.icann.org/en/groups/ssac/documents/sac-055-en.pdf
20120914 WHOIS WHOIS: Blind Men And An Elephant Re: WhoIS policy, The Board to clearly state that the development of a uniform policy is a critical priority. The Board's resolution of November 8th 2012 on the "WHOIS Policy Review Team Report" and the accompanying "action plan" demonstrate the Board's commitment to moving towards a uniform data registration policy, with the action plan specifically mandating the development of a "Single WHOIS Policy" and referring to SAC055. https://www.myicann.org/board-resolution/2012-11-08-whois-policy-review-team-report SAC055 Ongoing SSAC TBC TBC http://www.icann.org/en/groups/ssac/documents/sac-055-en.pdf
20120914 WHOIS WHOIS: Blind Men And An Elephant The domain name policy committee should develop clear targets for compliance with respect to registration data accuracy; performance provisions such as SLA must be considered as part of the compliance function. The Board's resolution of November 8th 2012 on the "WHOIS Policy Review Team Report" and in particular the accompanying "action plan" highlight the need for continued and strengthened compliance activities over registration data-related contractual obligations. However, no specific targets for compliance in relation to data accuracy have been adopted to date. Through the 2013 Registrar Accreditation Agreement (RAA), ICANN has now incorporated data accuracy requirements which are subject to compliance oversight. SAC055 Ongoing SSAC TBC TBC http://www.icann.org/en/groups/ssac/documents/sac-055-en.pdf
20120914 WHOIS WHOIS: Blind Men And An Elephant An accuracy policy should define each data element and require that it be examined and indicate for each element a method for determining the level of accuracy of the data. The EWG is evaluating accuracy policies and a policy development process (PDP) on registration data policy by the gNSO will follow the EWG's work. The policy recommendations arising from the GNSO's work will then be sent to the Board for consideration. SAC055 Ongoing SSAC TBC TBC http://www.icann.org/en/groups/ssac/documents/sac-055-en.pdf
20120914 WHOIS WHOIS: Blind Men And An Elephant Internationalized Domain Names: Internationalization MUST be supported by default, not called out separately. The focus should be on Recommendation 2 from the IRD-WG final report. The "WHOIS Policy Review Team Report" adopted by the Board on the 8th of November 2012 included specific recommendations regarding IDN registration data. http://www.icann.org/en/groups/board/documents/resolutions-08nov12-en.htm#1.a For reference, the IETF/WEIRDS activities take this into consideration. The successor protocol will support display of domain name and other registration data in non-Latin scripts. SAC055 Ongoing SSAC TBC TBC http://www.icann.org/en/groups/ssac/documents/sac-055-en.pdf
20120914 WHOIS WHOIS: Blind Men And An Elephant Internationalized Domain Names: Policies with respect to the accuracy of registration data should apply equally to all registration data without regard to whether it is internationalized or ASCII registration data. The action plan adopted by the Board included specific recommendations acknowledging the importance of addressing IDN registration data as part of the the future work on general registration data issues and evaluating the relevant recommendations from the SSAC or GNSO. ICANN agrees with this recommendation. The same granular validation policy should be applied for internationalized registration data as for ASCII registration data. SAC055 Ongoing SSAC TBC TBC http://www.icann.org/en/groups/ssac/documents/sac-055-en.pdf
20120702 ROOT SYSTEM The New Generic Top Level Domain (gTLD) Process The SSAC does not have any formal view with respect to the issue of batching the review of applications. We do not believe a process for ordering applications bears upon the security and stability of the Internet. This is a comment rather than a recommendation directed at the ICANN Board or staff. SSAC Letter to the ICANN Board on the New Generic Top Level Domain (gTLD) Process (02 July 2012) Closed SSAC TBC TBC http://www.icann.org/en/news/correspondence/faltstrom-to-icann-board-02jul12-en.pdf
20120702 ROOT SYSTEM The New Generic Top Level Domain (gTLD) Process The SSAC believes that questions regarding the maximum number of new TLDs that can be added to the root zone are misplaced. The proper concern is to ensure that the overall root zone publication system is audited and monitored to confirm that its resources can support an increase without degradation in the current service level. The Board formally asked RSSAC for its advice on this topic and an update on plans to satisfy this recommendation. The Board also asked the CEO whether there are other parties who should be consulted, and to ask such parties to participate. ICANN has taken steps to improve the monitoring of the L-root which it operates directly. Monitoring other root servers is within the remit of RSSAC or the root operators individually. On 7 December 2012 ICANN published "Root Zone Scaling Measurements at L‐root" that describes the planned measurements, and includes a timeline for implementation for L‐root. Trending data is published for L‐root at: http://dns.icann.org/services/root-zone-scaling-report-zone-contents/ SSAC Letter to the ICANN Board on the New Generic Top Level Domain (gTLD) Process (02 July 2012) Ongoing SSAC TBC TBC http://www.icann.org/en/news/correspondence/faltstrom-to-icann-board-02jul12-en.pdf
20120702 ROOT SYSTEM The New Generic Top Level Domain (gTLD) Process From SAC 046 on Root Scaling: Formalize and publicly document the interactions between ICANN and the root server operators with respect to root zone scaling. ICANN and the root server operators may choose to utilize RSSAC to facilitate this interaction. The Board requested the CEO direct staff to work with the root server operators via RSSAC to complete the documentation of the interactions between ICANN and the root server operators with respect to root zone scaling. Implementation Status: ICANN as L‐Root operator participates in regular discussions with other Root Server Operators regarding instrumentation of the Root Server system. With respect to measurements directly motivated by concerns over root zone scaling, these discussions have been ongoing since May 2011. While a record of discussions on the RSSAC list exists in the form of its archive, no specific documentation on the interactions between ICANN and other root server operators on this topic has been drafted. [This task is not complete] SSAC Letter to the ICANN Board on the New Generic Top Level Domain (gTLD) Process (02 July 2012) Ongoing SSAC TBC TBC http://www.icann.org/en/news/correspondence/faltstrom-to-icann-board-02jul12-en.pdf
http://www.icann.org/en/groups/ssac/documents/sac-046-en.pdf
20120702 ROOT SYSTEM The New Generic Top Level Domain (gTLD) Process From SAC 046 on Root Scaling: ICANN, U.S. Dept. of Commerce, National Telecommunications and Information Administration (NTIA), and VeriSign should publish statements, or a joint statement, that they are materially prepared for the proposed changes. The Board recommended the CEO to direct staff to work with NTIA and Verisign to explore publication of one or more statements regarding preparation for the proposed changes. Implementation Status: ICANN staff worked with NTIA and Verisign and the parties released a joint statement on 5 November 2012. A copy of the joint statement was sent to the SSAC (via Patrik Fältström) on 8 November 2012. [COMPLETED] SSAC Letter to the ICANN Board on the New Generic Top Level Domain (gTLD) Process (02 July 2012) Complete SSAC TBC TBC http://www.icann.org/en/news/correspondence/faltstrom-to-icann-board-02jul12-en.pdf
http://www.icann.org/en/groups/ssac/documents/sac-046-en.pdf
20120702 ROOT SYSTEM The New Generic Top Level Domain (gTLD) Process From SAC 046 on Root Scaling: ICANN should publish estimates of expected and maximum growth rates of TLDs, including IDNs and their variants, and solicit public feedback on these estimates, with the end goal of being as transparent as possible about the justification for these estimates. The Board recommended the CEO to direct staff to publish current estimates of the expected growth rates of TLDs. The Board suggested the publication of the expected growth rates of TLDs be coordinated with the re‐examination of the process for evaluating gTLD applications. Implementation Status: ICANN has been regularly publishing the expected and maximum growth rates of TLDs. For example, see page 2 of: http://newgtlds.icann.org/en/applicants/batching/drawingprioritization‐10oct12‐en.pdf as well as in other regular new gTLD updates. [COMPLETED]
  1. Batching / Metering: After careful analysis of public comment and possible solutions for processing new gTLD applications, ICANN proposed a drawing for prioritizing applications through the steps leading to delegation. ICANN held a Prioritization Draw (Draw) on 17 December 2012 in Los Angeles to assign priority numbers to all new gTLD applications. Each application was assigned a randomly‐drawn priority number. [COMPLETED]
 SSAC Letter to the ICANN Board on the New Generic Top Level Domain (gTLD) Process (02 July 2012) Complete SSAC TBC TBC http://www.icann.org/en/news/correspondence/faltstrom-to-icann-board-02jul12-en.pdf
http://www.icann.org/en/groups/ssac/documents/sac-046-en.pdf
20120702 ROOT SYSTEM The New Generic Top Level Domain (gTLD) Process From SAC 046 on Root Scaling: ICANN should update its "Plan for Enhancing Internet Security, Stability, and Resiliency," to include actual measurement, monitoring, and data-sharing capability of root zone performance, in cooperation with RSSAC and other root zone management participants to define the specific measurements, monitoring, and data sharing framework. Board Action: The Board formally asked RSSAC for its advice on this topic and an update on plans to satisfy this recommendation. The Board also asked the CEO whether there are other parties who should be consulted, and to ask such parties to participate. NOT COMPLETE. In response to a letter to the SSAC from the ICANN Chairman dated 25 September 2012 (http://www.icann.org/en/news/correspondence/crockerto‐murai‐larson‐25sep12‐en), on 18 October 2012, Matt Larson, SSAC Vice Chairman acknowledged the receipt of the Board request, and requested RSSAC form a work party to collect the existing measurements used by the root server operators and determine, along with ICANN staff, the appropriate parties to participate on the task. As a result, the RSSAC work party prepared a document entitled “Recommendation on Measurement of Root Server System” dated 16 April 2013.
Currently, it is in last call for comments by the RSSAC. [ONGOING]
  1. In addition to the RSSAC effort, on 7 December 2012 ICANN published "Root Zone Scaling Measurements at L‐root" that describes the planned measurements.
 SSAC Letter to the ICANN Board on the New Generic Top Level Domain (gTLD) Process (02 July 2012) Ongoing SSAC TBC TBC http://www.icann.org/en/news/correspondence/faltstrom-to-icann-board-02jul12-en.pdf
http://www.icann.org/en/groups/ssac/documents/sac-046-en.pdf
20120702 ROOT SYSTEM The New Generic Top Level Domain (gTLD) Process From SAC 046 on Root Scaling: ICANN should commission and incent interdisciplinary studies of security and stability implications from expanding the root zone more than an order of magnitude, particularly for enterprises and other user communities who may implement strong assumptions about the number of TLDs that may conflict with future allocations. The Board formally requested SSAC for its advice on how interdisciplinary studies of security and stability implications from expanding the root zone more than an order of magnitude should be carried out and whom else should be consulted, and tasked staff with formulating and executing one or more studies, as needed. Implementation: After submission of a letter to the SSAC from the ICANN Chairman on 25 September 2012 (http://www.icann.org/en/news/correspondence/crocker‐to‐faltstrom‐25sep12‐en), the SSAC formed a work party to provide a response to the ICANN Board. On 16 April 2013, the SSAC submitted the requested clarifications to the ICANN Board. [ONGOING] SSAC Letter to the ICANN Board on the New Generic Top Level Domain (gTLD) Process (02 July 2012) Ongoing SSAC TBC TBC http://www.icann.org/en/news/correspondence/faltstrom-to-icann-board-02jul12-en.pdf
http://www.icann.org/en/groups/ssac/documents/sac-046-en.pdf
20120611 Domain Name Registration Data SSAC Report on the Domain Name Registration Data Model Recommendation (1): The SSAC invites all ICANN Supporting Organizations and Advisory Committees, and in particular Registry and Registrar Stakeholder groups to (a) consider this data model and comment on its completeness, and (b) comment on the utility of the model in furthering the definition of a directory service for domain name registration data as outlined in SAC033 and SAC051. It is anticipated that the community discussion and policy development work arising out of the EWG report will include a broad community conversation on the development of a new data model and the definitions applicable to that model.
In addition, the data model in SAC 054 has been presented and incorporated into the IETF WEIRDS group for consideration. ICANN staff and ICANN community participate in WEIRDS. The WEIRDS object directory was developed with consideration of SSAC data model.		 SAC054 Ongoing SSAC TBC TBC http://www.icann.org/en/groups/ssac/documents/sac-054-en.pdf
20120611 Domain Name Registration Data SSAC Report on the Domain Name Registration Data Model Recommendation (2): The SSAC encourages the community to adopt the labeling and terminology used in this data model in future work. The Board in its November 8 2012 resolution directed that work related to the development of new directory service policy begin and that it incorporate the language used by the SSAC. Both the new gTLD registry agreement and the 2013 RAA incorporate the SSAC's terminology. The terminology in SAC 054 has been presented and largely adopted by the IETF WEIRDS group. SAC054 Complete SSAC TBC TBC http://www.icann.org/en/groups/ssac/documents/sac-054-en.pdf
20120223 DNS SECURITY SSAC Report on Dotless Domains The SSAC concludes that the combined effect of these potential ambiguities makes it very difficult in practice to predict how a dotless domain name will be resolved in different situations. The result could be anything from fully expected behaviour to a security incident in which the user of a domain name (or URL with the domain name embedded) communicates unknowingly with a party other than intended; or, as in the email example in Section 3.4 above, a failure of the system to provide any service at all. Additionally, this ambiguous behavior could be used to develop methodologies to compromise the session and allow for malicious activities with, for example, DNS redirection. The SSAC is aware that there currently exist TLDs that attempt to resolve dotless domain names. Our initial examination reveals that resolution of these names is not consistent or universal, and in particular, applications behave differently when presented with "dotless" responses.
These behaviors occur for reasons illustrated in this paper. Recommendation: Dotless domains will not be universally reachable and the SSAC recommends strongly against their use. As a result, the SSAC also recommends that the use of DNS resource records such as A, AAAA, and MX in the apex of a Top-Level Domain (TLD) be contractually prohibited where appropriate and strongly discouraged in all cases.		 At its meeting on 13 August 2013, the ICANN Board New gTLD Program Committee (NGPC) adopted a resolution affirming that "dotless domain names" are prohibited. http://www.icann.org/en/news/announcements/announcement-30aug13-en.htm SAC053 Complete SSAC TBC TBC http://www.icann.org/en/groups/ssac/documents/sac-053-en.pdf
20120131 IDN SSAC Advisory on the Delegation of Single-Character Internationalized Domain Name Top-Level Domains Recommendation (1): Given the potential for user confusion and the currently unfinished work on string similarity and IDN variants, the SSAC recommends a very conservative approach to the delegation of single-character IDN top-level domains. In particular, until ICANN completes its work on user confusion/string similarity and IDN variants, the SSAC recommends:
  1. Delegation of all single-character IDN TLDs in all scripts should be disallowed by default.
  2. Exceptions may be made for some scripts, but only after careful consideration of potential confusability both within and across scripts. Such consideration should invite comments from the technical and linguistic community, and from ICANN’s advisory committees.
  3. Single-character TLD applications in an exceptionally allowed script should be accepted only when there is clear evidence that there is no risk of user confusion.
    Each applied-for single-character TLD label must be explicitly examined across scripts to ensure that there is absolutely no possibility of user confusion within or across scripts.
  4. ICANN should consult with the technical and linguistic community to determine which scripts, if any, should be restricted with respect to the delegation of single character TLDs, and how any such restrictions should be defined, and how such restrictions may be relaxed if appropriate.
  5. ICANN should take into consideration the outcome of the IETF work on the creation of a concise specification of the TLD label syntax based on existing syntax documentation, extended minimally to accommodate IDNs.11
  6. ICANN should consider adopting the following guidelines regarding its consideration of which scripts and code points could be accepted as exceptions:
    1. The code point must be PVALID according to IDNA2008.
    2. The code point is from one of the following Unicode categories: lower case letter (Ll), upper case letter (Lu), and other letter (Lo) as defined by the Unicode Standard.12
    3. Some single-character IDN TLDs are composed of multiple Unicode code points, which may include non Lx-class code points. These should be subjected to a more stringent technical and confusability analysis, whose criteria should be well defined and made public.
    4. The script in which an exception is made and a single character IDN is allowed should not have characters that are intrinsically confusable with characters of another script (for example, Latin/Greek/Cyrillic, Lao/Thai, etc.).
    5. The existing and extended rules of confusability must be met. Single-character code points must explicitly be examined across scripts. Denial of a single character TLD application does not imply blocking of the script. Similarly, acceptance of a single-character TLD application does not imply acceptance of the script.
    6. If a script is allowed, a distinct and explicit specification of which subset of the script is available for single-character TLDs should be required prior to the acceptance of a single-character TLD application. By default all characters are disallowed, even when a script is allowed, and an explicit single-character-TLD-allowed list must be generated for each case.
 The Board adopted this conservative approach and did not change the applicant guidebook to allow for the delegation of single character IDN TLDs SAC052 Complete SSAC TBC TBC http://www.icann.org/en/groups/ssac/documents/sac-052-en.pdf
20120131 IDN SSAC Advisory on the Delegation of Single-Character Internationalized Domain Name Top-Level Domains Recommendation (2): Because important relevant work on string similarity, IDN variant issues, and TLD label syntax is currently underway within ICANN, the IETF, and other bodies, ICANN should review the Findings of this report, and any policies that it adopts in response to Recommendation 1, no later than one year after the three work items mentioned above have been completed. ICANN plans to take this recommendation into account in the future. SAC052 Ongoing SSAC TBC TBC http://www.icann.org/en/groups/ssac/documents/sac-052-en.pdf
20110919 WHOIS SSAC Report on WHOIS Terminology and Structure Recommendation (1): The ICANN community should adopt the terminology outlined in this report in documents and discussions, in particular:
  • Domain Name Registration Data (DNRD). The data that domain name registrants provide when registering a domain name and that registrars or registries collects.
  • Domain Name Registration Data Access Protocol (DNRD-AP). The components of a (standard) communications exchange—queries and responses—that specify the access to DNRD.
  • Doman Name Registration Data Directory Service (DNRD-DS). The service(s) offered by domain name registries and registrars to implement the DNRD-AP and to provide access to DNRD-DSD.
Additional terminology includes “DNRDe,” “DNRD Policy,” “DNRD-DS Policy,” “Internationalized DNRD,” and “Localized DNRD.” The term “WHOIS” should only be used when referring to the protocol as currently specified in RFC 3912.		 The Board in its Nov 8 2012 resolution directed that work begin related to the development of new directory service policy and that it incorporate the language used by the SSAC.
Resolved (2011.10.28.26), the Board hereby acknowledges the receipt of SAC 051, and thanks SSAC and other contributors for their efforts in the creation of the report.
Resolved (2011.10.28.27), the Board directs staff to produce, in consultation with the community, a roadmap for the coordination of the technical and policy discussions necessary to implement the recommendations outlined in SAC 051.
Resolved (2011.10.28.28), the Board directs staff to forward SAC 051 to ICANN's Advisory Committees and Supporting Organizations for their advice, if any, with regards to implementing the SSAC recommendations, and to forward SAC 051 to the Whois Review Team.		 Both the new gTLD registry agreement and the 2013 RAA incorporate the SSAC's terminology.
ICANN staff published the Roadmap, and is currently in implementation of the roadmap. http://www.icann.org/en/news/announcements/announcement-6-04jun12-en.htm.
ICANN and RIR communities have evaluated proposals for an RDAP in the IETF WEIRDS working party, see http://tools.ietf.org/wg/weirds/. The relevant recommendations from SAC reports mentioned were considered during the development of the RDP and data model for domain registration data. Several registries and ICANN are evaluating (prototyping, experimentation) the RDAP. CNNIC is developing an open source implementation see http://www.internetnews.me/2012/10/27/cnnic-to-implement-alternative-whois/.		 SAC051 Complete SSAC TBC TBC http://www.icann.org/en/groups/ssac/documents/sac-051-en.pdf
20110919 WHOIS SSAC Report on WHOIS Terminology and Structure Recommendation (2): The ICANN community should evaluate and adopt a replacement domain name registration data access protocol that supports the query and display of Internationalized DNRD as well as addressing the relevant recommendations in SAC 003, SAC 027 and SAC 033. The action plan adopted by the Board in November 2012 included specific recommendations regarding IDNs data. SAC051 Ongoing SSAC TBC TBC http://www.icann.org/en/groups/ssac/documents/sac-051-en.pdf
20110919 WHOIS SSAC Report on WHOIS Terminology and Structure Recommendation (3): The ICANN community should develop a uniform and standard framework for accessing DNRD that would provide mechanisms to define and implement a range of verification methods, credential services, and access control capabilities. It is anticipated that the community discussion and policy development work arising out of the Expert Working Group (EWG) report will include a broad community conversation on the development of a new data model and the definitions applicable to that model. The work of the EWG to date has included a focus on ways to standardise and centralise both the verification of data as well as access to Domain Name Registration Data (DNRD). SAC051 Ongoing SSAC TBC TBC http://www.icann.org/en/groups/ssac/documents/sac-051-en.pdf
20110614 DNS SECURITY DNS Blocking: Benefits Versus Harms – An Advisory from the Security and Stability Advisory Committee on Blocking of Top Level Domains at the Domain Name System Blocking or altering responses to Domain Name System (DNS) queries is increasingly prominent. Domain name or Internet Protocol (IP) address filtering (or otherwise preventing access to web content as a matter of security policy) may be viewed by some organizations as a natural extension of historical telephony controls that aimed to block people within organizations from incurring toll charges.
Technical approaches to DNS blocking are intended to affect users within a given administrative domain, such as a privately or publicly operated network. Preventing resolution of the domain name into an IP address will prevent immediate connection to the named host, although circumvention techniques may enable connectivity to the intended system anyway (this includes simply accessing the site via IP address rather than via a Fully Qualified Domain Name (FQDN)). A DNS resolver or network operator could also rewrite a DNS response to contain an IP address mapping the operator chooses, whether rewriting a Non-Existent Domain (NXDOMAIN) response or rewriting the DNS response for an existing FQDN, with potentially harmful effects on DNS Security Extension (DNSSEC)-supporting name servers and their users. A particularly coarse-grained approach is for an operator to silently discard DNS responses, although this results in non-deterministic behavior and may itself be problematic. Regardless of the mechanism used, organizations that implement blocking should apply these principles:
  1. The organization imposes a policy on a network and its users over which it exercises administrative control (i.e., it is the administrator of a policy domain).
  2. The organization determines that the policy is beneficial to its objectives and/or the interests of its users.
  3. The organization implements the policy using a technique that is least disruptive to its network operations and users, unless laws or regulations specify certain techniques.
  4. The organization makes a concerted effort to do no harm to networks or users outside its policy domain as a consequence of implementing the policy.
 This is general advice to organisations implementing DNS blocking rather than advice directed to the ICANN Board. It is information to assist the Board, ICANN staff, and SSAC in deliberating with the GAC, governments, and others who sought to understand the benefits or harms resulting from blocking responses to DNS queries. SAC50 Closed SSAC TBC TBC http://www.icann.org/en/groups/ssac/documents/sac-050-en.pdf
20110603 Registration services SSAC Report on DNS Zone Risk Assessment and Management The SSAC recommends that registrants consider implementing [NINE] safeguards and proactive measures to manage the risk associated with loss, disruption, or inconsistent availability of name service: (1) Thoroughly document all aspects of your DNS architecture and operations; (2) Design for resiliency; (3) Actively manage DNS information; (4) Protect domain registration and hosting accounts against unauthorized access or misuse; (5) Monitor the health and well being of your name service; (6) Track operational statistics and trends; (7) Develop a continuity plan for recovering from DNS; (8) Before making changes in provisioning, plan carefully, and; (9): Make informed choices when selecting DNS providers. This is general best practice risk mitigation advice to registrants. SAC049 Closed SSAC TBC TBC http://www.icann.org/en/groups/ssac/documents/sac-049-en.pdf
20110512 DNS ABUSE SSAC Comment on the Orphan Glue Records in the Draft Applicant Guidebook The SSAC offers the following comments for consideration on the removal of orphan glue records:
  1. Orphaned glue is an ambiguous term for which no definitive definition exists. The SSAC has prepared a definition that we recommend be included for reference in the Applicant Guidebook (see below for the proposed definition).
 The Board approved the Applicant Guidebook containing this recommendation on 20 June 2011. http://www.icann.org/en/groups/board/documents/resolutions-20jun11-en.htm.
ICANN agrees with this advice and implemented it in the language of the Applicant Guidebook and the new gTLD registry agreement, specification 6, section 4.2, which references the SSAC Advisory directly:
"Malicious Use of Orphan Glue Records. Registry Operator shall take action to remove orphan glue records (as defined at http://www.icann.org/en/committees/security/sac048.pdf) when provided with evidence in written form that such records are present in connection with malicious conduct."		 SAC048 Complete SSAC TBC TBC http://www.icann.org/en/groups/ssac/documents/sac-048-en.pdf
20110512 DNS ABUSE SSAC Comment on the Orphan Glue Records in the Draft Applicant Guidebook
  1. Orphaned glue can be used for abusive purposes; however, the dominant use of orphaned glue supports the correct and ordinary operation of the DNS. Thus it is inappropriate to include the management of orphaned glue under the rubric of "abuse prevention and mitigation" and we suggest that it be removed.
 ICANN did not agree with this recommendation and has thus not implemented it. SAC048 Closed SSAC TBC TBC http://www.icann.org/en/groups/ssac/documents/sac-048-en.pdf
20110512 DNS ABUSE SSAC Comment on the Orphan Glue Records in the Draft Applicant Guidebook
  1. Finally, to mitigate the actual abuse of orphaned glue, registry operators should take action to remove these records when provided with evidence that the glue is indeed present to abet malicious conduct.
 The Board approved the Applicant Guidebook containing this recommendation on 20 June 2011. ICANN fully agrees with this recommendation and implemented it in the Applicant Guidebook and new gTLD registry agreement. http://www.icann.org/en/groups/board/documents/resolutions-20jun11-en.htm SAC048 Complete SSAC TBC TBC http://www.icann.org/en/groups/ssac/documents/sac-048-en.pdf
20110415 REGISTRATION SERVICES SSAC Comment on the ICANN gTLD Registry Transition Processes Model The SSAC recommends that ICANN define a testing process that emulates a full failover scenario and that successor and emergency registry operators demonstrate their ability to satisfy the testing criteria. SAC047 was considered by ICANN and relevant recommendations were implement into the transition process, including the requirement for EBERO to conduct failover testing periodically. SAC047 Complete SSAC TBC TBC http://www.icann.org/en/groups/ssac/documents/sac-047-en.pdf
20110415 REGISTRATION SERVICES SSAC Comment on the ICANN gTLD Registry Transition Processes Model The SSAC recommends that ICANN preserve operational data about ex-registries. ICANN should define a framework to share such data with the community. Availability of such data will ensure that the registration transition process can be studied and if needed, improved. SLA monitoring log data is being retained and can be studied and used to improve the transition process. SAC047 Ongoing SSAC TBC TBC http://www.icann.org/en/groups/ssac/documents/sac-047-en.pdf
20110415 REGISTRATION SERVICES SSAC Comment on the ICANN gTLD Registry Transition Processes Model The SSAC emphasizes that in many if not most circumstances, restoring domain name system (DNS) resolution services will be the number one priority for registrants and gTLD users. This requires DNS zone files for gTLDs to be escrowed separately. The transition process requires The DNS zone files for gTLDs to be escrowed separately. SAC047 Complete SSAC TBC TBC http://www.icann.org/en/groups/ssac/documents/sac-047-en.pdf
20110415 REGISTRATION SERVICES SSAC Comment on the ICANN gTLD Registry Transition Processes Model The SSAC notes that the Explanatory Memorandum makes no provision to ensure that a registrant retains the registration of a domain name during transition. The process must have a provision to lock domain ownership during a transition. ICANN agrees with this recommendation and notes that the transition processes were designed at the outset to protect registrants. SAC047 Ongoing SSAC TBC TBC http://www.icann.org/en/groups/ssac/documents/sac-047-en.pdf
20110415 REGISTRATION SERVICES SSAC Comment on the ICANN gTLD Registry Transition Processes Model The SSAC notes that in certain operating circumstances, registry functions, especially critical services such as DNS resolution and DNS security (DNSSEC), may be separable from other functions (registry database maintenance). The SSAC asks whether in such circumstances critical functions can be transitioned separately. ICANN disagrees with this recommendation and believes that the various required functions should be operated by a unique registry. SAC047 Closed SSAC TBC TBC http://www.icann.org/en/groups/ssac/documents/sac-047-en.pdf
20110415 REGISTRATION SERVICES SSAC Comment on the ICANN gTLD Registry Transition Processes Model With respect to registration fees, the SSAC also notes that certain registrant information is not associated with or collected for the purpose of the public directory service, but is instead part of the administrative data that might be split between the registry and the registrar. If the registry is replaced, one of two conditions might exist:
  1. The current registry operator has information on the payment cycle. In this case, the current registry operator must provide the billing and payment cycle to the successor registry along with each registrant’s registration information.
  2. The registrar has payment information. In this case, the current registry operator must provide the sponsoring registrar information for each domain that is registered to the successor registry.
 ICANN agrees with these recommendations. The payment cycle information is reflected by the expiration date of the domain name, which is included as part of the data escrow that the successor registry receives. SAC047 Complete SSAC TBC TBC http://www.icann.org/en/groups/ssac/documents/sac-047-en.pdf
20110415 REGISTRATION SERVICES SSAC Comment on the ICANN gTLD Registry Transition Processes Model Lastly, the SSAC makes the following recommendations regarding the construction of the Explanatory Memorandum:
  1. It should be footnoted with references to the AG.
  2. It should reference and use defined terms from the Applicant Guidebook rather than crafting its own definitions.
  3. It imposes requirements on various parties, but it is unclear if these have the stature of requirements stated in the Applicant Guidebook. Since its function is to be explanatory, the text should truly be explanatory as opposed to normative.
 ICANN adopted these recommendations and clarified in the registry transition process that the explanatory memorandum is part of the applicant guidebook and therefore it was adopted when the applicant guidebook was adopted. SAC047 Complete SSAC TBC TBC http://www.icann.org/en/groups/ssac/documents/sac-047-en.pdf
20101206 ROOT SYSTEM Report of the Security and Stability Advisory Committee on Root Scaling The SSAC believes that RSSAC is in a better position to respond to the first question, and defers to its judgment. Regarding the second question, the SSAC recommends the following steps be taken before launching additional gTLDs, in parallel with continued deployment of IDNs and IPv6. Recommendation (1): Formalize and publicly document the interactions between ICANN and the root server operators with respect to root zone scaling. ICANN and the root server operators may choose to utilize RSSAC to facilitate this interaction. Board Action: The Board requested the CEO direct staff to work with the root server operators via RSSAC to complete the documentation of the interactions between ICANN and the root server operators with respect to root zone scaling. Implementation Status: ICANN as L‐Root operator participates in regular discussions with other Root Server Operators regarding instrumentation of the Root Server system. With respect to measurements directly motivated by concerns over root zone scaling, these discussions have been ongoing since May 2011. While a record of discussions on the RSSAC list exists in the form of its archive, no specific documentation on the interactions between ICANN and other root server operators on this topic has been drafted. [This task is not complete] SAC046 Ongoing SSAC TBC TBC http://www.icann.org/en/groups/ssac/documents/sac-046-en.pdf
20101206 ROOT SYSTEM Report of the Security and Stability Advisory Committee on Root Scaling Recommendation (2): ICANN, National Telecommunications and Information Administration (NTIA), and VeriSign should publish statements, or a joint statement, that they are materially prepared for the proposed changes. The Board recommended the CEO to direct staff to work with NTIA and Verisign to explore publication of one or more statements regarding preparation for the proposed changes. Implementation Status: ICANN staff worked with NTIA and Verisign and the parties released a joint statement on 5 November 2012. A copy of the joint statement was sent to the SSAC (via Patrik Fältström) on 8 November 2012. SAC046 Complete SSAC TBC TBC http://www.icann.org/en/groups/ssac/documents/sac-046-en.pdf
20101206 ROOT SYSTEM Report of the Security and Stability Advisory Committee on Root Scaling Recommendation (3): ICANN should publish estimates of expected and maximum growth rates of TLDs, including IDNs and their variants, and solicit public feedback on these estimates, with the end goal of being as transparent as possible about the justification for these estimates. The Board recommended the CEO to direct staff to publish current estimates of the expected growth rates of TLDs. The Board suggested the publication of the expected growth rates of TLDs be coordinated with the re‐examination of the process for evaluating gTLD applications. Implementation Status: ICANN has been regularly publishing the expected and maximum growth rates of TLDs. For example, see page 2 of http://newgtlds.icann.org/en/applicants/batching/drawingprioritization‐10oct12‐en.pdf as well as in other regular new gTLD updates.
  1. Batching / Metering: After careful analysis of public comment and possible solutions for processing new gTLD applications, ICANN proposed a drawing for prioritizing applications through the steps leading to delegation. ICANN held a Prioritization Draw (Draw) on 17 December 2012 in Los Angeles to assign priority numbers to all new gTLD applications. Each application was assigned a randomly‐drawn priority number.
 SAC046 Complete SSAC TBC TBC http://www.icann.org/en/groups/ssac/documents/sac-046-en.pdf
20101206 ROOT SYSTEM Report of the Security and Stability Advisory Committee on Root Scaling Recommendation (4): ICANN should update its "Plan for Enhancing Internet Security, Stability, and Resiliency," to include actual measurement, monitoring, and data sharing capability of root zone performance, in cooperation with RSSAC and other root zone management participants to define the specific measurements, monitoring, and data sharing framework. The Board formally asked RSSAC for its advice on this topic and an update on plans to satisfy this recommendation. The Board also asked the CEO whether there are other parties who should be consulted, and to ask such parties to participate. RSSAC is developing measurement plans. The L Root is also conducting measurements. NOT COMPLETE. In response to a letter to the SSAC from the ICANN Chairman dated 25 September 2012 (http://www.icann.org/en/news/correspondence/crockerto‐murai‐larson‐25sep12‐en), on 18 October 2012, Matt Larson, SSAC Vice Chairman acknowledged the receipt of the Board request, and requested RSSAC form a work party to collect the existing measurements used by the root server operators and determine, along with ICANN staff, the appropriate parties to participate on the task. As a result, the RSSAC work party prepared a document entitled “Recommendation on Measurement of Root Server System” dated 16 April 2013. Currently, it is in last call for comments by the RSSAC. [ONGOING]
  1. In addition to the RSSAC effort, on 7 December 2012 ICANN published Root Zone Scaling Measurements at L‐root" that describes the planned measurements, and includes a timeline for implementation for L‐root.
Trending data is published for L‐root at: http://dns.icann.org/services/root-zone-scaling-report-zone-contents/
The announcements of the reports and the reports can be found: http://www.icann.org/en/news/announcements/announcement‐3‐07dec12‐en.htm [ONGOING]		 SAC046 Ongoing SSAC TBC TBC http://www.icann.org/en/groups/ssac/documents/sac-046-en.pdf
20101206 ROOT SYSTEM Report of the Security and Stability Advisory Committee on Root Scaling Recommendation (5): ICANN should commission and incent interdisciplinary studies of security and stability implications from expanding the root zone more than an order of magnitude, particularly for enterprises and other user communities who may implement strong assumptions about the number of TLDs or use local TLDs that may conflict with future allocations. See row 46. Resolution on name collision was adopted 10/07/2013. SAC046 Complete SSAC TBC 10/7/13 http://www.icann.org/en/groups/ssac/documents/sac-046-en.pdf
20101115 ROOT SYSTEM Invalid Top Level Domain Queries at the Root Level of the Domain Name System The SSAC recommends that ICANN promote a general awareness of the potential problems that may occur when a query for a TLD string that has historically resulted in a negative response begins to resolve to a new TLD. Specifically, ICANN should:
  • ICANN should Study invalid TLD query data at the root level of the DNS and contact hardware and software vendors to fix any programming errors that might have resulted in those invalid TLD queries. The SSAC is currently exploring one such problem as a case study, and the vendor is reviewing its software. Future efforts to contact hardware or software vendors, however, are outside SSAC’s remit. ICANN should consider what if any organization is better suited to continue this activity.
 The NGPC resolution on name collision adopted on 10/07/2013 addresses some of the issues related to invalid Top Level Domain queries at the root level of the DNS. http://www.icann.org/en/groups/board/documents/resolutions-new-gtld-07oct13-en.htm ICANN has been studying the data. Once the study has been finalised, ICANN will be in a better position to contact hardware and software vendors in relation to this issue.
The name collision mitigation framework includes (i) studies of invalid TLD query data, (ii) a process that delays or block delegation of known-to-be-conflicting second level domain labels so that mitigations can be implemented, (iii) notifications to all mentioned communities in the form of published reports and announcements, and (iv) technical advice regarding collision mitigation: specifically, the framework considers an alternative course (fix the cause not the symptom), which is to identify corrective action that users and network operators can take (e.g., use FQDNs) so that all queries that are submitted to the public DNS are resolvable or correctly return NXDOMAIN. The recommendation to contact hardware vendors and software vendors "to fix" is not a universally feasible solution. In certain cases, e.g., browsers and CAs, notification did yield cooperation, however, in other cases, such cooperation did not occur; for example, ICANN staff initially pursued this course with outside engineers, who showed initial interest but eventually became unresponsive to progress report queries from staff. In the general case, the installed base may not be upgradeable, vendors are not obliged to fix the problems, or users will not remediate unless they are affected by the change in behavior. The framework is a reasonable way forward.		 SAC045 Ongoing SSAC TBC TBC http://www.icann.org/en/groups/ssac/documents/sac-045-en.pdf
20101115 ROOT SYSTEM Invalid Top Level Domain Queries at the Root Level of the Domain Name System ICANN should contact organizations that are associated with strings that are frequently queried at the root. Forewarn organizations who send many invalid queries for TLDs that are about to become valid, so they may mitigate or eliminate such queries before they induce referrals rather than NXDOMAIN responses from root servers. ICANN has been studying the data. Once the study has been finalised, ICANN will be in a better position to forewarn organizations who send many invalid queries for TLDs. SAC046 Ongoing SSAC TBC TBC http://www.icann.org/en/groups/ssac/documents/sac-046-en.pdf
20101115 ROOT SYSTEM Invalid Top Level Domain Queries at the Root Level of the Domain Name System ICANN should educate users so that, eventually, private networks and individual hosts do not attempt to resolve local names via the root system of the public DNS. ICANN is working on developing a guide for IT departments to identify and manage the name colision risks in their networks. SAC047 Ongoing SSAC TBC TBC http://www.icann.org/en/groups/ssac/documents/sac-047-en.pdf
20101115 ROOT SYSTEM Invalid Top Level Domain Queries at the Root Level of the Domain Name System Recommendation (2): The SSAC recommends that ICANN consider the following in the context of the new gTLD program.
  • Prohibit the delegation of certain TLD strings. RFC 2606, “Reserved Top Level Domain Names,” currently prohibits a list of strings, including test, example, invalid, and localhost.4 ICANN should coordinate with the community to identify a more complete set of principles than the amount of traffic observed at the root as invalid queries as the basis for prohibiting the delegation of additional strings to those already identified in RFC 2606.
 ICANN agrees with this recommendation and prohibited the delegation of TLDs listed in RFC2606.
ICANN has been studying the data. Once the study has been finalised, ICANN will be in a better position to identify a more complete set of principles as the basis for prohibiting the delegation of additional strings to those already identified in RFC 2606.		 SAC047 Ongoing SSAC TBC TBC http://www.icann.org/en/groups/ssac/documents/sac-047-en.pdf
20101115 ROOT SYSTEM Invalid Top Level Domain Queries at the Root Level of the Domain Name System The SSAC recommends that ICANN alert the applicant during the string evaluation process about the pre-existence of invalid TLD queries to the applicant’s string. ICANN should coordinate with the community to identify a threshold of traffic observed at the root as the basis for such notification. ICANN agrees with this recommendation and has implemented it through a warning on this issue included in the applicant guidebook. SAC047 Complete SSAC TBC TBC http://www.icann.org/en/groups/ssac/documents/sac-047-en.pdf
20101115 ROOT SYSTEM Invalid Top Level Domain Queries at the Root Level of the Domain Name System The SSAC recommends that ICANN define circumstances where a previously delegated string may be re-used, or prohibit the practice. ICANN had not to date addressed this recommendation. The IAB, not ICANN determines whether a TLD string should be reserved. The chronology of IAB's deliberations on this issue could be requested by the ICANN chair. ICANN will block delegation of high-risk TLDs, ICANN has notified nTLD applicants of invalid TLD queries, and the name collision mitigation framework requires that delegated new TLDs must not delegate SLDs that are identified as collision labels until mitigations are implemented. SAC047 Open SSAC TBC TBC http://www.icann.org/en/groups/ssac/documents/sac-045-en.pdf