
<html>

<body>

I believe that this is the minimalist list of accountability measures or

accountability-related processes that would be required based on the two

proposals currently under consideration.<br><br>

I have explicitly not included the wider list of measures that the CCWG

is considering for possible inclusion in its WS1, specifically those

which the community would like to see and for which the IANA transition

might provide additional impetus for the Board to approve, but are not

absolutely required to ensure that the IANA transition can occur. I

recognize that this is a judgement call that not all might agree

with.<br><br>

During the last of the four weekend meetings, Chuck mentioned one

additional issue, and referred to a chat exchange between him and Donna

during the third meeting that listed several other potential

accountability issues. Unfortunately, that chat transcript was not

preserved due to an error in saving it.<br><br>

The list of measures for the Contract Co. model is based on the list that

the Co-Chairs created in December, augmented by Chucks suggestion. I do

not believe that the December list has been negated by any work done in

the interim, but perhaps I have missed something. I could not find a

rationale for the inclusion of the first of the three items, but include

it here so that the CWG could decide if it is based on a real need

associated with the proposal or not. If included, I would suggest the CWG

be more specific as to under what conditions it would apply. Chuck's

suggestion seems to conflict with the 2nd measure in that the 2nd measure

is specified as being binding. I am also not sure if it could possibly be

replaced by the more generalized IAP (once the request goes to

IANA).<br><br>

The requirements for the internal-to-ICANN model are based on my

discussions with a number of people over the last weeks.<br><br>

<font size=5><b>Contract Co. Model Requirements<br><br>

</font>1. Independent Review of Board Actions<br><br>

</b>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

discretions.<br><br>

<b>2. Independent certification for delegation and re-delegation

requests<br><br>

</b>This would be a replacement for the authorization function for all

changes to the Root Zone or its WHOIS Database currently performed by the

NTIA. The replacement mechanism would have gTLD requests for delegations

and re-delegations authorized by an independent third party and its

decision on these matters would be binding on ICANN/IANA. <br><br>

<b>3. Independent Appeals Panel<br><br>

</b>An independent review panel must be set up 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.<br><br>

<b>4. gTLD Delegation or Redelegation Appeal within ICANN prior to the

change request going to IANA<br><br>

</b>A Registry could appeal an ICANN decision to delegate or redelegate

and gTLD, based on policy not being followed (or presumably contractual

terms not being followed).<br><br>

<font size=5><b>Internal-To-ICANN Model Requirements<br><br>

</b></font>This model will require all of the above measures plus the

following:<br><br>

<b>5. Control over ICANN Board decisions.<br><br>

</b>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).<br><br>

<b>6. Ability to Remove Directors<br><br>

</b>The ability of the overall multi-stakeholder community to remove some

or all of the Board Directors. In the case of a full Board removal, a

mechanism would be required for appointing an Interim Board and then a

replacement regular Board. In addition, ACs and SOs could be given the

right to recall their appointed Director(s).<br><br>

<br><br>

<br><br>

<br><br>

<br>

</body>

</html>