Skip to main content

Minutes - Risk Committee (RC) Meeting

RC Attendees: Bruce Tonkin – Chair; Steve Crocker, Rajasekhar Ramaraj, Mike Silber, and Suzanne Woolf

Other Board Attendees: Rod Beckstrom, Peter Dengate Thrush, Dennis Jennings,

Staff Attendees: Greg Rattray – Chief Internet Security Advisor; Doug Brent – Chief Operating Officer; Barbara Clay – Vice President, Marketing & Communications; Jamie Hedlund – Vice President, Government Affairs - Americas; John Jeffrey – ICANN General Counsel; Dan Halloran, Patrick Jones, Barbara Roseman, Diane Schroeder and Ken Shiu.

The following is a summary of discussions, actions taken and actions identified:

  1. Staff provided an overview briefing on the current risk strategy and planning framework for the evaluation of ICANN meeting venues, including discussion of the evaluation process incorporating security plans, initial site evaluation by staff, utilization of third party risk assessments (UN security ratings) and security risk mitigation measures. The RC noted its responsibility to ensure that staff had a risk framework in place for evaluation of meeting venues and that the framework should include appropriate measures to address any change in the subsequent risk assessment of a chosen meeting venue.
  2. Staff provided a report on the recent implementation of the 2009 recommendations on the IANA Functions Department Root Zone Management Risk Assessment including the conducting of business continuity testing across multiple data centers, internal technical training for staff, confirmation of IANA department request process functioning during business interruption, review of IT communications connectivity, the intention to seek European Foundation for Quality Management (EFQM) certification of the IANA department and publication of the after-action report on the ICANN website.
    • Actions:
      • Staff to incorporate an incident review process into the development of the IANA department process framework.
  3. Discussed the key risk areas identified in relation to each of the FY11 Operating Budget activities with particular discussion on DNS risk responsibilities and funding adequacy for Affirmation of Commitments reviews.
    • Actions:
      • Staff to further develop risk identification language and an appropriate DNS definition within the FY11 Operating plan document.
      • Staff to look at developing further community reporting of L-Root best practice initiatives.
      • Staff to commence drafting FY11 work plan for ICANN’s enterprise risk management program.
      • Staff suggests incorporating risk management into development of FY12 Operating Plan & budget process
      • RC members (Steve Crocker and Suzanne Woolf) to review language on security and stability risk area and suggest revision.
  4. The RC had a brief discussion of DNS Risk Assessment.
  5. The RC resolved to table IPv4 depletion issues for consideration to the next RC meeting.
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"""" is not an IDN."