[CCWG-ACCT] CCWG-Accountability Plenary – Proposed Implementation guidance for recommendations Identified by the ICANN Board.

[Bernard Turcotte]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/accountability-cross-community/attachments/20180612/ccea7b29/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CCWG-Accountability-WS2-FinalRecommendations-ImplementationGuidance1V1.1BT.pdf
Type: application/pdf
Size: 87219 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/accountability-cross-community/attachments/20180612/ccea7b29/CCWG-Accountability-WS2-FinalRecommendations-ImplementationGuidance1V1.1BT-0001.pdf>