Skip to main content
Resources

Approved Board Resolutions | Regular Meeting of the ICANN Board

  1. Main Agenda
    1. Appointment of 2015 Nominating Committee Chair and Chair-Elect
  2. Consent Agenda:
    1. Approval of Board Meeting Minutes
    2. Appointment of Benedict Addis to the Security & Stability Advisory Committee (SSAC)
    3. Thank You from the Security and Stability Advisory Committee (SSAC) to David Conrad
  3. Main Agenda:
    1. Registry Services Technical Evaluation Panel (RSTEP) Report on Public Interest Registry's Request to Implement Technical Bundling in .NGO and .ONG
    2. Planning for Future gTLD Application Rounds
    3. FY15 Operating Plan and Budget
    4. Final Draft of the ICANN Five-Year Strategic Plan (FY16-FY20)
    5. Acknowledgment of Second At-Large Summit Declaration
    6. AOB

 

  1. Main Agenda

    1. Appointment of 2015 Nominating Committee Chair and Chair-Elect

      Whereas, the BGC reviewed the Expressions of Interest from candidates for the 2014 Nominating Committee ("NomCom") Chair and Chair-Elect, considered the results of a 360-degree evaluation of the 2014 NomCom leadership, and evaluated response to questions posed by the BGC to each candidate.

      Whereas, the BGC has recommended that Stephane Van Gelder be appointed as the 2015 NomCom Chair.

      Resolved (2014.09.09.01), the Board hereby appoints Stephane Van Gelder as the 2015 Nominating Committee Chair.

      Rationale for Resolution 2014.09.09.01

      ICANN's Bylaws require the Board to appoint the Nominating Committee (NomCom) Chair and NomCom Chair-Elect. See Article VII, sections 2.1 and 2.2 at http://www.icann.org/en/general/bylaws.htm#VII. The Board has delegated the responsibility for recommending the NomCom Chair and Chair-Elect for Board approval to the Board Governance Committee. See BGC Charter at http://www.icann.org/en/committees/board-governance/charter.htm. The BGC twice posted a call for expressions of interest (EOI) (see (https://www.icann.org/news/announcement-2-2014-07-01-en), received and reviewed the received EOIs, oversaw a 360-degree evaluation of the 2014 NomCom leadership and plans to conduct interviews with some of the candidates before making its recommendation on the 2015 NomCom Chair-Elect. The Board has considered and agrees with the BGC's recommendation for the 2015 NomCom Chair and looks forward to the BGC's further recommendation for the 2015 NomCom Chair-Elect. The Board also would like to thank all who expressed interest in becoming part of the NomCom leadership.

      Appointing a NomCom Chair and Chair-Elect identified through a public EOI process positively affects the transparency and accountability of ICANN, as well as supports the public interest. Adopting the BGC's recommendation has no financial impact on ICANN that was not otherwise anticipated, and will not negatively impact the security, stability and resiliency of the domain name system.

  2. Consent Agenda:

    1. Approval of Board Meeting Minutes

      Resolved (2014.09.09.02), the Board approves the minutes of the 30 July 2014 Meeting of the ICANN Board.

    2. Appointment of Benedict Addis to the Security & Stability Advisory Committee (SSAC)

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

      Whereas, the SSAC Membership Committee, on behalf of the SSAC, requests that the Board should appoint Benedict Addis to the SSAC.

      Resolved (2014.09.09.03), that the Board appoints Benedict Addis to the SSAC.

      Rationale for Resolution 2014.09.09.03

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

      The SSAC's continued operation as a competent body is dependent on the accrual of talented subject matter experts who have consented to volunteer their time and energies to the execution of the SSAC mission. Benedict Addis is a technical officer in the Cyber and Forensics department of the Serious Organised Crime Agency (SOCA), a UK law enforcement body. He has a significant computer science and network security background, which is an integral part of his law enforcement responsibilities. He has been actively working on Internet abuse and Internet criminal activities for many years. Mr. Addis offers a valuable perspective to the SSAC regarding the intersection of government policy and law enforcement.

    3. Thank You from the Security and Stability Advisory Committee (SSAC) to David Conrad

      Whereas, the Board appointed David Conrad to the SSAC on 18 March 2011.

      Whereas, Mr. Conrad resigned from the SSAC on 01 August 2014.

      Whereas, ICANN wishes to acknowledge and thank Mr. Conrad for his service to the community by his membership on the SSAC.

      Resolved (2014.09.09.04), that David Conrad has earned the deep appreciation of the Board for his service to ICANN by his membership on the SSAC, and that the Board wishes Mr. Conrad well in all future endeavors.

      Rationale for Resolution 2014.09.09.04

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

  3. Main Agenda:

    1. Registry Services Technical Evaluation Panel (RSTEP) Report on Public Interest Registry's Request to Implement Technical Bundling in .NGO and .ONG

      Whereas, on 12 March 2014, Public Interest Registry (PIR) submitted a Registry Services Evaluation Policy (RSEP) request [PDF, 24 KB] to offer mandatory technical bundling of second level domain names for .NGO and .ONG under Exhibit-A of each respective Registry Agreement.

      Whereas, on 21 May 2014, ICANN staff posted the RSEP request for public information and conducted its review of the request under the RSEP.

      Whereas, on 4 June 2014, ICANN staff's preliminary determination did not identify any significant competition issues. Separately, ICANN staff determined that the proposed registry service might raise significant stability or security issues, and informed [PDF, 320 KB] PIR of the need to refer the proposal to the Registry Services Technical Evaluation Panel (RSTEP) for further evaluation.

      Whereas, on 6 June 2014, ICANN referred PIR's RSEP request [PDF, 952 KB] to the RSTEP for further evaluation.

      Whereas, on 10 June 2014, ICANN posted PIR's RSEP request for public comment. The public comment concluded on 30 July 2014 and no public comments were received.

      Whereas, on 29 July 2014, the RSTEP report was posted for public comment. The public comment period concluded on 13 August 2014 and no public comments were received.

      Whereas, the RSTEP report concluded that from a technical evaluation perspective, the proposal does not create "a reasonable risk of a meaningful adverse effect on stability or security" as defined in the RSEP Policy related to the introduction of the registry service to support the mandatory technical bundling of second level domain names for .NGO and .ONG. The RSTEP report and staff also identified several potential technical and implementation questions associated with introducing the proposed new registry service to the DNS, including: implications of unbundling of .NGO and .ONG; potential registrant and/or end user confusion; equivalency issues being discussed within the context of IDN variants; and other operational concerns.

      Resolved (2014.09.09.05), the Board adopts the findings in the RSTEP report that PIR's proposal does not create "a reasonable risk of a meaningful adverse effect on stability or security", and approves PIR's request related to the introduction of the registry service to support the mandatory technical bundling of second level domain names for .NGO and .ONG.

      Resolved (2014.09.09.06), the Board authorizes the President and CEO, or his designee(s), to develop an amendment to implement the new registry service that takes into account and appropriately addresses the related outstanding technical and implementation questions.

      Rationale for Resolutions 2014.09.09.05 – 2014.09.09.06

      Why is the Board addressing the issue?

      On 12 March 2014, Public Interest Registry (PIR), the registry operator for .NGO and .ONG TLDs, submitted a request to provide a new registry service to offer support for mandatory technical bundling of second level domains for .NGO and .ONG. The proposal provides an explanation of the proposed technical bundling, the implementation of the EPP commands, the handling of DNSSEC, handling of second-level IDN variants, and WHOIS service. The proposal, which was submitted through the Registry Services Evaluation Policy (RSEP) process, was referred to the Registry Services Technical Evaluation Panel (RSTEP) and the RSEP proposal and RSTEP report were respectfully opened for public comment as required by the RSEP.

      Pursuant to Section 2.7 of the Registry Services Evaluation Policy (RSEP), the Board had 30 calendar days following receipt of the Registry Services Technical Evaluation Panel's report on 24 July 2014 to reach a decision. The Board could decide to 1) approve the request, 2) decline the request, or 3) defer the request for more information.

      What is the proposal being considered?

      The Board's action today is to take action on the report of the RSTEP, which evaluated the security and stability issues that may be associated with PIR's RSEP request to implement a new registry service to allow for mandatory "technical bundling" of second level domain names. PIR's request states, "[a] Technical Bundle is a set of two domain names in different TLDs, with identical second level labels for which the following parameters are shared:

      • Registrar Ownership
      • Registration and Expiry Dates
      • Registrant, Admin, Billing, and Technical Contacts
      • Name Server Association
      • Domain Status
      • Applicable grace periods (Add Grace Period, Renewal Grace Period, Auto-Renewal Grace Period, Transfer Grace Period, and Redemption Grace Period)
      • And for which at least the following parameters are unique: 'DS records as required based on RFC 5910.'"

      Which stakeholders or others were consulted?

      ICANN staff initiated a public comment forum from 10 June 2014 to 8 July 2014, inviting the community to provide feedback on PIR's RSEP proposal. During the public comment period, no comments were received. The final report of public comments can be found at: https://www.icann.org/public-comments/tech-bundling-2014-06-10-en.

      Additionally, the RSTEP review team was consulted to conduct a technical evaluation of the proposed registry service with respect to the likelihood and materiality of effects on security and stability, including whether the proposed registry service would create a reasonable risk of a meaningful adverse effect on security or stability. On 24 July 2014, the RSTEP report [PDF, 1.02 MB] was delivered to the ICANN community. ICANN initiated a public comment forum from 29 July 2014 to 5 August 2014, inviting the community to provide feedback on the RSTEP report. During the public comment period, no comments were received. The final report of public comments can be found at: https://www.icann.org/public-comments/rstep-technical-bundling-2014-07-29-en.

      What concerns or issues were raised by the community?

      No comments were provided for the RSEP proposal public comment period and the RSTEP report public comment period. However, the following technical and implementation issues were identified in the report of the RSTEP and by ICANN, which will need to be addressed by PIR [and/or the community] as part of the development of an amendment to the .NGO and .ONG Registry Agreements to implement the new registry service:

      • Analysis on the implications of "unbundling", that is if at some point in the future, the decision is made by PIR (or a successor registry) to remove the explicit association between .NGO and .ONG.

      • Implicit in the PIR proposal is an assertion that the contents of the .NGO and .ONG domains are "the same" (hence they are bundled together), however there is no mechanism by which this similarity can be enforced at all levels within the DNS, nor will applications such as web servers, mail servers, etc., understand that .NGO and .ONG domains should be treated identically without explicit configuration. This may lead to confusion both by client end users (e.g., "why does EXAMPLE.SOMETHING.ONG resolve when EXAMPLE.SOMETHING.NGO doesn't?") and by registrants ("why do I have to configure my web server to understand every third-level domain for both my second-level domain in .NGO and .ONG?"). Additional information is needed to address this potential for confusion within the PIR proposal;

      • The label similarity issue, specifically two labels are interpreted to be "the same" even though the strings that make up those labels are different, implicit in the PIR proposal, of which bundling is a potential solution, can and likely will be viewed as functionally equivalent to a component of the "IDN variant" issue. The community has been working on solutions to the variant issue for a number of years and full resolution has not yet been reached. It is possible the community working on the variant issue will view an acceptance of the technical bundling of .NGO and .ONG as an inappropriate "end run" around the policies and processes being established for the handling of variants; and

      • Technical bundling is being considered as a potential solution to address IDN variants, however the community has not developed a framework for its use nor approved this approach for implementation. Acceptance of the PIR proposal, and going forward without further community input on technical bundling, may raise concerns with IDN variant applicants and other interested community members who would want discussion on this topic for the implementation of IDN variant TLDs.

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

      The Board reviewed several materials in taking its action today. The Board 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?

      PIR identified that the benefits of introducing the mandatory technical bundling would be two-fold: (1) it eliminates the likelihood of public confusion that reasonably may ensue if different gTLD entities were able to register the same second-level domain and (2) it provides the registrant with a defensive registration to ensure that the gTLD is able to focus on its mission and outreach in a transparent and effective manner. However, additional information is needed to understand additional potential impacts on the community associated with the broader implications of this service when introduced to the DNS.

      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.

      The RSTEP report identified the technical evaluation of this proposed registry service with respect to the likelihood and materiality of effects on security and stability concludes that it does not create a reasonable risk of a meaningful adverse effect on security and stability.

      Various communities, in particular those interested in IDN variants, have been working on solutions to label similarity issues, of which the technical bundling of .NGO and .ONG is an example, for a number of years and full resolution has not yet been reached. It is possible those communities would be able to provide insights in resolving the similarity questions and consultations with those communities may be appropriate. The Board's action is in no way intended to create a precedent or a requirement for the treatment of IDN variant issues, and each circumstance must be evaluated on its own merits.

      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 on 29 July 2014, the RSTEP report was posted for public comment. The public comment period concluded on 13 August 2014 and no public comments were submitted. Additionally, on 10 June 2014, ICANN posted PIR's RSEP request for public comment. The public comment concluded on 30 July 2014 and no public comments were submitted.

    2. Planning for Future gTLD Application Rounds

      No resolution taken.

    3. FY15 Operating Plan and Budget

      Whereas, the draft FY15 Operating Plan and Budget was posted for public comment in accordance with the Bylaws on 8 May 2014, which was based upon community consultations, and consultations throughout ICANN staff and the Board Finance Committee, during the past fiscal year.

      Whereas, intervening activities and comments received from the public comment forum were taken into account to determine significant revisions to the 8 May 2014 draft FY15 Operating Plan and Budget.

      Whereas, in addition to the public comment forum, ICANN actively solicited community feedback and consultation with the ICANN community by other means, including online conference calls, meetings in Singapore and London, and email communications.

      Whereas, the Board Finance Committee has discussed, and guided staff on, the development of the FY15 Operating Plan and Budget at each of its recent regularly scheduled meetings.

      Whereas, the Board Finance Committee met on 19 August 2014 to discuss the final draft FY15 Operating Plan and Budget, and recommended that the Board adopts the FY15 Operating Plan and Budget.

      Whereas, per section 3.9 of the 2001, 2009 and 2013 Registrar Accreditation Agreements, respectively, the Board is to establish the Registrar Variable Accreditation Fees, which must be established in order to develop the annual budget.

      Whereas, the description of the Registrar fees, including the recommended Registrar Variable Accreditation Fees, for FY15 has been included in the FY15 Operating Plan and Budget.

      Resolved (2014.09.09.07), the Board adopts the FY15 Operating Plan and Budget and in doing so establishes the Variable Accreditation Fees (per registrar and transaction) as set forth in the FY15 Operating Plan and Budget.

      Rationale for Resolution 2014.09.09.07

      In accordance with Article XVI, Section 4 of the ICANN Bylaws, the Board is to adopt an annual budget and publish it on the ICANN website. On 8 May 2014, a draft the FY15 Operating Plan and Budget was posted for public comment. This version was based on numerous discussions with members of the Executive team, and extensive consultations with ICANN Supporting Organizations, Advisory Committees, and other stakeholder groups throughout the prior several months. Intervening activities, and comments received from the public comment forum resulted in some limited but significant revisions to the 8 May 2014 draft FY15 Operating Plan and Budget.

      All comments received in all manners were considered in developing the final version of the FY15 Operating Plan and Budget, and where feasible and appropriate have been adopted.

      In addition to the day-to-day operational requirements, the FY15 Operating Plan and Budget includes the FY15 new gTLD budget items and amounts allocated to various FY15 budget requests received from community leadership. The annual budget also discloses the impacts of the new gTLD program. Further, because the Registrar Variable Accreditation Fee is key to the development of the budget, the FY15 Operating Plan and Budget sets out and establishes those fees, which are consistent with recent years, and will be reviewed for approval by the Registrars.

      This FY15 Operating Plan and Budget will have a positive impact in that it provides a proper framework by which ICANN will be managed and operated. It also provides the basis for the organization to be held accountable in a transparent manner. This will have a fiscal impact on ICANN and the community as is intended. This should not have anything but a positive impact on the security, stability and resiliency of the domain name system (DNS) with respect to any funding that is dedicated to those aspects of the DNS.

    4. Final Draft of the ICANN Five-Year Strategic Plan (FY16-FY20)

      Item removed from Agenda.

    5. Acknowledgment of Second At-Large Summit Declaration

      Whereas, the Second At-Large Summit (ATLAS II) was held at the ICANN 50 meeting in London, United Kingdom in June 2014.

      Whereas, ATLAS II has built on the first summit organized in March 2009 at the ICANN 34 meeting in Mexico.

      Whereas, the Board has received the Final ATLAS II Declaration (https://community.icann.org/download/attachments/48338039/ATLAS-II-Declaration-with-appendix-RC9.pdf?version=1&modificationDate=1407420726000&api=v2 [PDF, 204 KB]).

      Whereas, the At-Large community continues the Summit's spirit of engagement and enthusiasm through a set of post-ATLAS II implementation activities.

      Resolved (2014.09.09.08), the Board acknowledges the Final ATLAS II Declaration, and extends its congratulations on the successful Summit held during ICANN 50 in London.

      Resolved (2014.09.09.09), the Board affirms the significance of the ATLAS II Summit and its outcomes as valuable input from the At-Large community of individual Internet users towards strengthening ICANN.

      Resolved (2014.09.09.10), the Board expresses its appreciation for the tremendous effort made by the At-Large community in delivering the At-Large Summit, the Final ATLAS II Declaration and the post-ATLAS II implementation activities.

      Resolved (2014.09.09.11), the Board looks forward to following up with the ALAC on any inputs that are provided to the Board resulting from the Final ATLAS II Declaration.

      Note: Three voting members of the Board abstained from voting on the resolutions. They stated for the record that they were supportive of the work resulting from the ATLAS, but wanted to draw attention to their encouragement for the Board to take future consideration of plans to develop the ATLAS into a regularly occurring event.

      Rationale for Resolutions 2014.09.09.08 – 2014.09.09.11

      The Second At-Large Summit (ATLAS II), which was made possible by the Board approving a special budget for the event, resulted in the production of the ATLAS II Declaration. This Declaration was sent to Steve Crocker by Olivier Crépin-Leblond on 7 August 2014.

      This document is the result of the work of approximately 150 At-Large Structures from 70 countries meeting face to face in London in June 2014.

      The Declaration includes the work of all of the 5 ATLAS II Thematic Working Groups:

      • Thematic Group 1 (TG1): Future of Multi-Stakeholder Models
      • Thematic Group 2 (TG2): The Globalization of ICANN
      • Thematic Group 3 (TG3): Global Internet: The User Perspective
      • Thematic Group 4 (TG4): ICANN Transparency and Accountability
      • Thematic Group 5 (TG5): At-Large Community Engagement in ICANN

      It contains 43 Recommendations both the ICANN Board, to ICANN and to the ALAC, referenced as R-1 to R-43. It also contains 10 Observations for the wider Internet Community, referenced as O-1 to O-10.

      The At-Large community is currently beginning work on the implementation of the Recommendations and Observations through a special Taskforce.

      The ALAC is seeking feedback on the Declaration from the wider ICANN community.

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

    6. AOB

      No resolution taken.

Published on 11 September 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."