Preliminary Report | Special Meeting of the ICANN Board of Directors 25 January 2011

[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. If significant revisions have been requested prior to the posting of the preliminary report than such rationale will be held until it is approved by the Board as the minutes of that meeting are approved.

A Special Meeting of the ICANN Board of Directors was held on 25 January 2011.

Chairman Peter Dengate Thrush promptly called the meeting to order.

In addition to Chairman Peter Dengate Thrush the following Directors participated in all or part of the meeting: Rod Beckstrom (President and CEO), Steve Crocker (Vice Chairman), Sébastien Bachollet, Cherine Chalaby, Bertrand de la Chapelle, Rita Rodin Johnston, Erika Mann, Gonzalo Navarro, Raymond A. Plzak, Rajasekhar Ramaraj, George Sadowsky, Mike Silber, Bruce Tonkin, Katim Touray, and Kuo-Wei Wu.

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

Reinhard Scholl, TLG Liaison, sent apologies.

This is a preliminary report of the approved resolutions resulting from the Regular Meeting of the ICANN Board of Directors, which took place 25 January 2011.

  1. Executive Session

    The Board conducted an executive session, in confidence. No actions were taken during the executive session.

  2. Consent Agenda

    The Chair of the Board introduced the design of the agenda to the newer Board members and noted that any Board member could request the removal of items from the Consent Agenda. The Board requested three items to be moved to the Main Agenda, which were moved to the first items on the main agenda.

    The Board then took the following action:

    RESOLVED, the following resolutions in this Consent Agenda are hereby approved:

    1. Approval of Minutes of 8 December 2010 ICANN Special Board Meeting

      RESOLVED (2011.01.25.01) the Board hereby approves the minutes of the 8 December 2010 ICANN Special Board Meeting.

    2. Approval of Minutes of 10 December 2010 ICANN Regular Board Meeting

      RESOLVED (2011.01.25.02) the Board hereby approves the minutes of the 10 December 2010 ICANN Regular Board Meeting.

    3. Approval of Minutes of 10 December 2010 ICANN Organizational Board Meeting

      RESOLVED (2011.01.25.03) the Board hereby approves the minutes of the 10 December 2010 ICANN Organizational Board Meeting.

    4. Approval of Revised Charter of the Finance Committee

      Whereas, the Board Finance Committee (BFC) is currently operating under a Charter approved in 2000, available at http://www.icann.org/en/committees/finance/.

      Whereas, as part of the BFC's obligation to review its operations and make appropriate recommendations for updates or enhancements, on 5 December 2010 the BFC approved a Revised Charter that better reflects the BFC's current operations. The Revised Charter also incorporates, unchanged, the standard language for Board Committee Charters as previously approved by the Board Governance Committee. See http://www.icann.org/en/minutes/resolutions-06mar09.htm#10.

      RESOLVED (2011.01.25.04), the Revised Charter of the Board Finance Committee is approved.

      Rationale for Resolution 2011.01.25.04

      Approving the revised Board Finance Committee (BFC) charter at this time makes sense as the revised version better reflects the current operations of the BFC than the prior version. It also now conforms to the recent revisions to all other charters, as approved by the Board Governance Committee. Further, the revised charter reflects the BFC's activities as they relate to the size and scope of ICANN in 2011 and that the BFC is operating in accordance with the best practices. In developing the revised Charter both best practices as well as the actual operations of ICANN's BFC were reviewed and considered significant to approve the revised charter.

      The approval of the Revised BFC Charter should have a positive public effect in that it increases the accountability and transparency of the organization and aligns with the BFC's current activities and best practices. There is no financial impact on ICANN or the community by revising the BFC charter. Confirmation of the BFC mandate through revision to its charter does not present any impact on the systemic security, stability and resiliency of the DNS.

    5. From SSAC – Appointment of SSAC Chair

      Whereas, Article XI, Section 2, Subsection 2 of the Bylaws governs the Security and Stability Advisory Committee (SSAC).

      Whereas, Article XI, Section 2, Subsection 2 of the Bylaws states that the Board shall appoint the Chair and the members of the SSAC.

      Whereas, on 10 December 2010 Steve Crocker announced his intention to resign as Chair of the SSAC upon the selection by the SSAC of a new Chair and appointment by the Board.

      Whereas, on 22 December 2010 Ray Plzak resigned as Vice Chair of the SSAC.

      Whereas, the SSAC initiated an election for Chair and Vice Chair from the members of the Committee beginning 10 December 2010 and ending 07 January 2011.

      Whereas, the Committee elected Patrik Fältström as Chair and James Galvin as Vice Chair.

      RESOLVED (2011.01.25.05), the Board accepts the recommendation of the SSAC and appoints Patrik Fältström as Chair of the SSAC and extends its best wishes to Patrik Fältström and to James Galvin in their important new roles.

    6. From SSAC – Thank you to departing SSAC Member – Christophe Reverd

      Whereas, Christophe Reverd was appointed to the ICANN Security and Stability Advisory Committee on 26 June 2009.

      Whereas, ICANN wishes to acknowledge and thank Christophe Reverd for his service to the community by his membership on the Security and Stability Advisory Committee.

      RESOLVED (2011.01.25.06), that Christophe Reverd has earned the deep appreciation of the Board for his service to ICANN by his membership on the Security and Stability Advisory Committee, and that the Board wishes Christophe Reverd well in all future endeavours.

    7. From SSAC – Thank you to departing SSAC Member & Vice-Chair – Ray Plzak

      Whereas, Ray Plzak was appointed to the ICANN Security and Stability Advisory Committee on 17 May 2002.

      Whereas, ICANN wishes to acknowledge and thank Ray Plzak for his service to the community as Vice Chair and member of the Security and Stability Advisory Committee.

      RESOLVED (2011.01.25.07) that Ray Plzak has earned the deep appreciation of the Board for his service to ICANN as Vice Chair and member of the Security and Stability Advisory Committee, and that the Board wishes Ray Plzak well in all future endeavours.

    8. From SSAC – Thank you to departing SSAC Chair – Steve Crocker

      Whereas, Dr. Stephen Crocker was appointed as Chair of the ICAN Security and Stability Advisory Committee on 14 March 2002.

      Whereas, Dr. Crocker has served with consummate skill and dedication as the Chair of the SSAC.

      Whereas, Dr. Crocker brought structure and substance to the operation of the SSAC, and led the Committee through major landmark events such as SiteFinder and Root Scaling.

      Whereas, Dr. Crocker expanded the membership of SSAC to include subject matter experts on a broad range of topics, simultaneously increasing the Committee's geographic diversity and depth of Staff support.

      Whereas, Dr. Crocker guided the SSAC through its first comprehensive external review, and ensured the implementation of all recommendations in a timely manner.

      Whereas, Steve Crocker transformed the Security and Stability Advisory Committee from a concept to excellence in execution, resulting in enhanced credibility to the Committee in specific and to ICANN in general.

      Whereas, on 10 December 2010 Dr. Crocker announced his intention to resign as Chair of the SSAC upon the selection by the SSAC of a new Chair and appointment by the Board.

      Whereas, the SSAC initiated an election for Chair and Vice Chair from the members of the Committee beginning 10 December 2010 and ending 07 January 2011.

      Whereas, the Committee elected Patrik Fältström as Chair and James Galvin as Vice Chair.

      Whereas, on 25 January 2011 the Board appointed Patrik Fältström as the new Chair of the SSAC.

      RESOLVED (2011.01.25.08), that Dr. Crocker has earned the tremendous gratitude and deep appreciation of the Board for his tireless service and dedication to ICANN as Chair of the Security and Stability Advisory Committee, and that the Board wishes Dr. Crocker well in all future endeavours.

    9. Approval to Track Global Policy Process for IPv4 Post-Exhaustion

      Whereas, the Board's Review Procedures for Global Internet Number Resource Policies Forwarded for Ratification by the ASO Address Council in Accordance with the ASO MoU, states that "When, in accordance with step 1 in the Global Policy Development Process of the ASO MoU (Attachment A, article 1), ICANN staff liaising with the addressing community becomes aware of a global policy development within the scope of the ASO MoU, ICANN staff informs the ICANN Board of this development. The Board decides, as and when appropriate, that this development should be followed by ICANN staff and instructs the ICANN CEO to assign staff for this purpose. ICANN staff so assigned shall inform all ICANN Supporting Organizations and Advisory Committees, shall establish an ICANN web page to be kept up to date and shall compile a background report to be kept up to date on this global policy development. This background report shall be provided to the Board as requested."

      Whereas, ICANN staff has informed the Board that a policy proposal entitled "Global Policy Proposal for the Allocation of IPv4 by the IANA post exhaustion" is in development and that this Proposal has entered the first adoption steps within the individual RIRs as well as being recognized by the ASO Address Council as a valid Global Policy Proposal.

      Whereas, the Proposal is identified as a global policy development within the scope of the Memorandum of Understanding between ICANN and the ASO.

      RESOLVED (2011.01.25.09), the Board requests that the development of the policy proposal entitled "Global Policy Proposal for the Allocation of IPv4 by the IANA post exhaustion" be followed by ICANN staff in line with the Board's Review Procedures for such policy proposals and instructs the ICANN CEO to assign staff for this purpose.

      Rationale for Resolution 2011.01.25.09

      The Global Policy Proposal has reached the discussion stage in all Regional Internet Registries and the time is ripe to start producing and posting Background Reports on the Proposal's status. Directing staff to conduct the required tracking work is in furtherance of ICANN's obligations under the MoU with the ASO and the Board's Review Procedures for Global Internet Number Resource Policies.

      There will be a nominal budgetary impact when directing staff to track the Proposal, as ICANN staff are already allocated to the ASO, and the tracking of proposals at this stage require limited staff effort. If approved, future implementation may pose additional impacts on the budget, public and security/stability related issues, but those are not ripe for assessment at this time. Requiring staff tracking at this stage will also allow for advance preparation in advance of a request from the ASO for ratification.

    10. Approval of RSSAC Review Implementation Plan

      Whereas, on 5 August 2010, the Board resolved to receive the Final Report of the RSSAC review Working Group, and directed the Structural Improvements Committee (SIC) "to present a set of suggested actions for approval at the October 2010 Board meeting, so as to address the conclusions and recommendations formulated in the final report of this Working Group", at http://www.icann.org/en/minutes/resolutions-05aug10-en.htm#2.f.

      Whereas, ICANN staff members supporting the organizational reviews identified a set of measures in a document "RSSAC review WG final report: implementation steps", dated December 2010, to address the recommendations arising out of the Working Group and provided those to the SIC.

      Whereas, the SIC finds the proposed measures are adequate and proposes to have staff, working in coordination with the SIC, to finalize an implementation plan based upon the implementation steps identified, and to provide a final implementation plan to the Board for receipt and consideration.

      RESOLVED (2011.01.25.10), the Board approves the "RSSAC review WG final report: implementation steps" put forward by the SIC and instructs the SIC, in coordination with staff, to provide the Board with a final implementation plan to address the conclusions and recommendations in the final reports of the RSSAC review Working Group.

      Rationale for Resolution 2011.01.25.10

      The proposed implementation steps were provided to the Board in fulfillment of the Board's 5 August 2010 resolution requiring the submission of this proposal. The implementation steps address the recommendations arising out of the Review Working Group's Final Report. A draft Final Report was posted for public comment and no comments were received, including none indicating that there would be a negative impact if the recommendations were adopted. Further, adoption of the implementation plan for the RSSAC Review will set the stage for a dedicated staff effort to improve cooperation and communication between ICANN and the root server operators within the framework of the RSSAC structure.

      Directing the creation of a final implementation plan will have a nominal budgetary impact, in that it will require further resources of the staff supporting ICANN's Organizational Reviews. The identification of final implementation steps is anticipated to occur within the resources already allocated. The further impact of the implementation work will be identified as practicable.

    11. Approval of Proposed Bylaws Amendment to Create a Non-Voting Chair-Elect to the Nominating Committee

      Whereas, Article VII, Section 2 and 3 of the Bylaws govern the composition of the Nominating Committee (NomCom) and the terms of the NomCom members.

      Whereas, in its final report published 29 January 2010 http://www.icann.org/en/reviews/nomcom/nomcom-review-finalization-wg-final-report-29jan10-en.pdf [PDF, 361 KB], the NomCom Review Finalization Working Group recommended that the Chair of the NomCom be elected one year in advance, requiring changes to the ICANN Bylaws in Article VII, Section 2 and 3 at http://www.icann.org/en/general/bylaws.htm#VII.

      Whereas, on 12 March 2010, the Board received the NomCom Review final report and directed the Structural Improvements Committee (SIC) to identify actions necessary to address the recommendations within the report, at http://www.icann.org/en/minutes/resolutions-12mar10-en.htm#1.6.

      Whereas, the SIC, at its 14 October 2010 meeting, recommended that the Bylaws should be amended to achieve the recommendation of the NomCom Review Finalization Working Group by electing the NomCom Chair one year in advance, while also highlighting that the related Bylaws amendments must incorporate appropriate flexibility for the Board.

      Whereas, the Board, at its 28 October 2010 meeting, resolved that the proposed Bylaws amendments should be posted for public comments.

      Whereas, the proposed Bylaws amendments, see http://www.icann.org/en/general/proposed-bylaws-revision-vii-10nov10-en.pdf [PDF, 64 KB], were posted for public comments from 10 November to 10 December 2010 and this period elapsed without any comments being received.

      RESOLVED (2011.01.25.11), the Board approves the proposed Bylaws amendments and directs staff to work with the Structural Improvements Committee to prepare for implementation of the new provisions to be effective for the 2013 Nominating Committee.

      Rationale for Resolution 2011.01.25.11

      The Bylaws amendments proposed will have the purpose of achieving the recommendation of the NomCom Review Finalization Working Group by designating the NomCom Chair one year in advance, while preserving appropriate flexibility for the Board to review the candidate for the Chair.

      As no public comments have been received indicating that this would not be a positive change regarding the Nominating Committee and its processes. The budgetary impact of this is neutral, as the transition from the non-voting advisor to the Chair to the Chair-Elect does not represent a change in the number of Nominating Committee members supported through the budget for the Nominating Committee.

    12. Thanks to the 2010 Nominating Committee

      Whereas, on 27 August 2009, ICANN appointed Wolfgang Kleinwächter as Chair of the Nominating Committee.

      Whereas, the 2010 Nominating Committee consisted of delegates from each of ICANN's constituencies and advisory bodies.

      RESOLVED (2011.01.25.12), the ICANN Board expresses its deep appreciation to Wolfgang Kleinwächter and all of the members of the 2010 Nominating Committee for their dedication, hard work, and successful efforts.

    13. Approval of Redelegation of the .BF domain representing Burkina Faso

      Whereas, BF is the ISO 3166-1 two-letter country-code designated for Burkina Faso.

      Whereas, ICANN has received a request for redelegation of .BF to the Autorité de Régulation des Communications Electroniques;

      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.

      RESOLVED (2011.01.25.13), the proposed redelegation of the .BF domain to the Autoritéde Régulation des Communications Electroniques is approved.

      Rationale for Resolution 2011.01.25.13

      Why the Board is addressing the issue now?

      Staff presents delegation and redelegation requests for country-code domains to the Board for decision, once staff is 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 the IANA function 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 basic principles 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.

    14. Approval of Redelegation of the .CD domain representing the Democratic Republic of Congo

      Whereas, CD is the ISO 3166-1 two-letter country-code designated for the Democratic Republic of the Congo;

      Whereas, ICANN has received a request for redelegation of .CD to Office Congolais des Postes et Telecommunications;

      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.

      RESOLVED (2011.01.25.14), the proposed redelegation of the .CD domain to the Office Congolais des Postes et Telecommunications is approved.

      Rationale for Resolution 2011.01.25.14

      Why the Board is addressing the issue now?

      Staff presents delegation and redelegation requests for country-code domains to the Board for decision, once staff is 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 the IANA function 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 basic principles 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.

    15. Approval of Redelegation of the .SY domain representing the Syrian Arab Republic

      Whereas, SY is the ISO 3166-1 two-letter country-code designated for the Syrian Arab Republic;

      Whereas, ICANN has received a request for redelegation of .SY to the National Agency for Network Services;

      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.

      RESOLVED (2011.01.25.15), the proposed redelegation of the .SY domain to the National Agency for Network Services is approved.

      Rationale for Resolution 2011.01.25.15

      Why the Board is addressing the issue now?

      Staff presents delegation and redelegation requests for country-code domains to the Board for decision, once staff is 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 the IANA function 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 basic principles 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.

    16. Approval of Delegation of the .한국 ("Hanguk") domain representing the Republic of Korea in Korean

      Whereas, 한국 ("Hanguk"), encoded as "xn--3e0b707e", is a string that has been deemed to appropriately represent the Republic of Korea through the IDN Fast Track process.

      Whereas, ICANN has received a request for delegation of .한국 to the Korea Internet & Security Agency.

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

      RESOLVED (2011.01.25.16), the proposed delegation of the .한국 domain to the Korea Internet & Security Agency is approved.

      Rationale for Resolution 2011.01.25.16

      Why the Board is addressing the issue now?

      Staff presents delegation and redelegation requests for country-code domains to the Board for decision, once staff is 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 the IANA function 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 basic principles 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.

    17. Approval of Delegation of the .新加坡 ("Singapore") domain, and the .சிங்கப்பூர் ("Singapore") domain, representing Singapore in Chinese and Tamil

      Whereas, Singapore is currently listed in the ISO 3166-1 standard;

      Whereas, 新加坡 ("Singapore"), encoded as "xn--yfro4i67o"; and சிங்கப்பூர் ("Singapore"), encoded as "xn--clchc0ea0b2g2a9gcd"; are two strings that were deemed to appropriately represent Singapore through the IDN Fast Track process;

      Whereas, ICANN has received a request for delegation of .新加坡 and .சிங்கப்பூர் to Singapore Network Information Centre Pte Ltd;

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

      RESOLVED (2011.01.25.17), the proposed delegation of the top-level domains to Singapore Network Information Centre Pte Ltd is approved.

      Rationale for Resolution 2011.01.25.17

      Why the Board is addressing the issue now?

      Staff presents delegation and redelegation requests for country-code domains to the Board for decision, once staff is 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 the IANA function 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 basic principles 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.

    18. Approval of Delegation of the .سورية ("Sourya") domain representing the Syrian Arab Republic in Arabic

      Whereas, the Syrian Arab Republic is currently listed in the ISO 3166-1 standard;

      Whereas, .سورية ("Sourya"), encoded as "xn--ogbpf8fl", is a string that has been deemed to appropriately represent the Syrian Arab Republic through the IDN Fast Track process.

      Whereas, ICANN has received a request for delegation of .سورية to the National Agency for Network Services.

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

      RESOLVED (2011.01.25.18), the proposed delegation of the .سورية ("Sourya") domain to the National Agency for Network Services is approved.

      Rationale for Resolution 2011.01.25.18

      Why the Board is addressing the issue now?

      Staff presents delegation and redelegation requests for country-code domains to the Board for decision, once staff is 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 the IANA function 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 basic principles 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.

    19. Approval of Delegation of the seven top-level domains representing India in various languages

      Whereas, India is currently listed in the ISO 3166-1 standard;

      Whereas, भारत ("Bharat"), encoded as "xn--h2brj9c"; بھارت "Bharat"), encoded as "xn--mgbbh1a71e"; భారత్ ("Bharat"), encoded as "xn--fpcrj9c3d"; ભારત ("Bharat"), encoded as "xn--gecrj9c"; ਭਾਰਤ ("Bharat"), encoded as "xn--s9brj9c"; இந்தியா ("Bharat"), encoded as "xn--xkc2dl3a5ee0h"; and ভারত ("Bharat"), encoded as "xn--45brj9c"; are seven strings that were deemed to appropriately represent India through the IDN Fast Track process;

      Whereas, ICANN has received a request for delegation of the seven strings as top-level domains to the National Internet Exchange of India;

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

      RESOLVED (2011.01.25.19), the proposed delegation of the seven top-level domains to the National Internet Exchange of India is approved.

      Rationale for Resolution 2011.01.25.19

      Why the Board is addressing the issue now?

      Staff presents delegation and redelegation requests for country-code domains to the Board for decision, once staff is 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 the IANA function 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 basic principles 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.01.25.01, 2011.01.25.02, 2011.01.25.03, 2011.01.25.04, 2011.01.25.05, 2011.01.25.06, 2011.01.25.07, 2011.01.25.08, 2011.01.25.09, 2011.01.25.10, 2011.01.25.11, 2011.01.25.12, 2011.01.25.13, 2011.01.25.14, 2011.01.25.15, 2011.01.25.16, 2011.01.25.17, 2011.01.25.18, and 2011.01.25.19 were approved in a single vote approving the consent agenda items. All Board members present unanimously approved these resolutions.

Main Agenda

  1. Approval of Proposed Bylaws Amendments Changing Term Ending Dates for Supporting Organization and At-Large Selected Board Members

    The Chair introduced the proposed Bylaws changes to align the end of terms for directors appointed by the Supporting Organization and the At-Large Community to an ICANN meeting, for transition purposes.

    The Board then briefly discussed the timing recommended by the Board Governance Committee for the transition period.

    The Board then took the following action:

    Whereas, the Bylaws currently require that all incoming members of the ICANN Board of Directors not selected by the Nominating Committee (NomCom) are seated on the Board six months after the prior year's Annual General Meeting (AGM).

    Whereas, six months after the prior year's AGM typically occurs in between ICANN's International Public Meetings ("Meeting").

    Whereas, the Board Review Working Group (BRWG) recommended [PDF, 116 KB] that the seating of Board members not appointed by NomCom occur at a mid-year Meeting to facilitate the smooth transition of Board members.

    Whereas, the Board Governance Committee ("BGC") considered this issue, agreed with the rationale of the BRWG, but recognized that a mid-year Meeting may not always occur; the BGC thus recommended modifications to the BRWG recommendation to allow for seating of incoming directors without delay.

    Whereas, proposed Bylaws amendments to reflect the BRWG recommendations were posted for public comment for two months (8 November 2010 through 8 January 2011) at http://www.icann.org/en/public-comment/public-comment-201012-en.htm#bylaws-amend-article-vi8.

    Whereas, just one public comment, supporting the proposed amendments, was received during the public comment period.

    RESOLVED (2011.01.25.20), the Board approves the proposed Bylaws amendments necessary to facilitate a change in transition of Board members selected by the Supporting Organizations or At-Large community.

    Nine Board members voted in favor of Resolution 2011.01.25.20. Seven Board members abstained from voting on the Resolution. The Resolution carried.

    Rationale for Resolution 2011.01.25.20

    Following an independent review by the Boston Consulting Group (BCG) of the ICANN Board (http://www.icann-ombudsman.com/en/reviews/board/report-02nov08-en.pdf [PDF, 921 KB]), a Board Review Working Group (BRWG) was formed to help determine implementation feasibility of the BCG recommendations. The BRWG, after numerous meetings, extensive email communications and document analysis, issued its Final Report (http://www.icann.org/en/reviews/board/board-review-final-26jan10-en.pdf [PDF, 116 KB]) in January 2010. One of the recommendations from the BRWG, which the Board considered, was to seat all Board members not selected by the Nominating Committee, at an ICANN mid-term meeting. With some minor modifications to address the possibility that no mid-term meeting will occur, the Board believes that the BRWG recommendations are reasoned and geared toward ensuring smooth transition of Board members. The only comment received from the community was from ALAC and in support of the proposed Bylaws amendments. (See http://forum.icann.org/lists/bylaws-amend-article-vi8/msg00000.html "The Proposed Bylaws Amendments on Board Member Term Transitions are in alignment with ALAC philosophies related to transitions. The ALAC welcomes and support these amendments.")

    The Board expects that this will have a positive public impact, in that typically new Board members will be seated at the conclusion of a Meeting, allowing for outgoing Board members to conclude their terms at the conclusion of that same Meeting. A transition period provides for a much smoother transition than changing terms in between Board meetings. The outgoing Board members will be able to complete a cycle of being briefed about and then addressing matters pending for discussion and decision at the next meeting. Likewise, the new Board members will be able to start afresh with the next issues at the beginning of the process.

    The Board's decision may have a minimal financial impact on ICANN in that both outgoing and incoming Board members' travel and accommodations will be funded to the transition Meeting. As currently structured, however, additional funding would be required for no more than four Board members, and often less. It is unlikely that the potential amount of additional travel support that may be required will have an impact on the budget or the community. The Board sees no impact on the systemic security, stability and resiliency of the DNS.

  2. Approval of VeriSign RSEP request (for .NAME) for release of numeric-only strings and numeric strings with hyphens

    The Board discussed the request from VeriSign for .NAME as well as the RSEP request for .TEL relating to the release of numeric-only strings, and the potential differences in the Board's consideration of each request.

    The Chair queried the Board and it was determined that a majority of the directors wished to defer further discussion on the .NAME request to allow further time for consideration. The Chair noted that the Board could follow up with staff on any questions on this item, and asked the Secretary to adjourn this item to the agenda of the next Board meeting.

  3. Approval of Telnic RSEP request for release of numeric-only strings except for single-character labels

    The Chair then queried the Board on whether to defer consideration of the .TEL request. A majority of the Board indicated it was prepared to move to a vote.

    The Board then took the following action:

    Whereas, Telnic submitted a Request pursuant to ICANN's Registry Services Evaluation Policy to amend the .TEL Registry Agreement to allow the allocation of numeric-only (excluding single-digit) domain names in .TEL.

    Whereas, .TEL is one of the only two gTLDs currently not allowed to allocate numeric-only domain names.

    Whereas, ICANN evaluated the proposed amendment to the .TEL Registry Agreement as a new registry service pursuant to the Registry Services Evaluation Policy, did not identify any security, stability or competition issues, and posted an amendment for public comment and Board consideration (see http://www.icann.org/en/announcements/announcement-14oct10-en.htm).

    Whereas, the potential issues cited during the public comment period and by ICANN were adequately addressed by Telnic's responses.

    Whereas, approving the proposal would augment the options available to registrants for registering names in .TEL.

    RESOLVED (2011.01.25.21), the amendment to allow allocation of numeric-only (excluding single-digit) domain names in .TEL is approved, and the President and General Counsel are authorized to take such actions as appropriate to implement the amendment.

    Twelve Board members voted in favor of Resolution 2011.01.25.21. Four Board members abstained from voting on the Resolution. The Resolution carried.

    Rationale for Resolution 2011.01.25.21

    Why the Board is addressing the issue now?

    On 8 October 2010 Telnic submitted a request pursuant to ICANN's Registry Services Evaluation Policy to amend the .TEL Registry Agreement to allow the allocation of numeric-only (excluding single-digit) domain names in .TEL. ICANN advised Telnic that an amendment to Appendices 6, Schedule of Reserved Names, and S, the Charter, would be necessary to implement the new service. ICANN determined the amendment was a substantial change to the Registry Agreement; therefore, Board consideration was necessary.

    What are the proposals being considered?

    The Board considered whether or not to approve the proposed amendment to allow the allocation of numeric-only (excluding single-digit) domain names in .TEL.

    What Stakeholders or others were consulted?

    The proposed amendment was subject to public comment from 14 October 2010 through 13 November 2010; four comments were received, one was supportive, one did not address the merits of the proposal but made a suggestion to enhance it, one raised a potential issue, and the last one was the response from Telnic. ICANN asked Telnic to address the issues raised in the public comment forum and by ICANN, which Telnic and .TEL's delegated policy-making authority "the IPAG" did by submitting each one a letter to ICANN.

    What concerns or issues were raised by community?

    One commenter raised the following issue in the public comment forum: 1) whether the proposal might constitute a fundamental change to the TLD; and as a corollary, 2) whether the delegated policy-making authority was followed.

    What significant materials did Board review?

    While considering the proposed amendment, the Board reviewed the following materials: the request from Telnic for a new registry service <http://www.icann.org/en/registries/rsep/telnic-request-08oct10-en.pdf> [PDF, 33 KB]; the proposed amendment subject of the Board resolution <http://www.icann.org/en/tlds/agreements/tel/proposed-tel-amendment-2-14oct10-en.pdf> [PDF, 65 KB]; public comments related to the amendment <http://forum.icann.org/lists/tel-numeric-only-domains/>; a letter from .TEL's IPAG addressing the issues raised <http://www.icann.org/en/registries/rsep/conroy-to-pritz-25nov10-en.pdf> [PDF, 644 KB]; and a letter from Telnic addressing the issues raised <http://www.icann.org/en/registries/rsep/mahdavi-to-schwartz-07jan11-en.pdf> [PDF. 80 KB].

    What factors the Board Found to be Significant?

    1. ICANN conducted the threshold security, stability and competition review on the proposed service pursuant to the RSEP, and did not identify any significant issues. Numeric-only names have been allowed in 14 gTLDs and several ccTLDs for years without harm to the security or stability of the Internet. From a purely technical point of view, there is no difference on what TLD allows the numeric-only names, therefore there is no new issue created by this proposal. ICANN advised Telnic that an amendment to Appendices 6, Schedule of Reserved Names, and S, the Charter, would be necessary to implement the new service.
    2. The proposed amendment was available for public comment from 14 October 2010 through 13 November 2010; four comments were received, one was supportive, one did not address the merits of the proposal but made a suggestion to enhance it, one raised a potential issue, and the last one was the response from Telnic. The comment period produced no clear consensus view on whether or not the amendment should be approved; each commenter provided input suggesting a different path, and some issues, described above, were noted.
    3. The comment from Tim Ruiz (registrar GoDaddy.com, Inc.) suggested that the proposal might constitute a fundamental change to the purpose of the TLD. Ruiz further added that Telnic's promise not to allow numeric-only second-level registrations was a fundamental aspect of its application and a primary reason why .TEL was awarded to Telnic and not Pulver (another bidder for .TEL sTLD at the time). He concluded that this request should not be granted without requiring the rebidding of the .TEL sTLD itself, giving an opportunity for others to bid competitively.
    4. Khashayar Mahdavi, CEO of Telnic Limited (.TEL registry) submitted a response to Tim Ruiz's comment. He stated that the proposal is not a fundamental change to the nature of .TEL, since the restriction on all-numeric strings has nothing to do with the nature of .TEL and was instead a measure put in place to address initial concerns about potential conflicts with ENUM. He stated that .TEL's purpose, as described in its Charter, is to serve the community of users who wish to use a TLD to store and publish their contact information in the DNS.
    5. In response to ICANN's request, .TEL's policy-making body, IPAG provided additional information in a letter on 25 November 2010 explaining the policy development and approval process that was followed, in order to develop the RSEP request.
    6. In the same letter, the Chairman of the IPAG, Lawrence Conroy, a well-recognized ENUM expert, explained why the proposal does not create a technical issue with ENUM. Conroy stated that "In this proposal, single-digitlabels (such as 1.tel or 4.tel) are reserved, rather than continuing to apply ablanket prohibition of all numeric labels (such as 3663.tel); that is not neededor useful. By blocking all single digit labels, the root of an ENUM tree cannotbe placed directly in .tel. ENUM simply doesn't work with multi-digit labels.Telnic did not and does not intend to launch any alternative to ENUM, and hasa long standing agreement with ICANN that this will be the case for .tel." (the letter is included in the Annex).
    7. In a letter from Telnic on 7 January 2011, in response to ICANN's request, Telnic explained why they believe the proposal would not cause confusion between a numeric-only name under .TEL and what might be considered to be a corresponding telephone number. Telnic noted the issue has not been raised before, that adequate tools exists to deal with instances of actual user confusion and/or misrepresentation, and that other TLDs already offer such names without restriction or problems. Lastly, Telnic remarked that should user confusion be identified as an actual problem; their IPAG is well qualified to address any issues that may arise.
    8. .TEL is one of the two gTLDs that is prohibited from allocating numeric-only domain names. By approving the proposal, .TEL would be in a better position to compete with the rest of the gTLDs in the market, which in turn, would provide more options to registrants.

    Are there Positive or Negative Community Impacts?

    By approving the proposed amendment, the gTLD market will be more competitive by allowing .TEL to have a similar offering to the rest of the gTLDs, and more importantly, the registrants will have more options to choose for registration.

    Are there fiscal impacts/ramifications on ICANN (Strategic Plan, Operating Plan, Budget); the community; and/or the public?

    There are no foreseen fiscal impacts/ramifications of approving this amendment on the Strategic Plan, the Operating Plan, Budget, the community, or the public.

    Are there any Security, Stability or Resiliency issues relating to the DNS?

    The proposed service related to the amendment was subject to the preliminary security and stability review pursuant to the Registry Services Evaluation Policy. ICANN did not identify any security, stability or competition issues: http://www.icann.org/en/registries/rsep/arias-to-shadrunov-14oct10-en.pdf [PDF, 53 KB].

  4. CEO's Report

    The Board received a report from the CEO on progress since the Cartagena meeting, including planning for the Board/GAC consultation, the Silicon Valley meeting, and the IDN variants project, as well as an update on staffing of IDN work. The Board then discussed the issue of sponsorship of ICANN meetings. No actions were taken.

  5. Strategic Plan

    The Board received an update from staff on the status of work on the Strategic Plan and the community consultations resulting in revisions to the draft Plan. Staff noted that further public comment would be considered for inclusion in the plan and a version would be presented to the Board in advance of the Silicon Valley meeting. No actions were taken.

  6. Rationale documents

    The Board received a short presentation from staff on the work to create three levels of rationale documents based upon the complexity of the issue under consideration for the Board, as represented in the papers for this meeting. It was noted that this work will continue to evolve and feedback is welcome. The Board discussed the difference between rationales and minutes of meetings, and the scope of rationale documents to present issues considered, materials viewed, and reasons why items were rejected or accepted.

    1. Economic Studies – adopting rationale

      Staff presented the work done to build a detailed rationale for the Board's actions regarding economic studies within the New gTLD program. The Board discussed proposed edits to the rationale document, and noted that additional revisions were to be required prior to concluding on the final text of the rationale document. However, the Board indicated a general approval of the approach taken within the rationale document, subject to the final editing.

      The Board then discussed changes to the resolution approving the rationale document, including a notation that the final rationale document would be posted with the minutes of the Board meeting.

      The Board then took the following action:

      Whereas, on 10 December 2010, the Board recognized that the overarching issue of the call for economic analysis, has been addressed by comprehensive expert consultation and analyses, including reports by CRA International, Dennis Carlton, Michael Katz and Greg Rosston. http://www.icann.org/en/minutes/resolutions-10dec10-en.htm#2.

      Whereas, on 10 December 2010, the Board acknowledged that with respect to the call for economic analysis, ICANN is in the process of receiving and reviewing public comment, and the Board will take into account that public comment including the advice of the GAC and directed staff to make change http://www.icann.org/en/minutes/resolutions-10dec10-en.htm#2.

      Whereas, all economic studies have confirmed the overall benefits of continuing to open the domain name space, in terms of enabling innovation, increasing choice and fostering a healthier competitive environment.

      Whereas, the introduction of detailed rules and safeguard mechanisms via community comments in the successive versions of the draft applicant guidebook is the appropriate way to minimize the potential costs related to the implementation of this policy and optimize the use of the domain name space as a common global resource

      Whereas, in order to avoid the opportunity costs of further delays, efforts should now be focused on finalizing those mechanisms, during the Board-GAC meeting in February and the community interaction at the Silicon Valley meeting in March.

      Whereas the CEO shall continue to ensure that staff takes into account public comment on New gTLD Economic Study Phase II, as well as the advice of the GAC on the call for economic studies, and make revisions as appropriate to the Final Applicant Guidebook.

      Whereas the CEO will carefully watch timing of implementation and fulfill ICANN's obligations under the Affirmation of Commitments that if and when new gTLDs have been in operation for one year, ICANN will organize a review that will examine the extent to which the introduction or expansion of gTLDs has promoted competition, consumer trust and consumer choice, as well as effectiveness of (a) the application and evaluation process, and (b) safeguards put in place to mitigate issues involved in the introduction or expansion.

      Whereas, the Board has considered rationale for making this decision and is in the process of revising the rationale, which will be made part of the minutes from this meeting upon approval.

      RESOLVED (2011.01.25.22), the Board will not commission any further economic studies on new gTLDs in advance of making its decision on the launch of the new gTLD Program as the Board has determined that no further commissioned economic studies could better inform the Board's decision.

      Fifteen Board members voted in favor of Resolution 2011.01.25.22. One Board member was opposed to the Resolution. The Resolution carried.

      Rationale for Resolution 2011.01.25.22

      Pursuant to the Board's resolution, the rationale as discussed during the meeting is being revised and will be posted as it is approved with the minutes of this meeting.

    2. Cross-ownership - adopting rationale

      The Board noted that all previously declared conflicts of interest on this topic remained, and that it was not necessary for the conflicted members and liaisons to leave the meeting for the discussion so long as they refrained from participating in the discussion.

      The Board briefly discussed potential changes to the rationale documents as provided to the Board and determined that it was appropriate to allow a review period following the adoption of the resolutions to review and edit the proposed rationale. Accordingly, the proposed rationale is being published but will not be in an approved form until the board has adopted the rationale as part of the approval of the minutes for this meeting.

      The Board then discussed potential changes to the resolution.

      The Board then took the following action:

      Whereas, on 5 November 2010, the Board passed a resolution on the issue of cross-ownership between registries and registrars for the New gTLD Program. http://www.icann.org/en/minutes/resolutions-05nov10-en.htm.

      Whereas, the Board has reviewed and considered a Proposed Rationale explaining the Board's decision.

      RESOLVED (2011.01.25.23), the Board adopts the Proposed Rationale as the Rationale for the Board's decision on cross-ownership between registries and registrars in the New gTLD Program.

      Nine Board members voted in favor of Resolution 2011.01.25.23. Four Board members were opposed to the Resolution. Three Board members abstained from voting on the Resolution. The resolution carried.

      Rationale for Resolution 2010.01.25.23

      The draft rationale approved by the Board is provided here: http://www.icann.org/en/minutes/draft-cross-ownership-rationale-04feb11-en.pdf [PDF, 164 KB]. The final version of the rationale will be posted with the minutes of this meeting.

  7. Board/GAC Consultations

    1. Process for Consultations

      The Board received a presentation from Staff on the work done to date to form a proposed process for consultations with the GAC, and the ongoing discussion on the formation of a process was noted. The Board discussed the planning for the upcoming consultation with the GAC in Brussels in light of the suggested steps, as well as the need for GAC comment prior to the Board approval of a process. The Board agreed that the proposed process should be forwarded to the GAC for comment, and no Board action was necessary at this time.

    2. New gTLDs

      The Board discussed the proposed resolution on the GAC meeting in Brussels, and a concern was raised about the correctness of the information presented as background on the current agreement between the Board and the GAC. The Board also had a brief discussion regarding support of additional travel to the GAC meeting, and noted that additional discussion on that topic could be continued online.

      The Board then took the following action:

      Whereas, the ICANN Board and ICANN's Governmental Advisory Committee (GAC) has scheduled a meeting from 28 February – 1 March 2011 in Brussels, Belgium ("Meeting") to discuss a specific list of issues raised by the GAC relating to the New gTLD Program as follows ("Topics"):

      • The objection procedures including the requirements for governments to pay fees;
      • Procedures for the review of sensitive strings;
      • Root Zone Scaling;
      • Market and Economic Impacts;
      • Registry – Registrar Separation;
      • Protection of Rights Owners and consumer protection issues;
      • Post-delegation disputes with governments;
      • Use and protection of geographical names;
      • Legal recourse for applicants;
      • Providing opportunities for all stakeholders including those from developing countries;
      • Law enforcement due diligence recommendations to amend the Registrar Accreditation Agreement as noted in the Brussels Communiqué; and
      • The need for an early warning to applicants whether a proposed string would be considered controversial or to raise sensitivities (including geographical names).

      Whereas, the Meeting is not intended to be the consultation mandated by Article XI, section 2, paragraph 1(j) of the ICANN Bylaws.

      Whereas, the Board wishes to trigger the Bylaws mandated consultation to take place during ICANN's Silicon Valley/San Francisco ("SV/SF") meeting scheduled for 13-18 March 2011.

      Whereas, the Board intends for the Bylaws mandated consultation during the SV/SF meeting to be limited to the Topics discussed during the Meeting.

      Resolved (2011.01.25.24), the ICANN Board hereby determines that it intends to progress toward launching the New gTLD Program, as close as practically possible to the form as set out in the Proposed Final Applicant Guidebook.

      Resolved (2011.01.25.25), the Board hereby determines to take actions on the Topics listed above that, at present, are not consistent with GAC advice.

      Resolved (2011.01.25.26), the ICANN Board hereby triggers the consultation as provided for in ICANN Bylaws section Article XI, Section 2, Paragraph 1(j), which shall take place on Thursday, 17 March 2011, during the ICANN SV/SF meeting.

      Resolved (2011.01.25.27), the Bylaws-mandated consultation triggered above shall be limited to the Topics discussed at the Meeting for which the Board has not changed its position during or after the Meeting, and that remain not consistent with GAC advice.

      All Board members in attendance approved of Resolutions 2011.01.25.24, 2011.01.25.25, 2011.25.26, and 2011.25.27.

      Rationale for Resolutions 2011.01.25.24 – 2011.01.25.27

      Both the Board and the GAC have identified a need to have a consultation regarding the outstanding issues relating to the proposed launch of a new gTLD program. Both parties have agreed that this is the correct time to have this consultation. The Board will review all of the papers (including supporting materials and references) prepared for the meeting in consideration of GAC advice. Further, the Board has consulted with all stakeholders throughout the process for posting and revising each version of the Applicant Guidebook on issues identified by the GAC. The particular issues raised by the GAC that will be addressed at the Meeting are found in the GAC Cartagena Communique. http://gac.icann.org/press-release/gac-2010-communique-39.

      Conducting the Meeting and the Bylaws Consultation between the Board and the GAC should have a positive impact on the community. It assures the entire community that the Board is taking the comment process and its Bylaws requirements seriously and hopes to achieve as much consensus as possible.

      There will be a significant fiscal impact on ICANN's budget as a result of the Meeting, which will require additional resources for travel, accommodations, meeting space and related expenses. This includes expenses for some GAC members, Board members, staff members and possibly other representatives. GAC members that are not funded to this Meeting may also feel some fiscal impact if they choose to attend the Meeting in person. There are no security, stability or resiliency issues relating to the DNS that will result from holding the Meeting or the Bylaws Consultation.

    3. ICM

      Staff provided a brief introduction on the proposed Resolution for the Board. The Board then discussed a proposed timing for the completion of the consultation.

      The Board then took the following action:

      Whereas, at its meeting in Cartagena, Colombia, the Board noted its agreement with the staff's assessment of potential conflicts with GAC advice if the Board proceeds with its determination to enter a registry agreement with ICM Registry for the .XXX sTLD, and invoked the GAC consultation process. See http://www.icann.org/en/minutes/resolutions-10dec10-en.htm#4.

      Whereas, during the meeting in Cartagena, the GAC sought affirmative statements from the Board on its positions on ICM-related items.

      Whereas, in an attempt to make a future consultation with the GAC as productive as possible, the Board position on all items of GAC advice are clearly set forth in an attached document.

      RESOLVED (2011.01.25.28), the Board directs staff to provide the GAC with the document setting forth the full Board position on items of GAC advice. The Board positions set forth correspond to the items identified for consultation at the Board's 28 October 2010 meeting.

      RESOLVED (2011.01.25.29), the ICANN Board hereby establishes that the consultation on ICM as triggered in Cartagena and as provided for in ICANN Bylaws section Article XI, Section 2, Paragraph 1(j), shall take place no later than Thursday, 17 March 2011.

      Ten members of the Board approved of Resolutions 2011.01.25.28 and 2011.01.25.29. Five members were unavailable to vote on the Resolutions. One member of the Board abstained from voting on the Resolutions.

      Rationale for Resolutions 2011.01.25.28 – 2011.01.25.29

      As the Board has continued in its consideration of ICM's application for the .XXX sTLD, on 28 October 2010, the Board identified areas requiring consultation with the GAC prior to the Board entering a proposed Registry Agreement with ICM, as certain pieces of GAC advice may not be consistent with the Board's anticipated action. The Board's obligation to consult with the GAC arises out of Article XI, Section 2.1(j)-(k) of the ICANN Bylaws, and the Board formally invoked the consultation process at its meeting in Cartagena. In order to make the consultation as productive as possible, and to address the GAC's concern that it receive the Board's position on whether entering into a Registry Agreement with ICM would be inconsistent with GAC advice, the attached provides further detail and specific citations to support the Board's position on each piece of GAC advice.

      The provision of a comprehensive Board position document is likely to result in a positive impact on the public. The position document provides detail and explanation that will benefit the entirety of the ICANN community as the discussions surrounding the anticipated approval of a Registry Agreement for the .XXX sTLD continue. The forwarding of this document does not pose any fiscal impact on ICANN, the community or the public, however there may be additional costs and expenses incurred in facilitating the consultation between the Board and the GAC, including travel and lodging expenses. The provision of the position document will not have any impact on the security, stability or resiliency of the DNS.

  8. Report on AOC Reviews including ATRT Recommendations – Next Steps

    The Board held a quorum call and assessed that eleven voting members remained in attendance.

    The Board briefly discussed the need for a more fulsome briefing with staff regarding the ATRT recommendations outside of the Board meeting.

    The Board then took the following action:

    Whereas, the Affirmation of Commitments required ICANN to organize a review – to be completed no later than December 31, 2010 – of its execution of commitments to maintain and improve robust mechanisms for public input, accountability, and transparency so as to ensure that the outcomes of its decision-making will reflect the public interest and be accountable to all stakeholders;

    Whereas, as required by the Affirmation, the Accountability and Transparency Review Team (ATRT) submitted its final report to the Board on 31 December 2010 and posted it for public comment through 14 February 2011;

    Whereas, the Affirmation states that the Board will take action on the resulting recommendations within six months of receipt of the report;

    RESOLVED (2011.01.25.30), the Board acknowledges the hard work and dedication of ICANN's ATRT members and thanks these volunteers for engaging in an intensive, public process, under challenging deadlines, to produce a comprehensive set of recommendations to improve ICANN;

    RESOLVED (2011.01.25.31), the Board encourages the public to comment on the ATRT recommendations, and requests that all Supporting Organisations and Advisory Committees, and the Nominating Committee, provide the Board with initial input on the Report, by 14 February 2011, and that the Governmental Advisory Committee and the Nominating Committee work with the Board to consider actions on recommendations related to their organizations;

    RESOLVED (2011.01.25.32), the Board requests that ICANN Staff provide the Board with a proposal for Board action on each recommendation and, where practicable, proposed, initial work plans and budgets for the recommendations, along with a status report on efforts related to all recommendations, by 21 February 2011, taking into account all input received.

    Ten members of the Board approved of Resolutions 2011.01.25.30, 2011.01.25.31, and 2011.01.25.32. Five members were unavailable to vote on the Resolutions. One member of the Board abstained from voting on the Resolutions.

    Rationale for Resolutions 2011.01.25.30 – 2011.01.25.32

    Adherence to the Affirmation of Commitments requires ICANN to undertake the creation of proposals for Board action on each recommendation arising out of Accountability and Transparency Review Team's (ATRT) Final Report. While this work is already underway, ICANN's commitment to accountability transparency is furthered through the transparent tracking of the process.

    The community response to the ATRT's final recommendations is still being provided through the open public comment process. The creation of the proposal for Board action will have a budgetary impact on the organization. Significant staff resources will be devoted to the creation of the proposal, and the proposal itself will identify further budgetary considerations in the implementation of the recommendations. There is a potential that the financial resources of the organization may need to be reallocated to allow sufficient staff support to create a meaningful proposal.

  9. New gTLDs

    1. Rec6 Working Group Recommendations

      The Board received a request from Staff to provide direction on this issue in advance of the meeting with the GAC in Brussels. The Board noted that a call would be set up for discussion, and no action was taken.

      Due to time constraints, no other items were considered. The Chair then adjourned the meeting.