Logo
ICANN
ICANN
Filtered Search

Are you sure you want to sign out from http://www.icann.org?

If you want to sign out from both http://www.icann.org and ICANN Account, click here.

Board Activities and Meetings

View records of actions and decisions made by the ICANN Board from recent activities and meetings.

Approved Board Resolutions | Regular Meeting of the ICANN Board 16 September 2018

  1. Consent Agenda:
    1. Approval of Minutes
    2. Security and Stability Advisory Committee Appointment
    3. Convening the First IANA Naming Function Review
    4. Renewal of .coop TLD Registry Agreement
    5. Appointment of 2019 Nominating Committee Chair and Chair-Elect
  2. Main Agenda:
    1. GAC Advice: Panama Communiqué (June 2018)
    2. Root Server Strategy
    3. Proceeding with KSK Rollover
    4. Further Consideration of the .AMAZON Applications
    5. AOB

 

  1. Consent Agenda:

    1. Approval of Minutes

      Resolved (2018.09.16.01), the Board approves the minutes of the 18 July and 21 August 2018 Meetings of the ICANN Board.

    2. Security and Stability Advisory Committee Appointment

      Whereas, the Security and Stability Advisory Committee (SSAC) reviews its membership and makes adjustments from time-to-time.

      Whereas, the SSAC Membership Committee, on behalf of the SSAC, requests that the Board appoint David Piscitello to the SSAC for a term beginning immediately upon approval of the Board and ending on 31 December 2020.

      Resolved (2018.09.16.02), the Board appoints David Piscitello to the SSAC for a term beginning immediately upon approval of the Board and ending on 31 December 2020.

      Rationale for Resolution 2018.09.16.02

      The SSAC is a diverse group of individuals whose expertise in specific subject matters enables the SSAC to fulfil 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 naming and address allocation systems.

      The SSAC's continued operation as a competent body is dependent on the accumulation of talented subject matter experts who have consented to volunteer their time and energies to the execution of the SSAC mission.

      Throughout his 40-year career, David has accumulated extensive experience in networking, security, Internet protocols and services. David served as a member of ICANN staff from 2005-2018, most recently in the role of Vice President Security and ICT Coordination, and supported the work of the SSAC for many years. He conducted research and wrote technical reports and advisories on behalf of the Committee, working in conjunction with then Chairman, Dr. Stephen Crocker. He has contributed positively to many SSAC discussions.

      This resolution is an organizational administrative function for which no public comment is required. The appointment of SSAC members is in the public interest and in furtherance of ICANN's mission as it contributes to the commitment of the ICANN to strengthen the security, stability, and resiliency of the DNS.

    3. Convening the First IANA Naming Function Review

      Whereas, the ICANN Bylaws require "The Board, or an appropriate committee thereof, shall cause periodic and/or special reviews (each such review, an "IFR") of PTI's performance of the IANA naming function against the contractual requirements set forth in the IANA Naming Function Contract and the IANA Naming Function SOW to be carried out by an IANA Function Review Team ("IFRT") established in accordance with Article 18 of the ICANN Bylaws."

      Whereas, Section 18.2.a of the ICANN Bylaws requires that the first Periodic IFR shall be convened no later than 1 October 2018.

      Whereas, Section 18.7 of the ICANN Bylaws specifies the composition of the IFRT and requires that the members and liaisons of the Review Team be appointed in accordance with the rules and procedures of the appointing organizations.

      Whereas, some of the appointing organizations have already appointed members and liaisons to the IFRT.

      Whereas, Section 18.8.c of the ICANN Bylaws requires that the appointing organizations for the IFRT members and liaisons work together to achieve a Review Team that is balanced for diversity (including functional, geographic and cultural) and skill, and seek to broaden the number of individuals participating across the various reviews; provided, that the Review Team includes members from each ICANN Geographic Region, and the ccNSO and Registries Stakeholder Group shall not appoint multiple members who are citizens of countries from the same ICANN Geographic Region.

      Whereas, Section 18.8.e of the ICANN Bylaws requires the ICANN Board to appoint an ICANN staff member to serve as a point of contact to facilitate formal lines of communication between the Review Team and ICANN.

      Whereas, Section 18.3 of the ICANN Bylaws specifies the scope and responsibilities of the Review Team.

      Whereas, Section 18.3.j of the ICANN Bylaws requires the Review Team to "identify process or other areas for improvement in the performance of the IANA naming function under the IANA Naming Function Contract and IANA Naming Function SOW and the performance of the CSC and the EC as it relates to oversight of PTI."

      Whereas, Section 18.11 of the ICANN Bylaws requires ICANN org to provide administrative and operational support necessary for the Review Team to carry out its responsibilities, including providing and facilitating remote participation in for all meetings.

      Resolved (2018.09.16.03), the Board hereby convenes the first IANA Naming Function Review and directs ICANN President and CEO or his designee(s) to provide administrative and operational support necessary for the Review Team to carry out its responsibilities, including providing and facilitating remote participation for all meetings.

      Resolved (2018.09.16.04), the Board asks that the remaining appointing organizations complete their processes to appoint members and liaisons. Further, the appointing organizations should coordinate to ensure that the composed Review Team meets diversity requirements in Section 18.8.c of the ICANN Bylaws.

      Resolved (2018.09.16.05), the IFR shall be conducted in accordance with the scope specified in Section 18.3 of the ICANN Bylaws.

      Resolved (2018.09.16.06), in fulfilment of the Board's obligation to appoint an ICANN org staff member to serve as a point of contact to facilitate formal lines of communication between the Review Team and ICANN org, the Board directs the ICANN President and CEO to designate the appropriate staff member to serve in that role.

      Rationale for Resolutions 2018.09.16.03 – 2018.09.16.06

      The Board is convening the first periodic IANA Naming Function Review ("IFR") to satisfy the requirement under Section 18.2 of the ICANN Bylaws that the first periodic IFR be convened no later than 1 October 2018. The IFR is a new accountability mechanism created as part of the IANA stewardship transition to ensure that PTI meets the needs and expectations of its naming customers by adhering to the contractual requirements set forth in the IANA Naming Function Contract and the IANA Naming Function Statement of Work [PDF, 626 KB].

      Steps have already been taken by appointing organizations to appoint members and liaisons to the Review Team. The Board asks that the remaining appointing organizations complete their processes to appoint members and liaisons so that the composed Review Team can begin its work. To ensure that the final composition of the Review Team meets the requirements of the ICANN Bylaws, the Board asks that the appointing organizations coordinate to finalize the composition of the Review Team in accordance with Section 18.8.c of the ICANN Bylaws. ICANN org has been directed to provide a staff member point of contact to support communication between the Review Team and ICANN org.

      The Board understands that the scope of the IFR is well-defined at Section 18.3 in the ICANN Bylaws. There is the possibility of overlap with the ongoing CSC Effectiveness Review, required at Section 17.3 of the Bylaws, which states: "The effectiveness of the CSC shall be reviewed two years after the first meeting of the CSC…The method of review will be determined by the ccNSO and GNSO." The CSC Effectiveness Review must commence by 6 October 2018, which is two years from when the Customer Standing Committee held its first meeting. The potential overlap is with the IFR Review Team scope item to "Identify process or other areas for improvement in the performance…of the CSC…as it relates to oversight of PTI." To ensure effective and efficient use of community resources, the Board encourages the IFR Review Team to consider as input into its work any future findings, recommendations, or methodology and criteria that the GNSO and ccNSO adopt as it relates to the review of the effectiveness of the Customer Standing Committee.

      The Board-approved FY19 ICANN annual operating plan and budget contains resources budgeted to support the IFR.

      This action is within ICANN's mission as it supports ICANN carrying out the part of its mission relating to coordination of the allocation and assignment of names in the root zone, and directly supports the public interest. The ICANN Board is taking this action in accordance with the requirements of the ICANN Bylaws. As such, no public comment period is needed to inform the Board's action.

    4. Renewal of .coop TLD Registry Agreement

      Whereas, the registry operator for .coop, DotCooperation LLC, has an existing agreement with ICANN org and it is set to expire on 22 November 2018.

      Whereas, ICANN org entered into negotiations with the registry operator to develop a proposed renewal agreement and commenced a public comment period from 11 June 2018 through 27 July 2018 on the proposed Renewal Registry Agreement for the .coop TLD, receiving comments from two organizations. A summary and analysis of the comments were provided to the Board.

      Whereas, the Board has reviewed the comments and determined that no revisions to the proposed .coop Renewal Registry Agreement are necessary after taking the comments into account.

      Whereas, the .coop Renewal Registry Agreement includes new provisions consistent with the comparable terms of the New gTLD Registry Agreement.

      Resolved (2018.09.16.07), the proposed .coop Renewal Registry Agreement is approved and the President and CEO, or his designee(s), is authorized to take such actions as appropriate to finalize and execute the Agreement.

      Rationale for Resolution 2018.09.16.07

      Why is the Board addressing the issue now?

      ICANN org and DotCooperation LLC entered into a Registry Agreement on 01 July 2007 for operation of the .coop top-level domain. The current .coop TLD Registry Agreement expires on 22 November 2018 and the registry operator has the right to a presumptive renewal with the existing agreement. The proposed Renewal Registry Agreement was posted for public comment between 11 June 2018 and 27 July 2018. At this time, the Board is approving the proposed .coop Renewal Registry Agreement for the continued operation of the .coop TLD by DotCooperation LLC.

      What is the proposal being considered?

      The proposed .coop TLD Renewal Registry Agreement is based on the current .coop TLD Registry Agreement with modifications agreed upon by ICANN org and DotCooperation LLC and includes certain provisions from the base New gTLD Registry Agreement.

      Which stakeholders or others were consulted?

      ICANN org conducted a public comment period on the proposed .coop Renewal Registry Agreement from 11 June 2018 and 27 July 2018. Additionally, ICANN org engaged in negotiations with the Registry Operator to agree to the terms to be included in the proposed .coop Renewal Registry Agreement that was posted for public comment.

      What concerns or issues were raised by the community?

      The public comment forum on the proposed .coop Renewal Registry Agreement closed on 27 July 2018, with ICANN org receiving two (2) comments. The comments can be summarized in the two categories listed below.

      1. The inclusion of new gTLD Rights Protection Mechanisms (RPMs) and safeguards such as Public Interest Commitments in legacy gTLDs registry agreement renewals: One commenter expressed support for the inclusion in the proposed renewal agreement of certain rights protection mechanisms, such as Uniform Rapid Suspension and Trademark Post-Delegation Dispute Resolution Procedure, and the inclusion of the Public Interest Commitments (i.e., safeguards) contained in the base gTLD Registry Agreement. Conversely, one commenter expressed concern over the inclusion of base gTLD rights protection mechanisms in legacy agreements. They suggested that these provisions should not be added as a result of contract negotiations but should be addressed through the GNSO policy development process ("PDP").
      2. The negotiation process for the proposed renewal of the .coop TLD Registry Agreement and legacy gTLD registry agreement negotiations in general: One commenter was encouraged that .coop is transitioning to the technical and operational specifications from the base gTLD Registry Agreement, but was disappointed that .COM and .NET have not modernized their terms as well. Another commenter reiterated objections to the negotiation process, stating that GDD staff "unilaterally establishes a new status quo for registry agreements" and substitutes "its (GDD) judgement instead of GNSO policy development" by exceeding its "powers and overrides safeguards intended to preserve transparency and inclusion with the multistakeholder community."

      What significant materials did the Board review?

      As part of its deliberations, the Board reviewed various materials, including, but not limited to, the following materials and documents:

      What factors has the Board found to be significant?

      The Board carefully considered the public comments received for the .coop Renewal Registry Agreement, along with the summary and analysis of those comments. The Board also considered the terms agreed upon by the Registry Operator as part of the bilateral negotiations with ICANN org.

      While the Board acknowledges the concerns expressed by some community members regarding the inclusion of the URS in the proposed Renewal Registry Agreement, the Board notes that the inclusion of the URS in the Renewal Registry Agreement is based on the negotiations between ICANN org and the Registry Operator, where Registry Operator expressed its interest in renewing its agreement based on the new gTLD Registry Agreement.

      The Board notes that the URS was recommended by the Implementation Recommendation Team (IRT) as a mandatory rights protection mechanism (RPM) for all new gTLDs. The GNSO was asked to provide its view on whether certain proposed rights protection mechanisms (which included the URS) were consistent with the GNSO's proposed policy on the introduction of New gTLDs and were the appropriate and effective option for achieving the GNSO's stated principles and objectives. The Special Trademark Issues Review Team (STI) considered this matter and concluded that "Use of the URS should be a required RPM for all New gTLDs." That is, the GNSO stated that the URS was not inconsistent with any of its existing policy recommendations.

      Although the URS was developed and refined through the process described here, including public review and discussion in the GNSO, it has not been adopted as a consensus policy and ICANN org has no ability to make it mandatory for any TLDs other than new gTLD applicants who applied during the 2012 New gTLD round.

      Accordingly, the Board's approval of the Renewal Registry Agreement is not a move to make the URS mandatory for any legacy TLDs, and it would be inappropriate to do so. In the case of .coop, inclusion of the URS was developed as part of the proposal in negotiations between the Registry Operator and ICANN org.

      Are there positive or negative community impacts?

      The Board's approval of the .coop Renewal Registry Agreement offers positive technical and operational benefits. For example, the .coop Renewal Registry Agreement includes the same Approved Services as included in the base gTLD Registry Agreement plus DNS Service - TLD Zone Contents, and Active Domain Directory. In addition, DotCooperation LLC will be required to follow the same public interest commitments for .coop as in the base gTLD Registry Agreement. Taking this action is in the public interest as it contributes to the commitment of ICANN org to strengthen the security, stability, and resiliency of the DNS.

      Are there fiscal impacts or ramifications on ICANN org (e.g. strategic plan, operating plan, budget), the community, and/or the public?

      There is no significant fiscal impact expected from the .coop Renewal Registry Agreement.

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

      The .coop Renewal Registry Agreement is not expected to create any security, stability, or resiliency issues related to the DNS. The .coop Renewal Registry Agreement includes terms intended to allow for swifter action in the event of certain threats to the security or stability of the DNS, as well as other technical benefits expected to provide consistency across all registries leading to a more predictable environment for end-users.

    5. Appointment of 2019 Nominating Committee Chair and Chair-Elect

      Whereas, the Board Governance Committee (BGC) reviewed the Expressions of Interest from candidates for the 2019 Nominating Committee (NomCom) Chair and Chair-Elect, considered the results of a peer review of the 2018 NomCom leadership, and conducted interviews of candidates.

      Whereas, the BGC has recommended that J. Damon Ashcraft be appointed as the 2019 NomCom Chair and Cheryl Ann Miller be appointed as the 2019 NomCom Chair-Elect.

      Resolved (2018.09.16.08), the Board hereby appoints J. Damon Ashcraft as the 2019 Nominating Committee Chair and Cheryl Ann Miller as the 2019 Nominating Committee Chair-Elect.

      Rationale for Resolution 2018.09.16.08

      ICANN's Bylaws require the Board to appoint the Nominating Committee (NomCom) Chair and NomCom Chair-Elect. See ICANN Bylaws, Article 8, Section 8.1. The Board has delegated the responsibility for recommending the NomCom Chair and Chair-Elect for Board approval to the Board Governance Committee (BGC). (See BGC Charter at http://www.icann.org/en/committees/board-governance/charter.htm.) The BGC posted a call for expressions of interest (EOI) on 13 June 2018 seeking EOIs by 2 July 2018 (see (https://www.icann.org/news/announcement-2-2018-06-13-en). The BGC received and reviewed several EOIs, reviewed peer review results of the 2018 NomCom leadership and conducted interviews with candidates before making its recommendations. The Board has considered and agrees with the BGC's recommendation for the 2019 NomCom Chair and 2019 NomCom Chair-Elect. The Board also would like to thank all who expressed interest in becoming part of the 2019 NomCom leadership.

      Appointing a NomCom Chair and Chair-Elect identified through a public EOI process, including interviews of the candidates, is in the public interest as it positively affects the transparency and accountability of ICANN. It is also fully consistent with ICANN's mission.

      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.

      This is an organizational administrative function not requiring public comment.

  2. Main Agenda:

    1. GAC Advice: Panama Communiqué (June 2018)

      Whereas, the Governmental Advisory Committee (GAC) met during the ICANN62 meeting in Panama City, Panama and issued advice to the ICANN Board in a communiqué [PDF, 576 KB] on 28 June 2018 ("Panama Communiqué").

      Whereas, the Panama Communiqué was the subject of an exchange between the Board and the GAC on 31 July 2018.

      Whereas, in a 27 July 2018 letter [PDF, 160 KB], the GNSO Council provided its feedback to the Board concerning advice in the Panama Communiqué relevant to generic top-level domains to inform the Board and the community of gTLD policy activities that may relate to advice provided by the GAC.

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

      Resolved (2018.09.16.09), the Board adopts the scorecard titled "GAC Advice – Panama Communiqué: Actions and Updates (16 September 2018)" [PDF, 294 KB] in response to items of GAC advice in the Panama Communiqué.

      Rationale for Resolution 2018.09.16.09

      Article 12, Section 12.2(a)(ix) of the ICANN Bylaws permits the GAC to "put issues to the Board directly, either by way of comment or prior advice, or by way of specifically recommending action or new policy development or revision to existing policies." In its Panama Communiqué (28 June 2018), the GAC issued advice to the Board on: General Data Protection Regulation (GDPR) and WHOIS, protection of names and acronyms of Intergovernmental Organizations (IGOs) in gTLDs, and two-character country codes at the second level. The GAC also provided a follow-up to previous advice on the deferred items regarding GDPR and WHOIS from the GAC San Juan Communiqué. The ICANN Bylaws require the Board to take into account the GAC's advice on public policy matters in the formulation and adoption of the polices. If the Board decides to take an action that is not consistent with the GAC advice, it must inform the GAC and state the reasons why it decided not to follow the advice. Any GAC advice approved by a full consensus of the GAC (as defined in the Bylaws) may only be rejected by a vote of no less than 60% of the Board, and the GAC and the Board will then try, in good faith and in a timely and efficient manner, to find a mutually acceptable solution.

      The Board is taking action today to accept all the items related to GDPR and WHOIS, and protections of IGOs and will defer consideration of the two (2) advice items related to two-character country codes at the second level, pending further discussion with the GAC. The Board will consider if further action is needed following these discussions. The Board's actions are described in the scorecard dated 16 September 2018 [PDF, 294 KB].

      In adopting its response to the GAC advice in the Panama Communiqué, the Board reviewed various materials, including, but not limited to, the following materials and documents:

      The adoption of the GAC advice as provided in the scorecard will have a positive impact on the community because it will assist with resolving the advice from the GAC concerning gTLDs and other matters. There are no foreseen fiscal impacts associated with the adoption of this resolution. Approval of the resolution will not impact security, stability or resiliency issues relating to the DNS. The Board's consideration of GAC advice is in the public interest, in recognition of the GAC's role in advising on matters of public policy, and is also consistent with ICANN's mission.

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

    2. Root Server Strategy

      Whereas, ICANN's present approach of deploying a large number of individual servers ("L-Singles") and a small number of larger, multi-server installations ("L-Clusters") has, to date, been an adequate defense against attacks on the Root Server System.

      Whereas, the Root Server System as currently deployed is seen by many within the technical community as at risk of being unable to keep pace with the growth in attack capacity and thus, is increasingly vulnerable to attack traffic whether launched by malicious entities or as a result of misconfiguration, misuse, or bugs.

      Whereas, a successful attack against the Root Server System would pose a serious risk to the security and stability of the DNS and pose a potentially existential risk to ICANN org, as the facilitator of the coordination of operation and evolution of the DNS root server system.

      Whereas, a comprehensive strategy intended to reduce the effects of the attacks against the Root Server System should take into consideration multiple approaches that leverage and enhance existing root server operator practices, integrate new technological advances and methodologies, as well as increase observation and monitoring of the system as a whole.

      Resolved (2018.09.16.10), that the Board instructs the ICANN org as the operator of the ICANN Managed Root Server/L-Root (IMRS) to work with the Community to finalize a strategy to reduce effects of attacks on the IMRS and, once finalized, directs the CEO to begin implementation of that strategy by developing a project plan with associated timelines and potential expenditures for subsequent Board review and approval.

      Rationale for Resolution 2018.09.16.10

      Architecturally, the root of the DNS namespace serves as a single point through which the lookup of any name within that namespace must pass at least once. This poses a risk of a "single point of failure" for the entire DNS. To date, this risk has been mitigated by "hardening" the infrastructure that provides name service for that root. This hardening has traditionally been implemented by expanding capacity, either by increasing bandwidth to name servers or via the use of "anycast" routing, deploying more name servers that answer questions for the root around the world.

      However, as a result of continued evolution of Internet technologies and facilities, in particular, the deployment of "Internet of Things" devices and increased capacity of networks all over the world, coupled with the unfortunate lack of sufficient security in those devices and networks, attackers have increasing power to cripple Internet infrastructure. Specifically, the growth in attack capacity risks outstripping the ability of the root server operator community to expand defensive capacity. While it remains necessary to continue to expand defensive capacity in the near-term, the long-term outlook for the traditional approach appears bleak.

      In addition, due to the lack of significant deployment of DNSSEC validation, responses from the Root Server System remains at risk from integrity attacks. Similarly, as a result of DNS messages assumed to be sent unencrypted, the users of the Root Server System (i.e., resolvers) are subject to confidentiality attacks. While these attacks are not necessarily new, the ever-increasing reliance on the DNS and hence, the Root Server System, suggests a new strategy to reduce the effect of these attacks against the Root Server System is required.

      To meet this requirement ICANN org has devised a comprehensive strategy for the ICANN managed root server that in addition to expanding existing traditional protective mechanisms looks to potentially leverage commercial cloud infrastructure and further decentralize root service, encourage deployment of DNSSEC validation, facilitate the development of privacy enhancements for the DNS, promote increased engagement with both the root server operator community as well as resolver operators, and enhance root system monitoring.

      This strategy should be finalized with the cooperation of the community, and in particular the RSSAC. Once finalized the implementation of the strategy should begin by developing a detailed project plan that includes timelines, milestones, and anticipated expenditures. Upon completion of the project plan, it should be provided to the Board for review and approval.

      The resolution to finalize the root strategy and develop the necessary detail project plan is anticipated to require personnel resources that are within the current FY19 budget, so no additional budgetary impact is anticipated.

      This decision is in the public interest and within ICANN's mission, as it supports ICANN org's work to ensure the stable and secure operation of the Internet's unique identifier systems.

    3. Proceeding with KSK Rollover

      Whereas, ICANN org committed to roll the KSK "after 5 years of operation" as documented in the "DNSSEC Practice Statement for the Root Zone KSK Operator".

      Whereas, ICANN org solicited a design team to prepare a full set of plans in order to implement the KSK roll.

      Whereas, as part of the implementation of that plan, ICANN org collected certain data that raised questions relating to the impact of the KSK rollover on end users.

      Whereas, ICANN org suspended the rollover on 27 September 2017 in order to understand the data being collected.

      Whereas, ICANN org, in consultation with members of the DNS technical community, gained further understanding of the data that had been collected.

      Whereas, ICANN org extrapolated the likely impact of the KSK roll.

      Whereas, ICANN org has updated the full plan documents and created "Updated Plan for Continuing the Root KSK Rollover".

      Whereas, the Board has received input from RSSAC, RZERC, and SSAC on the plan documents and that input indicates that those bodies found no reason to not continue with the updated plan for the KSK rollover and that portions of the community, in particular, those in the DNS technical community, have expressed concerns about the impact of further postponing the KSK rollover, specifically that: not moving forward with the KSK rollover would not be in keeping with the consensus of community expectations; is not supported by data obtained to date; could result in confusion about or loss of community attention to ICANN org's DNSSEC messaging; could encourage a belief that the KSK will never be rolled resulting in a risk of the current KSK getting embedded in hard-to-change system; and/or reduce confidence in DNSSEC as a trustworthy system.

      Whereas, the anticipated number of end users negatively impacted by the KSK rollover is significantly less than the community-specified threshold of 0.5% of end users, and the identification and remediation of that negative impact should be straightforward for those affected.

      Whereas, ICANN believes that the benefits to the community of proceeding with the rollover in a timely fashion outweigh the difficult to quantify risks.

      Resolved (2018.09.16.11), that the Board instructs ICANN org to proceed with the KSK rollover as described in the "Updated Plan for Continuing the Root KSK Rollover".

      Rationale for Resolution 2018.09.16.11

      The plan to roll the DNS root KSK was paused on 27 September 2017 due to unexpected data, specifically data received as a result of early implementations of RFC 8145, that raised questions related to how ready validating resolvers were for the roll that was scheduled to be implemented on 11 October 2017. ICANN org, along with others, analyzed that data and determined that there were indications that a relatively small percentage of resolvers were likely to be negatively impacted by the KSK rollover, however it was also established that the data was unsuitable for determining the number of end users that would be impacted.

      Based on that research, ICANN org asked the technical community to recommend a plan of action. While there was a minority dissent, the majority of input from that community was that ICANN org should proceed with the KSK rollover procedure in an orderly fashion.

      With that input, ICANN org created a summary plan, titled "Plan for Continuing the Root KSK Rollover", to roll the root KSK on 11 October 2018. ICANN org published the summary plan for community review on 1 February 2018 (see <https://www.icann.org/public-comments/ksk-rollover-restart-2018-02-01-en>). The time allowed for comments was extended beyond the normal 45 days to allow presentations about the plan at ICANN 61 in San Juan and IETF 101 in London and to request more community input at those fora.

      The consensus of the community response received by 2 April 2018 was in favor of the published plan, with some suggestions of additional outreach that ICANN org has already done. Based on that community response, ICANN org created the "Updated Plan for Continuing the Root KSK Rollover", revising the original KSK roll plan documents to show which steps had already been taken and which steps still needed to be taken using the revised dates. These plan documents are available at <https://www.icann.org/resources/pages/ksk-rollover-operational-plans>.

      The community input on the proposed plan came from a variety of Advisory Committees, Stakeholder Groups, organizations, and individuals. The Board requested explicit input from RSSAC, RZERC, and SSAC on the proposed plan. The following are responses to the Board's request:

      ICANN org considered all the findings in these three responses from Advisory Committees, particularly any findings that were hesitant about proceeding with the rollover. On balance, ICANN org interprets those findings as to indicate the risks of disruption to a very small number of Internet users who may never be prepared for a rollover as being less than the benefits of rolling the KSK now and regularly in the future. The attached reference material also lists the major objections to proceeding known to ICANN org along with responses to those objections.

      The KSK rollover is not anticipated to have any fiscal impact on ICANN org that has not already been accounted for in the budgeted resources necessary for ongoing support of the root KSK rollover.

      This decision is in the public interest and within ICANN's mission, as it supports ICANN org's work to ensure the stable and secure operation of the Internet's unique identifier systems.

      This is an Organizational Administrative Function that does not require public comment beyond what has already been requested.

    4. Further Consideration of the .AMAZON Applications

      Whereas, in 2012, Amazon EU S.à r.l. ("the Amazon corporation") applied for .AMAZON and two Internationalized Domain Name (IDN) versions of the word 'Amazon' ("the .AMAZON applications"). The .AMAZON applications were the subject of Governmental Advisory Committee (GAC) Early Warnings filed by the governments of Brazil and Peru (with the endorsement of Bolivia, Ecuador and Guyana), which put the Amazon corporation on notice that these governments had a public policy concern about the applied-for strings.

      Whereas, in July 2013, in the Durban Communiqué, the .AMAZON applications were the subject of consensus GAC Advice that stated that the .AMAZON applications should not proceed. On 14 May 2014, the New gTLD Program Committee accepted that advice and directed ICANN org to not proceed with the .AMAZON applications.

      Whereas, in October 2015, the Amazon corporation submitted a proposal to the Amazon Cooperation Treaty Organization (ACTO) member states in an attempt to come to a solution that could benefit both parties. This proposal was rejected.

      Whereas, in July 2017, the Amazon corporation prevailed in an Independent Review Process (IRP) filed in 2016. The IRP declaration recommended that the Board "promptly re-evaluate Amazon's applications" and "make an objective and independent judgment regarding whether there are, in fact, well-founded, merits-based public policy reasons for denying Amazon's applications."

      Whereas, on 29 October 2017, the Board asked the GAC for additional information regarding the GAC's advice on the .AMAZON applications. In its November 2017 Abu Dhabi Communiqué, the GAC advised the Board to "[c]ontinue facilitating negotiations between the Amazon Cooperation Treaty Organization's (ACTO) member states and the Amazon corporation with a view to reaching a mutually acceptable solution to allow for the use of .amazon as a top level domain name."

      Whereas, on 4 February 2018, the ICANN Board accepted the GAC advice and directed the ICANN org President and CEO "to facilitate negotiations between the Amazon Cooperation Treaty Organization's (ACTO) member states and the Amazon corporation."

      Whereas, the Amazon corporation presented the GAC and ACTO with a new proposal in October 2017. After the Amazon corporation submitted a further updated proposal in February 2018, the ACTO member states issued a statement 5 September 2018, declaring that "…[t]he Amazon countries have concluded that the proposal does not constitute an adequate basis to safeguard their immanent rights relating to the delegation of the '.amazon' TLD." The ACTO member states also stated the delegation of .AMAZON "requires consent of the Amazon countries" and that they "have the right to participate in the governance of the '.amazon' TLD."

      Whereas, the ACTO member states affirmed in October 2017 "…that the name Amazon, in any language, is part of the cultural heritage and identity of the Amazon countries, and that its use as a first level domain name, unless otherwise agreed by the Amazon countries, shall be reserved for the promotion of the interests and rights of the Amazon peoples and their inclusion in the information society."

      Whereas, the Board is sensitive to and appreciates the ACTO member states work to serve the public interest of the Amazon region, including the promotion and protection of the Amazon region's natural and cultural heritage.

      Resolved (2018.09.16.12), ICANN's President and CEO is directed to support the development of a solution for delegation of the strings represented in the .AMAZON applications that includes sharing the use of those top-level domains with the ACTO member states to support the cultural heritage of the countries in the Amazonian region.

      Resolved (2018.09.16.13), the Board directs the ICANN President and CEO or his designee(s), if possible, to provide a proposal to the Board, on the .AMAZON applications to allow the Board to take a decision on the delegation of the strings represented in the .AMAZON applications.

      Resolved (2018.09.16.14), the ICANN President and CEO or his designee(s), is directed to provide regular and detailed updates to the Board on the status of the .AMAZON applications.

      Rationale for Resolution 2018.09.16.12 – 2018.09.16.14

      This action supports the ICANN Board's consideration of the outcome of the Independent Review Process (IRP) filed by the Amazon corporation, as well as consideration of advice from the Governmental Advisory Committee as it relates to the .AMAZON applications. The Board is taking this action today to further the possibility of delegation of the .AMAZON applications as contemplated in the declaration of the IRP Panel, while recognizing the public policy issues raised through GAC advice on these applications.

      The Board takes this action today to support further work that could result in a solution that would allow the .AMAZON applications to move forward in a manner that would align with GAC advice and inputs on this topic.

      Background

      The Amazon corporation applied for .AMAZON and two Internationalized Domain Name (IDN) versions of the word 'Amazon' ("the .AMAZON applications"). In response to the .AMAZON applications, the governments of Brazil and Peru, with the endorsement of Bolivia, Ecuador and Guyana, submitted an Early Warning through the GAC, in accordance with the Applicant Guidebook, in which the concerned governments stated that: "[g]ranting exclusive rights to this specific gTLD to a private company would prevent the use of this domain for the purposes of public interest related to the protection, promotion and awareness raising on issues related to the Amazon biome. It would also hinder the possibility of use of this domain to congregate web pages related to the population inhabiting that geographical region." (Early Warning, available at https://gacweb.icann.org/display/gacweb/GAC+Early+Warnings?preview=/27131927/27197938/Amazon-BR-PE-58086.pdf [PDF, 79 KB].)

      After indicating in the Beijing Communiqué (April 2013) that the .AMAZON Applications required further GAC consideration, the GAC provided consensus advice (GAC Advice) to the ICANN Board in the Durban Communiqué (18 July 2013) that the Amazon Applications should not proceed (https://gacweb.icann.org/display/GACADV/2013-07-18-Obj-Amazon).

      On 14 May 2014, the Board (acting through the NGPC) accepted the GAC Advice and directed ICANN not to proceed with the Amazon Applications. (Resolution 2014.05.14.NG03, available at https://www.icann.org/resources/board-material/resolutions-new-gtld-2014-05-14-en#2.b.)

      In October 2015, the Amazon corporation submitted a proposal to the Amazon Cooperation Treaty Organization (ACTO) member states in an attempt to come to a solution that could benefit both parties. However, this proposal was rejected by the ACTO member states. Subsequently, the Amazon corporation began an Independent Review Process (IRP) in March 2016. The IRP ended in July 2017 with the IRP Panel finding in favor of the Amazon corporation. Following the outcome of the IRP, and acting on additional GAC advice, the ICANN Board tasked the ICANN org with supporting the Amazon corporation and ACTO member states in negotiating a solution.

      In October 2017, at ICANN60 in Abu Dhabi, the Amazon corporation presented to the GAC and ACTO member states a new proposal for a "practical compromise". In February 2018, based on further negotiations facilitated by the ICANN org, the Amazon corporation submitted a further updated proposal. On 5 September 2018, following review of the proposal by the ACTO Working Group, at a meeting of the Amazon Cooperation Council, the ACTO member states issued a statement declaring that "…[t]he Amazon countries have concluded that the proposal does not constitute an adequate basis to safeguard their immanent rights relating to the delegation of the '.amazon' TLD."

      The Amazon Corporation Proposals

      Since October 2015, the Amazon corporation has submitted various proposals to the ACTO member states in an effort to reach a mutually agreeable solution. The initial, October 2015 proposal was rejected by the ACTO member states, leading to the eventual IRP filed by the Amazon corporation. Following resolution of the IRP, in which the IRP Panel found in favor of the Amazon corporation, at the ICANN60 Abu Dhabi meeting, the Amazon corporation presented to the GAC a new proposal for a "practical compromise." In February 2018, following negotiations facilitated by the ICANN org between the Amazon corporation and ACTO member states, the Amazon corporation submitted a further updated proposal. According to this proposal, the Amazon corporation proposed four main courses of action:

      1. Help with the global visibility of the Amazonia region and its people as well as to protect their cultural heritage, by:
        1. establishing a mutually agreed upon second level domain to allow for visibility into the Amazon region. The Amazon corporation would bear the cost of the website up to $1,000,000 and for the duration of four years;
      2. Help to prevent the misuse of domain names associated with the Amazonia region and its peoples, by:
        1. agreeing to reserve a substantial number of second level domains in English, Spanish and Portuguese;
      3. Create a Steering Committee to oversee implementation of the agreement
      4. Engage in goodwill efforts by providing the ACTO member states credits for use of Amazon corporation services and products up to $5,000,000.

      Additionally, the Amazon corporation proposed helping the ACTO member states create an informational program to help publicize the benefits of the agreement.

      ACTO Concerns and Response to Amazon Proposals

      The ACTO member states concerns regarding the use of the .AMAZON TLD revolve around the ability for countries and individuals in the Amazon region to use the domain names for public interest purposes. In an Early Warning issued by the countries Brazil and Peru in November 2012, the two countries declared that:

      "Granting exclusive rights to this specific gTLD to a private company would prevent the use of this domain for the purposes of public interest related to the protection, promotion and awareness raising on issues related to the Amazon biome. It would also hinder the possibility of use of this domain to congregate web pages related to the population inhabiting that geographical region."

      In October 2017, following the IRP Panel Final Declaration on .AMAZON, the ACTO member states issued a statement, reaffirming:

      "…that the name Amazon, in any language, is part of the cultural heritage and identity of the Amazon countries, and that its use as a first level domain name, unless otherwise agreed by the Amazon countries, shall be reserved for the promotion of the interests and rights of the Amazon peoples and their inclusion in the information society."

      Finally, on 5 September 2018, following the updated proposal submitted by the Amazon corporation in February 2018, including after clarifications sought by the ACTO member states in understanding the proposal, the ACTO member states sent a letter to the Board stating that, with regard to the delegation of .AMAZON, that this "requires consent of the Amazon countries" and that they "have the right to participate in the governance of the '.amazon' TLD. Additionally, the ACTO member states declare that "the proposal does not constitute an adequate basis to safeguard their immanent rights relating to the delegation of the '.amazon' TLD."

      The member states do mention, however, that they are willing "to engage with the ICANN Board…with a view to safeguarding their rights as sovereign states."

      Items considered by the Board

      In taking this action, the Board considered:

      • The Amazon corporation's Proposals of 6 October 2015 and 7 February 2018;
      • The IRP Panel Declaration in .AMAZON Independent Review Process;
      • The Amazon corporation's October 2017 proposal to the GAC and ACTO member states;
      • The NGPC's 14 May 2014 action on the .AMAZON applications and the Board's 29 October 2017 and 4 February 2018 actions on the .AMAZON applications;
      • ACTO's 5 September 2018 letter and related annexes.

      Impacts

      This action is anticipated to have a small resource impact on ICANN org based upon the resources needed to meet the Board's direction. However, the use of resources towards finding an agreeable solution is preferable to addressing the potential impacts of continued impasse as it relates to delegation of the .AMAZON applications. This action is in support of ICANN's mission, in that it furthers the New gTLD Program and anticipated expansion of the DNS. It is also in the public interest in its balancing the core values of increasing competition in the DNS while recognizing governments' provision of public policy advice.

      This is an administrative function that does not require public comment.

    5. AOB

      No resolution taken.

Published on 18 September 2018

Related Documents