Skip to main content
Resources

Approved Board Resolutions | Regular Meeting of the ICANN Board

  1. Consent Agenda
    1. Approval of Board Meeting Minutes
    2. FY2014 Budget Approval Timing
      1. Rationale for Resolutions 2013.05.18.02 – 2013.05.18.03
    3. Site of the October 2014 ICANN Meeting in North America
      1. Rationale for Resolutions 2013.05.18.04 – 2013.05.18.06
    4. ACDR Proposal to be a UDRP Provider
      1. Rationale for Resolution 2013.05.18.07
  2. Main Agenda
    1. SSAC Advisory on Internal Name Certificates
      1. Rationale for Resolutions 2013.05.18.08 – 2013.05.18.11
    2. SSAC Budget Request
      1. Rationale for Resolution 2013.05.18.12
  3. Executive Session
    1. CEO At-Risk Compensation
      1. Rationale for Resolutions 2013.05.18.13 – 2013.05.18.14
    2. Confidential Resolution
      1. Rationale for Resolutions 2013.05.18.15 – 2013.05.18.18

 

  1. Consent Agenda:

    1. Approval of Board Meeting Minutes

      Resolved (2013.05.18.01), the Board approves the minutes of the 11 April 2013 Regular Meeting of the ICANN Board.

    2. FY2014 Budget Approval Timing

      Whereas, the FY2014 Budget is currently out for public comment, which closes on 20 June 2013.

      Whereas, ICANN typically approves each year's budget during one of ICANN's Public meetings.

      Whereas, ICANN's mid-year meeting this year, in Durban, South Africa (14-18 July 2013), is taking place after the initiation of the 2014 Fiscal Year, which begins on 1 July 2014.

      Resolved (2013.05.18.02), the ICANN Board intends to approve the FY2014 Budget during the ICANN public meeting in Durban, South Africa.

      Resolved (2013.05.18.03), for the period of time beginning on 1 July 2013 through to the date the Board approves the FY2014 Budget, the Board directs the President and CEO to operate ICANN in a manner consistent with the FY2014 Budget that is posted for public comment.

      Rationale for Resolutions 2013.05.18.02 – 2013.05.18.03

      As per ICANN's Bylaws, the budget of any given year needs to be approved by the end of the preceding fiscal year (30 June). Historically, this approval has happened during the last ICANN Public meeting of the fiscal year (a mid-term meeting), which usually is scheduled towards the end of June. This year, the mid-term meeting is being held from 14 July – 18 July 2013, which is in the next fiscal year.

      The public comment forum on the FY2014 Budget is scheduled to close on 20 June 2013. As that is only ten days prior to the close of the fiscal year, there is limited time to assure that all public comments are reviewed and considered (including any potential changes to the draft budget that are incorporated after review of the public comment) prior to providing the budget to the Board for consideration. In addition, several members of the ICANN community have expressed a preference for each year's budget to be approved at an ICANN Public meeting.

      To allow for sufficient time for review of public comments and for the Board consideration of the comments to the budget, staff recommended to the Board Finance Committee (BFC) that the FY2014 Budget be approved by the Board at the Durban meeting. The BFC agreed and recommended the Board resolve to approve the FY2014 Budget in Durban. This action enhances the Board's accountability to the community, in that the Board is responding to stated community desires for budget approval to occur at a public meeting, as well as assuring that the Board has sufficient time to consider the community inputs prior to taking a decision on the FY2014 Budget.

      In order to allow for ICANN to operate during the beginning of FY2014, beginning on 1 July 2014 through to the date the Board approves the FY2014 Budget, ICANN requires Board authorization. Therefore, the Board is authorizing the President and CEO to operate during this period in accordance with the FY2014 Budget that was posted for public comment. This action will allow for ICANN to maintain its operations pending formal approval of the FY2014 Budget.

      The other alternative here would be to have the Board take a decision on or before 30 June 2013, and outside of a public meeting. This was not deemed preferable under all of the circumstances.

      The delay in approval of the budget, as it is accompanied with a measure to allow the operations of ICANN to continue, is not expected to have a material impact on the planned fiscal operations of the organization or the community. This decision will not have an impact on the security, stability or resiliency of the DNS.

      This is an Organizational Administrative Function of ICANN not requiring public comment.

    3. Site of the October 2014 ICANN Meeting in North America

      Whereas, ICANN intends to hold its third Meeting for 2014 in the North America region as per its policy, and in line with the Board's 20 December 2012 Resolution on 2014 meeting locations.

      Whereas, staff has completed a thorough review of all available meeting venues in North America and finds the one in Los Angeles, California to be the most suitable.

      Whereas, the Board Public and Stakeholder Engagement Committee agreed to Los Angeles, California as the site for the ICANN 2014 North America Meeting.

      Resolved (2013.05.18.04), the Board approves Los Angeles, California as the location of the ICANN 2014 North America Public meeting, which is scheduled for 12-17 October 2014.

      Resolved (2013.05.18.05), the 2014 Los Angeles ICANN Public meeting is designated as ICANN's 2014 Annual Meeting.

      Resolved (2013.05.18.06), the Board reaffirms its 20 December 2012 resolution authorizing the President and CEO to make all necessary arrangements to conduct the 2014 ICANN Meetings, including all necessary contracting and disbursements.

      Rationale for Resolutions 2013.05.18.04 – 2013.05.18.06

      Three times a year ICANN hosts a Public meeting in a different geographic region (as defined in the ICANN Bylaws) of the world. ICANN 51, scheduled for 12-17 October 2014, is to occur in the North America geographic region. Staff identified available and suitable locations, and conducted a thorough analysis of those venues to ensure that they meet the Meeting Selection Criteria. Based on that analysis, Staff recommended that ICANN 51 be held in Los Angeles, California.

      The Board reviewed Staff's recommendation for hosting the meeting in Los Angeles, California and determined that the proposal met the significant factors of the Meeting Selection Criteria used to guide site selection. The process for selection of this site does not call for public consultation, as the staff assessment of the feasibility of any site is the primary consideration.

      Meeting locations for the March 2014 (Singapore) and June 2014 (London) meetings were approved by the Board on 20 December 2012. For comparative information, the meeting facilities and production budget of the Singapore meeting is not to exceed US$885,000, the meeting facilities and production budget of the London meeting is not to exceed US$734,000; and the Los Angeles meeting has a meeting facilities and production budget not to exceed US$568,000. These numbers are exclusive of other meeting-related costs.

      There will be a financial impact on ICANN in hosting the meeting and providing travel support as necessary, as well as on the community in incurring costs to travel to the meeting. But such impact would be faced regardless of the location of the meeting. There is no impact on the security or the stability of the DNS due to the hosting of the meeting.

      This is an Organizational Administrative Function for which public comment is not required.

    4. ACDR Proposal to be a UDRP Provider

      Whereas, the Arab Center for Dispute Resolution (ACDR) submitted a proposal to ICANN to be approved as an UDRP provider.

      Whereas, the ACDR proposal was posted for public comment on 28 September 2010 and a revised version was posted on 1 March 2013, which took into account comments received; ACDR has produced a further revised proposal addressing a final issue raised in the 1 March 2013 public comment forum.

      Whereas, the revised ACDR proposal meets the suggested elements as set forth in Information Concerning Approval Process for Dispute Resolution Service Providers.

      Resolved (2013.05.18.07), the Board approves the application of ACDR to become a UDRP provider, and advises the President and CEO, through the General Counsel's Office, to enter into discussions with ACDR regarding the process for ACDR's provision of UDRP services.

      Rationale for Resolution 2013.05.18.07

      The Board's approval of the ACDR application brings to a close the work of the ACDR (in cooperation with ICANN staff) in working to meet the standards and elements of the process for approval of Uniform Domain Name Dispute Resolution Policy ("UDRP") providers. This enhances ICANN's accountability through adherence to its processes. In addition, the approval of the first UDRP provider located in the Middle East enhances ICANN's accountability to the Internet community as a whole, enhancing choice for UDRP complainants.

      The ACDR's proposal was posted twice for public comment. All of the comments received were provided to ACDR for consideration. Some of the comments in opposition addressed issues such as the level of fees, which is fully within the ACDR's purview. Other commenters suggested that ICANN develop contracts with each of its UDRP providers as a means to require uniformity among providers. Contracts have never been required of UDRP providers. On the issue of uniformity among providers, however, the ACDR's proposal does two things: first, highlighted areas where risk of non-uniform conduct was perceived (such as issues with commencement dates and definitions of writings) have been modified; second, the proposal now includes an affirmative recognition that if ICANN imposes further requirements on providers, the ACDR will follow those requirements; third, the ACDR has revised a specific portion of its Supplemental Rules that was highlighted by commenters as a potential risk to uniformity. This is a positive advancement and helps address concerns of ICANN's ability to, in the future, identify areas where uniformity of action is of its obligation to abide by ICANN modifications that could enhance uniformity among providers.

      ICANN's consideration of the ACDR's proposal also highlights the import of accountability to the community. After the community requested the opportunity to see the proposal again prior to approval, the Board agreed and asked staff to proceed with a further comment period. In addition, the Board also requested that staff report to the community on how ICANN's earlier consideration of UDRP provider uniformity issues was concluded. As a result, a briefing paper has been prepared and will be publicly posted.

      There is a minimal resource impact on ICANN as a result of this decision in assuring that ICANN staff is available to work with the ACDR in starting and maintaining its work as a provider. There is no expected impact on the security, stability or the resiliency of the DNS as a result of this decision.

      This is an Organizational Administrative Function for which public comment was received.

  2. Main Agenda:

    1. SSAC Advisory on Internal Name Certificates

      Whereas, the delegation of TLDs in a way that promotes security and a good user experience is a longstanding topic of importance to ICANN's Board and the global Internet community.

      Whereas, on 15 March 2013, the ICANN Security and Stability Advisory Committee (SSAC) published SAC 057: SSAC Advisory on Internal Name Certificates.

      Whereas, enterprises have local environments that may include strong assumptions about which top-level domains exist at the root level of the public DNS, and/or have introduced local top-level domains that may conflict with names yet to be delegated at the root level of the public DNS.

      Whereas, in its stewardship role, ICANN wishes to determine what these potential clashes are.

      Resolved (2013.05.18.08), the Board directs the President and CEO, in consultation with the SSAC, to commission a study on the use of TLDs that are not currently delegated at the root level of the public DNS in enterprises. The study should consider the potential security impacts of applied-for new-gTLD strings in relation to this usage.

      Resolved (2013.05.18.09), the Board requests RSSAC to assist ICANN in the collection of data and observations related to root server operations that are relevant for the study, and to work with root server operators to enable sharing of such data and observations as appropriate, in the most expedient way possible.

      Resolved (2013.05.18.10), The Board directs the President and CEO to reach out to the Certificate Authority/Browser forum to collect statistics on the distribution of internal name certificates by top-level domain, in the most expedient way possible.

      Resolved (2013.05.18.11), the Board requests the SSAC to consider offering additional advice based on its assessment of the issues identified in the ICANN study, in the most expedient way possible.

      Rationale for Resolutions 2013.05.18.08 – 2013.05.18.11

      Why the Board is addressing the issue now?

      The internal certificate issue identified by SSAC in SAC 057 is a symptom that enterprises have local environments that include strong assumptions about the static number of top-level domains and/or have introduced local top-level domains that may conflict with names yet to be allocated. Regardless of whether these assumptions are valid or not, to be proactive in its stewardship role, ICANN wishes to determine what security and stability implications these potential conflicts have, especially since applications for new gTLDs are in the process of being evaluated by ICANN for delegation into the root. This study also sets a precedent for potential future TLD rounds, where similar studies might need to be conducted as a matter of due diligence.

      What are the proposals being considered?

      The Board requests the ICANN President and CEO to commission a study on the use of TLDs not currently delegated at the root level of the public DNS in enterprises. The study would also consider the potential security impacts of applied-for new-gTLD strings in relation to this usage. In fulfilling the study, the Board is also considering requesting RSSAC to assist root operators in providing some statistics and observations. Finally the Board is considering requesting the SSAC to consider whether it has additional advice for the Board based on its analysis of the study.

      What Stakeholders or others were consulted?

      The SSAC presented the "SAC 057: SSAC Advisory on Internal Name Certificates" to the ICANN community in Beijing. As a result, the SSAC received feedback from the community on this issue and their input informed the SSAC's request.

      What concerns or issues were raised by the community?

      Some community members have raised concerns about the use of TLDs that are not currently delegated at the root level of the public DNS and its impact to enterprises when ICANN delegates these TLDs into the public DNS. Some have asked for an evaluation of such risks so that the ICANN community can make informed decisions. Some have said that their studies show no significant risk to the security and stability of the DNS and have exhorted ICANN to continue on the course of evaluation and eventual delegation of all successful gTLD applications, regardless of conflict due to internal name certificates.

      What significant materials did Board review?

      The SSAC Report on Internal Name Certificates1 [PDF, 1.14 MB], The SSAC Report on invalid Top Level Domain Queries at the Root Level of the Domain Name System (15 November 2010 with corrections)2 [PDF, 507 KB], Report of the Security and Stability Advisory Committee on Root Scaling (6 December 2010)3 [PDF, 175 KB]

      What factors the Board found to be significant?

      In taking its action, the Board considered the recommendations of the SSAC in SAC 045, 046 and 057.

      Are there Positive or Negative Community Impacts?

      The Board's action to direct staff, through the President and CEO, to commission a detailed study on the risks related to the use of TLDs that are not currently delegated at the root level of the public DNS in enterprises will provide a positive impact on the community as it will enhance the understanding of this issue by providing additional information on security impacts of applied-for new-gTLD strings in relation to this usage. This will permit the community and the Board to understand in more detail the potential security and stability concerns if TLDs that are in conflict are delegated, and the impact on the overall functionality of the Internet.

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

      This action is not expected to have an impact on ICANN's resources, and directing this work to be done may result in changes to the implementation plans for new gTLDs. While the study itself will not have a fiscal impact on ICANN, the community or the public, it is possible that study might uncover risks that result in the requirement to place special safeguards for gTLDs that have conflicts. It is also possible that some new gTLDs may not be eligible for delegation.

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

      SAC057 has identified several security risks to the DNS. This study intends to provide a more quantitative view of the problem, and to provide information that would inform future decisions.

      This is an Organizational Administrative Function for which public comment is not required. However, any recommendations arising out of the work directed through this resolution are likely to require community input prior to Board consideration.

    2. SSAC Budget Request

      Whereas, on 11 April 2013, the Board approved SO/AC budget requests submitted through the Fast-Track Process for inclusion in the FY2014 Budget.

      Whereas, the Board did not approve at that time a request from the SSAC regarding additional travel to the ICANN meeting in Durban.

      Resolved, (2013.05.18.12), the Board now approves the SSAC request in the amount of US$20,000 for additional travel to the ICANN meeting in Durban for inclusion in ICANN's Fiscal Year 2014 budget as part of the SO/AC Additional Budget Requests Fast-Track Process.

      Rationale for Resolution 2013.05.18.12

      The SO/AC Additional Budget Requests Fast-Track Process leads to budget approval earlier than usual is a reasonable accommodation for activities that begin near the beginning of FY14. This slight augmentation to ICANN's established budget approval process and timeline helps facilitate the work of the ICANN Community and of the ICANN Staff, and does not create additional expenses.

      Upon the recommendation of the Board Finance Committee, and in light of the specific role that the SSAC plays within ICANN, this decision is important to the work regarding the security, stability and resiliency of the DNS, though no direct anticipated impact on the security, stability or resiliency on the DNS is expected as a result of this decision.

      This is an Organizational Administrative Function for which ICANN received community input.

  3. Executive Session:

    1. CEO At-Risk Compensation

      Whereas, each Board member has confirmed that he/she does not have a conflict of interest with respect to establishing the amount of payment for the President and CEO's FY13 T2 at-risk compensation payment.

      Whereas, the Compensation Committee recommended that the Board approve payment to the President and CEO for his FY13 T2 at-risk compensation.

      Resolved (2013.05.18.13), the Board hereby approves a payment to the President and CEO for his FY13 T2 at-risk compensation component.

      Resolved (2013.05.18.14), specific items within this resolution shall remain confidential as an "action relating to personnel or employment matters", pursuant to Article III, section 5.2 of the ICANN Bylaws.

      Rationale for Resolutions 2013.05.18.13 – 2013.05.18.14

      When the President and CEO was hired, he was offered a based salary, plus an at-risk component of his compensation package. Consistent with all ICANN staff, the President and CEO is evaluated against specific goals that he sets in coordination with the Compensation Committee.

      In Beijing, the Compensation Committee recommended that the Board approve the President and CEO's at-risk Compensation for the second trimester of FY13 and the Board agrees with that recommendation.

      While this will have a fiscal impact on ICANN, it is an impact that was contemplated in the FY13 budget. This decision will not have an impact on the security, stability or resiliency of the domain name system.

      This in an Organizational Administrative Function that does not require public comment.

    2. Confidential Resolution

      [Resolutions Redacted]

      Resolved (2013.05.18.18), specific items of this resolution [Resolutions 2013.05.18.15, 2013.05.18.16 and 2013.05.18.17] shall remain confidential as an "action relating to personnel or employment matters", pursuant to Article III, section 5.2 of the ICANN Bylaws, and the entire resolution shall remain confidential pursuant to this same Bylaws provision pending determination by the President and CEO that the non-confidential portion can be made public.

      Rationale for Resolutions 2013.05.18.15 – 2013.05.18.18

      [Rationale Redacted]

Published on 21 May 2013


1 See http://www.icann.org/en/groups/ssac/documents/sac-057-en.pdf [PDF, 1.14 MB]

2 See http://www.icann.org/en/groups/ssac/documents/sac-045-en.pdf [PDF, 507 KB]

3 See http://www.icann.org/en/groups/ssac/documents/sac-046-en.pdf [PDF, 175 KB]

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