You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »


  • Adopted: 4 May 2017

  • Shared with the ICANN Board: 11 May 2017

  • ICANN Board comments on the Terms of Reference of the Second Security, Stability, and Resiliency of the DNS Review Team (SSR2): 23 June 2017 (view PDF)

Terms of Reference for the Second Security, Stability and Resiliency Review Team - v4.0 | Doc 

Background on SSR Reviews

Security, Stability and Resiliency (SSR) Reviews were established in ICANN's Bylaws, which provides for accountability and transparency mechanisms through the empowered community. The reviews that were formally known as "Affirmation of Commitments Reviews" and included the "Security, Stability and Resiliency of the DNS Review (SSR1),” are now referred to as "Specific Reviews" under these Bylaws. 

Under the Bylaws, the Board is responsible for causing an SSR review every five years. In Resolution 2017.02.03.11 the Board convened the SSR2 Review Team and requested that this team develop and deliver to the Board their approved Terms of Reference and Work Plan, to ensure that the team's scope and timeline is consistent with the requirements of the ICANN Bylaws. 

ICANN Mission and Bylaws Requirements of the SSR2 Review

ICANN’s mission relative to the unique identifiers is the first article of its Bylaws:

“Section 1.1. MISSION

(a) The mission of the Internet Corporation for Assigned Names and Numbers ("ICANN") is to ensure the stable and secure operation of the Internet's unique identifier systems as described in this Section 1.1(a) (the "Mission"). Specifically, ICANN:

(i) Coordinates the allocation and assignment of names in the root zone of the Domain Name System ("DNS") and coordinates the development and implementation of policies concerning the registration of second-level domain names in generic top-level domains ("gTLDs"). In this role, ICANN's scope is to coordinate the development and implementation of policies:

  • For which uniform or coordinated resolution is reasonably necessary to facilitate the openness, interoperability, resilience, security and/or stability of the DNS including, with respect to gTLD registrars and registries, policies in the areas described in Annex G-1 and Annex G-2; and
  • That are developed through a bottom-up consensus-based multistakeholder process and designed to ensure the stable and secure operation of the Internet's unique names systems.

The issues, policies, procedures, and principles addressed in Annex G-1 and Annex G-2 with respect to gTLD registrars and registries shall be deemed to be within ICANN's Mission.

(ii) Facilitates the coordination of the operation and evolution of the DNS root name server system.

(iii) Coordinates the allocation and assignment at the top-most level of Internet Protocol numbers and Autonomous System numbers. In service of its Mission, ICANN (A) provides registration services and open access for global number registries as requested by the Internet Engineering Task Force ("IETF") and the Regional Internet Registries ("RIRs") and (B) facilitates the development of global number registry policies by the affected community and other related tasks as agreed with the RIRs.

(iv) Collaborates with other bodies as appropriate to provide registries needed for the functioning of the Internet as specified by Internet protocol standards development organizations. In service of its Mission, ICANN's scope is to provide registration services and open access for registries in the public domain requested by Internet protocol development organizations.

(b) ICANN shall not act outside its Mission.

(c) ICANN shall not regulate (i.e., impose rules and restrictions on) services that use the Internet's unique identifiers or the content that such services carry or provide, outside the express scope of Section 1.1(a). For the avoidance of doubt, ICANN does not hold any governmentally authorized regulatory authority.”

Under the Bylaws, Section 4.6(c),

“(i) The Board shall cause a periodic review of ICANN’s execution of its commitment to enhance the operational stability, reliability, resiliency, security, and global interoperability of the systems and processes, both internal and external, that directly affect and/or are affected by the Internet’s system of unique identifiers that ICANN coordinates (“SSR Review”).

“(ii) The issues that the review team for the SSR Review (“SSR Review Team”) may assess are the following:

A)    security, operational stability and resiliency matters, both physical and network, relating to the coordination of the Internet’s system of unique identifiers;

B)    conformance with appropriate security contingency planning framework for the Internet’s system of unique identifiers;

C)    maintaining clear and globally interoperable security processes for those portions of the Internet’s system of unique identifiers that ICANN coordinates.

“(iii) The SSR Review Team shall also assess the extent to which ICANN has successfully implemented its security efforts, the effectiveness of the security efforts to deal with actual and potential challenges and threats to the security and stability of the DNS, and the extent to which the security efforts are sufficiently robust to meet future challenges and threats to the security, stability and resiliency of the DNS, consistent with ICANN’s Mission.

“(iv) The SSR Review Team shall also assess the extent to which prior SSR Review recommendations have been implemented and the extent to which implementation of such recommendations has resulted in the intended effect.

“(v) The SSR Review shall be conducted no less frequently than every five years, measured from the date the previous SSR Review Team was convened.” (see Bylaws, Section 4.6(c)).

 

Definitions

 An assessment of this type requires a common understanding of the key terms associated with the review. Initially, the SSR2-RT is operating under the following definitions:

  • Security – The capacity to protect and prevent misuse of Internet unique identifiers;
  • Stability – The capacity to ensure that the Identifier System operates as expected and that users of unique identifiers have confidence that the system operates as expected;
  • Resiliency – The capacity of the Identifier System to effectively withstand, tolerate and survive malicious attacks and other disruptive events without disruption or cessation of service.
  • Unique Identifiers - ICANN’s technical mission includes helping to coordinate, at the overall level, the allocation of the Internet’s system of unique identifiers: specifically, top-level domain names, blocks of Internet Protocol (IP) addresses and autonomous system (AS) numbers allocated to the Regional Internet Registries, and protocol parameters as directed by the IETF

 

Focus of the SSR2 – Scope of Work

 From the requirement in the Bylaws:

 “(iv): The SSR Review Team shall also assess the extent to which prior SSR Review recommendations have been implemented and the extent to which implementation of such recommendations has resulted in the intended effect.”

 The SSR2 Review Team will undertake a conscientious review of the SSR1 Review Team’s recommendations.  Specifically, the team will review the status of their implementation, the impacts and results from those that have been implemented, and which of them are still critical, post-transition.

 “(iii): The SSR Review Team shall also assess the extent to which ICANN has successfully implemented its security efforts, the effectiveness of the security efforts to deal with actual and potential challenges and threats to the security and stability of the DNS, and the extent to which the security efforts are sufficiently robust to meet future challenges and threats to the security, stability and resiliency of the DNS, consistent with ICANN’s Mission.”

The Internet unique identifier systems that are within ICANN’s purview affect many dependent systems, which may not themselves be under ICANN’s authority.  In order to understand the security, stability, and resiliency importance of the ICANN identifierspace (the elements that are within ICANN’s authoritative scope), the SSR2 Review Team will consider the issues in its entirety including inter-connected functions.  The SSR2 Review Team may, therefore, review, discuss and seek advice from varying stakeholders in the community including those entities providing specific functions on behalf of ICANN to ensure that any recommendations provided takes into account the most complete reflection of the operational reality of ICANN.  However, the SSR2 Review Team will then focus its recommendations on those efforts, issues, policies, systems, and identifiers that are clearly within ICANN’s scope and remit. The list of investigation topics and concerns may be informed by groups, committees, or any other organizations identified in the SSR2 Review Team’s outreach plan. 

(ii)(A): May assess the “security, operational stability and resiliency matters, both physical and network, relating to the coordination of the Internet’s system of unique identifiers.”

As per Bylaws Section (ii)(A); these topics will include ICANN’s interoperable security processes, its business continuity planning and disaster and operational recovery plans, its risk management and mitigation process, and (though not required) to include other nascent and upcoming concerns.

(ii)(B): May assess “conformance with appropriate security contingency planning framework for the Internet’s system of unique identifiers.”

 (ii)(C): May assess “maintaining clear and globally interoperable security processes for those portions of the Internet’s system of unique identifiers that ICANN coordinates.”

Further, based on Bylaws Sections (ii)(B-C), consideration of whether there exists an appropriate and effective security planning framework for SSR issues, whether there was an operational SSR impact from moving the IANA services to PTI, how effective ICANN’s coordination is with other organizations that are involved in ICANN’s indentifier space, and what necessary changes are needed to address current and foreseeable SSR issues will be addressed.

All considerations will be investigated and analyzed with a clear intent to produce actionable recommendations that fall within ICANN’s purview. 

Timeline

 

  • February-May 2017: agree terms of reference and workplan
  • May-September 2017: fact finding and assembling materials
  • October 2017: Assemble findings and consult with ICANN community
  • November 2017-January 2018: Socialize draft recommendations with community
  • February 2018: Publish draft report for public comment
  • March-April 2018: Review input received and incorporate as appropriate
  • June 2018: Send final report to ICANN Board
  • June 2018: Socialize final recommendations with community

 

Operation of the Review Team

Decision Making

 Section 4.6. of ICANN’s Bylaws states:

SPECIFIC REVIEWS (iii) – “Review team decision-making practices shall be specified in the Operating Standards, with the expectation that review teams shall try to operate on a consensus basis. In the event a consensus cannot be found among the members of a review team, a majority vote of the members may be taken.”

In accordance with this article of the Bylaws the SSR2-RT has agreed, by consensus, that it will strive to make its decisions on a consensus basis. This means that all Team members agree on a position, or only a small minority of Team members disagree, but most agree. To the extent that the SSR2-RT is unable to achieve consensus with respect to any recommendations, its reports and recommendations will include minority views.[1] 

Decisions of the SSR2-RT will be made at meetings, either face-to- face or via teleconference (teleconference or Adobe), and via the SSR2-RT’s email list, as requested by the Co-Chairs.

Leadership

At its meeting on March 22 2017 the SSR2-RT selected by consensus Denise Michel, Emily Taylor and Eric Osterweil as Co-Chairs.

Responsibilities of the Co-Chairs include:

 

  • Remain neutral when serving as Co-Chair
  • Identify when speaking as an advocate
  • Maintain standards and focus on the aims of the Review Team as established in its Terms of Reference
  • Drive toward delivery of key milestones according to the Work Plan
  • Ensure effective communication between members and with broader community, board and staff
  • Set the agenda and run the meetings
  • Ensure that all meeting attendees get accurate, timely and clear information
  • Determine and identify the level of consensus within the team
  • Provide clarity on team decisions
  • Ensure decisions are acted upon
  • Build and develop teamwork
  • Facilitate RT reporting to the community to maintain accountability and transparency

 

Responsibilities of SSR2-RT members include:

  • Attend all calls and face to face meetings where feasible
  • Actively engage on email list, including providing feedback when requested to do so through that medium
  • Actively engage with relevant stakeholder groups within the ICANN community, and within each team member’s local constituencies
  • Provide input and comments based on core expertise and experience
  • Undertake desk research as required and in accordance with scope of work
  • Be prepared to listen to others and make compromises in order to achieve consensus recommendations
  • Participate in drafting and sub-groups as required.

Electronic Tools

The SSR2-RT has an email list (ssr2-review@icann.org) for review team members and support staff to use. All emails exchanged on this list are publicly archived. Email communication between the review team members regarding SSR2 work should be exchanged on this list. 

In exceptional circumstances, such as when required due to Non-Disclosure Agreement or Confidential Disclosure Agreement provisions, non-public email exchanges may take place between SSR2-RT members and ICANN staff. When possible a non-confidential summary of such disussions will be posted to the public SSR2-RT mailing list.

There will be an SSR2-RT wiki where all relevant information about the review team and its work will be publicly archived.

Outreach

The SSR2-RT will conduct outreach to the ICANN community and beyond to support its mandate and in keeping with the global reach of ICANN’s mission.

 As such the SSR2-RT will ensure the public has access to, and can provide input on, the Team’s work. Interested community members will have an opportunity to interact with the SSR2-RT, and the Team will present its work and hear input from communities (subject to SSR2 budget requirements). 

Meetings of the SSR2-RT

The SSR2-RT will hold regular (usually weekly) Adobe Connect or telephone teleconferences, and periodic face-to-face meetings. Remote participation will be available where possible. Details will be available on the Team’s wiki.

Meetings Rules and Transparency

  • Co-Chairs will publish a meeting agenda at least 24 hours in advance of each meeting.
  • It is expected that review team members who are unable to attend meetings (face to face or online) will listen to the recordings of any meetings missed prior to attending the next meeting.
  • Decisions and action items from a meeting shall be published to the SSR2-RT wiki and email distribution list by staff within 24 hours of the meeting.
  • Team meetings will be announced on the SSR2 wiki at least 24 hours in advance of the meeting.
  • SSR2-RT meetings will be recorded and made publicly available on the SSR2 Wiki page at https://community.icann.org/pages/viewpage.action?pageId=64070219
  • SSR2-RT meetings will be open to observers via Adobe Connect or a teleconference bridge.
    • For electronic meetings such as an Adobe Connect room meeting, a separate Adobe Connect room will be made available to observers which will carry the same feed as the RT Adobe Connect room but will not allow observers to interact with the RT.
    • Face-to-face meetings of the RT at an ICANN meeting will provide a separate Adobe Connect room for observers where a live feed to the RT meeting will be transmitted.
    • Face-to-face meetings of the RT not at an ICANN meeting will be broadcast in an Observer Adobe Connect room.
    • Holding part of a meeting “off the record”:
      • All SSR2-RT meetings will be recorded.
      • Any SSR2-RT member can request that the discussions be taken “off the record” at any point. If such a request is accepted by the Co-Chair leading the meeting, the meeting will go “off the record” while the SSR2-RT decides if the request should be approved.
      • When a meeting is taken “off the record,” the record shall reflect this decision as well as the underlying considerations that motivated such action. The Co-Chairs should ensure that the meeting becomes “on the record” again as soon as the topic requiring “off the record” is completed. Observers should be advised that the meeting has become “on the record” again.
      • If the SSR2-RT approves the request the meeting will remain “off the record” until the discussion of the issue approved to be “off the record” is completed.
      • If the SSR2-RT rejects the request the meeting will resume being “on the record”.
      • SSR2-RT members wishing to hold “off the record” discussions with the SSR2-RT are encouraged to discuss this with a Co-Chair prior to the meeting. Should the Co-Chairs approve the request prior to the meeting this will allow for adequate preparations to be made ahead of time to facilitate going “off the record” during the meeting.
      • The SSR2-RT shall have access to ICANN internal information and documents pursuant to the Confidential Disclosure Framework set forth in the Operating Standards (when available) (the Confidential Disclosure Framework) and completion of ICANN’s Non-Disclosure Agreement.
      • The SSR2 Fact Sheet captures attendance of review team members, costs associated with professional services and travel to attend face-to-face meetings, and review milestones.  The SSR2 Fact Sheet is updated and publicly posted quarterly.

Sub-teams of the SSR2-RT

  • The SSR2-RT can create as many sub-teams as it deems necessary to complete its tasks through its standard decision process.
  • Sub-teams will be composed of SSR2-RT members and will have a clear scope, timeline, deliverables and leadership.
  • Sub-teams when formed will appoint a rapporteur who will report the progress of the sub-team back to the plenary on a defined timeline.
  • Sub-teams will operate per SSR2-RT rules and all sub-team requests will require SSR2-RT approval.
  • Sub-teams can arrange face-to-face meetings in conjunction with SSR2-RT face-to-face meetings.
  • All documents, reports and recommendations prepared by a sub-team will require SSR2-RT approval before being considered a product of the SSR2-RT.
  • The SSR2-RT may terminate any sub-group at any time.

SSR2-RT Support

Independent Experts

Section 4.6. of ICANN’s Bylaws states: 

SPECIFIC REVIEWS (iv) - “Review teams may also solicit and select independent experts to render advice as requested by the review team. ICANN shall pay the reasonable fees and expenses of such experts for each review contemplated by this Section 4.6 to the extent such fees and costs are consistent with the budget assigned for such review. Guidelines on how review teams are to work with and consider independent expert advice are specified in the Operating Standards.”

Should the need for independent experts arise, the decision to request independent expert(s) will formally be approved by the SSR2-RT, after considering input from ICANN Organization on budget implications and contracting requirements. The Co-Chairs will communicate the SSR2-RT’s request to ICANN so it can be processed per ICANN’s standard operating procedures.

Travel Support

Members of the SSR2-RT who request funding from ICANN to attend face-to-face meetings will receive it according ICANN’s standard travel policies and subject to the SSR2-RT budget. Travel funding for SSR2-RT members attending a face-to-face meeting being held in conjunction with an ICANN meeting will be for the duration of the ICANN meeting.


[1] The nature and use of consensus and minority views are informed by the “GNSO Working Group Guidelines” 

  • No labels