Skip to main content
Resources

Adopted Board Resolutions | Special Meeting of the ICANN Board

  1. Consent Agenda:
    1. Approval of Minutes
    2. RSSAC Co-Chair Appointment
    3. Root Zone Evolution Review Committee (RZERC) Liaison Appointment
    4. GAC Advice: Helsinki Communiqué (June 2016)
  2. Main Agenda:
    1. Community Consultation on San Juan, Puerto Rico as the Location of the March 2018 North America ICANN Meeting – for discussion – no resolution to be taken
    2. March 2018 ICANN Meeting Hotels Contracting
  3. Executive Session - Confidential:
    1. Officer Compensation
    2. President and CEO At Risk Compensation – FY17-SR1

 

  1. Consent Agenda:

    1. Approval of Minutes

      Resolved (2016.12.13.01), the Board approves the minutes of the 5 November and 8 November 2016 Meetings of the ICANN Board.

    2. RSSAC Co-Chair Appointment

      Whereas, Article 12, Section 2, Subsection C of the Bylaws governs the Root Server System Advisory Committee (RSSAC).

      Whereas, Article 12, Section 2, Subsection C (ii) of the Bylaws states that the RSSAC's chairs and members shall be appointed by the Board.

      Whereas, on 1 December 2016, the RSSAC conducted an election for one co-chair position and re-elected Tripti Sinha (University of Maryland, D-Root Server Operator) to a two-year term as co-chair. Brad Verd (Verisign, A/J-Root Server Operator) will continue to serve as co-chair for the second year of a two-year term.

      Resolved (2016.12.13.02) the Board of Directors accepts the recommendation of the RSSAC and appoints Tripti Sinha as co-chair of RSSAC and extends its best wishes to RSSAC Co-Chairs of their important roles.

      Rationale for Resolution 2016.12.13.02

      The ICANN Bylaws call for the Board to appoint the RSSAC Co-Chairs as selected by the membership. The appointment of RSSAC co-chairs will allow the RSSAC to be properly composed to serve its function within ICANN's policy development work as an advisory committee.

      The appointment of co-chairs is not anticipated to have any fiscal impact on ICANN that has not already been accounted for in the budgeted resources necessary for ongoing support of the RSSAC.

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

    3. Root Zone Evolution Review Committee (RZERC) Liaison Appointment

      Whereas, in line with the recommendations of the CWG-Stewardship post-IANA transition, ICANN established the Root Zone Evolution Review Committee (RZERC) to review issues relating to the architecture and operational systems for the DNS Root Zone as it evolves, and providing recommendations to the ICANN Board to ensure the security, stability, and resiliency of the root zone.

      Whereas appointees to the RZERC must have a strong overall understanding of the Root Zone, and must be able to fully represent their appointing organization's particular interest in the root zone.

      Whereas the RZERC is required to include 9 committee members from specific organizations, including one ICANN Board member.

      Whereas the ICANN Board appointed Suzanne Woolf to the RZERC on an interim basis as the ICANN Board member for the Inaugural Composition of the RZERC finalized on 12 August 2016.

      Whereas Suzanne Woolf concluded her term on the ICANN Board on 8 November 2016.

      Resolved (2016.12.13.03), the ICANN Board thanks Suzanne Woolf for her service on the RZERC.

      Resolved (2016.12.13.04), the ICANN Board appoints Kaveh Ranjbar to the ICANN Board position on the RZERC.

    4. GAC Advice: Helsinki Communiqué (June 2016)

      Whereas, the Governmental Advisory Committee (GAC) met during the ICANN56 meeting in Helsinki, Finland and issued advice to the ICANN Board in a Communiqué [PDF, 328 KB] on 30 June 2016 ("Helsinki Communiqué").

      Whereas, the Helsinki Communiqué was the subject of an exchange [PDF, 301 KB] between the Board and the GAC on 20 July 2016.

      Whereas, on 11 August 2016, the GNSO Council provided feedback [PDF, 436 KB] to the Board concerning advice in the Helsinki Communiqué relevant to generic top-level domains to inform the Board and the community of gTLD policy activities that may relate to advice provided by the GAC.

      Whereas, the Board developed an iteration of the scorecard to respond to the GAC's advice in the Helsinki Communiqué, taking into account the exchange between the Board and the GAC and the information provided by the GNSO Council.

      Resolved (2016.12.13.05), the Board adopts the scorecard titled "GAC Advice – Helsinki Communiqué: Actions and Updates (13 December 2016)" [PDF, 298 KB] in response to items of GAC advice in the Helsinki Communiqué.

      Rationale for Resolution 2016.12.13.05

      Article 12, Section 12.2(a)(ix) of the ICANN Bylaws permits the GAC to "put issues to the Board directly, either by way of comment or prior advice, or by way of specifically recommending action or new policy development or revision to existing policies." In its Helsinki Communiqué (30 June 2016), the GAC issued advice to the Board on various matters including: (1) policies and procedures for future rounds of the New gTLD Program, (2) GNSO consensus policy recommendations on privacy and proxy accreditation, (3) permitting registry operators to allow registration of two-letter domain names at the second level that correspond to country/territory codes, (4) permitting three-letter codes in the ISO-3166 list as gTLDs in future rounds, and (5) protection of names and acronyms of Intergovernmental Organizations (IGOs) in all gTLDs. The ICANN Bylaws require the Board to take into account the GAC's advice on public policy matters in the formulation and adoption of the polices. If the Board decides to take an action that is not consistent with the GAC advice, it must inform the GAC and state the reasons why it decided not to follow the advice. Any GAC advice approved by a full consensus of the GAC (as defined in the Bylaws) may only be rejected by a vote of no less than 60% of the Board, and the GAC and the Board will then try, in good faith and in a timely and efficient manner, to find a mutually acceptable solution.

      At this time, the Board is taking action to address the advice from the GAC in the Helsinki Communiqué. The Board's actions are described in scorecard dated 13 December 2016 [PDF, 298 KB]. In adopting its response to the GAC advice in the Helsinki Communiqué, the Board reviewed various materials, including, but not limited to, the following materials and documents:

      The adoption of the GAC advice as provided in the scorecard will have a positive impact on the community because it will assist with resolving the advice from the GAC concerning gTLDs and other matters. There are no foreseen fiscal impacts associated with the adoption of this resolution. Approval of the resolution will not impact security, stability or resiliency issues relating to the DNS.

      This is an Organizational Administrative function that does not require public comment.

  2. Main Agenda:

    1. Community Consultation on San Juan, Puerto Rico as the Location of the March 2018 North America ICANN Meeting – for discussion – no resolution to be taken

    2. March 2018 ICANN Meeting Hotels Contracting

      Whereas, ICANN intends to hold its first Public Meeting of 2018 in the North America region.

      Whereas, the October 2016 Public Meeting in San Juan was postponed to March 2018 and staff has completed a thorough review of the venue in San Juan, Puerto Rico and finds it suitable.

      Resolved (2016.12.13.06), the Board indicates that the March 2018 Public Meeting shall be held in San Juan, Puerto Rico and authorizes the President and CEO, or his designee(s), to engage in and facilitate all necessary contracting and disbursements for the host and other hotels for the March 2018 ICANN Public Meeting in San Juan, Puerto Rico, in an amount not to exceed [REDACTED FOR NEGOTIATION PURPOSES].

      Resolved (2016.12.13.07), specific items within this resolution shall remain confidential for negotiation purposes pursuant to Article III, section 5.2 of the ICANN Bylaws until the President and CEO determines that the confidential information may be released.

      Rationale for Resolutions 2016.12.13.06 – 2016.12.13.07

      As part of ICANN's Public Meeting schedule, presently three times a year ICANN hosts a meeting in a different geographic region (as defined in the ICANN Bylaws). ICANN 61, scheduled for 10-15 March 2018, is to occur in the North America geographic region. Since the October 2016 Public Meeting scheduled for San Juan, Puerto Rico was moved to Hyderabad, ICANN determined to hold the March 2018 ICANN Public Meeting in San Juan, Puerto Rico.

      The staff performed a thorough analysis of the meeting venue and supporting hotels to ensure that they met the Meeting Selection Criteria (see http://meetings.icann.org/location-selection-criteria).

      The Board reviewed staff's briefing for hosting the meeting in San Juan, Puerto Rico and the determination that the proposal met the significant factors of the Meeting Selection Criteria, as well as the related costs for facilities selected, for the March 2018 ICANN Public Meeting.

      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 and venue of the meeting. This action will have no impact on the security or the stability of the DNS.

      This is an Organizational Administrative function that does not require public comment.

  3. Executive Session - Confidential:

    1. Officer Compensation

      Whereas, the attraction and retention of high caliber staff is essential to ICANN's operations and ICANN desires to ensure competitive compensation for staff.

      Whereas, each Board member has confirmed that they are not conflicted with respect to compensation package for the CIO.

      Resolved (2016.12.13.08), the Board grants the President and CEO the discretion to adjust the CIO's compensation for FY17, effective 1 July 2016, by an amount up to an additional 3%, which is consistent with ICANN's remuneration practices as evidenced by the independent compensation expert information on comparable compensation, subject to a limitation that the CIO's FY17 base salary shall not increase by more than 3% of his current FY17 base salary.

      Rationale for Resolution 2016.12.13.08

      Attracting and retaining high caliber staff by providing a competitive compensation package is crucial to the organization. An improving job market will make more opportunities available for high caliber performers outside of ICANN.

      ICANN's President and CEO has requested that he be granted the discretion to increase the FY17 base salary, effective 1 July 2016, of the CIO by up to 3% of his current FY17 base salary. This amount is in alignment with the actions taken by the President and CEO with respect to the other members of ICANN's Executive Team who are not Officers (which does not require Board approval).

      ICANN is in a critical phase that calls for continuity of certain skill and expertise, particularly with ongoing key projects including the New gTLD Program, the organizational and other reviews underway, the recently concluded IANA stewardship transition, expanding contractual compliance, and enhanced globalization efforts, among many others. Each of these projects requires knowledgeable and skilled executives to ensure ICANN's operational goals and objectives are met while ensuring that risk is mitigated to the greatest extent possible. Adhering to ICANN's employment philosophy, and providing competitive compensation, will help ensure these goals are achieved.

      Continuity and retention of key personnel during key organization phases is beneficial to all aspects of the organization. Thus, salary adjustments provided under this resolution likely will have a positive impact on the organization and its effort to fulfill its mission, as well as on the transparency and accountability of the organization. There will be some fiscal impact to the organization, but that impact will not have an effect on the overall current fiscal year budget. This resolution will not have any direct impact on the security, stability and resiliency of the domain name system.

      This is an Organizational Administrative function that does not require public comment.

    2. President and CEO At Risk Compensation – FY17-SR1

      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 FY17 SR1 at-risk compensation payment.

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

      Resolved (2016.12.13.09), the Board hereby approves a payment to the President and CEO for his FY17 SR1 at-risk compensation component.

      Rationale for Resolution 2016.12.13.09

      When the President and CEO was hired, he was offered a base salary, plus an at-risk component of his compensation package. This same structure exists today. Consistent with all ICANN staff members, the President and CEO is to be evaluated against specific goals, which the President and CEO has set in coordination with the Compensation Committee.

      Toward the end of FY17 SR1, which is a scoring period that normally runs from 16 May 2015 through 15 November 2015, but it began in this instance on 23 May 2016, the President and CEO provided to the Compensation Committee with his self-assessment of his achievements towards his goals for FY17 SR1 the measurement period. After seeking input from other Board members, the Compensation Committee reviewed with the President and CEO his FY17 SR1 goals and discussed his achievements against those goals. Following that discussion, the Compensation Committee recommended that the Board approve the President and CEO's at-risk compensation for the FY17 SR1 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 FY17 budget. This decision will not have an impact on the security, stability or resiliency of the domain name system.

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

Published on 15 December 2016

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