Skip to main content
Resources

Approved Board Resolutions | Regular Meeting of the ICANN Board

  1. Consent Agenda:
    1. Approval of Board Meeting Minutes
    2. Redelegation of the .MK domain and delegation of the .мкд domain representing the Former Yugoslav Republic of Macedonia to the Macedonian Academic Research Network Skopje
    3. Delegation of the გე ("ge") domain representing Georgia in Georgian (Mkhedruli) script to the Information Technologies Development Center
    4. Extension of .AN (Netherlands Antilles) ccTLD removal date
    5. Registrars Stakeholder Group Charter Amendments
    6. Thank You to Community Members
    7. Thank You to Sponsors of ICANN 51 Meeting
    8. Thank You to Interpreters, Staff, Event and Hotel Teams of ICANN 51 Meeting
  2. Main Agenda:
    1. Thank You to the 2014 Nominating Committee
    2. Introduction of Two-character Domain Names in the New gTLD Namespace
    3. ICANN Strategic Plan for fiscal years 2016-2020
    4. Board Consideration of Recommendations from the Cross Community Working Group on Enhancing ICANN Accountability
    5. Thank You to Olga Madruga-Forti for her service to the ICANN Board
    6. Thank You to Sébastien Bachollet for his service to the ICANN Board
    7. Thank You to Bill Graham for his service to the ICANN Board
    8. Thank You to Heather Dryden for her service to the ICANN Board

 

  1. Consent Agenda:

    1. Approval of Board Meeting Minutes

      Resolved (2014.10.16.01), the Board approves the minutes of the 9 September 2014 Regular Meeting of the ICANN Board.

    2. Redelegation of the .MK domain and delegation of the .мкд domain representing the Former Yugoslav Republic of Macedonia to the Macedonian Academic Research Network Skopje

      Resolved (2014.10.16.02), as part of the exercise of its responsibilities under the IANA Functions Contract, ICANN has reviewed and evaluated the request to redelegate the .MK country-code top-level domain and delegate the .мкд IDN country-code top-level domain to Macedonian Academic Research Network Skopje. The documentation demonstrates that the proper procedures were followed in evaluating the request.

      Resolved (2014.10.16.03), 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 2014.10.16.02 – 2014.10.16.03

      Why the Board is addressing the issue now?

      In accordance with the IANA Functions Contract, the ICANN staff has evaluated two requests for ccTLD redelegation and 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 two requests to the IANA Department to assign and change the sponsoring organization (also known as the manager or trustee) of the .мкд and .MK country-code top-level domains to the Macedonian Academic Research Network Skopje.

      Which stakeholders or others were consulted?

      In the course of evaluating delegation and redelegation applications, 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.

      What significant materials did the Board review?

      The Board reviewed the following IANA Department staff evaluations:

      • The domains are eligible for continued delegation, as MK is an assigned alpha-2 code that is listed in the ISO 3166-1 standard for the country of the Former Yugoslav Republic of Macedonia, and мкд is the approved internationalized domain name string for the Former Yugoslav Republic of Macedonia;
      • The requests are consented by the existing sponsoring organization, Ministry of Foreign Affairs;
      • The relevant government has been consulted and does not object;
      • The proposed sponsoring organization and its contacts agree to their responsibilities for managing these domains;
      • The proposals have demonstrated appropriate local Internet community consultation and support;
      • The proposals do not contravene any known laws or regulations;
      • The proposals ensure the domains are managed locally in the country, and are bound under local law;
      • The proposed sponsoring organization has confirmed they will manage the domains in a fair and equitable manner;
      • The proposed sponsoring organization has demonstrated appropriate operational and technical skills and plans to operate the domains;
      • The proposed technical configuration meets the IANA Department's various technical conformance requirements;
      • No specific risks or concerns relating to Internet stability have been identified; and
      • Staff have provided a recommendation that these requests be implemented based on the factors considered.

      These evaluations are responsive to the appropriate criteria and policy frameworks, such as "Domain Name System Structure and Delegation" (RFC 1591) and "GAC Principles and Guidelines for the Delegation and Administration of Country Code Top Level Domains".

      As part of the process established by the IANA Functions Contract, the "Delegation and Redelegation Report" will be published at http://www.iana.org/reports.

      What factors the Board found to be significant?

      The Board did not identify any specific factors of concern with these requests.

      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 these requests pose any notable risks to security, stability or resiliency.

      This is an Organizational Administrative Function not requiring public comment.

    3. Delegation of the გე ("ge") domain representing Georgia in Georgian (Mkhedruli) script to the Information Technologies Development Center

      Resolved (2014.10.16.04), as part of the exercise of its responsibilities under the IANA Functions Contract, ICANN has reviewed and evaluated the request to delegate the გე country-code top- level domain to the Information Technologies Development Center (ITDC). The documentation demonstrates that the proper procedures were followed in evaluating the request.

      Resolved (2014.10.16.05), 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 2014.10.16.04 – 2014.10.16.05

      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 create the country-code top-level domain and assign the role of sponsoring organization (also known as the manager or trustee) to Information Technologies Development Center (ITDC).

      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.

      What significant materials did the Board review?

      The Board reviewed the following IANA Department staff evaluations:

      • The domain is eligible for delegation, as it is a string that has been approved by the IDN ccTLD Fast Track process, and represents a country that is listed in the ISO 3166-1 standard;
      • The relevant government has been consulted and does not object;
      • The proposed sponsoring organization and its contacts agree to their responsibilities for managing this domain;
      • The proposal has demonstrated appropriate local Internet community consultation and support;
      • The proposal does not contravene any known laws or regulations;
      • The proposal ensures the domain is managed locally in the country, and is bound under local law;
      • The proposed sponsoring organisation has confirmed they will manage the domain in a fair and equitable manner;
      • The proposed sponsoring organisation has demonstrated appropriate operational and technical skills and plans to operate the domain;
      • The proposed technical configuration meets the IANA Department's various technical conformance requirements;
      • No specific risks or concerns relating to Internet stability have been identified; and
      • Staff have provided a recommendation that this request be implemented based on the factors considered.

      These evaluations are responsive to the appropriate criteria and policy frameworks, such as "Domain Name System Structure and Delegation" (RFC 1591) and "GAC Principles and Guidelines for the Delegation and Administration of Country Code Top Level Domains".

      As part of the process established by the IANA Functions Contract, the "Delegation and Redelegation Report" will be published at http://www.iana.org/reports.

      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.

    4. Extension of .AN (Netherlands Antilles) ccTLD removal date

      Whereas, the .AN top-level domain is being decommissioned after its ISO 3166-1 country code was superseded by the new codes.

      Whereas, on 11 October 2011 the Board resolved that the .AN domain should be retired by 31 October 2014.

      Whereas, the .AN domain operator and the Netherlands' Ministry of Economic Affairs have sought a nine month extension of the deadline in order to provide additional opportunity for the remaining registrants to conclude their transition away from the .AN domain.

      Resolved (2014.10.16.06), the deadline for the .AN domain removal from the DNS Root Zone is extended to 31 July 2015.

      Rationale for Resolution 2014.10.16.06

      Why the Board is addressing the issue?

      The .AN top-level domain is due to be retired from the DNS Root Zone by 31 October 2014. The .AN operator and the Netherlands' Ministry of Economic Affairs have asked for an extension of the removal date.

      What is the proposal being considered?

      The request is to extend the retirement date of the .AN top level domain to 31 July 2015.

      What concerns or issues were raised by the community?

      The .AN operator expressed that while the majority of domain registrants have migrated to the new domains, there remains a minority of about 30 registrants that need more time to complete their transition. The operator is concerned that the current deadline is not achievable for the remaining registrants.

      Are there positive or negative community impacts?

      Approval of the requested extension allows ICANN staff to work with the current operator to conclude the retirement of .AN domain. It demonstrates the IANA Functions Department's diligence in fulfilling its obligations while working with the community to consider their needs where appropriate.

      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 .AN retirement date extension 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?

      Granting the requested extension date helps maintain the security and stability of the .AN domain name while ICANN works with the operator to remove the domain name from the DNS Root Zone.

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

    5. Registrars Stakeholder Group Charter Amendments

      Whereas, the Registrars Stakeholder Group (RrSG) of the GNSO has proposed a series of amendments to its governing Charter document.

      Whereas, the RrSG, ICANN staff, and the Structural Improvements Committee (SIC) have completed all requirements associated with the Board Process For Amending GNSO Stakeholder Group and Constituency Charters.

      Resolved (2014.10.16.07), the ICANN Board approves the Registrars Stakeholder Group Charter Amendments, and directs the staff to provide access to the new governing document on the appropriate web pages for the group.

      Rationale for Resolution 2014.10.16.07

      The ICANN Bylaws (Article X, Section 5.3) state, "Each Stakeholder Group shall maintain recognition with the ICANN Board." The Board has interpreted this language to require that the ICANN Board formally approve any amendments to the governing documents of Stakeholder Groups (SG) and/or Constituencies in the Generic Names Supporting Organization (GNSO).

      In September 2013, the Board established a Process For Amending GNSO Stakeholder Group and Constituency Charters (Process) to provide a streamlined methodology for compliance with the Bylaws requirement.

      The GNSO Registrars Stakeholder Group (RrSG), ICANN Staff, and the Structural Improvements Committee (SIC) completed all steps identified in the Process including a determination that the proposed charter amendments will not raise any fiscal or liability concerns for the ICANN organization and publication of the amendments for community review and comment (no objections received).

      There is no anticipated impact from this decision on the security, stability and resiliency of the domain name system as a result of this decision.

    6. Thank You to Community Members

      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, the following members of the At-Large Community are concluding their terms of service:

      • Rinalia Abdul Rahim – At-Large IDN Working Group Co-Chair
      • Fouad Bajwa – APRALO Vice-Chair
      • Olivier Crépin-Leblond – ALAC Chair
      • Alan Greenberg – ALAC Liaison to the GNSO
      • Philip Johnson – AFRALO Secretariat
      • Evan Leibovitch – ALAC Vice Chair (NARALO)
      • Glenn McKnight – NARALO Secretariat
      • Jean-Jacques Subrenat – ALAC Member (EURALO, Nominating Committee Appointee)
      • Dev Anand Teelucksingh – ALAC Member (LACRALO)

      Resolved (2014.10.16.08), Rinalia Abdul Rahim, Fouad Bajwa, Olivier Crépin-Leblond, Alan Greenberg, Philip Johnson, Evan Leibovitch, Glenn McKnight, Jean-Jacques Subrenat, and Dev Anand Teelucksingh have earned the deep appreciation of the Board for their terms of service, and the Board wishes them well in their future endeavors within the ICANN community and beyond.

      Whereas, the following Address Supporting Organization (ASO) Address Council member (AC) is concluding his term of service:

      • Naresh Ajawani – ASO AC Member

      Resolved (2014.10.16.09), Naresh Ajawani has earned the deep appreciation of the Board for his terms of service, and the Board wishes him well in his future endeavors within the ICANN community and beyond.

      Whereas, the following members of the Country Code Names Supporting Organization (ccNSO) Council are concluding their terms of service:

      • Keith Davidson – Framework of Interpretation Working Group Chair
      • Hong Xue – ccNSO Councilor

      Resolved (2014.10.16.10), Keith Davidson and Hong Xue have earned the deep appreciation of the Board for their terms of service, and the Board wishes them well in their future endeavors within the ICANN community and beyond.

      Whereas, the following members of the Generic Names Supporting Organization (GNSO) are concluding their terms of service:

      • John Berard – GNSO Councilor (Commercial Business Users Constituency)
      • Ching Chiao – GNSO Councilor (Registries Stakeholder Group)
      • Jeffrey Eckhaus – Registrars Stakeholder Group Vice Chair
      • Maria Farrell – GNSO Councilor (Non-Commercial Users Constituency)
      • Magaly Pazello – GNSO Councilor (Non-Commercial Users Constituency)
      • Petter Rindforth – GNSO Councilor (Intellectual Property Interests Constituency)
      • Klaus Stoll – GNSO Councilor (Not-for-Profit Operational Concerns Constituency)
      • Jennifer Wolfe – GNSO Councilor (Nominating Committee Appointee)

      Resolved (2014.10.16.11), John Berard, Ching Chiao, Jeffrey Eckhaus, Maria Farrell, Magaly Pazello, Petter Rindforth, Klaus Stoll, and Jennifer Wolfe, have earned the deep appreciation of the Board for their terms of service, and the Board wishes them well in their future endeavors within the ICANN community and beyond.

      Whereas, the following members of the Nominating Committee (NomCom) are concluding their terms of service:

      • Ron Andruff – Delegate of the Commercial and Business Users Constituency
      • Veronica Cretu – Delegate of the At-Large Advisory Committee
      • William Manning – Delegate of the RSSAC
      • John McElwaine – Delegate of the Intellectual Property Constituency
      • Russ Mundy – Delegate of the IAB for IETF
      • Vanda Scartezini – Delegate of the At-Large Advisory Committee

      Resolved (2014.10.16.12), Ron Andruff, Veronica Cretu, William Manning, John McElwaine, Russ Mundy, and Vanda Scartezini have earned the deep appreciation of the Board for their terms of service, and the Board wishes them well in their future endeavors within the ICANN community and beyond.

    7. Thank You to Sponsors of ICANN 51 Meeting

      The Board wishes to thank the following sponsors: Verisign, Inc., Public Interest Registry, Afilias Limited, PDR Solutions FZC, Community.Asia, Neustar, Freenom, China Internet Network Information Center, .GLOBAL, .CLUB Domains, CentralNic, Brandma.Co, NCC Group, Trademark Clearinghouse, Hu Yi Global Information Resources (Holding) Company . HongKong Limited, Uniregistry Corp., ZA Central Registry, Minds + Machines Group, Iron Mountain, Inc., INOC, Radix FZC, and ICANNWIKI.

    8. Thank You to Interpreters, Staff, Event and Hotel Teams of ICANN 51 Meeting

      The Board expresses its deepest appreciation to the scribes, interpreters, audiovisual team, technical teams, and 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 Grand Hyatt Century Plaza Hotel, for providing a wonderful facility to hold this event. Special thanks are extended to Kim Aragon, Associate Director of Event Planning and Susie Schultz, International Sales Manager.

  2. Main Agenda:

    1. Thank You to the 2014 Nominating Committee

      Whereas, ICANN appointed Cheryl Langdon-Orr as Chair of the 2014 Nominating Committee, Stéphane Van Gelder as Chair-Elect of the 2014 Nominating Committee, and Yrjö Länsipuro as Associate Chair.

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

      Resolved (2014.10.16.13), the ICANN Board expresses its deep appreciation to Cheryl Langdon-Orr, Stéphane Van Gelder, Yrjö Lansipuro and all of the members of the 2014 Nominating Committee (including Ron Andruff, Satish Babu, John Berryhill, Alain Bidron, Don Blumenthal, Veronica Cretu, Sarah B. Deutsch, Robert Guerra, Hans Petter Holen, Louis Houle, Juhani Juselius, Brenden Kuerbis, Bill Manning, John McElwaine, Russ Mundy, Vanda Scartezini and Fatimata Seye Sylla) for their dedication, hard work and successful efforts.

    2. Introduction of Two-character Domain Names in the New gTLD Namespace

      Whereas, on 4 December 2006, the ICANN Registry Services Technical Evaluation Panel (RSTEP), determined that the proposed release of two-character Second Level Domain names (SLDs) in the .name gTLD did not create a reasonable risk of a meaningful adverse effect on security and stability.

      Whereas, Specification 5, section 2 of the New gTLD Registry Agreement provides that two-character labels "shall be withheld from registration or allocated to Registry Operator at the second level. Such labels may not be activated in the DNS, and may not be released for registration to any person or entity other than Registry Operator, provided that such two-character label strings may be released to the extent that Registry Operator reaches agreement with the related government and country-code manager of the string as specified in the ISO 3166-1 alpha-2 standard. The Registry Operator may also propose the release of these reservations based on its implementation of measures to avoid confusion with the corresponding country codes, subject to approval by ICANN".

      Whereas, since 18 January 2014, Registry Operators representing 207 new gTLDs have submitted Registry Services Evaluation Policy (RSEP) requests for the implementation of a new Registry Service consisting in the release of various sets of two-character labels.

      Whereas, for each RSEP request, ICANN made a preliminary determination that such proposed Registry Services did not raise significant Security, Stability or Competition Issues (as those terms are defined in the RSEP).

      Whereas, the Governmental Advisory Committee (GAC) indicated that some of its members raised concerns about the release of two-character domain names that are letter/letter combinations, and the GAC therefore intends to consider the matter during ICANN 51 in Los Angeles.

      Whereas, in the GAC's Los Angeles Communiqué [PDF, 127 KB] (15 October 2014), the GAC noted it was "not in a position to offer consensus advice on the use of two-character second level domain names in new gTLD operations, including those combinations of letters that are also on the ISO 3166-1 alpha 2 list." The GAC also noted that, "[i]n considering these RSEP requests, and consistent with the Applicant Guidebook, the GAC considers that the public comment period is an important transparency mechanism, and in addition asks that relevant governments be alerted by ICANN about these requests as they arise."

      Resolved (2014.10.16.14), the proposed registry service for the release of two-character domains in the gTLD namespace does not create a reasonable risk of a meaningful adverse effect on security and stability, and the Board authorizes the President and CEO, or his designee(s), to develop and implement an efficient procedure for the release of two-character domains currently required to be reserved in the New gTLD Registry Agreement, taking into account the GAC's advice in the Los Angeles Communiqué.

      Rationale for Resolution 2014.10.16.14

      Why is the Board addressing the issue?

      Section 2 of Specification 5 (Schedule of Reserved Names) of the New gTLD Registry Agreement addresses reservations of two-character labels as follows:

      All two-character ASCII labels shall be withheld from registration or allocated to Registry Operator at the second level within the TLD. Such labels may not be activated in the DNS, and may not be released for registration to any person or entity other than Registry Operator, provided that such two-character label strings may be released to the extent that Registry Operator reaches agreement with the related government and country-code manager of the string as specified in the ISO 3166-1 alpha-2 standard. The Registry Operator may also propose the release of these reservations based on its implementation of measures to avoid confusion with the corresponding country codes, subject to approval by ICANN.

      In January 2014, New gTLD Registry Operators began submitting requests to ICANN through the Registry Services Evaluation Policy (RSEP) process proposing to implement a new registry service to release certain two-character domain names required to be reserved by the New gTLD Registry Agreement. The implementation of the proposals would require an amendment to the Exhibit A of the respective Registry Agreements. The proposed amendments to implement the new registry service were the subject of public comment periods over the past several months. In total, ICANN has posted 28 RSEP proposals and amendments, which concern a total of 203 New gTLDs. ICANN continues to receive additional RSEP requests on a weekly basis for the same Registry Service.

      Pursuant to Section 2.4.D of the RSEP and the RSEP Implementation Notes, if the implementation of a proposed service requires a material change to the Registry Agreement, the preliminary determination will be referred to the ICANN Board for consideration.

      What is the proposal being considered?

      The Board is taking action at this time to direct the President and CEO to develop and implement an efficient process to permit the release of two-characters names in New gTLDs, taking into account the GAC's advice in the Los Angeles Communiqué.

      Which stakeholders or others were consulted?

      As of 24 September 2014, ICANN staff initiated five (5) public comment forums to obtain feedback from the community on the amendments to implement the proposed new registry service: 12 June 2014 <https://www.icann.org/public-comments/two-char-new-gtld-2014-06-12-en>; 8 July 2014 <https://www.icann.org/public-comments/two-char-new-gtld-2014-07-08-en>; 23 July 2014 <https://www.icann.org/public-comments/two-char-new-gtld-2014-07-23-en>; 19 August 2014 <https://www.icann.org/public-comments/two-char-new-gtld-2014-08-19-en>; and 12 September 2014 <https://www.icann.org/public-comments/two-char-new-gtld-2014-09-12-en>. Various members of the community submitted comments, including the At-Large Advisory Committee (ALAC) and registry operators.

      In addition, ICANN notified the GAC when each request from a registry operator was posted for public comment.

      What concerns or issues were raised by the community?

      There were several comments received during the public comment period indicating a series of arguments in favor of, or in opposition to, the general release of certain two-character names in the new gTLD namespace. The majority of the comments received were in favor for the release of the two character domain names.

      The arguments made in opposition to the release of the two character domain names expressed two general concerns. The first concern is related to the general recognition and associated use of the two character domain names leading to user confusion or abuse. The second concern is how to specifically protect ccTLDs when country and territory names are newly formed.

      Public comments received so far are overwhelmingly in favor of the introduction of two-character domain names in the new gTLD namespace. The arguments made in favor to the release of the two-character domain names were as follows:

      • The introduction of two character domain names would increase competition since the current restrictions hinder competition, in particular for the New gTLDs which are competing with legacy TLDs (delegated prior to the 2012 New gTLD application round) who are allowed to offer such registrations. The current restrictions to the New gTLD Registry Operators create a discriminatory situation which is contrary to the ICANN Bylaws Article II, Section 3 which provide for Non-Discriminatory Treatment of ICANN stakeholders.
      • The introduction of two-character domain names poses a limited risk of confusion, or no risk at all, as demonstrated by prior use of two character domain names in existing TLDs.
      • The release of certain types of two character domain names to include at least one digit or number, would not cause concern and may be considered for release.
      • The release of two-character domain names would provide opportunities for companies and brands to have tailored segmented domain names to connect with the public as well as provide localized content, thus expanding consumer choice and driving economic growth, in particular in developing countries.
      • The proposed registry service does not conflict with the Rights Protection Mechanisms (RPM) requirements document.
      • There is uniform precedent regarding the release of two-character domain name in the history of relevant RSEP requests.
      • The release of country codes and names is allowed by the Applicant Guidebook.

      The GAC has also raised some concerns about the release of certain two-character domain names (i.e. letter/letter combinations). In its 27 March 2014 Singapore Communiqué, the GAC discussed the Brand Registry Group proposal for a streamlined process under an addendum to the Registry Agreement for the approval of country names and two letter and character codes at the second level. The GAC stated, "While the GAC has no major concerns about brand owners seeking approval for such names, but that this approval should be done directly with the countries concerned rather than through a GAC level operational process." The GAC reported that individual GAC members could assist with proposals relevant to their particular country if requested. The GAC suggested that consideration be given to establishing a register of countries that do not require individual requests to be made.

      Subsequently, in its Los Angeles Communiqué, the GAC noted it was "not in a position to offer consensus advice on the use of two-character second level domain names in new gTLD operations, including those combinations of letters that are also on the ISO 3166-1 alpha 2 list." The GAC also noted that, "[i]n considering these RSEP requests, and consistent with the Applicant Guidebook, the GAC considers that the public comment period is an important transparency mechanism, and in addition asks that relevant governments be alerted by ICANN about these requests as they arise." The Board's action today takes into account the GAC's input on the release of two-character domains.

      What significant materials did the Board review? What factors did the Board find to be significant?

      The Board reviewed several materials and also considered several significant factors during its deliberations about whether or not to approve the request. The significant materials and factors that the Board considered as part of its deliberations, included, but are not limited to the following:

      Are there positive or negative community impacts? Are there fiscal impacts or ramifications on ICANN (strategic plan, operating plan, budget); the community, and/or public? Are there any security, stability or resiliency issues relating to the DNS?

      The overall impact on the community is anticipated to be positive as new opportunities for diversification and competition in the gTLD namespace are created, while no specific risk of user confusion has been identified.

      The eventual implementation of this Registry Service may have a fiscal impact on ICANN, the community or the public, as there may be additional costs associated with the broader implications of this Registry Service.

      As determined by the ICANN Registry Services Technical Evaluation Panel in a 4 December 2006 report on proposed release of two-character domains in the .name gTLD, such a service does not create a reasonable risk of a meaningful adverse effect on security and stability.

      Is this either a defined policy process within ICANN's Supporting Organization or ICANN's Organizational Administrative Function decision requiring public comment or not requiring public comment?

      The Registry Services Evaluation Policy is an ICANN consensus policy, effective as of 15 August 2006. Consistent with the policy, ICANN posted the Registry Agreement amendments for public comment as the implementation of the proposed service required what was then considered a material change to the Registry Agreement. Following today's resolution, future RSEP proposals requesting the release of two-characters names composed letter/number or number/number combinations will not be considered as requiring a material change to the Registry Agreement.

    3. ICANN Strategic Plan for fiscal years 2016-2020

      Whereas, ICANN's Strategic Plan for fiscal years 2016 – 2020 is the result of an extensive, collaborative, bottom-up, multistakeholder and multilingual process that began in April 2013 online and at the ICANN meeting in Beijing (and is detailed online).

      Whereas, the Strategic Plan provides a new ICANN Vision, reiterates ICANN's existing Mission, and describes five Strategic Objectives, each with Strategic Goals, Key Success Factors, and Strategic Risks.

      Whereas, to compliment the Strategic Plan, a Five-Year Operating Plan provides—for each Strategic Objective and Goal—portfolios of ICANN activities, key operational success factors, operational risks, key performance indicators, key dependencies, and phasing over five years (at the Goal level), and together these plans will serve as a foundation for the annual operating plans and budgets.

      Resolved, (2014.10.16.15) that the ICANN Strategic Plan for fiscal years 2016 – 2020 is adopted, and ICANN's President and CEO is directed to take actions necessary to publish and execute the Plan.

      Rationale for Resolution 2014.10.16.15

      The Strategic Plan provides ICANN's Vision, restates ICANN's Mission, and sets forth five Strategic Objectives, each with Strategic Goals, Key Success Factors (Outcomes), and Strategic Risks. It will guide ICANN's activities in fiscal years 2016 through 2020 and inform ICANN's operating plans and budgets.

      To provide the public with more insight and advance ICANN's accountability and transparency, Measurements (Key Performance Indicators) and high-level, five-year phasing have been expanded upon in a Five-Year Operating Plan that compliments the Strategic Plan. A new element of ICANN's planning process, the Five-Year Operating Plan details—for each Strategic Objective and Goal—portfolios of ICANN activities, key operational success factors (outcomes), risks, key performance indicators (measurements), key dependencies, and phasing over five years (at the Goal level).

      Beginning with fiscal year 2016, the Strategic Plan–along with the Five-Year Operating Plan–will inform the annual operating plans and budgets. The annual operating plans and budgets will address the resource requirements of the strategies, as well as impact on the security, stability and resiliency of the DNS, and any necessary risk mitigation actions.

      The progress of work, accomplishments toward goals and effectiveness of strategies will be managed and reported through ICANN's managements systems, including through a set of key success factors and key performance indicators. These will inform an annual planning check to validate that the organization is on-track, or that adjustments are needed.

      ICANN's Strategic Plan is the result of an extensive, collaborative, bottom-up, multistakeholder, and multilingual process that began in April 2013 online and at the ICANN meeting in Beijing. ICANN has sought extensive public input on its key challenges and opportunities and on strategic areas highlighted by ICANN's Board. Public comments, and community discussions (detailed here) involving ICANN's Supporting Organizations, Stakeholder Groups, Constituencies, and Advisory Committees, have informed all elements of the Strategic Plan. Responses to all public comments received on the draft strategic plans and can be found here [PDF, 808 KB] and here [PDF, 414 KB]. The Strategic Plan also reflects work and input on related initiatives, such as the Security, Stability and Resiliency Framework, the Regional Engagement Strategies, and Strategy Panel strategic themes.

    4. Board Consideration of Recommendations from the Cross Community Working Group on Enhancing ICANN Accountability

      Whereas, the Board acknowledges that the community is acting quickly to convene a Cross Community Working Group on Enhancing ICANN Accountability.

      Whereas, the community input in evolving the Enhancing ICANN Accountability Process has been invaluable, and the Board looks forward to the receipt of recommendations that have broad community support and consensus.

      Whereas, the Board understands that questions remain regarding how the Board will address the consensus recommendations developed through the Cross Community Working Group on Enhancing ICANN Accountability.

      Resolved (2014.10.16.16), the Board commits to following the following principles when considering the Cross Community Working Group Recommendations on Enhancing ICANN Accountability and Governance:

      1. These principles apply to consensus-based recommendations from the Cross Community Working Group on Enhancing ICANN Accountability and Governance.
      2. If the Board believes it is not in the global public interest to implement a recommendation from the Cross Community Working Group on Enhancing ICANN Accountability and Governance (CCWG Recommendation), it must initiate a dialogue with the CCWG. A determination that it is not in the global public interest to implement a CCWG Recommendation requires a 2/3 majority of the Board.
      3. The Board must provide detailed rationale to accompany the initiation of dialogue. The Board shall agree with the CCWG the method (e.g., by teleconference, email or otherwise) by which the dialogue will occur. The discussions shall be held in good faith and in a timely and efficient manner, to find a mutually acceptable solution.
      4. The CCWG will have an opportunity to address the Board's concerns and report back to the Board on further deliberations regarding the Board's concerns. The CCWG shall discuss the Board's concerns within 30 days of the Board's initiation of the dialogue.
      5. If a recommendation is modified through the CCWG, it is returned back to the Board for further consideration. The CCWG is to provide detailed rationale on how the modification addresses the concerns raised by the Board.
      6. If, after modification, the Board still believes the CCWG Recommendation is not in the global public interest to implement the CCWG Recommendation, the Board may send the item back to the CCWG for further consideration, again requiring a 2/3 vote of the Board for that action. Detailed rationale for the Board's action is again required. In the event the Board determines not to accept a modification, then the Board shall not be entitled to set a solution on the issue addressed by the recommendation until such time as CCWG and the Board reach agreement.

      Rationale for Resolution 2014.10.16.16

      In response to the community's call for a review of ICANN's accountability in light of the changing historical relationship with the United States Government, ICANN agreed to move forward with a process on Enhancing ICANN Accountability. Now that there is agreement that the process will move forward through a Cross Community Working Group, the community requested closure on how the Board would handle recommendations arising out of the Cross Community Working Group, with a particular concern on the Board's ability to modify or discard recommendations with which it does not agree. Given the community adoption of a Cross Community Working Group model, which includes a Board liaison, the Board looks forward to the continued dialogue throughout the process with all participants to build the recommendations and the broad consensus that will underlie each of these recommendations.

      The Board heard the community concerns, and puts forward these principles to guide how the Board will consider the consensus recommendations arising from the Cross Community Working Group on Enhancing ICANN Accountability. These are modeled on the requirements for both the GNSO and ccNSO policy development processes, to acknowledge the broad-based contributions to the accountability work.

      The adoption of these principles do not have any financial nor resource implications on ICANN that can be identified at this time. There are no anticipated impacts to the security, stability or resiliency of the DNS as a result of this decision.

      This is an Organizational Administrative Function addressing public comments already received.

    5. Thank You to Olga Madruga-Forti for her service to the ICANN Board

      Whereas, Olga Madruga-Forti was appointed by the Nominating Committee to serve as a Member of the ICANN Board on 18 October 2012.

      Whereas, Olga concludes her term on the ICANN Board on 16 October 2014.

      Whereas, Olga has served as a member of the following Committees:

      • Audit Committee
      • Global Relations Committee
      • Governance Committee
      • New gTLD Program Committee

      Resolved (2014.10.16.17), Olga Madruga-Forti has earned the deep appreciation of the Board for her term of service, and the Board wishes her well in her future endeavors within the ICANN community and beyond.

    6. Thank You to Sébastien Bachollet for his service to the ICANN Board

      Whereas, Sébastien Bachollet was appointed by the At-Large Community to serve as a Member of the ICANN Board on 9 December 2010.

      Whereas, Sébastien concluded his term on the ICANN Board on 16 October 2014.

      Whereas, Sébastien served as a member of the following Committees and Working Groups:

      • Finance Committee
      • Structural Improvements Committee
      • Public and Stakeholder Engagement Committee
      • Meeting Strategy Working Group

      Resolved (2014.10.16.18), Sébastien Bachollet has earned the deep appreciation of the Board for his term of service, and the Board wishes him well in his future endeavors within the ICANN community and beyond.

    7. Thank You to Bill Graham for his service to the ICANN Board

      Whereas, Bill Graham was appointed to serve by the Generic Names Supporting Organization as a Member of the ICANN Board on 23 June 2011.

      Whereas, Bill concludes his term on the ICANN Board on 16 October 2014.

      Whereas, Bill has served as a member of the following Committees and Working Groups:

      • Audit Committee
      • Global Relations Committee
      • Governance Committee
      • IANA Committee
      • New gTLD Program Committee
      • Risk Committee
      • Structural Improvements Committee
      • Board-GAC Recommendation Implementation Working Group

      Resolved (2014.10.16.19), Bill Graham has earned the deep appreciation of the Board for his term of service, and the Board wishes him well in his future endeavors within the ICANN community and beyond.

    8. Thank You to Heather Dryden for her service to the ICANN Board

      Whereas, Heather Dryden was appointed to serve as GAC Liaison to the ICANN Board on 25 June 2010.

      Whereas, Heather concludes her term on the ICANN Board on 16 October 2014.

      Whereas, Heather has served as a liaison on the following Committees:

      • New gTLD Program Committee

      Resolved (2014.10.16.20), Heather Dryden has earned the deep appreciation of the Board for her term of service, and the Board wishes her well in her future endeavors within the ICANN community and beyond.

Published on 16 October 2014

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