Skip to main content

CCWG-Accountability co-Chairs Statement Leading into ICANN54 in Dublin

Members and participants of the CCWG-Accountability are on their way to Dublin for a full week of intense work and engagement with other ICANN54 attendees. A list of the Enhancing ICANN Accountability-related meetings is available here.

As co-Chairs, we are grateful to the volunteers, support staff, advisors and independent counsel who put up a tremendous effort to prepare for these meetings. They deserve and have earned the community's greatest respect and the deepest recognition.

We are very pleased that the analysis of the 93 comments received in the 2nd Public Comment period is now complete. Work Parties (WPs) have produced summaries, analyzed the content of submissions and identified options for the group's consideration. You can find these essential inputs here.

In anticipation of the various meetings, we are providing a rough assessment of our progress through a Scorecard, which can be found below:

Report Section Subtopic WP Owner Status Relationship with CWG-Stewardship Requirements
3.1. Revised mission, commitments & core values Refine wording of mission & core values based on public comment feedback WP2 To be refined Represents the standard of review for the IRP, which is a requirement from the CWG-Stewardship
3.1. Revised mission, commitments & core values Human rights bylaw article WP4 To be considered  
4. "Fundamental Bylaws" Scope WP2 Supported Fundamental Bylaws are a requirement of the CWG-Stewardship
5.1. Independent Review Panel enhancements   WP2 To be refined IRP is a requirement from the CWG-Stewardship
5.2. Reconsideration process Enhancements   WP2 To be refined  
6. Mechanism to represent the community (community council or other) Implementation model discussion WP1 Some disagreement The mechanism is necessary to provide for the powers required by CWG-Stewardship
6. Mechanism to represent the community (community council or other) Community Forum WP1 To be refined The mechanism is necessary to provide for the powers required by CWG-Stewardship
6. Mechanism to represent the community (community council or other) Decision making mechanisms WP1 Some disagreement The mechanism is necessary to provide for the powers required by CWG-Stewardship
7.1. Reject Budget/strategy PC2 received some proposals to adjust. Also pending on community mechanism discussions WP1 To be considered The CWG-Stewardship requires community rights, regarding elaboration and approval of the budget, especially with relation to IANA
7.2. Reject Bylaw change Details are pending community mechanism discussions WP1 To be refined  
4.5. Approve "Fundamental Bylaw" change Details are pending community mechanism discussions WP1 To be refined CWG-Stewadship requires fundamental Bylaws mechanisms to protect against future changes of accountability mechanisms
7.3. Individual Board Director removal PC2 received some proposals to adjust. Also pending on community mechanism discussions WP1 To be considered Community rights, specifically to appoint/remove members, recall entire Board
7.4. Recall of the ICANN Board PC2 received some proposals to adjust. Also pending on community mechanism discussions WP1 To be considered Community rights, specifically to appoint/remove members, recall entire Board
9. AoC reviews transcription into the Bylaws Refine details WP1 Supported CWG-Stewardship requires an IANA Function Review as a "Fundamental Bylaw"
10. Bylaw changes recommended after stress tests Discuss ST 18 and refine ST-WP Some disagreement  
10. Stress Tests (Based on WA 4 and ST-WP work) Some comments received on ST 29 & 30 ST-WP To be refined  
11. Items for consideration in Work stream 2 Scope to be defined versus continuous improvement items Co-chairs To be considered  
8.3. SO/AC Accountability Consider SO/AC Accountability WP3 To be refined  
12. Implementation Plan including Timing   Co-chairs To be refined Reviewed draft started

Download a PDF of this Scorecard here.

A significant number of items have a status of "To be refined," but we are confident that these refinements can be provided shortly to meet stakeholder expectations. Our hope is that many of these will turn into a "Supported" status by the end of the Dublin meeting.

Areas where more work is needed to reach consensus are in orange and red. Several of these items are related to community powers and have received broad support in principle. However, the implementation model for these powers remains a fundamental discussion. Until a solution is found that does not raise any significant level of objection, these issues cannot be finalized.

There have been significant discussions in the last few weeks, on the mailing list as well as during the face-to-face meeting in Los Angeles. These discussions were useful to better understand the various perspectives and the areas where views were diverging.

As co-Chairs, we would describe these discussions as follows:

  • Views in the community differ on the level of enforceability that is Strictly required for the community powers, in light of the CWG-Stewardship conditions (beginning at paragraph 106).
  • The CCWG-Accountability has requested legal input to provide more details on the practical differences in terms of complexity, delay or cost associated to the various levels of enforceability.
  • Significant concerns were raised regarding the weight of the various SOs and ACs in the community mechanism, as well as the ability to opt-in or opt-out of this system. Alternative decision making mechanisms, such as consensus or rough consensus, are being investigated.
  • The requirement of SO and AC accountability to the global Internet community as a whole has been a key theme of the comments received, although few concrete suggestions are offered (see WP3 documents)
  • A 2-phase scenario to implement community empowerment is being investigated, which could help accommodate some of the concerns related to the significance of the changes proposed by the CCWG-Accountability 2nd Draft Report.

The CCWG-Accountability is fully mobilized and committed to make great strides during the Dublin meeting. We are aware that the finalization of our recommendations is the last missing piece in the IANA Stewardship Transition puzzle and we take this responsibility very seriously. We will welcome in Dublin all contributions to this bottom-up, multistakeholder, consensus driven process.

All hands on deck! Looking forward to a productive week in Dublin!

CCWG-Accountability co-Chairs
Thomas Rickert
León Sanchez
Matheiu Weill

Comments

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