<html>
<body>
I think I answered on the call, but in case not...<br><br>
At 15/01/2015 09:55 AM, Gomes, Chuck wrote:<br>
<blockquote type=cite class=cite cite="">Alan,<br>
<br>
First let me put in writing the what I said in the last weekend
call: We need the Accountability CCWG to provide an accountability
process that registry operators (c’s & g’s) and possibly governments
in the case of ccTLDs can use in cases where they think delegation and
re-delegation decisions are not in line with approved policy or for
governments local law. This may be covered by your item 4 (<b>gTLD
Delegation or Redelegation Appeal within ICANN prior to the change
request going to IANA</b>) although I am not sure that appeals would
always have to happen before going to IANA; that would be preferred
though.</blockquote><br>
4 was included based on your comment at the meeting. I wored it as best
as I could based on my understanding, but it was just my take on
it.<br><br>
<blockquote type=cite class=cite cite=""> <br>
Alan – why do you think that this would conflict with item 2
(<b>Independent certification for delegation and re-delegation
requests</b>)? In the case of gTLDs, the decision whether or not a
gTLD could be delegated or re-delegated would happen before any
certification would occur. The certification would simply confirm
that required steps were followed properly. For gTLDs I think that
any appeal would preferably happen before any certification happened but
I suppose it could happen afterwards; those details would need to be
defined. I won’t try to venture into the ccTLD
world.</blockquote><br>
The possible conflict is that they both called for binding output. If the
item 2 was done in all cases, I was not sure if the concept of appealing
a binding outcome made sense or not.<br><br>
<blockquote type=cite class=cite cite=""> <br>
On a totally different topic with regard to item 2, I don’t think that is
something that we need the Accountability CCWG to deal with that.
In my view, that seems to be clearly in our court. Any
accountability for a certification decision would probably be covered by
general accountability processes.</blockquote><br>
You may be right. I included it because Jonathan and Lise did in an
earlier document.<br><br>
<blockquote type=cite class=cite cite=""> <br>
Why is item 6 (<b>Ability to Remove Directors</b>) an action that the CWG
needs from the CCWG. I agree that we need some specific
accountability mechanisms from the CCWG but we don’t specifically need
the one that would allow for the removal of Directors. That option
may provide some of the accountability that the CWG needs but we require
that specific option.</blockquote><br>
It was mentioned in one version of the ALAC proposal and I saw it in some
version of the auDA comment (although I appear to be wrong about it being
in the final auDA proposal).<br><br>
Alan<br><br>
<blockquote type=cite class=cite cite=""> <br>
Chuck<br>
<br>
<b>From:</b> cwg-stewardship-bounces@icann.org
[<a href="mailto:cwg-stewardship-bounces@icann.org" eudora="autourl">
mailto:cwg-stewardship-bounces@icann.org</a>] <b>On Behalf Of </b>Alan
Greenberg<br>
<b>Sent:</b> Thursday, January 15, 2015 1:12 AM<br>
<b>To:</b> CWG IANA<br>
<b>Subject:</b> [CWG-Stewardship] Accountability measures required by CWG
Proposal(s)<br>
<br>
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>
<b>Contract Co. Model Requirements<br><br>
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>
<b>Internal-To-ICANN Model Requirements<br><br>
</b>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>
</blockquote></body>
</html>