[CWG-Stewardship] Accountability measures required by CWG Proposal(s)
Alan Greenberg
alan.greenberg at mcgill.ca
Thu Jan 15 23:38:23 UTC 2015
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 (cs & gs) 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 wont 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 dont 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 dont
>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>
More information about the CWG-Stewardship
mailing list