Skip to main content
Resources

Approved Board Resolutions | Special Meeting of the ICANN Board

  1. Consent Agenda:
    1. Approval of Minutes
  2. Main Agenda:
    1. Consideration of Reconsideration Request 18-8
    2. Reaffirming the Temporary Specification for gTLD Registration Data
    3. AOB

 

  1. Consent Agenda:

    1. Approval of Minutes

      Resolved (2018.11.06.01), the Board approves the minutes of the 16 September and 3 October 2018 Meetings of the ICANN Board.

  2. Main Agenda:

    1. Consideration of Reconsideration Request 18-8

      Whereas, Afilias Domains No. 3 Ltd. (Requestor) submitted Reconsideration Request 18-8 seeking reconsideration of ICANN organization's response to the Requestor's request for documents, pursuant to ICANN's Documentary Information Disclosure Policy (DIDP), relating to the .WEB contention set.

      Whereas, the Requestor claims that in declining to produce certain requested documents in the DIDP Response, ICANN org violated the DIDP and its Core Values and commitments established in the Bylaws concerning transparency and openness.

      Whereas, the Board Accountability Mechanisms Committee (BAMC) previously determined that Request 18-8 is sufficiently stated and sent the Request to the Ombudsman for review and consideration in accordance with Article 4, Section 4.2(j) and (k) of the ICANN Bylaws.

      Whereas, the Ombudsman recused himself from this matter pursuant to Article 4, Section 4.2(l)(iii) of the Bylaws.

      Whereas, the BAMC carefully considered the merits of Request 18-8 and all relevant materials and recommended that Request 18-8 be denied because ICANN org adhered to established policies and procedures in the DIDP Response; and ICANN org did not violate its commitments established in the Bylaws concerning transparency and openness.

      Whereas, the Requestor did not file a rebuttal to the BAMC Recommendation on Request 18-8 within the allotted time under Article 4, Section 4.2(q) of the Bylaws.

      Resolved (2018.11.06.02), the Board adopts the BAMC Recommendation on Request 18-8 [PDF, 211 KB].

      Rationale for Resolution 2018.11.06.02

      1. Brief Summary and Recommendation

        The full factual background is set forth in the BAMC Recommendation on Request 18-8 [PDF, 211 KB] (BAMC Recommendation), which the Board has reviewed and considered, and which is incorporated here.

        On 28 August 2018, the BAMC evaluated Request 18-8 and all relevant materials and recommended that the Board deny Request 18-8 because ICANN org adhered to established policies and procedures in the DIDP Response; and ICANN org did not violate its commitments established in the Bylaws concerning transparency and openness.

        Pursuant to Article 4, Section 4.2(q), the Requestor has 15 days from the receipt of the BAMC's Recommendation on Request 18-8 to submit a rebuttal. No rebuttal was filed by the 12 September 2018 deadline and none has been received to date.

        The Board has carefully considered the BAMC's Recommendation [PDF, 211 KB] and all relevant materials related to Request 18-8, and the Board agrees with the BAMC's Recommendation [PDF, 211 KB].

      2. Issue

        The issues are as follows:

        • Whether ICANN org complied with established ICANN policies in responding to the Second DIDP Request; and
        • Whether ICANN org complied with its Core Values and commitments established in the Bylaws concerning transparency and openness.
      3. Analysis and Rationale

        1. ICANN Org Adhered to Established Policies and Procedures in Responding to the DIDP Request.

          1. The Response to the DIDP Request Complies with Applicable Policies and Procedures.

            The Requestor's DIDP Request sought the disclosure of documents relating to the .WEB/.WEBS contention set. The Board notes that the Requestor does not challenge the applicability of the DIDP Defined Conditions of Nondisclosure (Nondisclosure Conditions) asserted in ICANN org's DIDP Response. Instead, the Requestor claims that ICANN org should have determined that the public interest outweighs the reasons for nondisclosure set forth in the Nondisclosure Conditions.1 The Board finds that this represents a substantive disagreement with ICANN org's discretionary determination, and not a challenge to the process by which ICANN org reached that conclusion. On that basis alone, reconsideration is not warranted. Nevertheless, the BAMC did review the DIDP Response at issue in Request 18-8 and, for the reasons discussed in the BAMC Recommendation, which are incorporated herein by reference, the BAMC concluded, and the Board agrees, that the DIDP Response complied with applicable policies and procedures, and that reconsideration is not warranted. (See BAMC Recommendation [PDF, 211 KB], Pgs. 15-17.)

            The Board agrees with the BAMC's determination that the ICANN org adhered to the "Process For Responding To ICANN's Documentary Information Disclosure Policy (DIDP) Requests" (DIDP Response Process) when it responded to the Requestor's DIDP Request.2 (See BAMC Recommendation [PDF, 211 KB], Pgs. 15-17.) That is, consistent with the DIDP Response Process, ICANN org responded individually to each of the five items requested (and their subparts) by providing links to the publicly available documents responsive to the requests. ICANN org also identified documents responsive to these items and determined that they were subject to the following Nondisclosure Conditions and thus not appropriate for disclosure. Notwithstanding the applicable Nondisclosure Conditions, ICANN org considered whether the public interest in disclosing the information outweighed the harm that may be caused by the disclosure and determined that there are no circumstances for which the public interest in disclosure outweighed that potential harm.3

          2. ICANN Org Adhered to Established Policy and Procedure in Finding That the Harm in Disclosing the Requested Documents That Are Subject to Nondisclosure Conditions Outweighs the Public's Interest in Disclosing the Information.

            The BAMC concluded, and the Board agrees, that ICANN org adhered to established policy and procedure in finding that the harm in disclosing the requested that are subject to the Nondisclosure Conditions outweighs the public's interest in disclosing the information.

            As noted above, the Requestor does not challenge the applicability of the Nondisclosure Conditions to the responsive documents to the DIDP Request. Instead, the Requestor claims that ICANN org should have concluded that the public interest in disclosing these documents outweighed the harm that may be caused by such disclosure.4 According to the Requestor, "there is a significant public interest in providing for a competitive market in the DNS that outweighs any harm in disclosure, especially given the proposed confidentiality agreement in the [DIDP Request]."5

            As an initial matter, the Board agrees with the BAMC's determination that the Requestor's proposal to enter into a confidentiality agreement to protect the information contained in the requested materials does not support reconsideration. Indeed, the concept of a confidentiality agreement for the disclosure of documents through the DIDP runs afoul of the DIDP itself, which is to make public documents concerning ICANN org's operations unless there is a compelling reason for confidentiality.6 Moreover, the Requestor's proposal asks ICANN org to treat the Requestor differently than other requestors, and to act in a manner that is contrary to what is set forth in the DIDP Response Process, which could be in contravention of ICANN's Bylaws. Further, by proposing that the documents be made available only to the Requestor's outside counsel via a "confidentiality agreement," it appears that the Requestor concedes that the requested information is not appropriate for public disclosure.

            With respect to the allegations set forth in Request 18-8 regarding Verisign's intentions and conduct in connection with the .WEB gTLD, the Board agrees with the BAMC's conclusion that the Requestor fails to provide any evidence or other support for its assertions. The Board further agrees that the Requestor fails to explain how its unsubstantiated claims concerning Verisign's alleged conduct demonstrate that ICANN org violated a policy or procedure when it responded to the Requestor's DIDP Request.

            The Board also agrees with the BAMC's finding that ICANN org did not violate the DIDP Response Process when it determined that the public interest does not outweigh the potential harm in the disclosure of the confidential and privileged documents. ICANN's Bylaws recognize that "[s]ituations may arise in which perfect fidelity to all Core Values simultaneously is not possible. Accordingly, in any situation where one Core Value must be balanced with another, potentially competing Core Value, the result of the balancing must serve a policy developed through the bottom-up multistakeholder process or otherwise best serve ICANN's Mission."7 The DIDP, which was developed through the multistakeholder process with significant community input, specifically permits ICANN org to balance applicable competing Core Values and commitments in any given situation. Here, ICANN org's commitment to promote competition in the DNS is in tension with its commitment to operate with efficiency and excellence, as well as ICANN org's commitment to reasonably balance the interests of different stakeholders, and to support the multistakeholder process. Pursuant to the DIDP, ICANN org may exercise its discretion to withhold materials under these circumstances without violating its commitment to promoting competition, which is what ICANN org did in the DIDP Response. Accordingly, reconsideration is not warranted. (See BAMC Recommendation [PDF, 211 KB], Pgs. 17 – 21.)

        2. ICANN Org Adhered to Its Commitments and Core Values in Responding to the DIDP Request.

          The Board agrees with the BAMC's determination that the DIDP Response did not violate ICANN org's commitments and Core Values. Neither the DIDP nor ICANN's commitments and Core Values supporting transparency and accountability obligates ICANN org to make public every document in its possession. As noted above, the DIDP sets forth Nondisclosure Conditions for which other commitments or Core Values may compete or conflict with the transparency commitment. These Nondisclosure Conditions represent areas, vetted through public comment, that the community has agreed are presumed not to be appropriate for public disclosure. The public interest balancing test in turn allows ICANN org to determine whether or not, under the specific circumstances, its commitment to transparency outweighs its other commitments and Core Values. Accordingly, without contravening its commitment to transparency, ICANN org may appropriately exercise its discretion, pursuant to the DIDP, to determine that certain documents are not appropriate for disclosure.

          As the Amazon EU S.A.R.L. Independent Review Process Panel noted in June 2017:

          [N]otwithstanding ICANN's transparency commitment, both ICANN's By-Laws and its Publication Practices recognize that there are situations where non-public information, e.g., internal staff communications relevant to the deliberative processes of ICANN . . . may contain information that is appropriately protected against disclosure.8

          As noted above, ICANN org's Bylaws address this need to balance competing interests such as transparency and confidentiality, noting that "in any situation where one Core Value must be balanced with another, potentially competing Core Value, the result of the balancing test must serve a policy developed through the bottom-up multistakeholder process or otherwise best serve ICANN's Mission."9

          The BAMC concluded, and the Board agrees, that ICANN org set forth the basis for its determination in each instance of nondisclosure in the DIDP Response, which are pre-defined in the DIDP; the Nondisclosure Conditions that ICANN identified, by definition, set forth compelling reasons for not disclosing the materials. (See BAMC Recommendation [PDF, 211 KB], Pgs. 22-23.) It is entirely within ICANN org's discretion to make this finding, and ICANN org may conclude as much without contravening its commitment to transparency. Accordingly, the Requestor's generalized invocations of ICANN org's commitments to transparency and openness do not support reconsideration.

          This action is within ICANN's Mission and is in the public interest as it is important to ensure that, in carrying out its Mission, ICANN is accountable to the community for operating within the Articles of Incorporation, Bylaws, and other established procedures, by having a process in place by which a person or entity materially affected by an action of the ICANN Board or Staff may request reconsideration of that action or inaction by the Board. Adopting the BAMC's Recommendation has no financial impact on ICANN and will not negatively impact the security, stability and resiliency of the domain name system.

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

    2. Reaffirming the Temporary Specification for gTLD Registration Data

      Whereas, on 17 May 2018, the Board adopted the Temporary Specification for gTLD Registration Data (the "Temporary Specification") to be effective 25 May 2018 for a 90-day period. The Temporary Specification establishes temporary requirements to allow ICANN and gTLD registry operators and registrars to continue to comply with existing ICANN contractual requirements and community-developed policies concerning gTLD registration data (including WHOIS) in light of the European Union's General Data Protection Regulation (GDPR).

      Whereas, on 21 August 2018, the Board reaffirmed the adoption of the Temporary Specification to be effective for an additional 90-day period beginning on 23 August 2018.

      Whereas, the Board adopted the Temporary Specification pursuant to the procedures in the Registry Agreement and Registrar Accreditation Agreement for adopting temporary policies. This procedure requires that "[i]f the period of time for which the Temporary Policy is adopted exceeds ninety (90) calendar days, the Board shall reaffirm its temporary adoption every ninety (90) calendar days for a total period not to exceed one (1) year, in order to maintain such Temporary Policy in effect until such time as it becomes a Consensus Policy".

      Resolved (2018.11.06.03), the Board reaffirms the Temporary Specification for gTLD Registration Data pursuant to the procedures in the Registry Agreement and Registrar Accreditation Agreement concerning the establishment of temporary policies. In reaffirming this Temporary Specification, the Board has determined that:

      1. The modifications in the Temporary Specification to existing requirements concerning the processing of personal data in registration data continue to be justified and immediate temporary establishment of the Temporary Specification continues to be necessary to maintain the stability or security of Registrar Services, Registry Services or the DNS or the Internet.
      2. The Temporary Specification is as narrowly tailored as feasible to achieve the objective to maintain the stability or security of Registrar Services, Registry Services or the DNS or the Internet.
      3. The Temporary Specification will be effective for an additional 90-day period beginning 21 November 2018.

      Resolved (2018.11.06.04), the Board reaffirms the Advisory Statement Concerning Adoption of the Temporary Specification for gTLD Registration Data [PDF, 510 KB], which sets forth its detailed explanation of its reasons for adopting the Temporary Specification and why the Board believes such Temporary Specification should receive the consensus support of Internet stakeholders.

      Rationale for Resolutions 2018.11.06.03 – 2018.11.06.04

      The European Union's General Data Protection Regulation (GDPR) went into effect on 25 May 2018. The GDPR is a set of rules adopted by the European Parliament, the European Council and the European Commission that impose new obligations on all companies and organizations that collect and maintain any "personal data" of residents of the European Union, as defined under EU data protection law. The GDPR impacts how personal data is collected, displayed and processed among participants in the gTLD domain name ecosystem (including registries and registrars) pursuant to ICANN contracts and policies.

      On 17 May 2018, the Board adopted the Temporary Specification for gTLD Registration Data ("Temporary Specification") to establish temporary requirements to allow ICANN and gTLD registry operators and registrars to continue to comply with existing ICANN contractual requirements and community-developed policies concerning gTLD registration data (including WHOIS) in relation to the GDPR. The Temporary Specification, which became effective on 25 May 2018, was adopted utilizing the procedure for temporary policies established in the Registry Agreement and the Registrar Accreditation Agreement.

      On 21 August 2018, the Board reaffirmed the Temporary Specification for an additional 90-day period beginning 23 August 2018.

      As required by the procedure in the Registrar Accreditation Agreement and Registry Agreements for adopting a temporary policy or specification, "[i]f the period of time for which the Temporary Policy is adopted exceeds ninety (90) calendar days, the Board shall reaffirm its temporary adoption every ninety (90) calendar days for a total period not to exceed one (1) year, in order to maintain such Temporary Policy in effect until such time as it becomes a Consensus Policy."

      Today, the Board is taking action to reconfirm the Temporary Specification for an additional 90 days as the temporary requirements continue to be justified in order to maintain the stability or security of registry services, registrar services or the DNS. When adopting the Temporary Specification, the Board provided an Advisory Statement [PDF, 510 KB] to provide a detailed explanation of its reasons for adopting the Temporary Specification and why the Board believes such Temporary Specification should receive the consensus support of Internet stakeholders. The Board reaffirms the Advisory Statement, which is incorporated by reference into the rationale to the Board's resolutions.

      As required when a temporary policy or specification is adopted, the Board took action to implement the consensus policy development process and consulted with the GNSO Council on potential paths forward for considering the development of a consensus policy on the issues within the Temporary Specification. The consensus policy development process must be concluded in a one-year time period. The Board takes note that the GNSO Council launched an Expedited Policy Development Process on the Temporary Specification, and the Working Group is continuing with its deliberations to develop proposed policy recommendations. The Board will continue to engage with the GNSO Council on this matter and reconfirms its commitment to provide the necessary support to the work of the Expedited Policy Development Process to meet the deadline (see 7 August 2018 letter from Cherine Chalaby to GNSO Council Chair: https://www.icann.org/en/system/files/correspondence/chalaby-to-forrest-et-al-07aug18-en.pdf [PDF, 269 KB]).

      The Board's action to reaffirm the Temporary Specification is consistent with ICANN's mission "[…] to ensure the stable and secure operation of the Internet's unique identifier systems […]". As one of ICANN's primary roles is to be responsible for the administration of the topmost levels of the Internet's identifiers, facilitating the ability to identify the holders of those identifiers is a core function of ICANN. The Board's action today will help serve the public interest and further the requirement in ICANN's Bylaws to "assess the effectiveness of the then current gTLD registry directory service and whether its implementation meets the legitimate needs of law enforcement, promoting consumer trust and safeguarding registrant data." [Bylaws Sec. 4.6(e)(ii)]

      Also, this action is expected to have an immediate impact on the continued security, stability or resiliency of the DNS, as it will assist in continuing to maintain WHOIS to the greatest extent possible while the community works to develop a consensus policy. Reaffirming the Temporary Specification is not expected to have a fiscal impact on ICANN organization beyond what was previously identified in the Board's rationale for resolutions 2018.05.17.01 – 2018.05.17.09. If the resource needs are greater than the amounts currently budgeted to perform work on WHOIS- and GDPR-related issues, the President and CEO will bring any additional resource needs to the Board Finance Committee for consideration, in line with existing fund request practices.

      This is an Organizational Administrative Function of the Board for which public comment is not required, however ICANN's approach to addressing compliance with ICANN policies and agreements concerning gTLD registration data in relation to the GDPR has been the subject of comments from the community over the past year (https://www.icann.org/dataprotectionprivacy).

    3. AOB

      No Resolutions taken.

Published on 8 November 2018


1 Reconsideration Request 18-8, § 6, at Pg. 9-11. While the Requestor summarily concludes that the Nondisclosure Conditions were "unreasonably and illegitimately appl[ied]" (see Reconsideration Request 18-8, § 6, Pg. 8), the Requestor does not explain how that is so. Without more, the Requestor's unsupported assertions do not support reconsideration.

2 See DIDP Response Process, https://www.icann.org/en/system/files/files/didp-response-process-29oct13-en.pdf [PDF, 59 KB].

3 Id. at Pg. 14.

4 Reconsideration Request 18-8, § 6, at Pgs. 8-11.

5 Reconsideration Request 18-8, § 6, Pg. 9.

6 See DIDP.

7 ICANN Bylaws, 18 June 2018, Art. I, § 1.2(c).

8 Amazon EU S.A.R.L. v. ICANN, ICDR Case No. 01-16-000-7056, Procedural Order (7 June 2017), at Pg. 3, https://www.icann.org/en/system/files/files/irp-amazon-procedural-order-3-07jun17-en.pdf [PDF, 119 KB].

9 ICANN Bylaws, 18 June 2018, Art. 1, § 1.2(c).

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