Skip to main content
Resources

Approved Board Resolutions | Regular Meeting of the ICANN Board - Executive Session

  1. Consent Agenda
    1. Redelegation of .ID
    2. Redelegation of .EE
    3. Delegation of .MOH
    4. CRM Implementation Project
    5. Approval of President & CEO FY13 T3 At-Risk Compensation
  2. Main Agenda
    1. Reappointment of Ombudsman

 

  1. Consent Agenda:

    1. Redelegation of .ID

      Resolved (2013.07.17.01), as part of the exercise of its responsibilities under the IANA Functions Contract, ICANN has reviewed and evaluated the request to redelegate the .ID country-code top-level domain to Perkumpulan Pengelola Nama Domain Internet Indonesia. The documentation demonstrates that the proper procedures were followed in evaluating the request.

      Resolved (2013.07.17.02), the Board directs that pursuant to Article III, Section 5.2 of the ICANN Bylaws, that certain portions of the rationale not appropriate for public distribution within the resolutions, preliminary report or minutes at this time due to contractual obligations shall be withheld until public release is allowed pursuant to those contractual obligations.

      Rationale for Resolutions 2013.07.17.01 – 2013.07.17.02

      Why the Board is addressing the issue now?

      In accordance with the IANA Functions Contract, the ICANN staff has evaluated a request for ccTLD redelegation and is presenting its report to the Board for review. This review by the Board is intended to ensure that ICANN staff has followed the proper procedures.

      What is the proposal being considered?

      The proposal is to approve a request to IANA to change the sponsoring organisation (also known as the manager or trustee) of the .ID country-code top-level domain to "Perkumpulan Pengelola Nama Domain Internet Indonesia".

      Which stakeholders or others were consulted?

      In the course of evaluating a delegation application, ICANN staff consults with the applicant and other interested parties. As part of the application process, the applicant needs to describe consultations that were performed within the country concerning the ccTLD, and their applicability to their local Internet community.

      What concerns or issues were raised by the community?

      Staff are not aware of any significant issues or concerns raised by the community in relation to this request.

      [Rationale Redacted]

      What factors the Board found to be significant?

      The Board did not identify any specific factors of concern with this request.

      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, the local communities to which country-code top-level domains are designated to serve, and responsive to ICANN's obligations under the IANA Functions Contract.

      Are there financial 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 financial impact of the internal operations of country-code top-level domains within a country.

      Are there any security, stability or resiliency issues relating to the DNS?

      ICANN does not believe this request poses any notable risks to security, stability or resiliency.

      This is an Organizational Administrative Function not requiring public comment.

      [Rationale Redacted]

    2. Redelegation of .EE

      Resolved (2013.07.17.03), as part of the exercise of its responsibilities under the IANA Functions Contract, ICANN has reviewed and evaluated the request to redelegate the .EE country-code top-level domain to Eesti Interneti Sihtasutus. The documentation demonstrates that the proper procedures were followed in evaluating the request.

      Resolved (2013.07.17.04), the Board directs that pursuant to Article III, Section 5.2 of the ICANN Bylaws, that certain portions of the rationale not appropriate for public distribution within the resolutions, preliminary report or minutes at this time due to contractual obligations shall be withheld until public release is allowed pursuant to those contractual obligations.

      Rationale for Resolutions 2013.07.17.03 – 2013.07.17.04

      Why the Board is addressing the issue now?

      In accordance with the IANA Functions Contract, the ICANN staff has evaluated a request for ccTLD redelegation and is presenting its report to the Board for review. This review by the Board is intended to ensure that ICANN staff has followed the proper procedures.

      What is the proposal being considered?

      The proposal is to approve a request to IANA to change the sponsoring organisation (also known as the manager or trustee) of the .EE country-code top-level domain to "Eesti Interni Sihtasutus".

      Which stakeholders or others were consulted?

      In the course of evaluating a delegation application, ICANN staff consults with the applicant and other interested parties. As part of the application process, the applicant needs to describe consultations that were performed within the country concerning the ccTLD, and their applicability to their local Internet community.

      What concerns or issues were raised by the community?

      Staff are not aware of any significant issues or concerns raised by the community in relation to this request.

      [Rationale Redacted]

      What factors the Board found to be significant?

      The Board did not identify any specific factors of concern with this request.

      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, the local communities to which country-code top-level domains are designated to serve, and responsive to ICANN's obligations under the IANA Functions Contract.

      In this case, the actual technical transfer was implemented in 2010 before submission of a redelegation request through ICANN, and in spite of initial objections by the previous administrator.

      These objections have been cleared since then and the redelegation, now uncontested, can move forward.

      Are there financial 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 financial impact of the internal operations of country-code top-level domains within a country.

      Are there any security, stability or resiliency issues relating to the DNS?

      ICANN does not believe this request poses any notable risks to security, stability or resiliency.

      This is an Organizational Administrative Function not requiring public comment.

      [Rationale Redacted]

    3. Delegation of .MOH

      Resolved (2013.07.17.05), as part of the exercise of its responsibilities under the IANA Functions Contract, ICANN has reviewed and evaluated the request to delegate the IDN country-code top-level domain "мон" to Datacom LLC. The documentation demonstrates that the proper procedures were followed in evaluating the request.

      Resolved (2013.07.17.06), the Board directs that pursuant to Article III, Section 5.2 of the ICANN Bylaws, that certain portions of the rationale not appropriate for public distribution within the resolutions, preliminary report or minutes at this time due to contractual obligations shall be withheld until public release is allowed pursuant to those contractual obligations.

      Rationale for Resolutions 2013.07.17.05 – 2013.07.17.06

      Why the Board is addressing the issue now?

      In accordance with the IANA Functions Contract, the ICANN staff has evaluated a request for ccTLD delegation and is presenting its report to the Board for review. This review by the Board is intended to ensure that ICANN staff has followed the proper procedures.

      What is the proposal being considered?

      The proposal is to approve a request to IANA to delegate the IDN country-code top-level domain "мон" to Datacom LLC.

      Which stakeholders or others were consulted?

      In the course of evaluating a delegation application, ICANN staff consults with the applicant and other interested parties. As part of the application process, the applicant needs to describe consultations that were performed within the country concerning the ccTLD, and their applicability to their local Internet community.

      What concerns or issues were raised by the community?

      Staff are not aware of any significant issues or concerns raised by the community in relation to this request.

      [Rationale Redacted]

      What factors the Board found to be significant?

      The Board did not identify any specific factors of concern with this request.

      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, the local communities to which country-code top-level domains are designated to serve, and responsive to ICANN's obligations under the IANA Functions Contract.

      Are there financial 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 financial impact of the internal operations of country-code top-level domains within a country.

      Are there any security, stability or resiliency issues relating to the DNS?

      ICANN does not believe this request poses any notable risks to security, stability or resiliency.

      This is an Organizational Administrative Function not requiring public comment.

      [Rationale Redacted]

    4. CRM Implementation Project

      Whereas, ICANN has successfully completed a pilot program for Customer Relationship Management (CRM) implementation on the salesforce.com platform to support New gTLD Program operational activities, and is now prepared to begun full implementation.

      Whereas, because the estimated fees for this implementation work exceed $500,000 [Resolution redacted], ICANN Board authorization is required.

      Resolved (2013.07.13.07), the ICANN Board authorizes the President, Generic Domains Division to enter into one or more agreements, and make all disbursements required under the agreement(s), for the necessary CRM implementation work to support the upcoming phases of the New gTLD Program, including contracting and pre-delegation testing.

      Resolved (2013.07.13.08), the Board directs that pursuant to Article III, Section 5.2 of the ICANN Bylaws, portions of this resolution, the rationale and the Board briefing materials be kept confidential until the President, Generic Domains Division, determines that the confidential information can be made public.

      Rationale for Resolutions 2013.07.17.07 – 2013.07.17.08

      In order to support the effective and efficient continued operations of the New gTLD Program, program management has determined that it is necessary to migrate from the TLD Application System (TAS) to a more robust, flexible and configurable Operations platform. New gTLD Program management, working with IT, has evaluated multiple options and selected Salesforce.com as the Customer Relationship Management (CRM) and operations platform. The team piloted the platform to prove that it is a viable operational solution. In order to utilize the Saleforce.com platform for phases of the New gTLD Program beyond Initial Evaluation, additional systematic capabilities are required to be designed, developed and deployed. A project has been scoped, and preliminary design begun to implement these new system capabilities including, Extended Evaluation, Contracting, Pre-Delegation Testing, Community Priority Evaluations and Auctions. The New gTLD Program Committee is approving this expenditure because the project is estimated to exceed $500,000 [Resolution redacted].

      This action is not expected to have an impact on financial or other resources of ICANN that are not already anticipated. This action is not expected to have an impact on the security, stability or resiliency of the domain name system, though the outcomes of this work may result in positive impacts.

    5. Approval of President & CEO FY13 T3 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 T3 at-risk compensation payment.

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

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

      Resolved (2013.07.17.10), 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.07.17.09 – 2013.07.17.10

      When the President and CEO was hired, he was offered a base 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 Durban, 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 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. Main Agenda:

    1. Reappointment of Ombudsman

      Whereas, the Ombudsman's initial term concludes on 27 July 2013.

      Whereas, the Compensation Committee, which is responsible for overseeing the Ombudsman performance and compensation, has recommended that the Board reappoint Chris LaHatte as the Ombudsman for another two-year term.

      Whereas, the current Ombudsman has agreed to serve another term if appointed.

      Resolved (2013.07.17.11), in accordance with Article V, Section 1.2 of the ICANN Bylaws, the Board hereby reappoints Chris LaHatte as the ICANN Ombudsman for a second two-year term from 28 July 2013 through 27 July 2015, and authorizes the General Counsel and Secretary to execute an agreement with Mr. LaHatte.

      Rationale for Resolution 2013.07.17.11

      ICANN's Bylaws require ICANN to maintain an Office of the Ombudsman. See Article V of the Bylaws at http://www.icann.org/en/general/bylaws.htm#V. Having an ICANN Ombudsman positively affects the transparency and accountability of ICANN as the Ombudsman is one of the three main accountability mechanisms within ICANN. ICANN's current Ombudsman is familiar with and well versed in the complex issues now facing ICANN, including the New gTLD Program and other initiatives currently under way. Mr. LaHatte's caseload continues to increase over time, as both the nature of ICANN's activities and the breadth of the ICANN community expand. Maintaining continuity in the Ombudsman's Office with Mr. LaHatte, who is known and respected by members of the ICANN community, is important to ICANN's accountability.

      As there has been a budget for an ICANN Ombudsman since 2004 when the first Ombudsman was appointed this decision does not have any financial impact on ICANN, the community or the public that was not already anticipated or included in the budget. This decision will not have any 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 18 July 2013

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