Skip to main content
Resources

Preliminary Report Special Meeting of the ICANN Board

[Formal Minutes are still to be approved by the ICANN Board]

Note: This has not been approved by the Board and does not constitute minutes but does provide a preliminary attempt setting forth the reporting of the resolutions from that meeting. Details on voting and abstentions will be provided in the Board's Minutes, when approved by the board at a future meeting.

NOTE ON ADDITIONAL INFORMATION INCLUDED WITHIN PRELIMINARY REPORT – ON RATIONALES -- Where available, a draft Rationale for each of the Board’s actions is presented under the associated Resolution. The current process adopted is that a draft Rationale is not final until approved with the minutes of the Board meeting.

A Special Meeting of the ICANN Board of Directors was held on 28 July 2011 at 11:00 UTC.

Chairman Steve Crocker promptly called the meeting to order.

In addition to the Chair the following Directors participated in all or part of the meeting: Rod Beckstrom (President and CEO), Sébastien Bachollet, Cherine Chalaby, Bertrand de la Chapelle, Chris Disspain, Bill Graham, Gonzalo Navarro, Ray Plzak, R. Ramaraj, George Sadowsky, Mike Silber, Bruce Tonkin (Vice Chair), Katim Touray, and Kuo-Wei Wu.

Erika Mann sent apologies.

The following Board Liaisons participated in all or part of the meeting: Heather Dryden, GAC Liaison; Ram Mohan, SSAC Liaison; Thomas Narten, IETF Liaison; Reinhard Scholl, TLG Liaison; and Suzanne Woolf, RSSAC Liaison.

This is a preliminary report of the approved resolutions resulting from the Special Meeting of the ICANN Board of Directors, which took place 28 July 2011.

  1. Consent Agenda
  2. Receipt of Security, Stability & Resiliency Framework for FY12
  3. Appointment of a New Ombudsman
  4. CEO Report
  5. Any Other Business

  1. Consent Agenda

  2. The Chair of the Board introduced the Consent Agenda items.

    The Board then took the following action:

    Resolved, the following resolutions in this Consent Agenda are approved:

    1.1 Approval of Minutes of 20 June 2011 ICANN Board Meeting

    Resolved (2011.07.28.01), the Board approves the minutes of the 20 June 2011 ICANN Board Meeting.

    1.2. Approval of Minutes of 24 June 2011 ICANN Board Meeting

    Resolved (2011.07.28.02), the Board approves the minutes of the 24 June 2011 ICANN Board Meeting.

    1.3. Approval of Minutes of 24 June 2011 ICANN Organizational Board Meeting

    Resolved (2011.07.28.03), the Board approves the minutes of the 24 June 2011 ICANN Organizational Board Meeting.

    1.4. Approval of Minutes of 25 June 2011 ICANN Board Meeting

    Resolved (2011.07.28.04), the Board approves the minutes of the 25 June 2011 ICANN Board Meeting.

    1.5. Approval of Redelegation of .om Domain Representing Oman

    Whereas, OM is the ISO 3166-1 two-letter country-code designated for Oman;

    Whereas, ICANN has received a request for redelegation of .OM to the Telecommunications Regulatory Authority.

    Whereas, ICANN has reviewed the request, and has determined that the proposed redelegation would be in the interests of the local and global Internet communities;

    It is hereby Resolved (2011.07.28.05), that the proposed redelegation of the .OM top-level domain to the Telecommunications Regulatory Authority is approved.

    Rationale for Resolution 2011.07.28.05

    Why the Board is addressing the issue now?

    Staff present delegation and redelegation requests for country-code domains to the Board for decision, once staff are satisfied the applicant has provided a sufficiently complete application that has a reasonable prospect of a positive Board decision. In line with ICANN’s commitments to perform timely processing of requests relating to the IANA function, and the DNS root zone in particular, the ICANN Board seeks to evaluate such requests at its next scheduled Special Meeting.

    What is the proposal being considered?

    The proposal is to approve a request to IANA to change or designate the sponsoring organisation (also known as the manager or trustee) of a country-code top-level domain.

    In line with established practice, the ICANN Board is involved in making the decision to proceed with such requests as one step of this multi-step process.

    Which stakeholders or others were consulted?

    In the course of evaluating a delegation application, ICANN staff consults with the applicant, the current operator (if applicable), and other directly connected parties. In line with ICANN’s practice of keeping incomplete root zone change requests in confidence, ICANN has not performed open consultation on this matter.

    What concerns or issues were raised by the community?

    Any concerns or issues are raised within the public report that will be published in conjunction with this action. This report will be published on the IANA website at http://www.iana.org/ should the root zone change request has successfully completed final processing, usually 1-2 months after the Board’s decision.

    What significant materials did the Board review?

    The Board is involved in assessing requests against a variety of public interest criteria. This criteria includes establishing the country-code is eligible (e.g. listed in the ISO 3166-1 standard); establishing the proposed manager is supported by the local Internet community; establishing the proposed operator is operationally and technically competent; establishing the proposed manager is based locally and bound under local

    law; establishing the proposed manager operates fairly and equitably; establishing that in cases there is a transfer of operations that an appropriate plan is in place to preserve ongoing stability of the domain; and establishing that the action is compatible with any

    applicable local laws and regulations. During the staff compilation process, the applicant is asked to provide a variety of materials in support of these various aspects. Pertinent information from these supplied materials and other staff research is provided to the Board, and published in a public report at the end of implementing an approved request.

    What factors the Board found to be significant?

    The Board considers factors described in the public report, in relation to the basicprinciples of country-code domain delegation described earlier.

    Are there positive or negative community impacts?

    The timely approval of country-code domain name managers that meet the various public interest criteria is positive toward ICANN’s overall mission, and the local communities to which country-code top-level domains are designated to serve.

    Are there fiscal impacts or ramifications on ICANN (strategic plan, operating plan, budget); the community; and/or the public?

    The administration of country-code delegations in the DNS root zone is part of the IANA functions, and the delegation action should not cause any significant variance on pre-planned expenditure. It is not the role of ICANN to assess the fiscal impact of the internal operations of country-code top-level domains within a country, other than ensuring the operator is based in country and has the appropriate mechanisms to allow the local Internet community to properly oversee the domain’s ongoing operation.

    Are there any security, stability or resiliency issues relating to the DNS?

    For country-code top-level domain delegations, ICANN seeks to approve only such requests where reasonable concerns have been satisfactorily addressed, and the proposed new manager has demonstrated a sufficient level of operational and technical competency where such concerns should be minimal.

    Resolutions 2011.07.28.01, 2011.07.28.02, 2011.07.28.03, 2011.07.28.04, and 2011.07.28.05 were approved in a single vote approving the consent agenda items. All Board members present unanimously approved these resolutions. Two Board members were not available to vote on the resolutions.

  3. Receipt of Security, Stability & Resiliency Framework for FY12

  4. The Board received a report from the Chief Security Officer regarding the SSR Framework, including a discussion of how community considerations raised in response to earlier SSR Frameworks were incorporated into the FY12 Framework. The Board then engaged in a discussion regarding the status of the creation of a Working Group to assist the Board in oversight of work set out in the Framework, as well as the need for reporting on meeting the objectives set out within the Framework.

    The Board then took the following action:

    Whereas, the FY 12 Security, Stability & Resiliency (SSR) Framework was posted for public comment from 2 May to 7 June 2011.

    Whereas, a public comment summary and analysis was completed and published on 8 June 2011.

    Whereas, staff conducted a community briefing during the Singapore meeting and is incorporating feedback into the operational priorities described in the SSR Framework, including benchmarks, objectives, milestones and a mechanism for assessing success in SSR activities.

    Resolved (2011.07.28.06), the Board acknowledges receipt of the FY 12 SSR Framework.

    Rationale for Resolutions 2011.07.28.06

    Under the Affirmation of Commitments signed by ICANN and the US Department of Commerce on 30 September 2009, preserving the security, stability and resiliency of the DNS is recognized as a key commitment. The Affirmation acknowledges in Section 9.2 that ICANN has adopted a Security, Stability and Resiliency (SSR) Plan, which will be regularly updated to reflect emerging threats to the DNS, including unique identifiers. Previous SSR Plans were published in 2009 and 2010, and acknowledged by the ICANN Board at the international public meetings in Sydney, Australia (June 2009) and Cartagena, Colombia (December 2010).

    This latest version of the SSR Framework has been updated in a more streamlined and accessible format, and was published in May 2011 to bring ICANN’s baseline documentation on SSR on schedule with the publication of the FY 12 ICANN Operating Plan and Budget cycle. The document provides guidance to the community on ICANN’s role in SSR, describes areas in which ICANN has operational responsibility, areas in which ICANN is a collaborator, facilitator and contributor, and areas in which ICANN is an observer of activities led by others in the ecosystem. Community inputs received in the public comment period were generally supportive of the revised format, and asked for greater specificity and precision on definitions.

    A Board paper detailing the SSR Framework and annex containing information on the comments received between 2 May and 7 June 2011 has been provided to the Board.

    The document is separate from the overall ICANN Operating Plan and Budget and there are no anticipated fiscal impacts from this decision. The Framework serves as guidance on ICANN activities in SSR for the coming fiscal year.

    Resolution 2011.07.28.06 was unanimously approved by all Board members present. Two Board members were unavailable to vote on the resolution.

  5. Appointment of a New Ombudsman

  6. The Board received a report on the recommendation of the Compensation Committee, status of interviews and the status of work on the negotiation of an agreement with the identified candidate to fill the position of the ICANN Ombudsman, and approved the following resolution resulting from this process.

    The Board then took the following action:

    Whereas, on 31 January 2011 ICANN’s then Ombudsman moved on to other endeavors.

    Whereas, since 1 February 2011 an interim Ombudsman has been performing all of the Ombudsman functions and responsibilities.

    Whereas, ICANN has conducted a thorough and global search for a new Ombudsman.

    Whereas, the Board has identified a new Ombudsman, who has accepted the position.

    Resolved (2011.07.28.07), in accordance with Article V, Section 1.2 of the ICANN Bylaws, the Board hereby appoints Chris LaHatte as the ICANN Ombudsman for an initial term of two years, effective 28 July 2011 through 27 July 2013, and authorizes the General Counsel & Secretary to execute an agreement with Mr. LaHatte.

    Proposed Rationale for Resolution 2011.07.28.07:

    ICANN’s Bylaws require ICANN to maintain an Office of the Ombudsman. See Article V of the Bylaws at http://www.icann.org/en/general/bylaws.htm#V . Having an ICANN Ombudsman positively affects the transparency and accountability of ICANN as the Ombudsman is one of the three main accountability mechanisms within ICANN. As there has been a budget for an ICANN Ombudsman since 2004 when the first Ombudsman was appointed, replacing the current interim Ombudsman will have a negligible financial impact on ICANN. Appointing a new Ombudsman will not negatively impact the systemic security, stability and resiliency of the domain name system.

    Eleven Board members voted in favor of Resolution 2011.07.28.07. Three Board members abstained from voting on the resolution, and two Board members were unavailable to vote. The resolution carried.

  7. CEO Report

  8. The CEO provided a report to the Board on activities and achievements within the organization since Singapore.

  9. Any Other Business

  10. The Chair inquired of the Board if there was any other business for the Board members.

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."