By Gangesh Varma
Recommendation 7
Continuing our series on tracking the CCWG Accountability Process, in our fifth post, we look at Recommendation 7 which concerns ICANN’s Independent Review Process. This post examines the key changes and developments since the 3rd Draft Proposal was opened for public comment. Our previous posts can be found at this index page for the CCWG Accountability Blog Series.
Recommendation #7: Strengthening ICANN’s Independent Review Process.
Recommendation 7 attempts to strengthen ICANN’s existing Independent Review Process (IRP) to accommodate the changes post transition. ICANN’s IRP exists to ensure that ICANN does not exceed the scope of its mission, and operates within its Articles of Incorporation and Bylaws. The public comments largely supported this recommendation while seeking clarification and details to avoid any gaps in the implementation. They key clarifications regarding this recommendation revolved around the scope of the IRP, Community IRP (related to Recommendation #4), and suggestions to be provided as implementation details to the Implementation Oversight Team (IOT).
Scope of IRP
The discussions regarding the scope of the IRP can be discussed as per the following changes from the 3rd Draft Proposal:
Inclusion of PTI
Inclusion of actions or inactions of Post Transition IANA (PTI): The comments of the CWG-Stewardship indicated that the scope of IRP must be extended to appeals from direct customers of the IANA naming function that are not resolved through mediation.[1] It was decided that while the expansion of the scope to include the PTI is non-controversial it should be subject to the two conditions. First, it will be limited to the naming functions. Second, the standard of review for PTI cases will be an independent assessment of whether there is a material breach of PTI obligations under the contract with ICANN and this has resulted in material harm to the complainant.
Inclusion of DIDP Decisions
The idea that a denial of access to documents under DIDP can be escalated to an appeal through IRP was subject to considerable debate. The Board in its comments stated that reference to IRP to resolve under DIDP claims should be restricted to instances where such decisions violate ICANN’s bylaws as it currently does. It also suggested that the DIDP escalation path be made more robust and refined to involve a greater role for the Ombudsman under Work Stream 2. While DIDP processes are detailed in Work Stream 2, the CCWG agreed with the Board position and the final text of the recommendation specifically provides that the scope of IRP includes issues relating to DIDP decisions. However, it also specifies that this is restricted to cases where the DIDP decisions by ICANN are inconsistent with the ICANN Bylaws.
Exclusion of Protocol/Parameters Decisions
The Internet Advisory Board’s (IAB) comment to the 3rd Draft Proposal explicitly refused to support the recommendation unless it excluded the protocol/parameters decisions. It had stated in its comments to the 2nd Draft Proposal, that the protocol parameters community had a “well-tested appeals process” and that “a parallel process would be counter-productive” and in conflict with the Memorandum of Understanding between the IETF (including the IAB) and ICANN.
Limitation of challenge to Expert Panel Decisions
The Board in its comments had raised a concern with extending the IRP to challenge decisions of expert panels. It stated that IRP should not be used to challenge specific substantive operation decisions and such a measure would move away from the purpose of the IRP. Discussions during call #76 also highlighted the need to set up a process with respect to expert panel decisions and the need to be able to challenge the decisions where it is in conflict with the ICANN Bylaws. Eventually, the final text of Recommendation 7 provides that an IRP challenge to expert panel decisions would be limited to whether the panel decision is consistent with ICANN’s bylaws.
Community IRP
The power to launch a community IRP is one of the seven powers of the Empowered Community provided under Recommendation #4. Certain details applicable to this power are clarified under Recommendation #7.
Legal Expenses
The first clarification was with regard to the legal fees in case of the Community IRP. Recommendation #7 clarifies that the legal expenses of the Empowered Community associated with the community IRP will be borne by ICANN. In his comment, Prof. Jan-Aart Scholtecautions that this arrangement might prompt a conflict of interest. He recommends that the financial resources be allocated to a trust fund which will be institutionally separate and this trust may administer the legal fees. This concern however is not addressed in the proposal, and may be considered by the Implementation Oversight Team.
Community IRP Challenging PDP
Recommendation #7 also provides an exclusive carve out language for a community IRP that challenges the result of a Policy Development Process (PDP). The exclusionary clause discussed during call #78 provides that no community IRP can be launched against the results of a PDP without the support of the supporting organization that developed such PDP. It also provides that the in case of joint PDPs, it would require the support of the supporting organizations that developed the PDP. This language is also included in Recommendation 4.
While these are the key aspects in the development of Recommendation 7, a substantial amount of detail concerning its implementation will be addressed by the Implementation Oversight Team.
[1] See paragraph 8 of Annex 07. It may be noted that the CWG-Stewardship Proposal dependencies also requires the ability to ensure PTI compliance through the IRP.
Comments are closed