Skip to main content
Resources

Implementation of ATRT2 Recommendations

The table below includes links relating to the implementation of recommendations from the second Accountability and Transparency review (ATRT2). See the ATRT2 wiki for more information on the implementation of ATRT2 recommendations.

ICANN org delivered an ATRT3 Recommendation 2 Implementation Report in February 2024, thereby completing ATRT3 Recommendation 2.

Rec #

Status

Description

Implementation Wiki Page

1

Implemented

The Board should develop objective measures for determining the quality of ICANN Board members and the success of Board improvement efforts, and analyze those findings over time.

Rec #1

2

Implemented

The Board should develop metrics to measure the effectiveness of the Board?s functioning and improvement efforts, and publish the materials used for training to gauge levels of improvement.

Rec #2

3

Implemented

The Board should conduct qualitative/quantitative studies to determine how the qualifications of Board candidate pools change over time and should regularly assess Directors' compensation levels against prevailing standards.

Rec #3

4

Implemented

The Board should continue supporting cross-community engagement aimed at developing an understanding of the distinction between policy development and policy implementation. Develop complementary mechanisms whereby the Supporting Organizations and Advisory Committees (SO/AC) can consult with the Board on matters, including but not limited to policy, implementation and administrative matters, on which the Board makes decisions.

Rec #4

5

Implemented

The Board should review redaction standards for Board documents, Document Information Disclosure Policy (DIDP) and any other ICANN documents to create a single published redaction policy. Institute a process to regularly evaluate redacted material to determine if redactions are still required and if not, ensure that redactions are removed.

Rec #5

6.1

Implemented

6.1. ATRT2 recommends that the Board work jointly with the GAC, through the BGRI working group, to consider a number of actions to make its deliberations more transparent and better understood to the ICANN community. Where appropriate, ICANN should provie the necessary resources to facilitate the implementation of specific activities in this regard. Examples of activities that the GAC could consider to improve transparency and understanding include:

a. Convening “GAC 101” or information sessions for the ICANN community, to provide greater insight into how individual GAC members prepare for ICANN meetings in national capitals, how the GAC agenda and work priorities are established, and how GAC members interact intersessionally and during GAC meetings to arrive at consensus GAC positions that ultimately are forwarded to the ICANN Board as advice;

b. Publishing agendas for GAC meetings, conference calls, etc., on the GAC website seven days in advance of the meetings and publishing meeting minutes on the GAC website within seven days after each meeting or conference call.

c. Updating and improving the GAC website to more accurately describe GAC activities, including intersessional activities, as well as publishing all relevant GAC transcripts, positions and correspondence;

d. Considering whether and how to open GAC conference calls to other stakeholders to observe and participate, as appropriate. This could possibly be accomplished through the participation of liaisons from other ACs and SOs to the GAC, once that mechanism has been agreed upon and implemented;

e. Considering how to structure GAC meetings and work intersessionally so that during the three public ICANN meetings a year the GAC is engaging with the community and not sitting in a room debating itself;

f. Establishing as a routine practice agenda setting calls for the next meeting at the conclusion of the previous meeting;

g. Providing clarity regarding the role of the leadership of the GAC; and,

h. When deliberating on matters affecting particular entities, to the extent reasonable and practical, give those entities the opportunity to present to the GAC as a whole prior to its deliberations.

Rec #6

6.2

Implemented

6.2. ATRT2 recommends that the Board work jointly with the GAC, through the BGRI, to facilitate the GAC formally adopting a policy of open meetings to increase transparency into GAC deliberations and to establish and publish clear criteria for closed sessions.

Rec #6

6.3

Implemented

6.3. ATRT2 recommends that the Board work jointly with the GAC, through the BGRI, to facilitate the GAC developing and publishing rationales for GAC Advice at the time Advice is provided. Such rationales should be recorded in the GAC register. The register should also include a record of how the ICANN Board responded to each 2item of advice.

Rec #6

6.4

Implemented

6.4. The Board, working through the BGRI working group, should develop and document a formal process for notifying and requesting GAC advice (see ATRT1 Recommendation 10).

Rec #6

6.5

Implemented

6.5. The Board should propose and vote on appropriate bylaw changes to formally implement the documented process for Board-GAC bylaws consultation as developed by the BGRI working group as soon as practicable (see ATRT1 Recommendation 11).Increase support and resource commitments of government to the GAC (see ATRT 1 Recommendation 14)

Rec #6

6.6

Implemented

ATRT2 recommends that the Board work jointly with the GAC, through the BGRI working group, to identify and implement initiatives that can remove barriers for participation, including language barriers, and improve understanding of the ICANN model and access to relevant ICANN information for GAC members. The BGRI working group should consider how the GAC can improve its procedures to ensure more efficient, transparent and inclusive decision-making. The BGRI working group should develop GAC engagement best practices for its members that could include issues such as: conflict of interest; transparency and accountability; adequate domestic resource commitments; routine consultation with local Domain Name System (DNS) stakeholder and interest groups; and an expectation that positions taken within the GAC reflect the fully coordinated domestic government position and are consistent with existing relevant national and international laws.

Rec #6

6.7

Implemented

ATRT2 recommends that the Board work jointly with the GAC, through the BGRI working group, to regularize senior officials? meetings by asking the GAC to convene a High Level meeting on a regular basis, preferably at least once every two years. Countries and territories that do not currently have GAC representatives should also be invited and a stock-taking after each High Level meeting should occur.

Rec #6

6.8

Implemented

ATRT2 recommends that the Board work jointly with the GAC, through the BGRI working group, to work with ICANN?s Global Stakeholder Engagement group (GSE) to develop guidelines for engaging governments, both current and non-GAC members, to ensure coordination and synergy of efforts.

Rec #6

6.9

Implemented

The Board should instruct the GSE group to develop, with community input, a baseline and set of measurable goals for stakeholder engagement that addresses the following: a. Relationships with GAC and non-GAC member countries, including the development of a database of contact information for relevant government ministers;

b. Tools to summarize and communicate in a more structured manner government involvement in ICANN, via the GAC, as a way to increase the transparency on how ICANN reacts to GAC advice (e.g. by using information in the GAC advice register).

c. Making ICANN’s work relevant for stakeholders in those parts of the world with limited participation; and,3

d. Develop and execute for each region of the world a plan to ensure that local enterprises and entrepreneurs fully and on equal terms can make use of ICANN’s services including new gTLD’s.

Rec #6

7.1

Implemented

The Board should explore mechanisms to improve Public Comment through adjusted time allotments, forward planning regarding the number of consultations given anticipated growth in participation, and new tools that facilitate participation.

Rec #7

7.2

Implemented

The Board should establish a process under the Public Comment Process where those who commented or replied during the Public Comment and/or Reply Comment period(s) can request changes to the synthesis reports in cases where they believe the staff incorrectly summarized their comment(s).

Rec #7

8

Implemented

The recommendation states: To support public participation, the Board should review the capacity of the language services department versus the community need for the service using Key Performance Indicators (KPIs) and make relevant adjustments such as improving translation quality and timeliness and interpretation quality. ICANN should implement continuous improvement of translation and interpretation services including benchmarking of procedures used by international organizations such as the United Nations.

Rec #8

9.1

Implemented

The 9.1 subproject implementation focus is on the proposed Bylaws change recommended by the ATRT2 to impose a requirement on the ICANN Board to acknowledge advice arising from any of ICANN?s Advisory Committees.

Rec #9

9.2

Implemented

The 9.2 subproject implementation focus is to review ICANN?s existing accountability mechanisms through a community-comprised group.

Rec #9

9.3

Implemented

The 9.3 subproject is for the implementation of a review of the Office of the Ombudsman, the role within ICANN, and whether the duties/scope of the Ombudsman should be expanded or changed in line with suggestions from the ATRT2.

Rec #9

9.4

Implemented

The 9.4 subproject implementation focuses on developing a full set of statistical data that will be published annually with each Fiscal Year Annual Report.

Rec #9

9.5

Implemented

The 9.5 subproject implementation will conduct a review of the Anonymous Hotline policy and processes, implement any proposed modifications to policy and publish a report on results to the community.

Rec #9

10.1

Implemented

10.1. To enhance GNSO policy development processes and methodologies to better meet community needs and be more suitable for addressing complex problems, ICANN should:
a. In line with ongoing discussions within the GNSO, the Board should develop funded options for professional services to assist GNSO policy development WGs. Such services could include training to enhance work group leaders' and participants' ability to address difficult problems and situations, professional facilitation, mediation, negotiation. The GNSO should develop guidelines for when such options may be invoked,

b. The Board should provide adequate funding for face-to-face meetings to augment e-mail, wiki and teleconferences for GNSO policy development processes. Such face-to-face meeting must also accommodate remote participation, and consideration should also be given to using regional ICANN facilities (regional hubs and engagement centers) to support intersessional meetings. Moreover, the possibility of meetings added on to the start or end of ICANN meetings could also be considered. The GNSO must develop guidelines for when such meetings are required and justified, and who should participate in such meetings.

c. The Board should work with the GNSO and the wider ICANN community to develop methodologies and tools to allow the GNSO policy development processes to utilize volunteer time more effectively, increasing the ability to attract busy community participants into the process and also resulting in quicker policy development.

Rec #10

10.2

Implemented

10.2. The GAC, in conjunction with the GNSO, must develop methodologies to ensure that GAC and government input is provided to ICANN policy development processes and that the GAC has effective opportunities to provide input and guidance on draft policy development outcomes. Such opportunities could be entirely new mechanisms or utilization of those already used by other stakeholders in the ICANN environment. Such interactions should encourage information exchanges and sharing of ideas/opinions, both in face-to-face meetings and intersessionally, and should institutionalize the cross-community deliberations foreseen by the AoC.

Rec #10

10.3

Implemented

10.3. The Board and the GNSO should charter a strategic initiative addressing the need for ensuring more global participation in GNSO policy development processes, as well as other GNSO processes. The focus should be on the viability and methodology of having the opportunity for equitable, substantive and robust participation from and representing:
a. All ICANN communities with an interest in gTLD policy and in particular, those represented within the GNSO;

b. Under-represented geographical regions;

c. Non-English speaking linguistic groups;

d. Those with non-Western cultural traditions; and

e. Those with a vital interest in gTLD policy issues but who lack the financial support of industry players.

Rec #10

10.4

Implemented

10.4. To improve the transparency and predictability of the policy development process the Board should clearly state to what degree it believes that it may establish gTLD policy121 in the event that the GNSO cannot come to closure on a specific issue, in a specified time-frame if applicable, and to the extent that it may do so, the process for establishing such gTLD policies. This statement should also note under what conditions the Board believes it may alter GNSO Policy Recommendations, either before or after formal Board acceptance.

Rec #10

10.5

Implemented

10.5. The Board must facilitate the equitable participation in applicable ICANN activities, of those ICANN stakeholders who lack the financial support of industry players.­

Rec #10

11.1

Implemented

11.1. Institutionalization of the Review Process
The Board should ensure that the ongoing work of the AoC reviews, including implementation, is fed into the work of other ICANN strategic activities wherever appropriate.

Rec #11

11.2

Implemented

11.2. Coordination of Reviews
The Board should ensure strict coordination of the various review processes so as to have all reviews complete before next ATRT review begins, and with the proper linkage of issues as framed by the AoC.

Rec #11

11.3

Implemented

11.3. Appointment of Review Teams
The Board should ensure that AoC Review Teams are appointed in a timely fashion, allowing them to complete their work in the minimum one (1) year period that the review is supposed to take place, regardless of the time when the team is established. It is important for ICANN to factor in the cycle of AoC reviews; the Review Team selection process should begin at the earliest point in time possible given its mandate.

Rec #11

11.4

Implemented

11.4. Complete implementation reports
The Board should prepare a complete implementation report to be ready by review kick-off. This report should be submitted for public consultation, and relevant benchmarks and metrics must be incorporated in the report.

Rec #11

11.5

Implemented

11.5. Budget transparency and accountability
The ICANN Board should ensure in its budget that sufficient resources are allocated for Review Teams to fulfill their mandates. This should include, but is not limited to, accommodation of Review Team requests to appoint independent experts/consultants if deemed necessary by the teams. Before a review is commenced, ICANN should publish the budget for the review, together with a rationale for the amount allocated that is based on the experiences of the previous teams, including ensuring a continuous assessment and adjustment of the budget according to the needs of the different reviews.

Rec #11

11.6

Implemented

11.6. Board action on Recommendations
The Board should address all AoC Review Team recommendations in a clear and unambiguous manner, indicating to what extent they are accepting each recommendation.

Rec #11

11.7

Implemented

11.7. Implementation Timeframes
In responding to Review Team recommendations, the Board should provide an expected time frame for implementation, and if that time frame is different from one given by the Review Team, the rationale should address the difference.

Rec #11

12.1

Implemented

12.1. The Board should implement new financial procedures in ICANN that can effectively ensure that the ICANN community, including all SOs and ACs, can participate and assist the ICANN Board in planning and prioritizing the work and development of the organization.

Rec #12

12.2

Implemented

12.2. The Board should explicitly consider the cost-effectiveness of ICANN’s operations when preparing its budget for the coming year, in keeping with ICANN’s status as a non-profit organization operating and delivering services in a non-competitive environment. This should include how expected increases in the income of ICANN could be reflected in the priority of activities and pricing of services. These considerations should be subject of a separate consultation.

Rec #12

12.3

Implemented

12.3. Every three years the Board should conduct a benchmark study on relevant parameters, (e.g. size of organization, levels of staff compensation and benefits, cost of living adjustments, etc.) suitable for a non-profit organization. If the result of the benchmark is that ICANN as an organization is not in line with the standards of comparable organizations, the Board should consider aligning the deviation. In cases where the Board chooses not to align, this has to be reasoned in the Board decision and published to the Internet community.

Rec #12

12.4

Implemented

12.4. In order to improve accountability and transparency ICANN’s Board should base the yearly budgets on a multi-annual strategic plan and corresponding financial framework (covering e.g. a three-year period). This rolling plan and framework should reflect the planned activities and the corresponding expenses in that multi-annual period. This should include specified budgets for the ACs and SOs. ICANN’s {yearly) financial reporting shall ensure that it is possible to track ICANN’s activities and the related expenses with particular focus on the implementation of the (yearly) budget. The financial report shall be subject to public consultation.

Rec #12

12.5

Implemented

12.5. In order to ensure that the budget reflects the views of the ICANN community, the Board shall improve the budget consultation process by i.e. ensuring that sufficient time is given to the community to provide their views on the proposed budget and sufficient time is allocated for the Board to take into account all input before approving the budget. The budget consultation process shall also include time for an open meeting among the Board and the Supporting Organizations and Advisory Committees to discuss the proposed budget.

Rec #12

Domain Name System
Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as""icann.org"" is not an IDN."