Skip to main content
Resources

Minutes - Risk Committee (RC) Meeting

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

Other Board Member Board Attendees: Peter Dengate Thrush, Dennis Jennings

Staff Attendees: Greg Rattray – Chief Internet Security Advisor; Doug Brent – Chief Operating Officer; Jamie Hedlund – Vice President, Government Affairs – Americas; Kevin Wilson – Chief Financial Officer; Tina Dam, Samantha Eisner, Patrick Jones, Rick Lamb, Diane Schroeder , and Amy Stathos


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

  1. Staff provided an update on activities in furtherance of the RC workplan, including the status of the Enterprise Risk Management (“ERM”) Guidelines, the status of terms of reference for the proposed Risk Management Oversight Team, ongoing work to meet the RC’s request for objective standards for auditing of ERM process in light of lack of available standards, and status of communications with the root server community on root scaling issues.
    • Actions:
      • Staff to provide information regarding Board oversight of risk management.
      • Staff to attend RSSAC meeting in Anaheim, CA to facilitate discussions.

  2. Discussed and worked towards finalization of inventory of enterprise risks. Also discussed how the RC should engage on oversight of the risk factors identified, including trend analysis and anticipatory reporting to the RC on material actions and potential areas of exposure.
    • Actions:
      • RC members to provide final suggestions of language for refined risk inventory items.
      • Staff to revise risk inventory to reflect RC member comments.
      • After finalized, staff to report to the community on the identified risk areas.
      • Staff to provide report to the Board on the identified risk areas at a time to be determined.
      • Staff to report to RC on potential areas of material exposure.
      • When near launch of the new gTLD Program staff to conduct a systemic risk reassessment.
      • Staff to map mitigation measures for the identified risk areas to the operating plan and provide analysis of same to the RC for the next meeting.

  3. Staff provided report on status of project level risk assessment. The first report was on DNSSEC implementation, noting the risks identified in ICANN’s role in the joint project and the mitigation procedures in place. Staff also noted that ICANN has engaged contractors to conduct a SysTrust certification audit of ICANN’s procedures. Staff then provided a presentation on risks identified in IDN implementation, not limited to the current IDN Fast Track process, as well as identified risk mitigation efforts.
    • Actions:
      • Staff to consider future expansion of SysTrust certification audit to the other key areas of the IANA function, potentially by end of FY11.
      • Staff to continue work on communication of IDN requirements compliance and explore creation of an IDN “compliance” framework.
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."