Skip to main content
Resources

Work Stream 2 – Recommendations to Increase SO/AC Accountability

The Cross-Community Working Group on Enhancing ICANN Accountability (CCWG-Accountability) directed these recommendations at the Supporting Organizations (SOs), Advisory Committees (ACs), stakeholder groups, constituencies, and Regional At-Large Organizations for their consideration as best practices to be adopted in efforts to increase their accountability. Two of the recommendations are intended for ICANN org to own and implement.

Recommendations 6.1, 6.2, 6.3, 6.4, and 6.5 span suggestions aimed at improving existing SO and AC processes for accountability, transparency, participation, and outreach, including their documentation and publication, as well as at foreseeing regular reviews and updates of their policies and procedures. ICANN org owns two recommendations.

Rec Description Implementation Status

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.

In progress.

6.1.2

SO/AC/Groups should document their procedures for members to challenge the process used for an election or formal decision.

In progress.

6.1.3

SO/AC/Groups should document their procedures for non-members to challenge decisions regarding their eligibility to become a member.

In progress.

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.

In progress.

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.

In progress.

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.

Complete. Completed in Q3 2023. See implementation documentation.

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.

Complete. Completed in Q1 2024. See implementation documentation.

6.2 Transparency

6.2.1

Charter and operating guidelines should be published on a public webpage and updated whenever changes are made.

Complete. Completed in Q3 2023. See implementation documentation.

6.2.2

Members of the SO/AC/Group should be listed on a public webpage.

Complete. Completed in Q3 2023. See implementation documentation.

6.2.3

Officers of the SO/AC/Group should be listed on a public webpage.

Complete. Completed in Q3 2023. See implementation documentation.

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.

In progress.

6.2.5

Records of open meetings should be made publicly available. Records include notes, minutes, recordings, transcripts, and chat, as applicable.

In progress.

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.

Complete. Completed in Q3 2023. See implementation documentation.

6.2.7

Filed comments and correspondence with ICANN should be published and publicly available.

Complete. Completed in Q3 2023. See implementation documentation.

6.3 Participation

6.3.1

Rules of eligibility and criteria for membership should be clearly outlined in the bylaws or in operational procedures.

Complete. Completed in Q3 2023. See implementation documentation.

6.3.2

Where membership must be applied for, the process of application and eligibility criteria should be publicly available.

Complete. Completed in Q3 2023. See implementation documentation.

6.3.3

Where membership must be applied for, there should be a process of appeal when application for membership is rejected.

In progress.

6.3.4

An SO/AC/Group that elects its officers should consider term limits.

Complete. Completed in Q3 2023. See implementation documentation.

6.3.5

A publicly visible mailing list should be in place.

In progress.

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.

In progress. Targeted completion date: Q1 2024.

6.3.7

A glossary for explaining acronyms used by SO/AC/Groups is recommended.

In progress.

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.

In progress.

6.4.2

Each SO/AC/Group should maintain a publicly accessible website/wiki page to advertise their outreach events and opportunities.

In progress.

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.

In progress.

6.4.4

Outreach objectives and potential activities should be mentioned in SO/AC/Group bylaws, charter, or procedures.

In progress.

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.

In progress.

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.

In progress.

6.5.2

Members of SO/AC/Groups should be involved in reviews of policies and procedures, and should approve any revisions.

In progress.

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.

In progress.

6.6 Mutual Accountability Table

6.6.1

It is recommended that the Mutual Accountability Roundtable not be

implemented.

N/A

6.6.2

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 though ICANN's Ombuds Office, whose bylaws and charter are adequate to

handle such complaints.

N/A

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