ABCDEFGHIJKLMNOP
1
 Indicate the level of prioritization for implementation for ALAC by selecting from the drop down menu (i.e., (HIGH - MEDIUM - LOW) N/A - irrelevant)
Status: Under implementation, Comments: In ranking of ALAC/At-Large’s priorities (HIGH - MEDIUM - LOW) as well as a) level of effort (MINIMAL - MODERATE - SIGNIFICANT), b) sense of urgency (HIGH - MEDIUM - LOW)Current Designation is DRAFT ONLY and subject to change by OFB-WG post presentation
2
WS2 TopicRecommendation(s)ALACStatus/CommentsOverall Priority : Effort : Urgency
3
1. Improve Diversity1.1 SO/AC/Groups should agree that the following seven key elements of diversity should be used as a common starting point for all diversity considerations within ICANN:
- Geographical/Regional Representation
- Language
- Gender
- Age
- Physical Disability
- Diverse Skills
- Stakeholder Group or Constituency
HighSBT noted Diversity: 1.3 to 1.5 could be included in ATRT3 continuous improvement. JH noted high priority for 1.1 and importance of 1.6 (tools). CLO comment: I agree with what was discussed in our Call 1; relating to the importance as HIGH for the bundle of items 1.1 through to 1.6 ; assuming that would take medium levels of Resourcing , and a 12-18m time frame; BUT that the activities could be subsumed within the implementation planning of each AC and SO under the overarching HIGH level of Priority under ATRT3 Recommendation 1. MH Comment: *At-Large Disability Group (JH) has noted a high priority for 1.1 and the importance of 1.6 (tools).
*Different communities (SO/ACs) have different needs in this regard. ALAC/At-Large arguably most diverse (language, bandwidth, et al). (OCL)		HIGH Priority (as part continuous improvement programs {ATRT3} : MODERATE Effort/ complexity : MEDIUM sense of urgency
4
1. Improve Diversity1.2 Each SO/AC/Group should identify which elements of diversity are mandated in their charters or ICANN Bylaws and any other elements that are relevant and applicable to each of its levels including leadership (Diversity Criteria) and publish the results of the exercise on their official websites.
MediumMH Comment: Publishing of specific diversity elements within RALOs on their official websites would highlight the relevance and requirement for ICANN to address the specific diversity needs of the different RALOs (MH)
5
1. Improve Diversity1.3 Each SO/AC/Group, supported by ICANN staff, should undertake an initial assessment of their diversity for all of their structures including leadership on their Diversity Criteria and publish the results on their official website.
N/AMH comment: This topic [already] included in ATRT3 continuous improvement (SBT)
6
1. Improve Diversity1.4 Each SO/AC/Group should use the information from their initial assessment to define and publish on their official website their Diversity Criteria objectives and strategies for achieving these, as well as a timeline for doing so.
N/AMH comment: This topic is [already] included in ATRT3 continuous improvement (SBT)
7
1. Improve Diversity1.5 Each SO/AC/Group, supported by ICANN staff, should undertake a regular update of their diversity assessment against their Diversity Criteria and objectives at all levels including leadership. Ideally this update should be carried out annually but not less than every three years. They should publish the results on their official website and use this information to review and update their objectives, strategies, and timelines.
N/AMH Comment: This topic is [already] included in ATRT3 continuous improvement (SBT)
8
1. Improve Diversity1.6 ICANN staff should provide support and tools for the SO/AC/Groups to assist them in assessing their diversity in an appropriate manner. ICANN should also identify staff or community resources that can assist SO/ACs or other components of the community with diversity-related activities and strategies.
HighMH comment: At-Large Disability Group (JH) has noted a high priority for 1.1 and the importance of 1.6 (tools).
9
1. Improve Diversity1.7 ICANN staff should support SO/AC/Groups in developing and publishing a process for dealing with diversity-related complaints and issues.
N/ACLO and SBT noted: Defer to/ask Complaint Officer and Ombuds for process.
10
1. Improve Diversity1.8 ICANN staff should support the capture, analysis, and communication of diversity information, seeking external expertise if needed, in the following ways:
1.81 Create a diversity section on the ICANN website.
1.82 Gather and maintain all relevant diversity information in one place.
1.83 Produce an Annual Diversity Report for ICANN based on all the annual information and provide a global analysis of trends and summarize SO/AC/Groups recommendations for improvement, where appropriate. This should also include some form of reporting on diversity complaints.
1.84 Include diversity information derived from the Annual Diversity Report in ICANN's Annual Report.
MediumOCL noted difference between actions on diversity vs publishing stance on diversity (difference between 1.7 and 1.8). Different communities (SO/ACs) have different needs in this regard. ALAC/At-Large arguably most diverse (language, bandwidth, et al).

SBT Agree that At-Large (Ralos and ALAC) may publish their own data regarding diversity without waiting for an ICANN global solution
11
2. Guidelines for Standards of Conduct Presumed to be in Good Faith Associated with Exercising Removal of Individual ICANN Board Directors2.1 Recommendations for guidelines with respect to Petitions for removal:
2.1.1: May for any reason; and
2.1.2: Must:
2.1.2.1: Be believed by the Indemnified Party to be true.
2.1.2.2: Be in writing.
2.1.2.3: Contain sufficient detail to verify facts; if verifiable facts are asserted.
2.1.2.4: Supply supporting evidence if available/applicable.
2.1.2.5: Include references to applicable by-laws and/or procedures if the assertion is that a specific by-law or procedure has been breached.
2.1.2.6: Be respectful and professional in tone.
HighCLO comment: Need to check where Implementation is on this, but I propose High Priority for Importance; Medium/Low Resourcing; Medium to longer term (24-36m) time point in project and a Short less than 12 month duration

SBT: agree		HIGH Priority : LOW Effort/ complexity : MEDIUM sense of urgency
12
2. Guidelines for Standards of Conduct Presumed to be in Good Faith Associated with Exercising Removal of Individual ICANN Board Directors2.2 Recommendations for guidelines with respect to procedures for consideration of board removal notices by SO/ACs to include:
2.2.1: Reasonable time frames for investigation by SO/AC councils or the equivalent decision-making structures if the SO/AC deems that an investigation is required.
2.2.2: Period of review by the entire membership of the SO/AC provided the SO/AC organizational structure customarily provides review for individual members; otherwise, period of review by those empowered to represent the SO/AC in decisions of this nature.
2.2.3: Consistent and transparent voting method for accepting or rejecting a petition; such voting maybe be by the entire membership or those empowered to represent the SO/AC in decisions of this nature.
2.2.4: Documentation of the community process and how decisions are reached.
N/A
13
2. Guidelines for Standards of Conduct Presumed to be in Good Faith Associated with Exercising Removal of Individual ICANN Board Directors2.3.1 A standard framework be developed and used to raise the issue of Board removal to the respective body – either the specific SO/AC who appointed the member or the Decisional Participant in the case of a NomCom appointee. The framework would be in the context of developing a broader framework for implementing community powers and entering into the discussions contemplated by WS1. This framework could be developed by a new group specifically formed for that purpose.
N/A
14
2. Guidelines for Standards of Conduct Presumed to be in Good Faith Associated with Exercising Removal of Individual ICANN Board Directors2.3.2 Implement the guidelines as a community best practice to apply to all discussions even if not covered by the indemnities contemplated under Article 20. There may be discussions around rejecting a budget or rejecting a proposed standard Bylaw that would benefit from a good faith process. The guidelines for engaging discussions around Board removal could be adopted as a universal standard given that they are broad enough to encompass any discussion.
N/A
15
3. Framework of Interpretation for Human Rights3. Recommends the adoption of the Framework of Interpretation it developed for the ICANN Bylaws dealing with Human Rights, which can be found in Annex 3.
N/ACLO comment: Completed and Reviewed
16
4. Jurisdiction4.1 Recommendations Relating to OFAC Sanctions and Related Sanctions Issues;
4.1.1 ICANN Terms and Conditions for Registrar Accreditation Application Relating to OFAC Licenses. For ICANN to enter into a Registration Accreditation Agreement (RAA) with an applicant from a sanctioned country, it will need an OFAC license. Currently, “ICANN is under no obligation to seek such licenses and, in any given case, OFAC could decide not to issue a requested license.” This uncertainty could discourage residents of sanctioned countries from applying for accreditation. The sub-group recommends that the above sentence should be amended to require ICANN to apply for and use best efforts to secure an OFAC license if the other party is otherwise qualified to be a registrar (and is not individually subject to sanctions). During the licensing process, ICANN should be helpful and transparent with regard to the licensing process and ICANN’s efforts, including ongoing communication with the potential registrar.
LowWhilst important as an issue and one that does need to be addressed in due corse, the proportion of the At-Large Community effected is small and yet whilst importsnt to those effected, overall this Recommendation in comparison to others out of WS2 and on the slate from other RT's is given an overall Low priority, and LOW Urgency, we do however recognise that at least a MODERATE degree of effort will beed to be applied for implementation... Additionally this recommendations it's sub parts (which we mark N/A as they can be treated as mechanisms and features to be implemented in the 'package' of Jurisdiction Recommendations out of the WS2 process... LOW Priority : MODERATE Effort/ complexity : LOW sense of urgency
17
4. Jurisdiction4.1 Recommendations Relating to OFAC Sanctions and Related Sanctions Issues;
4.1.2 Approval of gTLD Registries.
In the 2012 round of the New gTLD program, it was difficult for residents from sanctioned countries to file and make their way through the application process. The Applicant Guidebook (AGB) states: “In the past, when ICANN has been requested to provide services to individuals or entities that are not SDNs (specially designated nationals) but are residents of sanctioned countries, ICANN has sought and been granted licenses as required. In any given case, however, OFAC could decide not to issue a requested license.” The sub-group recommends that ICANN should commit to applying for and using best efforts to secure an OFAC license for all such applicants if the applicant would otherwise be approved (and is not on the SDN list). ICANN should also be helpful and transparent with regard to the licensing process, including ongoing communication with the applicant.
Low
18
4. Jurisdiction4.1 Recommendations Relating to OFAC Sanctions and Related Sanctions Issues;
4.1.3 Application of OFAC Limitations by Non-U.S. Registrars.
It appears that some non-U.S.-based registrars might be applying OFAC sanctions with registrants and potential registrants, based on a mistaken assumption that they must do so simply because they have a contract with ICANN. Non-U.S. registrars may also appear to apply OFAC sanctions, if they “cut and paste” registrant agreements from U.S.-based registrars. While ICANN cannot provide legal advice to registrars, it can bring awareness of these issues to registrars.The sub-group recommends that ICANN clarify to registrars that the mere existence of their RAA with ICANN does not cause them to be required to comply with OFAC sanctions. ICANN should also explore various tools to remind registrars to understand the applicable laws under which they operate and to accurately reflect those laws in their customer relationships.
Low
19
4. Jurisdiction4.1 Recommendations Relating to OFAC Sanctions and Related Sanctions Issues;
4.1.4 General Licenses.
OFAC “general licenses” cover particular classes of persons and types of transactions. ICANN could pursue general licenses to cover transactions integral to ICANN’s role in managing the DNS and contracts for Internet resources, such as registries and registrars entering into Registry Agreements (RAs) and Registrar Accreditation Agreements (RAAs), Privacy/Proxy Accreditation, support for ICANN-funded travelers, etc. This would enable individual transactions to proceed without the need for specific licenses.

A general license would need to be developed in conjunction with the U.S. Department of the Treasury, which must amend OFAC regulations to include the new license. This regulatory process may be a significant undertaking.

The sub-group recommends that ICANN take steps to pursue one or more OFAC “general licenses.” ICANN should first prioritize a study of the costs, benefits, timeline and details of the process. ICANN should then pursue general licenses as soon as possible, unless it discovers significant obstacles. If so, ICANN should report this to the community and seek its advice on how to proceed. If unsuccessful, ICANN needs to find other ways to remove “friction” from transactions between ICANN and residents of sanctioned countries. ICANN should communicate regularly about its progress, to raise awareness in the ICANN community and with affected parties.
Low
20
4. Jurisdiction4.2 This sub-group considered how the absence of a choice of law provision in the base RA, the absence of a choice of law provision in the standard RAA, and the contents of the choice of venue provision in RAs could impact ICANN’s accountability. These are standard-form contracts that are not typically negotiated; changes are now determined through an amendment procedure (e.g. Art. 7.6 of the RA). The sub-group understands that it cannot require ICANN to make amendments to the RA or the RAA. Rather, this recommendation suggests possible changes to the RA and RAA for study and consideration by ICANN the organization, the GNSO, and the contracted parties. The RA and RAA do not contain choice of law provisions. The governing law is thus undetermined, until determined by a judge or arbitrator or by agreement of the parties.

4.2.1 Choice of Law and Venue Provisions in the Registry Agreement
The sub-group identified several alternative approaches for the RA, which could also apply to the RAA. The body of the report discusses the advantages and disadvantages of each approach.

4.2.1.1 Menu Approach. The sub-group supports a “Menu” approach, where the governing law would be chosen before the contract is executed from a “menu” of possible governing laws. The menu needs to be defined; this could best left to ICANN and the registries. The sub-group discussed a number of possible menus, which could include one country, or a small number of countries, from each ICANN geographic region, plus the status quo (no choice of law) and/or the registry’s jurisdiction of incorporation and/or the countries in which ICANN has physical locations. The sub-group has not determined what the menu items should be, but believes there should be a balance between the advantages and disadvantages of having different governing laws apply to the same base RA, which likely suggests having a relatively limited number of choices on the menu. The sub-group recommends that the Registry choose from among the options on the menu (i.e., the choice would not be negotiated with ICANN).

4.2.1.2 “California” (or “fixed law”) Approach. A second possible option is for all RAs to include a choice of law clause naming California and U.S. law as the governing law.

4.2.1.3 Carve-Out Approach. A third possible option would be a “Carve-Out” approach, whereby parts of the contract that would benefit from uniform treatment are governed by a uniform predetermined law (e.g., California) and other parts are governed either by the law of the registry’s jurisdiction or by a jurisdiction chosen using the “Menu” approach.

4.2.1.4 Bespoke Approach. In the “Bespoke” approach, the governing law of the entire agreement is the governing law of the Registry Operator.

4.2.1.5 Status Quo Approach. A fifth possible approach is to retain the status quo, (i.e., have no “governing law” clause in the RAA).

4.2.2 Choice of Law Provisions in Registrar Accreditation Agreements. The options for the RAA are essentially the same as for the RA.

4.2.3 Choice of Venue Provisions in Registry Agreements. Under the RA, disputes are resolved by “binding arbitration,” pursuant to ICC rules. The RA contains a choice of venue provision stating that the venue is Los Angeles, California as both the physical place and the seat of the arbitration. When entering into contracts with registries, ICANN could offer a list of possible venues for arbitration rather than imposing Los Angeles, California. The registry that enters into a registry agreement with ICANN could then choose which venue it prefers at or before the execution of the contract.
low
21
4. Jurisdiction4.3 Further Discussions of Jurisdiction-Related Concerns (Suggestion). There were a number of concerns raised in the sub-group where the sub-group had substantive discussions but did not get to a point of conclusion. As an example, there were discussions of limited, partial, relative, or tailored immunity for ICANN that did not come to conclusion. These concerns were put on the table by different stakeholders, and for these stakeholders, these are legitimate concerns. As these concerns were not discussed to the end, there should be a path forward for these concerns beyond the CCWG- Accountability, which was tasked to look into a limited number of issues within a limited period of time and with a limited budget.

Therefore, the sub-group suggests that another multistakeholder process of some kind should be considered to allow for further consideration, and potentially resolution, of these concerns. We believe that this report, with its annexes, can be a very useful tool for further debates which will surely take place – whether in another cross-constituency effort or in a future ATRT Review, or in some other ICANN context. The appropriate forum for such discussions is beyond the mandate of the CCWG-Accountability; however, we encourage the community to build on the work of the sub-group and prior work in this area.
N/A
22
5. Improving the ICANN Office of the Ombuds (IOO)5.1 The Ombuds Office should have a more strategic focus.
LowSBT: need to review what the IOO has done this year but I think that the IOO is already taking into account some of the items of 5.
https://www.icann.org/en/system/files/files/annual-report-2019-30jun19-en.pdf
Waiting for the 2020 report		LOW Priority : MODERATE Effort/ complexity : LOW sense of urgency
23
5. Improving the ICANN Office of the Ombuds (IOO)5.2 The Ombuds office should include procedures that:

5.2.1 Distinguish between different categories of complaints and explains how each will be handled;

5.2.2 Set out the kinds of matters where the Ombuds will usually not intervene – and where these matters are likely to be referred to another channel (with the complainant’s permission);

5.2.3 Provides illustrative examples to deepen understanding of the Ombuds’ approach.(IOO)
LowLow not because of the importance but that many of these issues are either being currently addressed with the new design on the ICANN Ombudsman web page which is already underway and will be subject to regular updates and improvement (so already provided for via reourcing already established)

Note from 20 Jan: Expectation that ICANN Org will update community on WS2 prior to ICANN70.
24
5. Improving the ICANN Office of the Ombuds (IOO)5.3 Once ICANN has agreed to a revised configuration for the Office of the Ombuds, a plan (see Rec 5.1 and 5.2) should be developed for a soft relaunch of the function, which should incorporate action to emphasis the importance of the Ombuds function by all relevant parts of ICANN, including:
- Board
- CEO
- Community Groups
- Complaints Officer
N/Ait is a dependency on 5.1 and 5.2
25
5. Improving the ICANN Office of the Ombuds (IOO)5.4 All relevant parts of ICANN should be required (should include the corporation, the Board and committees, and anybody or group with democratic or delegated authority) to respond within 90 days (or 120 days with reason) to a formal request or report from the Office of the Ombudsman. The response should indicate the substantive response along with reasons. Should the responding party not be able to meet the 120-day limit due to exceptional circumstances, that party can apply to the IOO to seek an additional extension prior to the expiration of the original 90-day delay. The application should be in writing, stating the nature of the exception and the expected time required to respond. The IOO will respond to such requests within a week.
Low
26
5. Improving the ICANN Office of the Ombuds (IOO)5.5 The ICANN Office of the Ombuds should establish timelines for its own handling of complaints and report against these on a quarterly and annual basis.
N/A
27
5. Improving the ICANN Office of the Ombuds (IOO)5.6 The Office of the Ombuds should be configured so that it has formal mediation training and experience within its capabilities.
LowSBT: From the IOO annual report (2018/19) [no report yeet for 2019/20]
"The ICANN community and several members of the ICANN Board, in the past, have mentioned that the ICANN Ombudsman should have formal mediation training. Acknowledging that one can never have too many tools in one’s toolbox, I am pleased to report that I have now completed the Canadian Institute of Conflict Resolution’s Third Party Neutral program. The program consists of four one-week training sessions covering mediation, conflict resolution, facilitation, and other related learning. The fourth and final module in the Program was successfully completed in November 2018."
28
5. Improving the ICANN Office of the Ombuds (IOO)5.7 Ideally, the Office of the Ombuds should be configured so that it has gender and, if possible, other forms of diversity within its staff resources. (The primary objective of this recommendation is to ensure that the Community has choices as to whom in the IOO they can bring their complaints to and feel more comfortable doing so.)
N/ASBT: From the IOO annual report (2018/19) [no report yeet for 2019/20]
"The Office of the Ombudsman supplemented the individual Ombudsman with an interim Adjunct Ombuds, Barbara Curwin."
Gender balance: Done
29
5. Improving the ICANN Office of the Ombuds (IOO)ICANN should establish an Ombuds Advisory Panel:
5.8.1 Made up of five members to act as advisers, supporters, and wise counsel for the Ombuds and should be made up of a minimum of at least two members with Ombudsman experience and the remainder with extensive ICANN experience;
5.8.2 The Panel should be responsible for:
5.8.2.1 Contributing to the selection process for new Ombuds, which would meet the various requirements of the Board and Community, including
diversity;
5.8.2.2 Recommending candidates for the position of Ombuds to the Board;
5.8.2.3 Recommending terms of probation to the Board for new Ombuds;
5.8.2.4 Recommend to the Board firing an Ombuds for cause;
5.8.2.5 Contribute to an external evaluation of the IOO every five years
5.8.2.6 Making recommendations regarding any potential involvement of the IOO in non-compliant work based on the criteria listed in Recommendation 11;
5.8.3 The Panel cannot be considered as being part of the Ombuds Office and cannot be considered additional Ombuds, but rather external advisors to the office;
5.8.4 Any such advisory panel would require the Ombuds to maintain its confidentiality engagements per the Bylaws.
LowSBT: We may suggest to link this to next request for tendeer for the IOO?

SBT: OK for low until the next call for application. But it must be mandatory at that time.
30
5. Improving the ICANN Office of the Ombuds (IOO)5.9 The Ombuds employment contracts should be revised to strengthen independence by allowing for a: (R5.9.1 - Five-year fixed term (including a 12-month probationary period) and permitting only one extension of up to three years (the extension should be subject to a community-based feedback mechanism to the Advisory Panel covering Ombuds performance over the previous years); (R5.9.2 - The Ombuds should only be able to be terminated with cause).
LowSBT: Idem 5.8
31
5. Improving the ICANN Office of the Ombuds (IOO)5.10 The Ombuds should have as part of their annual business plan, a communications plan – including the formal annual report – publishing reports on activity, collecting and publishing statistics and compliant trend information, collecting user satisfaction information, and publicizing systemic improvements arising from the Ombuds’ work.
N/ASBT: Done for 2019 (not yet for 2020 - June)
32
5. Improving the ICANN Office of the Ombuds (IOO)5.11 The following points should be considered and clarified publicly when looking at the Ombuds’ involvement in any non-complaints work:
- Whether there is unique value that the Ombuds can add through the proposed role or function?
- Whether the proposed reporting/accountability arrangements may compromise perceived independence?
- Whether the workload of the proposed role/function would limit the Ombuds ability to prioritize their complaints-related work?
- Whether any Ombuds’ involvement with the design of new or revised policy or
process, meets the requirement of not, in any way, creating a “stamp of approval”?
- Whether the proposed Ombuds input may be seen as a “short-cut” or substituting for full stakeholder consultation?
N/ASBT: Feedback from the IOO needed / done
Feedback from ICANN Org will be welcome prior to ICANN70.
33
6. Increase SO/AC Accountability
6.1 - Accountability
6.1.1 - SO/AC/Groups should document their decision-making methods, indicating any presiding officers, decision-making bodies, and whether decisions are binding or nonbinding;
6.1.2 - SO/AC/Groups should document their procedures for members to challenge the process used for an election or formal decision;
6.1.3 - SO/AC/Groups should document their procedures for non-members to challenge decisions regarding their eligibility to become a member
6.1.4 - SO/AC/Groups should document unwritten procedures and customs that have been developed in the course of practice, and make them part of their procedural operation documents, charters, and/or bylaws, Each year, SO/AC/Groups should publish a brief report on what they have done during the prior year to improve accountability, transparency, and participation, describe where they might have fallen short, and any plans for future improvements).
HighCLO Comment: I propose that all of Topic 6 from Ws2 could reasonably be transferred to be dealt with under the newer and High Priority of importance; Medium effort; and Resourcing Level Moderate to be implemented under a 18m to 3 year time frame (unless deemed superseded or redundant) in the ATRT3 Recommendation 1 (High Priority 1). General comment from 17 Dec WS2 meeting: This is an opportunity for ALAC to ensure that its interactions with the end users - that inclusion is a desirable trait that the ALAC may wish to consider in their own continuous improvement activities.
SBT: Agree Note from 20 Jan: Expectation that ICANN Org will update community on WS2 prior to ICANN70. 		HIGH Priority (as part continuous improvement programs {ATRT3} :VARIABLE (MODERATE <-> SIGNIFICANT) Effort/ complexity depending on the specifc task so staged implementaion may be desirable): MEDIUM sense of urgency
34
6. Increase SO/AC Accountability
6.1 - Accountability
6.1.5 Each year, SO/AC/Groups should publish a brief report on what they have done during the prior year to improve accountability, transparency, and participation, describe where they might have fallen short, and any plans for future improvements.
Medium
35
6. Increase SO/AC Accountability
6.1 - Accountability
6.1.6 Each Empowered Community (EC) Decisional Participant should publicly disclose any decision it submits to the EC. Publication should include description of processes followed to reach the decision.
N/A
36
6. Increase SO/AC Accountability
6.1 Accountability
6.1.7 Links to SO/AC transparency and accountability (policies, procedures, and documented practices) should be available from ICANN’s main website, under “accountability.” ICANN staff would have the responsibility to maintain those links on the ICANN website.
N/A
37
6. Increase SO/AC Accountability
6.2 Transparency;
6.2.1 Charter and operating guidelines should be published on a public webpage and updated whenever changes are made;
6.2.2 Members of the SO/AC/Group should be listed on a public webpage;
6.2.3 Officers of the SO/AC/Group should be listed on a public webpage.
High
38
6. Increase SO/AC Accountability
6.2 Transparency
6.2.4 Meetings and calls of SO/AC/Groups should normally be open to public observation. When a meeting is determined to be members-only, that should be explained publicly, giving specific reasons for holding a closed meeting. Examples of appropriate reasons include discussion of confidential topics such as;
6.2.4.1 Trade secrets or sensitive commercial information whose disclosure would cause harm to a person or organization's legitimate commercial or financial interests or competitive position;
6.2.4.2 Internal strategic planning whose disclosure would likely compromise the efficacy of the chosen course;
6.2.4.3 Information whose disclosure would constitute an invasion of personal privacy, such as medical records;
6.2.4.4 Information whose disclosure has the potential to harm the security and stability of the Internet;
6.2.4.5 Information that, if disclosed, would be likely to endanger the life, health, or safety of any individual or materially prejudice the administration of justice.
Medium
39
6. Increase SO/AC Accountability
6.2 Transparency;
6.2.5 Records of open meetings should be made publicly available. Records include notes, minutes, recordings, transcripts, and chat, as applicable;
6.2.6 Records of closed meetings should be made available to members, and may be made publicly available at the discretion of the AC/SO/Group. Records include notes, minutes, recordings, transcripts, and chat, as applicable;
6.2.7 Filed comments and correspondence with ICANN should be published and publicly available.
High
40
6. Increase SO/AC Accountability
6.3 Participation
6.3.1 Rules of eligibility and criteria for membership should be clearly outlined in the bylaws or in operational procedures.
6.3.2 Where membership must be applied for, the process of application and eligibility criteria should be publicly available.
Where membership must be applied for, there should be a process of appeal when application for membership is rejected.
6.3.4 An SO/AC/Group that elects its officers should consider term limits.
6.3.5 A publicly visible mailing list should be in place.
6.3.6 if ICANN were to expand the list of languages that it supports, this support should also be made available to SO/AC/Groups.
6.3.7 A glossary for explaining acronyms used by SO/AC/Groups is recommended.
High
41
6. Increase SO/AC Accountability
6.4 Outreach
6.4.1 Each SO/AC/Group should publish newsletters or other communications that can help eligible non-members to understand the benefits and process of becoming a member.
6.4.2 Each SO/AC/Group should maintain a publicly accessible website/wiki page to advertise their outreach events and opportunities.
6.4.3 Each SO/AC/Group should create a committee (of appropriate size) to manage outreach programs to attract additional eligible members, particularly from parts of their targeted community that may not be adequately participating.
6.4.4 Outreach objectives and potential activities should be mentioned in SO/AC/Group bylaws, charter, or procedures.
6.4.5 Each SO/AC/Group should have a strategy for outreach to parts of their targeted community that may not be significantly participating at the time, while also seeking diversity within membership.
Medium
42
6. Increase SO/AC Accountability
6.5 Updates to Policies and Procedures
6.5.1 Each SO/AC/Group should review its policies and procedures at regular intervals and make changes to operational procedures and charter as indicated by the review.
6.5.2 Members of SO/AC/Groups should be involved in reviews of policies and procedures, and should approve any revisions.
6.5.3 Internal reviews of SO/AC/Group policies and procedures should not be prolonged for more than one year, and temporary measures should be considered if the review extends longer.
Medium
43
6. Increase SO/AC Accountability
6.6 Mutual Accountability Roundtable
6.6.1 It is recommended that the Mutual Accountability Roundtable not be implemented.
Medium
44
6. Increase SO/AC Accountability
6.7 Should Independent Review Process (IRP) be applied to SO/AC activities?
6.7.1 The IRP should not be made applicable to activities of SO/AC/Groups. The appropriate mechanism for individuals to challenge an SO/AC action or inaction is through ICANN’s Ombuds Office, whose bylaws and charter are adequate to handle such complaints.
N/A
45
7. Improve Staff Accountability7.1 To address the lack of understanding of the existence and/or nature of existing staff accountability mechanisms, the following actions should be taken:
7.1.1 The ICANN organization should improve visibility and transparency of the organization’s existing accountability mechanisms, by posting on icann.org in one dedicated area the following:
7.1.1.1 Description of the organization’s performance management system and process.
7.1.1.2 Description of how departmental goals map to ICANN’s strategic goals and objectives.
7.1.1.3 Description of the Complaints Office and how it relates to the Ombuds Office.
7.1.1.4 Organization policies shared with the CCWG-Accountability during the course of the WS2 work.
7.1.1.5 ICANN Organization Delegations document.
7.1.1.6 The roles descriptions included in this overall report.
7.1.1.7 Expectations and guidelines regarding the development of staff reports for Public Comments, or staff response to Community correspondence.
MediumSBT: can the 7 be coordinated with some suggestions of ATRT3?MEDIUM Priority (as part continuous improvement programs {ATRT3} : MODERATE Effort/ complexity : MEDIUM sense of urgency
46
7. Improve Staff Accountability7.1 To address the lack of understanding of the existence and/or nature of existing staff accountability mechanisms, the following actions should be taken:
7.1.2 The ICANN organization should also evaluate what other communication mechanisms should be utilized to further increase awareness and understanding of these existing and new accountability mechanisms.
N/A
47
7. Improve Staff Accountability7.2 To address the lack of clearly defined, or broadly understood, mechanisms to address accountability concerns between community members and staff members regarding accountability or behavior:
7.2.1 The ICANN organization should enhance existing accountability mechanisms to include:
7.2.1.1 A regular information acquisition mechanism (which might include surveys, focus groups, reports from the Complaints Office) to allow the ICANN organization to better ascertain its overall performance and accountability to relevant stakeholders.
7.2.1.1.1 The group notes that several new mechanisms are now established, but have not yet been exercised enough to determine effectiveness or potential adjustments. The evaluation mechanism proposed here would be helpful in determining effectiveness of these recent mechanisms before creating yet more mechanisms that may turn out to be duplicative or confusing for the organization and community.
7.2.1.2 Results of these evaluations should be made available to the Community.
N/A
48
7. Improve Staff Accountability7.2 To address the lack of clearly defined, or broadly understood, mechanisms to address accountability concerns between community members and staff members regarding accountability or behavior:
7.2.2 Consistent with common best practices in services organizations, standardize and publish guidelines for appropriate timeframes for acknowledging requests made by the community, and for responding with a resolution or updated timeframe for when a full response can be delivered. The ICANN organization should include language in the performance management guidelines for managers that recommends people managers of community-facing staff seek input from the appropriate community members during the organization’s performance reviews. Identification of appropriate community members, frequency of outreach to solicit input, and how to incorporate positive and constructive feedback into the overall performance review should be at the discretion and judgement of the personnel manager, with appropriate guidance from HR as necessary. Such a feedback mechanism should be supplemental to the existing mechanisms available to the community to provide input on ICANN staff performance, including direct communication to specific staff member, their personnel managers, senior executive staff, Board Directors, and the Complaints Officer.
N/ACLO Comment: This topic is one where several of the specific Recommendations are likely to already be or about to likely be either implemented (Complaints Officer) in a manner that meets the aim, or is to be implemented as a Medium/High Priority in terms of Importance; Medium to Low Resourcing; and over a Medium Term of say 12-18m
49
7. Improve Staff Accountability7.3 The ICANN Organization should work with the community to develop and publish service level targets and guidelines (similar to the Service Level Agreement for the IANA Numbering Services) that clearly define the services provided by ICANN to the community as well as the service level target for each service. In this context:
7.3.1 ICANN should work with the community to identify and prioritize the classes of services for which service level targets and guidelines will be implemented, and to define how service level targets and guidelines will be defined.
7.3.2 Develop clear and reasonable guidelines for expected behavior between the ICANN organization and the community for those newly identified activities.
7.3.3 Develop and publish the resulting service levels, targets, and guidelines in a single area on icann.org. These targets and guidelines should also inform any regular information acquisition mechanism described in Recommendation 2 of this report.
50
8. Recommendations to Improve ICANN Transparency8.1 Improving ICANN’s Documentary Information Disclosure Policy (DIDP)
8.1.1 The caveat that the DIDP applies only to “operational activities” should be deleted.
8.1.2 The DIDP should include a documentation rule whereby, if significant elements of a decision-making process take place orally, or otherwise without a lasting paper- trail, the participants in that decision-making process should be required to document the substance of the conversation, and include it alongside other documentation related to this decision-making process.
8.1.3 The DIDP should be expanded to include clearly defined procedures for lodging requests for information, including requirements that requesters should only have to provide the details necessary to identify and deliver the information.
8.1.4 The DIDP should impose clear guidelines on ICANN for how to process requests, including delegating a specific employee or employees with the responsibility of responding to DIDP requests, including a commitment to provide reasonable assistance to requesters who need it, particularly where they are disabled or unable to identify adequately the information they are seeking.
8.1.5 The DIDP should commit to complying with requesters’ reasonable preferences regarding the form in which they wish to receive information under request (for example, if it is available as either a pdf or as a doc), if ICANN either already has that information available in the requested format, or can convert it to the requested format relatively easily.
8.1.6 The DIDP should specify that requests should receive a response “as soon as reasonably possible” and should cap timeline extensions to an additional 30 days.
8.1.7 The phrase “to the extent feasible, to reasonable requests” should be deleted from the provision on Responding to Information Requests.
8.1.8 In cases where information subject to request is already publicly available, ICANN staff should direct requesters, with as much specificity as possible, to where the information may be found. In other words, if the processing of a DIDP request reveals that the information has already been published, staff should include information about where this information may be found in their response to the requester.
8.1.9 The exception for information “that relates in any way to the security and stability of the Internet, including the operation of the L Root or any changes, modifications, or additions to the root zone” should be amended so that it only applies to information whose disclosure would be harmful to the security and stability of the Internet, including the operation of the L Root or any changes, modifications, or additions to the root zone.
8.1.10 The exception for “drafts of all correspondence, reports, documents, agreements, contracts, emails, or any other forms of communication” should be amended to clarify that this information should be disclosed unless it would be harmful to an ongoing deliberative or decision-making process.
8.1.11 The exceptions for “trade secrets and commercial and financial information not publicly disclosed by ICANN” and for "confidential business information and/or internal policies and procedures" should be replaced with an exception for “material whose disclosure would materially harm ICANN’s financial or business interests or the commercial interests of its stakeholders who have those interests.”
8.1.12 Where an exception is applied to protect a third party, the DIDP should include a mechanism for ICANN staff to contact this third party to assess whether they would consent to the disclosure.
8.1.13 The exception for information requests which are “not reasonable, excessive or overly burdensome, not feasible, abusive or vexatious or made by a vexatious or querulous individual” should be amended so that either the Ombudsman or the Complaints Officer automatically reviews any decision to use this exception.
8.1.14 The following sentence should be deleted: “Further, ICANN reserves the right to deny disclosure of information under conditions not designated above if ICANN determines that the harm in disclosing the information outweighs the public interest in disclosing the information.”
8.1.15 ICANN should consider future processes to expand transparency at ICANN Legal, including through clarification of how attorney-client privilege is invoked.
8.1.16 Wherever possible, ICANN's contracts should either be proactively disclosed 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).
8.1.17 The DIDP should include a severability clause, whereby in cases where information under request includes material subject to an exception to disclosure, rather than refusing the request outright, the information should still be disclosed with the sensitive aspects severed, or redacted, if this is possible.
8.1.18 Where an information request is refused, or the information is provided in a redacted or severed form, the DIDP should require that ICANN’s response include the rationale underlying the decision, by reference to the specific exception(s) invoked, as well as information about appeal processes that are available.
8.1.19 The Ombudsman’s mandate regarding transparency should be boosted to grant the office a stronger promotional role, including by integrating understanding of transparency and the DIDP into ICANN’s broader outreach efforts, by publishing a list of the categories of information ICANN holds.
8.1.20 Either the Ombudsman or the Complaints Officer should be tasked with carrying out reasonable monitoring and evaluation procedures, such as publishing the number of requests received, the proportion which were denied, in whole or in part, the average time taken to respond, and so on.
8.1.21 ICANN should commit to reviewing the DIDP every five years.
MediumCLO comment: I would suggest that all the Recommendations in topic 8 that are not already covered by implementations planning or subsumed by alternative actions (that would require detailing etc, and that will also be being prioritised by ICANN.org planning) can be incorporated into the preparatory phase for parts of ATRT3 Recommendation 1 re Holistic ICANN Review... This does have High importance to some Internet end users, but not widescale importance in general so probably a Medium Priority or Importance; Medium Resource requirements; Implementable over perhaps an 12 month duration between 18m to 24m point and including the third party assessment after say 12+ months post operation of updated processes.

SBT: Agree		MEDIUM Priority (as part continuous improvement programs {ATRT3} : MODERATE Effort/ complexity : LOW sense of urgency
51
8. Recommendations to Improve ICANN Transparency8.2 Documenting and Reporting on ICANN’s Interactions with Governments.
8.2.1 In the interest of providing the community greater clarity with regard to how ICANN engages government stakeholders and to ensure that the ICANN Community and, if necessary, the Empowered Community is fully aware of ICANN’s interactions with governments, the CCWG-Accountability recommends that ICANN begin disclosing publicly the following (notwithstanding any contractual confidentiality provisions) on at least a yearly (but no more than quarterly) basis with regard to expenditures over $20,000 per year devoted to “political activities,” both in the U.S. and abroad:
8.2.1.1 All expenditures on an itemized basis by ICANN both for outside contractors and internal personnel.
8.2.1.2 All identities of those engaging in such activities, both internal and external, on behalf of ICANN.
8.2.1.3 The type(s) of engagement used for such activities.
8.2.1.4 To whom the engagement and supporting materials are targeted.
8.2.1.5 The topic(s) discussed (with relative specificity).
MediumMEDIUM Priority (as part continuous improvement programs {ATRT3} : MODERATE Effort/ complexity : LOW sense of urgency
52
8. Recommendations to Improve ICANN Transparency8.3 Transparency of Board Deliberations
8.3.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.
8.3.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.
8.3.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.
Medium
53
8. Recommendations to Improve ICANN Transparency8.4 Improving ICANN’s Anonymous Hotline (Whistleblower Protection)
8.4.1 The policy should be clearly posted as “Employee Hotline Policy and Procedures” on the ICANN public website under the “Who we Are” or “Accountability and Transparency” portions as soon as possible.
8.4.2 Related to the above, the term “whistleblower” should be included in introductory text explaining the policy so that an ICANN community member – who may not know that the policy is called a “Hotline Policy” – may easily locate it using “whistleblower” as the search term. For example: “The following outlines elements of ICANN’s Hotline Policy and Procedures. Some organizations refer to this as “whistleblower protections.”
8.4.3 The definition of incidents reported should be broadened from “serious issues” to encourage the report of all issues and concerns related to behavior that may violate local laws and conflict with organizational standards of behavior. Furthermore, the policy should provide specific examples of such violations to guide a potential reporter.
8.4.4 ICANN need to improve internal administration of the Hotline process by employing case management software to better enable tracking, documenting, reporting, and anticipating potential problem areas.
8.4.5 ICANN should regularly provide employees with data about use of the Hotline, that details not only the frequency of use but also the types of incidents reported.
8.4.6 ICANN should not prioritize receipt of reports as “urgent” and “non-urgent,” but treat every report as a priority warranting formal acknowledgment of receipt of a report within 48 hours at the latest.
8.4.7 ICANN needs to more effectively address potential fear of retaliation against the reporter by stating unequivocally that alleged retaliation will be investigated with the same level of rigor as alleged wrongdoing. ICANN should also guarantee remedy for reporters who suffer from retaliation as well as clarify that good-faith reporting of suspected wrongdoing will be protected from liability.
Medium
54
8. Recommendations to Improve ICANN Transparency8.4 Improving ICANN’s Anonymous Hotline (Whistleblower Protection)
8.4.8 ICANN’s Hotline Policy and Procedures should undergo a third-party audit least every two years to help identify gaps and enable timely corrections. The audit, in turn, should be posted on the public website.
MediumMEDIUM Priority (as part continuous improvement programs {ATRT3} : MODERATE Effort/ complexity : MEDIUM sense of urgency
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100