Board Activities and Meetings
*Note: Where available, draft Rationale of the Board's actions is presented under the associated Resolution. The draft Rationale is not final until approved with the minutes of the Board meeting.
- Consent Agenda
- 1.1. Approval of Minutes of 20 June 2011 ICANN Board Meeting
- 1.2. Approval of Minutes of 24 June 2011 ICANN Board Meeting
- 1.3. Approval of Minutes of 24 June 2011 ICANN Board Meeting
- 1.4. Approval of Minutes of 25 June 2011 ICANN Board Meeting
- 1.5. Approval of Redelegation of .om Domain Representing Oman
- Receipt of Security, Stability & Resiliency Framework for FY12
- Appointment of a New Ombudsman
Resolved, the following resolutions in this Consent Agenda are approved:
Resolved (2011.07.28.01), the Board approves the minutes of the 20 June 2011 ICANN Board Meeting.
Resolved (2011.07.28.02), the Board approves the minutes of the 24 June 2011 ICANN Board Meeting.
Resolved (2011.07.28.03), the Board approves the minutes of the 24 June 2011 ICANN Organizational Board Meeting.
Resolved (2011.07.28.04), the Board approves the minutes of the 25 June 2011 ICANN Board Meeting.
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.
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.
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.
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.
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.
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.