The following are dependencies on ICANN accountability that the models being discussed in the CWG-Stewardship have discovered to date. Some may be specific to a particular model or variant of that model.

1. Budget Accountability

 Currently it is impossible to understand the actual costs of IANA, including its share of ICANN overhead costs and the breakout cost of the various services provided by ICANN in support of the different operational communities. CWG-Stewardship needs this level of accountability moving forward in its work in understanding the comparative cost or simply the cost of operation of the options or variants being considered. This will remain an ongoing stewardship dependency, especially in any internal solution for transition.  
2. Accountability for (re)delegations

We need the Accountability CCWG to provide accountability mechanisms and processes that registry operators (c’s & g’s) and possibly governments in the case of ccTLDs can use in cases where they think delegation and redelegation decisions are not in line with approved procedure or policy or for governments local law.  Note that the accountability needed in this regard may not directly relate to IANA functions per se; for example, in the case of gTLD (re)delegations the actual (re)delegation decision would not be made by the IANA functions operator and the decision would be made before a request is ever sent to the operator.  But it is essential for registry operators (c’s & g’s) to have a recourse mechanism if needed whether it occurs before, during or after the actual performing of the IANA services.  

It should also be noted that the accountability mechanism(s) may be different for gTLDs and ccTLDs.  With regard to ccTLD (re)delegation, what is the relation between ICANN accountability and national accountability in (re)delegation procedures?

It is recognized that this item could be related to item 4 below and in the case of ccTLDs to items 3 and/or 5 as well.
3. Independent Review of Board Actions

Change the ICANN Bylaws to specify that under certain circumstances (to be defined) the determinations of an Independent Review of Board Actions Panel would be binding and not implemented at the Board's discretion.

It is possible that this could be used for item 2 above in the case of ccTLDs.

4.   Independent Appeals Panel

An independent review panel is needed to deal with contested changes to the Root Zone or its WHOIS Database. Although discussions are still ongoing as to the specifics of such a proposal, it is generally agreed that the decisions of such a panel would be binding. There may also be a need for an injunction-like mechanism to defer the change in question during the appeal process.

This could be used for item 2 above.

5. Control over ICANN Board decisions.

The ability for ICANN Stakeholders, potentially augmented by other non-ICANN entities, to mandate or overrule, a particular Board decision, or to require that the implementation of such a decision be subject to consideration of an independent, binding review. These measures might need to be augmented by advance notice of such decisions and allow the MS community to react. In the most restricted form, this ability might be restricted to decisions related to IANA, but in reality, it may not be practical to define this scope limitation (ie how to recognize an IANA-related decision).

This could be used in item 2 above for ccTLDs.