[CWG-Stewardship] Accountability measures required by CWG Proposal(s)

[Alan Greenberg]

I think I answered on the call, but in case not...

At 15/01/2015 09:55 AM, Gomes, Chuck wrote:
>Alan,
>
>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 (gTLD 
>Delegation or Redelegation Appeal within ICANN 
>prior to the change request going to IANA) 
>although I am not sure that appeals would always 
>have to happen before going to IANA; that would be preferred though.

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.

>
>Alan – why do you think that this would conflict 
>with item 2 (Independent certification for 
>delegation and re-delegation requests)?  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.

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.

>
>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.

You may be right. I included it because Jonathan 
and Lise did in an earlier document.

>
>Why is item 6 (Ability to Remove Directors) 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.

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).

Alan

>
>Chuck
>
>From: cwg-stewardship-bounces at icann.org 
>[mailto:cwg-stewardship-bounces at icann.org] On Behalf Of Alan Greenberg
>Sent: Thursday, January 15, 2015 1:12 AM
>To: CWG IANA
>Subject: [CWG-Stewardship] Accountability measures required by CWG Proposal(s)
>
>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.
>
>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.
>
>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.
>
>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).
>
>The requirements for the internal-to-ICANN model 
>are based on my discussions with a number of people over the last weeks.
>
>Contract Co. Model Requirements
>
>1. 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 discretions.
>
>2. Independent certification for delegation and re-delegation requests
>
>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.
>
>3. Independent Appeals Panel
>
>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.
>
>4. gTLD Delegation or Redelegation Appeal within 
>ICANN prior to the change request going to IANA
>
>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).
>
>Internal-To-ICANN Model Requirements
>
>This model will require all of the above measures plus the following:
>
>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).
>
>6. Ability to Remove Directors
>
>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).
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/cwg-stewardship/attachments/20150115/02127194/attachment-0001.html>