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

Jonathan Robinson jrobinson at afilias.info
Thu Jan 15 22:16:18 UTC 2015



Alan's second definition /  interpretation is correct. Apologies for sending
something in shorthand which I should probably have expressed more fully.
Think of it as Tweet.


In the call today that is periodically held between ICANN staff and the SO /
AC / SG chairs, Fadi made reference to the importance of this CWG's work and
additionally its link with that of the CCWG.

In making that reference he made it clear that he understood the CWG's work
may need to be so dependent on the outcome of the CCWGs work that a proposal
from the CWG could contain a form of conditionality sufficiently strong that
it could be referred to as a "poison pill". In other words, our proposal
becomes invalid ("poisoned") if the CCWG's work doesn't adequately deal with
certain specified dependencies.


I hope that clarifies. Please note the meetings are recorded and transcribed
so it may be better to refer to what was actually said (as opposed to my
memory of it) if anything needs to be taken further.






From: Alan Greenberg [mailto:alan.greenberg at mcgill.ca] 
Sent: 15 January 2015 21:57
To: Gomes, Chuck; jrobinson at afilias.info; 'CWG IANA'
Subject: RE: [CWG-Stewardship] Accountability measures required by CWG



The typical meaning of a poison pill is a provision to prevent or forestall
a hostile corporate takeover, but it is also used in reference to a proposed
bill (as in an act of a legislature) where an amendment is made which causes
it to be distasteful to someone who otherwise would have supported it. I
presume that this latter meaning is implied, in that a provision of the CWG
proposal would invalidate it in its entirely if specific accountability
measures were not taken.


At 15/01/2015 02:44 PM, Gomes, Chuck wrote:

I do not understand the 'poison pill' point.
From: cwg-stewardship-bounces at icann.org [
mailto:cwg-stewardship-bounces at icann.org
<mailto:cwg-stewardship-bounces at icann.org> ] On Behalf Of Jonathan Robinson
Sent: Thursday, January 15, 2015 8:16 AM
To: jrobinson at afilias.info; 'Alan Greenberg'; 'CWG IANA'
Subject: Re: [CWG-Stewardship] Accountability measures required by CWG
Note the reference that Fadi has very recently made to the possible use of
an over-arching conditionality (in the CWG proposal) in the form of a
"poison pill" i.e. our (CWG) proposal being invalid unless certain key
accountability conditions are met.
From: Jonathan Robinson [ mailto:jrobinson at afilias.info
<mailto:jrobinson at afilias.info> ] 
Sent: 15 January 2015 12:46
To: 'Alan Greenberg'; 'CWG IANA'
Subject: RE: [CWG-Stewardship] Accountability measures required by CWG
Alan (and the CWG),
One question that strikes me which we will almost certainly be asked to
clarify is; What is the problem/issue that you (we) are trying to solve for
in each case?
The purpose for establishing the motivation is that it may be that there is
more than one remedy and that one remedy is more desirable than another
(for whatever reason including but not limited to legal advice).
Perhaps a table in the form of issue / proposed resolution 1 / proposed
resolution 2?
From: Alan Greenberg [ mailto:alan.greenberg at mcgill.ca
<mailto:alan.greenberg at mcgill.ca> ] 
Sent: 15 January 2015 06:12
Subject: [CWG-Stewardship] Accountability measures required by CWG
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

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/ba51d696/attachment.html>

More information about the CWG-Stewardship mailing list