[Internal-cg] CWG Proposal Dependencies on CCWG process Question from ICG Call #19

Russ Mundy mundy at tislabs.com
Wed Jul 8 20:00:47 UTC 2015


Gentle-folk,

On today's ICG call #19, there was a fair bit of discussion about the amount and type of dependencies that the CWG-Stewardship Proposal has on the results of the CCWG-Accountability (Workstream 1) process.  As I did my individual review of the CWG Proposal, I noted that there were a sizeable number of sections in the Proposal that mentioned one or more individual dependencies as well as what looks to be a "consolidated list" of the dependencies on pages 20 & 21.  

Although I did not see any inconsistancies or gaps between the dependencies identified in various parts of the Proposal and the "consolidated list", other ICG members might have more insight into this area.  So, I would like to ask if others have any comments or thoughts on the following questions:

- Do the dependencies listed in the CWG-Stewardship proposal on pages 20 & 21 (paragraph 106) adequately address the dependency points raised in various other parts of the CWG-Stewardship proposal?

- Are there any clarification or statements that the ICG should make or ask about the dependencies or any (possible) inconsistencies?


Russ M

p.s. As requested on the call, I have extracted the "consolidated list" sub-section titles as well as the full text below (any cut-and-paste errors are mine). I have not tried to list the various sections where individual dependencies are identified:

----> titles from "CWG dependency consolidated list" from page 20 & 21 of the CWG proposal <-----

1. ICANN Budget and IANA Budget.
2. Community Empowerment Mechanisms.
3. IFR.
4. CSC.
5. Separation Process.
6. Appeal mechanism.
7. Fundamental bylaws.

----> full text of "CWG dependency consolidated list" from page 20 & 21 of the CWG proposal <-----

The CWG-Stewardship proposal is significantly dependent and expressly conditioned on the implementation of ICANN-level accountability mechanisms by the Cross Community Working Group on Enhancing ICANN Accountability (CCWG-Accountability) as described below. The co-chairs of the CWG-Stewardship and the CCWG-Accountability have coordinated their efforts and the CWG-Stewardship is confident that the CCWG- Accountability recommendations, if implemented as envisaged, will meet the requirements that the CWG-Stewardship has previously communicated to the CCWG. If any element of these ICANN level accountability mechanisms is not implemented as contemplated by the CWG-Stewardship proposal, this CWG-Stewardship proposal will require revision. Specifically, the proposed legal structure and overall CWG-Stewardship proposal requires ICANN accountability in the following respects:

1. ICANN Budget and IANA Budget. The ability for the community to approve or veto the ICANN budget after it has been approved by the ICANN Board but before it comes into effect. The community may reject the ICANN Budget based on perceived inconsistency with the purpose, mission and role set forth in ICANN’s Articles and Bylaws, the global public interest, the needs of ICANN stakeholders, financial stability or other matters of concern to the community. The CWG-Stewardship recommends that the IFO’s comprehensive costs should be transparent and ICANN’s operating plans and budget should include itemization of all IANA operations costs to the project level and below as needed. An itemization of IANA costs would include “Direct Costs for the IANA department”, “Direct Costs for Shared resources” and “Support functions allocation”. Furthermore, these costs should be itemized into more specific costs related to each specific function to the project level and below as needed. PTI should also have a yearly budget that is reviewed and approved by the ICANN community on an annual basis. PTI should submit a budget to ICANN at least nine months in advance of the fiscal year to ensure the stability of the IANA services. It is the view of the CWG-Stewardship that the IANA budget should be approved by the ICANN Board in a much earlier timeframe than the overall ICANN budget. The CWG (or a successor implementation group) will need to develop a proposed process for the IANA-specific budget review, which may become a component of the overall budget review.

2. Community Empowerment Mechanisms. The empowerment of the multistakeholder community to have the following rights with respect to the ICANN Board, the exercise of which should be ensured by the related creation of a stakeholder community / member group:

(a) The ability to appoint and remove members of the ICANN Board and to recall the entire ICANN Board;

(b) The ability to exercise oversight with respect to key ICANN Board decisions (including with respect to the ICANN Board’s oversight of the IANA functions) by reviewing and approving (i) ICANN Board decisions with respect to recommendations resulting from an IFR or Special IFR and (ii) the ICANN budget; and

(c) The ability to approve amendments to ICANN’s “fundamental bylaws,” as described below.

3. IFR. The creation of an IFR which is empowered to conduct periodic and special reviews of the IANA functions (see Annex F). IFRs and Special IFRs will be incorporated into the Affirmation of Commitments mandated reviews set forth in the ICANN Bylaws.

4. CSC. The creation of a CSC which is empowered to monitor the performance of the IANA functions and escalate non-remediated issues to the ccNSO and GNSO. The ccNSO and GNSO should be empowered to address matters escalated by the CSC.

5. Separation Process. The empowerment of the Special IFR to determine that a separation process is necessary and, if so, to recommend that a Separation Cross-Community Working Group (SCWG) be established to review the identified issues and make recommendations. See Annex L for more detailed information as to approval requirements with respect to the formation of a SCWG and approval of SCWG recommendations.

6. Appeal mechanism. An appeal mechanism, for example in the form of an Independent Review Panel, for issues relating to the IANA functions. For example, direct customers with non-remediated issues or matters referred by ccNSO or GNSO after escalation by the CSC will have access to an Independent Review Panel. The appeal mechanism will not cover issues relating to ccTLD delegation and re- delegation, which mechanism is to be developed by the ccTLD community post- transition.

7. Fundamental bylaws. All of the foregoing mechanisms are to be provided for in the ICANN bylaws as “fundamental bylaws.” A “fundamental bylaw” may only be amended with the prior approval of the community and may require a higher approval threshold than typical bylaw amendments (for example, a supermajority vote).




More information about the Internal-cg mailing list