Skip to main content
Resources

Draft Terms of Reference for the Review of the Security and Stability Advisory Committee

ICANN's Bylaws require that Supporting Organizations, Councils and Advisory Committees be independently reviewed. These Terms of Reference will form the basis for a review of the Security and Stability Advisory Committee (SSAC).

The results of the Review shall be posted for public review and comment, and shall be considered by the Board not later than its second scheduled meeting after being posted for 30 days. As provided in the Bylaws, consideration by the Board includes the ability to revise the structure or operation of the SSAC by a two thirds vote of all Board Members.

  1. Purpose of Review

    The purpose of the Review is to help determine the best way forward, but such analysis depends in the first instance upon a solid assessment of how the SSAC has performed to date.

    In accordance with Article IV, Section 4, Paragraph 1 of the ICANN Bylaws, the review of the SSAC is designed to determine:

    1. Whether the organization has a continuing purpose in the ICANN structure; and
    2. If so, whether any change in structure or operations is desirable to improve its effectiveness.

    Both of these questions should be answered as comprehensively as possible, taking into account the rationale for the SSAC and its functioning so far.

  2. Rationale for the SSAC

    In accordance of Article XI, Section 2 of the Bylaws, the role of the Security and Stability Advisory Committee ("SSAC") is to advise the ICANN community and Board on matters relating to the security and integrity of the Internet's naming and address allocation systems. The SSAC has the following responsibilities:

    1. To develop a security framework for Internet naming and address allocation services that defines the key focus areas, and identifies where the responsibilities for each area lie. The committee shall focus on the operational considerations of critical naming infrastructure.
    2. To communicate on security matters with the Internet technical community and the operators and managers of critical DNS infrastructure services, to include the root name server operator community, the top-level domain registries and registrars, the operators of the reverse delegation trees such as in-addr.arpa and ip6.arpa, and others as events and developments dictate. The Committee shall gather and articulate requirements to offer to those engaged in technical revision of the protocols related to DNS and address allocation and those engaged in operations planning.
    3. To engage in ongoing threat assessment and risk analysis of the Internet naming and address allocation services to assess where the principal threats to stability and security lie, and to advise the ICANN community accordingly. The Committee shall recommend any necessary audit activity to assess the current status of DNS and address allocation security in relation to identified risks and threats.
    4. To communicate with those who have direct responsibility for Internet naming and address allocation security matters (IETF, RSSAC, RIRs, name registries, etc.), to ensure that its advice on security risks, issues, and priorities is properly synchronized with existing standardization, deployment, operational, and coordination activities. The Committee shall monitor these activities and inform the ICANN community and Board on their progress, as appropriate.
    5. To report periodically to the Board on its activities.
    6. To make policy recommendations to the ICANN community and Board

    The Chair and the members of the SSAC are appointed by the ICANN Board. The SSAC appoints one non-voting liaison to the ICANN Board of Directors.

  3. Questions to Address

    Key questions that the Review should consider are indicated below. This list is intended to be illustrative, rather than definitive or exhaustive, particularly as the initial results of the Review may suggest related questions that should also be answered. It will be important to consider the questions from different perspectives, including past and current members of the SSAC, the ICANN Board, other Supporting Organizations (SOs) and Advisory Committees (ACs) and perhaps others within (and outside of) the ICANN community.

      PART I. Does the SSAC have a continuing purpose in the ICANN structure?

      Overall purpose

    1. What security and stability issues has SSAC been dealing with and what issues should SSAC be dealing with or expecting to deal with in the future ICANN environment?
    2. What purpose has the SSAC served? What should be the purpose of the SSAC in the future? Does the rationale for the SSAC in the Bylaws need to be revised?
    3. Has SSAC activity accurately reflected the tasking and accountability set out in the Bylaws? Given the growth of ICANN since the original drafting of the Bylaws, what changes are needed to the SSAC component of the Bylaws to reflect the community’s current needs?
    4. Effectiveness

    5. Has the SSAC been effective in delivering a security framework for Internet naming and address allocation services, as outlined in the Bylaws (see above)? What changes, if any, are required to make SSAC more effective?
    6. Has the SSAC communicated effectively on security matters with the Internet technical community, as outlined in the Bylaws? What changes, if any, are required to make SSAC communicate more effectively?
    7. Has the SSAC gathered and articulated requirements for security and stability to offer to those engaged in technical revision of the protocols and in operations planning? What changes, if any, are required?
    8. How effective has the SSAC been in engaging in ongoing threat assessment and risk analysis, and advising the ICANN community accordingly? What changes, if any, are required?
    9. How effective has the SSAC been in communicating with those with direct responsibility for Internet naming and address allocation security matters, and in synchronizing its advice with existing activities of those organizations? How effectively has SSAC communicated with the ICANN technical community and operators and managers of critical DNS infrastructure? What changes, if any, are required?
    10. How effective has the SSAC been in its reporting to the Board on its activities and making policy recommendations to the Board? Has the SSAC been effective in providing advice to the ICANN Board on matters as outlined in the Bylaws? How effectively have SSAC recommendations been implemented? Does SSAC need to place greater effort on following through on recommendations that it makes? What changes, if any, are required?
    11. How effective has the SSAC been in making policy recommendations to the ICANN community?
    12. How does SSAC interact with other ICANN SOs and ACs? Are there regular communications between the SSAC and other SOs and ACs? How effective has the SSAC been in providing input and advice to other SOs and ACs? How effective has SSAC been in educating the ICANN community on security and stability issues? What changes, If any, are required?
    13. Has SSAC played an appropriate role in ICANN policy development processes?
    14. What authority, if any, should SSAC have to review and comment on ICANN’s corporate systems and plans?
    15. How effectively have SSAC recommendations been implemented? Does SSAC need to place greater effort on following through on recommendations that it makes?
    16. Overall, how effectively has SSAC performed its role?
    17. PART II. Is there any change in structure or operations that could improve the SSAC's effectiveness?

      Structure and composition

    18. What organizational structure, if any, is appropriate?
    19. There are now several security and stability structures within ICANN. Is a structure like SSAC still needed?
    20. What is the optimal size of SSAC to maximize its effectiveness?
    21. What should be the role of the Chair of the SSAC, and how should that person be selected?
    22. Is the composition of SSAC appropriate for its mission? Does the current process for recruiting SSAC members meet SSAC’s current and future needs?
    23. Have members of SSAC had the skills needed to conduct their work effectively?
    24. Does a non-voting liaison seat on the Board provide sufficient input and representation for SSAC? Is there any change needed?
    25. Internal Operations and Procedures

    26. How does the SSAC determine what advice to provide with respect to particular ICANN issues? What procedures govern how decisions regarding SSAC input for the Board and other ICANN entities are made? What are the benefits and costs of SSAC setting its own independent agenda as opposed to responding only to specific Board requests for advice? Are any changes needed to these procedures to improve the timeliness and quality of advice that is provided?
    27. Do SSAC procedures allow it to maximize the expertise of committee members?
    28. Given the volunteer nature of the committee, are the expectations placed on SSAC members appropriate? Should SSAC members be paid for their work?
    29. Are sufficient safeguards in place to identify and address potential or actual conflicts of interest?
    30. Does the SSAC operate in an accountable and transparent manner? Are any changes to SSAC procedures necessary to enhance accountability and transparency?
    31. Are the SSAC's procedures sufficient to guide all aspects of its work?
    32. Resources and support

    33. Has the SSAC had the resources necessary to accomplish its tasks?
    34. What kind of support has ICANN provided to the SSAC? What is the appropriate level of financial, institutional and staff support that should be provided to SSAC?
    35. Overall

    36. What other general or specific measures could enhance the effectiveness of SSAC?
Domain Name System
Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as""icann.org"" is not an IDN."