NOTE: As this is a lengthy email it is replicated in the attached PDF file with improved formatting for you convenience *CCWG-Accountability Plenary – Proposed Implementation guidance for recommendations Identified by the ICANN Board.* This email updates the CCWG on the preparation of implementation guidance, and asks participants to comment and share views on draft guidance on two topics where text is now available - Open Contracting, and Transparency of Board Deliberations. Please note that since the Implementation Guidance contained in this email was only completed two days prior to the scheduled plenary meeting and since this would not meet the requirement of distributing material 7 days prior to a plenary meeting the Wednesday 13 June meeting had to be cancelled. However the Co-Chairs felt it was critical to get this information to the plenary to allow discussions to begin on list prior to the Panama meeting. As a reminder we copy below the latest email from the Co-Chairs to the plenary list: Email to the WS2 plenary list 24 May 2018 Last week the Co-Chairs forwarded you the ICANN Board input on WS2 recommendations which was the result of our discussions with members of the Board on WS2 recommendations at ICANN 61. You will remember from our discussions at the WS2 face to face meeting at ICANN 61 that our objective for that meeting was to explore the possibility of resolving any lingering issues the ICANN Board would have with our recommendations via implementation guidance which would not modify any of the WS2 recommendations. The results of the meeting with members of the Board on WS2 recommendations was that the CCWG-Accountability would look into producing implementation advice relative to the concerns of the Board once these were formally presented to the CCWG-Accountability. As such the Board input on the WS2 recommendations provides that input and the transmission letter states that “As we discussed in San Juan, we hope that the CCWG-Acct finds these inputs helpful in considering if any further implementation guidance can be given that would support the Board’s consideration of the WS2 recommendations.” which is in line with the conclusions of the ICANN 61 meeting. The Co-Chairs held a meeting May 23 to consider various options for implementation guidance which would not alter the final recommendations of WS2 and have asked staff to prepare proposals for the Co-Chairs consideration so we can then present the best options to the plenary. Given the time required to prepare this the Co-Chairs have agreed that we should cancel the plenary scheduled for Wednesday 30 May 1900 UTC and focus on holding the Wednesday 6 June 0500 plenary to discuss the options for implementation guidance. The Board response to the WS2 recommendations dated 14 May 2018 identified four of the 92 recommendations which it has issues with: • The Ombudsman Advisory Council (from the Ombuds Subgroup) • Open Contracting (from the Transparency Subgroup) • Government Engagement recommendations (from the Transparency Subgroup) • Transparency of Board Deliberations The Board response also included the following text: In the event that these issues cannot be resolved and the Board considers that it cannot approve parts of the consensus based WS2 recommendations, the Board would have to invoke the special CCWG Accountability rejection process at the appropriate time. In the hopes of avoiding that the Board invokes the lengthy rejection process the Co-Chairs requested staff draft implementation guidance which would keep to the spirit of the recommendations and should be acceptable to the ICANN Board. As of today we have identified implementation guidance language for Open Contracting and Transparency of Board Deliberations which we would like the plenary to consider. Please find below the proposed implementation guidance for these two points which we would request the plenary participants comment on the list prior to the ICANN 62 CCWG-Accountability Face to Face meeting scheduled for Sunday 24 June 2018. *Transparency of Board Deliberations* o The 14 May 2018 Board comment on this recommendation can be found in Annex 1. o Original recommendation - The DIDP exception for deliberative processes should not apply to any factual information, technical reports or reports on the performance or effectiveness of a particular body or strategy, as well as any guideline or reasons for a decision which has already been taken or where the material has already been disclosed to a third party. * Implementation guidance – This information should be disclosed unless it would be harmful to an ongoing deliberative or decision-making process.* * Note: As ICANN organization points out, documents/information already provided to a third party (without obligation to keep as confidential) should not be withheld simply because of a deliberative process exception.* o Original recommendation - The Bylaws should be revised so that material may only be removed from the minutes of Board meetings where it would be subject to a DIDP exception. Decisions to remove material from the minutes of Board meetings should be subject to IRP appeal. * Implementation guidance – the basis for redaction of Board minutes and withholding information from a DIDP request should be consistent with each other overall (but for practical reasons can never be identical). For the most part this would seem to be the case including if the CCWG-Accountability recommendations which apply to the DIDP are implemented. As such ICANN should publish a register of all redaction of Board minutes explaining the basis for the redaction . Additionally the register should explain how the basis for this redaction aligns with the DIDP exceptions and if it does not align with such an exception explain why this is the case.* * Note: Re IRP appeal – this is currently in the Bylaws.* o Original recommendation - Where material is removed from the minutes of Board meetings, the default should be to allow for its release after a particular period of time, once the potential for harm has dissipated. * Implementation guidance – When redacting any information the Board should identify if the redacted information can eventually be released or not (ICANN should publish the list of the classes of information which can never be disclosed by law, or other reasons, such as staff employment matters etc.). If redacted information is identified as eventually being subject to release it should identify the conditions which would allow the release (this information should be included in the above mentioned Register). The CEO would annually review redacted information which is noted as being conditionally subject to release to see if the conditions for release are met. If the conditions are met the CEO would request authorization from the Board to release the information. * *Open Contracting* o The 14 May 2018 Board comment on this recommendation can be found in Annex 2. o Original recommendation - 16) Wherever possible, ICANN's contracts should either be proactively dis-closed or available for request under the DIDP. The DIDP should allow ICANN to withhold information subject to a non-disclosure agreement, however such agreements should only be entered into where the contracting party satisfies ICANN that it has a legitimate commercial reason for requesting the NDA, or where information contained therein would be subject to other exceptions within the DIDP (such as, for example, where the contract contains information whose disclosure would be harmful to the security and stability of the Internet). * Implementation guidance – As the recommendation starts with the language "wherever possible" and as the examples provided by the CCWG-Accountability were for governments and not corporations, we would recommend that ICANN define where this is "possible" and publish this.* * Implementation guidance – As part of this implementation ICANN should annually publish a register of all suppliers it pays 500,000$US or more per fiscal year broken down by categories (eg, computer equipment, software, telecommunication services, contracting etc.)* *Annex 1 - 14 May 2018 Board comment on Transparency of Board Deliberations* Similar to the treatment of the ICANN organization’s comments on Governmental Engagement, the ICANN Board notes that no modifications were made to the Transparency of Board Deliberations section of the Transparecy subgroup report (narrative or recommendations) to address any of the clarifications provided by the ICANN organization. As the exercise proceeds to determine if there are any implementation notes that can be included in the Final Report as presented to the Board, the ICANN Board encourages consideration of the inputs on this section as well. These subgroup considerations could include a gap analysis/clarity on Recommendation 1, and addressing the legal feasibility concerns raised in regard to Recommendation 2. The Transparency of Board Deliberations recommendations state: 1) The DIDP exception for deliberative processes should not apply to any factual information, technical reports or reports on the performance or effectiveness of a particular body or strategy, as well as any guideline or reasons for a decision which has already been taken or where the material has already been disclosed to a third party. 11 If the “internal process” limitation is intended to address ICANN org’s question 6, further clarity is still needed as to what is meant by the “internal process” language. 2) The Bylaws should be revised so that material may only be removed from the minutes of Board meetings where it would be subject to a DIDP exception. Decisions to remove material from the minutes of Board meetings should be subject to IRP appeal. 3) Where material is removed from the minutes of Board meetings, the default should be to allow for its release after a particular period of time, once the potential for harm has dissipated. ICANN organization’s comments stated: Of the three recommendations presented in this section, ICANN org has some key areas where it agrees with the Subgroup. First, documents/information already provided to a third party (without obligation to keep as confidential) should not be withheld simply because of a deliberative process exception. (Recommendation 1). The idea that redactions should only exist for as long as necessary is also important to transparency. (Recommendation 3). For example, negotiation limits for rental of office space need to be kept confidential during negotiations, and likely for a period of time after negotiations are complete. However, at a future point that limit can probably be released. On the other hand, resolutions about specific employment matters are normally never appropriate for publication. Introducing information on when and how decisions on removing redactions are made could be a helpful improvement. Recommendation 2, on the types of information appropriate to redact from minutes, will need to be revisited upon the completion of the review of the DIDP, and must be considered in light of the ICANN Bylaws requirements on the process and grounds for basis of removal from minutes. ICANN needs to retain an appropriate scope of redaction to meet its legal obligations. Withholding items from resolutions is not a frequent practice. Notably, if ICANN violates the Bylaws in how items are withheld from posting, the IRP is already available. As it relates to Recommendation 1, these are the transparency practices that are already in place for ICANN Board deliberations: • In accordance with the ICANN Bylaws, ICANN posts resolutions within a short time frame of approval, and since 2010, ICANN has been producing rationales to help support and explain the Board’s actions. • ICANN produces detailed minutes of minutes of meetings, and also since 2010, the Board makes available the documentation that supported its deliberations, the Board Briefing Materials. • At the time of posting each set of Board minutes, ICANN posts the corresponding briefing materials for that meeting. A discussion of how those materials are prepared for posting is at https://www.icann.org/resources/board-material/briefing- materialsguidelines-2011-03-21-en. These documents are posted notwithstanding the defined condition for nondisclosure under the DIDP regarding deliberative process materials. • A general discussion of ICANN’s redaction practices is available at https://www.icann.org/resources/pages/publication-practices-2016- 06-30-en. • In addition to the regular posting of resolutions, summaries of resolutions, and information about the outstanding action items from resolutions, is provided in the Board Report generated by the CEO’s office. • The Board Report also provides information about Board workshop sessions, including identification of issues discussed and follow-up steps. It would be helpful to understand if ICANN’s existing publication practice aligns with Recommendation 1 on the types of information that should be made available about the Board’s deliberations, or if Recommendation 1 is addressing other documents. *Annex 2 - 14 May 2018 Board comment on Open Contracting* The Transparency subgroup, at Recommendation 16 of its recommendations on Improving ICANN’s Documentary Information Disclosure Policy (DIDP), states: “Wherever possible, ICANN's contracts should either be proactively disclosed or available for request under the DIDP.” This is an iteration of the Recommendation 16 that was posted for public comment in February 2017, stating “ICANN should consider adopting open contracting, whereby all contracts above $5,000 are automatically disclosed, and non-disclosure clauses are limited in their application to the legitimate exceptions found in the DIDP.” ICANN organization, on 21 February 2017, submitted inputs on this Recommendation 16, stating: “Recommendation 16, suggesting open contracting (or the automatic disclosure of all contracts over US$5,000 or $10,000, and modification of non-disclosure agreements away from industry standards)3 represents a shift of ICANN’s contracting process, and could have significant impact on ICANN’s ability to serve its mission within appropriate budgetary controls and in ways that might be impractical.” 2 How an Advisory Panel recommendation for termination would interplay with the obligations of Bylaws Section 5.1(c) and the ¾ vote of the Board for termination is an example of a separate question that remains unanswered. While this could be solved during implementation, further guidance towards implementation would be helpful. 3 The concerns previously raised regarding non-disclosure agreements appear to have been resolved. The concerns raised over a year ago on the open contracting provision persist with the current version. This recommendation is still based on a presumption that governmental open contracting standards as “found in most progressive democracies” are appropriate to bring into ICANN, which is a private corporation that does not enjoy any privileges or immunities that apply to governments. ICANN has asked, multiple times for information, examples or studies on the use of open contracting in private (non-state) companies. No such examples have been provided. Instead, in order to provide further support for imposing open contracting standards onto ICANN, the drafters of this portion of the report, added citations to an article discussing the benefits of open contracting practices to combat corruption within the Ukrainian government, as well as one on a Paraguayan system built to counter “long-standing problems faced by the government, like graft, overpricing, nepotism and influence-peddling.” No information or studies have been provided to support the application of open contracting standards to private companies.4 The narrative provided in the report gives additional information on how the drafters see Recommendation 16 being implemented.5 The narrative discusses that ICANN should use a threshold (of $5,000-10,000) for proactive publication, as well as releasing details about bids received during procurement processes (which is broader than the recommendation). The narrative references the positive impacts found in the two “case studies” (the articles provided on Ukraine and Paraguay) as reasons to support ICANN’s adoption of governmental open contracting standards. Those are both based on situations where there were allegations or documentation of governmental corruption and graft, and the impacts of implementing open contracting programs in reducing corruption and graft and in giving equal access to procurement information to bidders. Because corruption was reduced and bidding 4 During the ICANN61 discussion, the suggestion was raised that because an open contracting recommendation was made without study or background on how to make it appropriate to ICANN, the only proper way for ICANN to document that open contracting could pose concerns for ICANN would be to provide documentation and studies. Further, within that discussion there were also suggestions that those making recommendations for accountability and transparency improvements within ICANN had no obligation to consider how those recommendations might impact the global public interest, as that is solely the job of the Board. We do not agree with either of these assertions, as they suggest that those making recommendations have no accountability for either demonstrating the value of those recommendations to the ICANN ecosystem, or considering the impacts that might result. That noted, we do not think that this open contracting recommendation was offered with any improper intent, and believe that dialogue around this issue can remain productive, as we believe that those participating in the WS2 process intend to be accountable, as do we, for our respective efforts and roles in this work. 5 As noted in footnote 1 of the ICANN Org comments on the Transparency Report, the introductory narrative to the report contains more detail, and at times different, information on the recommendations. It would be helpful to gain clarity over whether some of the additional detail is intended to augment the recommendations. opportunities were more available, there was discussion that the governments enjoyed lower costs in obtaining goods and services, and opportunities were open to more bidders. ICANN org already has many of the protections already in place that the Transparency report suggests that open contracting would provide. For example, ICANN has publicly available procurement guidelines ( https://www.icann.org/en/about/financials/procurement-guidelines-21feb10- en.pdf) and a Contracting and Disbursement Policy governing ICANN’s contracting practices, including requiring the approval of two officers for obligations over US$50,000, and the Board of Directors approval for obligations over US$500,000. See https://www.icann.org/resources/pages/contracting-disbursement-policy- 2015-08-25-en. While ICANN is subject to, through its IRS Form 990 annual filings, disclosure of the 10 vendors to which it provides the highest payments, ICANN org has, as a practice, expanded that obligation to the disclosure of vendors to which it provides annual payments of over US$1,000,000. ICANN org has an annual independent audit performed of its financial statements, and publicly posts its Audited Financial Statements, where the auditors consider if the financial statements are free from material misstatement, fraud or error. The Audited Financial Statements and Form 990s are available at https://www.icann.org/resources/pages/governance/current-en. ICANN’s annual budgeting and operating plan processes involve significant community inputs, with documentation posted and discussed. Within those processes, there remain opportunities to challenge budget assumptions, as well as for the community to consider how ICANN performed against those budgets. ICANN’s documented commitment to considering conflict of interests in contracting (see https://www.icann.org/en/system/files/files/enforcement-compliance-coi- 05jan16-en.pdf) continues. If those participating in the procurement process believe that there was inappropriate conduct in procurement, the range of appropriate ICANN accountability mechanisms are already available. Also, as explained previously to the WS2 rapporteur for the Transparency subgroup, ICANN has already started taking a far narrower stance on when the organization will enter into non-disclosure clauses with vendors, making information that is appropriate for public disclosure (and not subject to other DIDP conditions for non-disclosure) more likely to be available. The Transparency subgroup has not provided any problem statement of corruption within ICANN,6 or lack of bidding competiveness, or other concerns with ICANN’s procurement practices. The Transparency subgroup has instead suggested a broad fix of problems that have not been identified within ICANN. With the policies and protections identified above already in place, the ICANN Board reiterates the 6 The new ICANN Bylaws also allow for independent investigation of credible allegations of fraud or gross mismanagement of ICANN resources. Bylaws Section 22.8. Neither the ICANN Board or ICANN org are aware of any attempts to initiate this new community power. concern raised by ICANN organization that turning to a position where all of ICANN’s contracts should automatically be subject to disclosure could negatively impact ICANN’s ability to serve its mission within appropriate budgetary controls and have impractical outcomes. ICANN needs the ability to retain incentive for vendors to work with ICANN in serving its mission, at favorable prices, and without making it more challenging than some already perceive working with ICANN to be. This is key to ICANN serving the global public interest. The Board does not suggest that that there cannot be innovations in and further transparency around contracts at ICANN. However, automatic disclosure of all contracts does not seem to be a balanced measure, particularly without a view of the problems that disclosure is proposed to remedy. For example, innovations could be things such as documenting ICANN’s disclosure practices for high-value contracts, or reviewing if the high-value contract level is set at the correct amount.