Skip to main content

Minutes | Regular Meeting of the ICANN Board of Directors | Costa Rica

A Regular Meeting of the ICANN Board of Directors was held on 16 March 2012 in San Jose, Costa Rica at 11:10 a.m. local time.

Chairman Steve Crocker promptly called the meeting to order.

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

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

  1. Consent Agenda


  1. Consent Agenda

    The Chair noted that there were changes from the agenda as posted prior to the meeting. He also explained that the Board has been working to smooth out its process, to assure that the items are thoroughly researched and documented and the all of the relevant parties have had their say. As the Board met over the week, and through its detailed discussions, the Board disposed of some of the items that were previously on the agenda. The Board has also determined to defer a vote on the strategic plan. Therefore, all items on the agenda are part of the consent agenda for the Board. The Chair then introduced the consent agenda items.

    Prior to Board considering the consent agenda items, Cherine Chalaby read aloud the thanks to the sponsors, item 1.11 of the agenda. The President and CEO read aloud the thanks for the scribes, interpreters, staff, event and hotel teams, found at item 1.12.

    Gonzalo Navarro stated that it is difficult to give full thanks for the great meeting. He noted the warmth and hospitality of the Tico people, and thanked the organizers for all they made available to ICANN and hospitality. Gonzalo also noted his thanks to President Chinchilla for her speech to open the meeting. Gonzalo then read aloud the thanks to the local hosts, item 1.13 on the agenda.

    The Board then took the following action:

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

    1.1. Approval of Minutes of 7 February 2012 ICANN Board Meeting

    Resolved (2012.03.16.01), the Board approves the minutes of the 7 February 2012 ICANN Board Meeting.

    1.2. Approval of IRTP Part B Recommendation #9, Part 2

    Whereas, on 24 June 2009, the GNSO Council launched a Policy Development Process (PDP) on the Inter-Registrar Transfer Procedure Part B (IRTP Part B) addressing five charter questions. <>

    Whereas, the PDP followed the prescribed PDP steps as stated in the Bylaws, resulting in a Final Report delivered on 30 May 2011.

    Whereas, the IRTP Part B Working Group (WG) reached full consensus on the recommendations in relation to each of the five issues outlined in the Charter.

    Whereas, in relation to Recommendation #9, Part 2, the GNSO Council resolved at its meeting on 22 June 2011 to request ICANN Staff to provide a proposal for a new provision on locking / unlocking of a domain name, taking into account the IRTP Part B WG deliberations in relation to this issue (see IRTP Part B Final Report - (Recommendation #9, Part 2). Upon review of the proposal, the GNSO Council will consider whether to approve the recommendation.

    Whereas, ICANN staff developed the proposal in consultation with the IRTP Part B WG which was put out for public comment (see

    Whereas, comments were received from the Intellectual Property Constituency, and though received after the comment deadline were nonetheless considered by the GNSO Council, and the proposal was submitted to the GNSO Council.

    Whereas, the GNSO Council reviewed and discussed the ICANN Staff proposal in relation to IRTP Part B Recommendation #9, Part 2.

    Whereas, the GNSO Council unanimously adopted the recommendation and ICANN Staff proposal at its meeting on 19 January 2012 (see

    Whereas, the GNSO Council vote met and exceeded the required voting threshold to impose new obligations on ICANN contracted parties.

    Whereas, after the GNSO Council vote, a 21-day public comment period was held on the approved recommendations, and the comments have been summarized and considered (

    Resolved (2012.03.16.02), the Board adopts the GNSO Council Policy Recommendations amending the Inter-Registrar Transfer Policy set forth at

    Resolved (2012.03.16.03), the CEO is to develop and complete an implementation plan for these Recommendations and continue communication with the community on such work.

    Rationale for Resolutions 2012.03.16.02 – 2012.03.16.03

    Why is this issue addressed now?
    The Inter-Registrar Transfer Policy (IRTP) is a consensus policy that was adopted in 2004 which provides for a straightforward process for registrants to transfer domain names between registrars. The GNSO Council established a series of five Working Groups (Parts A through E) to review and consider various revisions to this policy.

    The IRTP Part B PDP is the second in a series of five scheduled PDPs addressing areas for improvements in the existing policy. The IRTP Part B Working Group has addressed five issues focusing on domain hijacking, the urgent return of an inappropriately transferred name, and lock status. Most of these recommendations have already been adopted by the GNSO Council and the ICANN Board. In relation to Recommendation #9, Part 2, a proposal from staff was requested. Following consultations with the IRTP Part B Working Group and a public comment forum on the Staff Proposal, GNSO Council approved IRTP Part B Recommendation #9, Part 2 and the staff proposal unanimously at its meeting on 19 January 2012 (see The IRTP Part B PDP Final Report received unanimous consensus support from the IRTP Part B Working Group as well as the GNSO Council.

    What is the proposal being put forward for Board consideration?

    Recommendation #9, Part 2 states that denial reason #7 of the IRTP should be replaced by adding a new provision in a different section of the IRTP on when and how domains may be locked or unlocked. The ICANN Staff proposal, taking into account the deletion of denial reason #7 as previously approved by the ICANN Board, proposes to expand the existing section 5 (EPP - based Registry Requirements for Registrars) of the IRTP to address "Registrar Lock Status". The proposed modifications to the IRTP can be found in redline form in the ICANN Staff Proposal on IRTP Part B Recommendation #9, Part 2 [PDF, 490 KB] which is included in the Annex. The main elements of the proposed modifications are:

    Registrar may only impose a lock that would prohibit transfer of the domain name if it includes in its registration agreement the terms and conditions for imposing such lock and obtains express consent from the Registered Name Holder: and

    Registrar must remove the "Registrar Lock" status within five (5) calendar days of the Registered Name Holder's initial request, if the Registrar does not provide facilities for the Registered Name Holder to remove the "Registrar Lock" status.

    Outreach conducted by the Working Group to solicit views of groups that are likely to be impacted:
    Public comment forums were held by the Working Group on the initiation of the PDP, the Initial Report, the proposed Final Report and the Staff Proposal on Recommendation 9, Part 2 in additional to regular updates to the GNSO Council as well as workshops to inform and solicit the input from the ICANN Community at ICANN meetings (see, for example, Brussels Meeting and San Francisco Meeting). Constituency/Stakeholder Group Statements were submitted (see All comments received were reviewed and considered by the IRTP Part B PDP WG (see section 6 of the IRTP Part B Final Report [PDF, 972 KB]). In addition, as prescribed by the ICANN Bylaws, a public comment forum was held on the recommendations to be considered by the ICANN Board.

    What concerns or issues were raised by the community?
    Following the closing of the public comment forum on the staff proposal (no comments received) and the submission of the proposal to the GNSO Council, the Intellectual Property Constituency submitted a number of comments, which were considered within the GNSO Council deliberations on the proposal. However, no further changes were deemed necessary to the recommendation as a result of those comment. The staff proposal and the subsequent motion adopting the recommendation were adopted unanimously.

    What significant materials did the Board review?
    The Board reviewed the GNSO Council Recommendations Report to the Board [PDF, 576 KB], as well as the summary of public comments and staff's response to those comments.

    What factors the Board found to be significant?
    The recommendation was developed by the IRTP Part B Working Group following the GNSO Policy Development Process as outlined in Annex A of the ICANN Bylaws and has received the unanimous support from the GNSO Council. As outlined in the ICANN Bylaws, the Council's unanimous (supermajority) support for the motion obligates the Board to adopt the recommendation unless by a vote of more than 66% the Board determines that the policy is not in the best interests of the ICANN community or ICANN. In addition, transfer-related issues are the number one area of complaint according to data from ICANN Contractual Compliance. Improvements to the IRTP have the potential to reduce the number of complaints, in addition to providing clarity and predictability to registrants as well as registrars.

    Are there positive or negative community impacts?
    Improvements to the IRTP have the potential to reduce the number of complaints, in addition to providing clarity and predictability to registrants as well as registrars. Adoption of the recommendations will require changes in processes for registrars, but these are considered to have a minimum impact and necessary in order to address the issues that are part of this policy development process. The recommendations, if implemented, would usefully clarify and enhance the IRTP, to the advantage of all parties concerned.

    Are there fiscal impacts or ramifications on ICANN (strategic plan, operating plan, budget), the community, and/or the public?
    Apart from those changes required in process for registrars as outlined above, no other fiscal impacts or ramifications on ICANN, the community, and/or the public are expected.

    Are there any security, stability or resiliency issues relating to the DNS?
    There are no security, stability, or resiliency issues related to the DNS if the Board approves the proposed recommendations.

    1.3. Bylaws Changes for New GNSO Policy Development Process

    Whereas, on 27 September 2011, the GNSO Council adopted the Updated Final Report <> [PDF, 1.51 MB] of the Policy Development Process Working Team (PDP-WT), setting out a proposed new Annex A to the ICANN Bylaws and a Policy Development Process (PDP) Manual, in fulfillment of a directive to develop a new PDP that is more effective and responsive to the GNSO's needs.

    Whereas, the Board adopted the new Annex A on 8 December 2011 and directed transition to the new PDP.

    Whereas, additional Bylaws revisions are necessary to fully implement the new PDP, including definition of new voting thresholds set out in the PDP-WT Updated Final Report.

    Whereas, a public comment forum was opened on these proposed changes on 10 February 2012 and one comment was received.

    Whereas, the ICANN Board reviewed the proposed changes and the comments submitted.

    Resolved (2012.03.16.04), the ICANN Board approves the further revisions to the ICANN Bylaws <> [PDF, 134 KB] as necessary for the implementation of the new PDP.

    Rationale for Resolution 2012.03.16.04

    The further revision of the ICANN Bylaws is necessary for complete documentation of the transition to the new PDP as approved by the GNSO Council and the ICANN Board. To assure accountability to the ICANN community, the proposed changes were posted for public comment to allow for community input and transparency into the implementation steps (see This action does not have an impact on ICANN's resources and will not have an impact on the security or stability of the DNS.

    1.4. Engagement of Independent Auditor

    Whereas, the ICANN Bylaws in Article XVI <> require that after the end of the fiscal year, the books of ICANN must be audited by certified public accountants. The Bylaws also state that the appointment of the fiscal auditors shall be the responsibility of the Board.

    Whereas, the Board Audit Committee has discussed the engagement of the independent auditor for the fiscal year ending 30 June 2012, and has recommended that the Board engage Moss Adams LLP.

    Whereas, the Board Audit Committee has recommended that the Board direct staff to execute a professional services agreement with Moss Adams, subject to review by the Chair of the Audit Committee.

    Resolved (2012.03.16.05), the Board authorizes the Chief Executive Officer to engage Moss Adams LLP as the auditors for the financial statements for the fiscal year ending 30 June 2012.

    Rationale for Resolution 2012.03.16.05

    The engagement of an independent auditor is in fulfillment of ICANN's obligations to undertake an audit of ICANN's financial books. This furthers ICANN's accountability to its bylaws and processes, and the results of the independent auditors work will be publicly available. There is a fiscal impact to the engagement that has already been budgeted for within ICANN's Operational Plan. There is no impact on the security or the stability of the DNS as a result of this appointment.

    1.5. Approval of Contracting & Disbursement Policy

    Whereas, the Board Finance Committee has reviewed the current Disbursement Policy and recommended that it be revised to clarify that the policy relates to both contracting and disbursement authority.

    Whereas, the Board agrees with Board Finance Committee.

    Resolved (2012.03.16.06), the Board adopts the ICANN Contracting and Disbursement Policy as reflected at <> (note: revised document will be posted when available), which replaces the ICANN Disbursement Policy last revised on 10 December 2010.

    Rationale for Resolution 2012.03.16.06

    The Board is committed to ensuring that ICANN operations are managed as efficiently as possible. One aspect of that is to provide authority to management to contract as needed for the day-to-day operations of the organization and to make timely disbursements in furtherance of those contracts. The intent of the contracting and disbursement policy is to provide management with the authority to operate the organization, but to also maintain sufficient oversight when one contract or project obligates the organization to disburse more than $500,000.00.

    There will be little, if any, impact on the ICANN community given that the purpose of the revisions to this policy is to clarify its applicability. There will be no financial impact on either ICANN or the community, and there will be no impact on the security, stability or resiliency of the domain name system.

    1.6. Approval of the DNS Risk Management Framework WG Charter

    Whereas, on 18 March 2011, the Board directed the Board Governance Committee (BGC) to recommend to the Board a working group to oversee the development of a risk management framework and system for the DNS as it pertains to ICANN's role as defined in the ICANN Bylaws.

    Whereas, at its meeting on 28 October 2011, the ICANN Board approved the Board membership of the Working Group as recommended by the Board Governance Committee.

    Whereas, on 12 March 2012 the Board Governance Committee approved the draft charter of the DNS Risk Management Framework Working Group and recommended that the Board approve the charter.

    Resolved (2012.03.16.07), the Board approves the charter of the DNS Risk Management Framework Working Group.

    Rationale for Resolution 2012.03.16.07

    The development of a risk management framework is intended to fulfill the Board's expressed desire to develop a security framework for Internet naming and address allocation services that defines the key focus areas, and identifies where the responsibilities for each area lie. The Board has established this working group of individuals with expertise in the relevant topic area to oversee the development of such a risk management framework and system for the DNS as it pertains to ICANN's role as defined in the ICANN Bylaws. The progress reflected by the establishment of this working group will assist ICANN in continuing to work to maintain security, stability and resiliency of the DNS.

    The results of the work overseen by this group should have a positive effect on the community in that it shall help define focus areas and responsibility. The establishment of the working group should not have a fiscal impact on the organization or the community.

    1.7. Approval of Redelegation of .BH

    Whereas, BH is the ISO 3166-1 two-letter country-code designated for Bahrain;

    Whereas, ICANN has received a request for the redelegation of .BH 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.

    Resolved (2012.03.16.08), the proposed redelegation of the .BH domain to the Telecommunications Regulatory Authority is approved.

    Rationale for Resolution 2012.03.16.08

    Why the Board is addressing the issue now?

    ICANN presents delegation and redelegation requests for country-code domains to the Board for decision once 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 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 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 should the root zone change request has successfully completed final processing, in a timely manner following 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 that: the country-code is eligible (e.g. listed in the ISO 3166-1 standard); the proposed manager is supported by the local Internet community; the proposed operator is operationally and technically competent; the proposed manager is based locally and bound under local law; the proposed manager operates fairly and equitably; that in cases there is a transfer of operations that an appropriate plan is in place to preserve ongoing stability of the domain; and 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 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 redelegations 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 function, and the delegation 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.

    1.8. Approval of Changes to SSAC Membership

    Whereas, the Security and Stability Advisory Committee (SSAC) reviews its membership and make adjustments from time-to-time.

    Whereas, the SSAC Membership Committee, on behalf of the SSAC, requests that the Board should appoint Robert Guerra and Julie Hammer to the SSAC.

    Resolved (2012.03.16.09), the Board appoints Robert Guerra and Julie Hammer to the SSAC.

    Rationale for Resolution 2012.03.16.09

    The SSAC is a diverse group of individuals whose expertise in specific subject matters enables the SSAC to fulfill its charter and execute its mission. Since its inception, the SSAC has invited individuals with deep knowledge and experience in technical and security areas that are critical to the security and stability of the Internet's domain name system.

    The SSAC's continued operation as a competent body is dependent on the accrual of talented subject matter experts who have consented to volunteer their time and energies to the execution of the SSAC mission. Robert Guerra is a special adviser to the Citizen Lab at the Munk School of Global Affairs at the University of Toronto and co-founder of Privaterra. Robert was previously a member of the SSAC from 2009 to 2010. Robert would bring to the SSAC a civil society perspective in additional to his broad technical experience. Julie Hammer is an independent director on the Board of auDA, the Australian ccTLD. Julie would bring to the SSAC a broad experience in security issues.

    1.9. Thank You to Departing SSAC Member

    Whereas, Xiaodong Lee was appointed to the ICANN Security and Stability Advisory Committee on 25 June 2010.

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

    Resolved (2012.03.16.10), Xiaodong Lee 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 Xiaodong Lee well in his new role at ICANN.

    Rationale for Resolution 2012.03.16.10

    It is the practice of the SSAC to seek Board recognition of the service of Committee members upon their departure.

    1.10. Thank You to Departing ccNSO Volunteer

    Whereas, ICANN wishes to acknowledge the considerable energy and skills that members of the stakeholder community bring to the ICANN process.

    Whereas, in recognition of these contributions, ICANN wishes to acknowledge and thank members of the community when their terms of service on Supporting Organizations and Advisory Committees end.

    Whereas, one (1) member of the ccNSO has left his position since the Dakar meeting:

    Patricio Poblete, ccNSO Council Member since its formation in 2004 to March 2012.

    Resolved (2012.03.16.11), Patricio Poblete has earned the deep appreciation of the Board for his term of service, and the Board wishes him well in his future endeavors.

    1.11. Thanks to Sponsors

    The Board wishes to thank the following sponsors:

    Verisign, Inc., Afilias Limited, .ORG, The Public Interest Registry, Neustar, China Organizational Name Administration Center, Iron Mountain, Knet Co., Ltd., CORE Internet Council of Registrars, SX Registry S.A., China Network Information Center, UniForum SA dba the .ZA Central Registry, Sedari, InterNetX, Community.Asia, Freedom Registry, Inc., GMO Registry, Inc., TANGO REGISTRY SYSTEMS, Foundation for Assistance for Internet Technologies and Infrastructure Development, CloudNames, Dejan SEO Pty Ltd and ICANNWiki, and our local sponsors, ICE (Instituto Costarricense de Electricidad), Instituto Costarricense de Turismo (ICT), LACNIC – Registro de Direcciones de Internet para America Latina y el Caribe, Ministerio de Ciencia y Tecnologia (MICIT), and SOMOS UCR.

    1.12. Thanks to Scribes, Interpreters, Staff, Event and Hotel Teams

    The Board expresses its appreciation to the scribes, the interpreters, technical teams, and to the entire ICANN staff for their efforts in facilitating the smooth operation of the meeting.

    The Board would also like to thank the management and staff of the Ramada Plaza Herradura for the wonderful facility to hold this event. Special thanks are given to Stephanie Roncallo, Lucia Bolaños, Luis Bustos Valerin, and Andrea Muñoz.

    1.13. Thanks to Local Hosts

    The Board wishes to extend its thanks to the local host organizer, NIC Costa Rica, National Academy of Sciences for their support. Special thanks are given to Dr. Gabriel Macaya Trejos, Dr. Guy de Teramond, Jéssica Calvo, Karen Gamboa, Luis Diego Espinoza, and Allan Campos, University of Costa Rica.

    The Board extends thanks to President of the Republic of Costa Rica, Mrs. Laura Chinchilla Miranda, and Minister Alejandro Cruz from the Ministry of Science and Technology for their support and participation during the meeting.

    Resolutions 2012.03.16.01, 2012.03.16.02, 2012.03.16.03, 2012.03.16.04, 2012.03.16.05, 2012.03.16.06, 2012.03.16.07, 2012.03.16.08, 2012.03.16.09, 2012.03.16.10, and 2012.03.16.11 were passed in a single voice vote. Sixteen members of the Board voted in favor of the resolutions. The resolutions carried.

    The Chair then called the meeting to a close.

Domain Name System
Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as"""" is not an IDN."