[CCWG-Accountability] [ccnso-members] RE: [ccTLDcommunity] Fwd: Accountability measures required by CWG Proposal(s)

Fri Jan 16 14:17:54 UTC 2015

Dmitry, Stephen, Chris,

the more I think about it the more we already have the accountability measures in place that Chuck apparently is not aware of:

1) The current GAC Principles. Yes, you read right :-)-O

The more I read them, the more I can live with them, because they (are sufficiently vague to) cater to the incumbent ccTLD Manager, including (Intellectual Property) rights. 

They also state the obvious, namely that an individual or entity finding oneself in a particular country is subject to that country's law (however harsh).

2) The Framework of Interpretation ("FoI") Principles.

They basically state that the IANA function Manager has no recourse against a ccTLD Manager, other than revocation. They also state that a revocation can only happen against the wishes of the incumbent ccTLD Manager if said incumbent ccTLD Manager has substantially misbehaved.

These two Principles together are all the accountability a current (incumbent) ccTLD Manager needs. If a ccTLD Manager asserts rights, which NA-NiC and I do with regards to .NA, and perform a reasonable, honest and competent job, there is nothing that ICANN, or rather the IANA function Manager can do, unilaterally.

That some governments allege "sovereignty" over two characters, does not mean they have, whatever it is they actually mean, nor that the IANA Function Manager can act, unilaterally.

I have not formed a position on what should happen during a DELEGATION, be it de-novo, ie the next one should be .SS, or after a revocation. The FoI Principles declare two "classes" of stakeholders, namely "Interested Parties" and "Significantly Interested Parties" ("SIP"). 

The government automatically (and quite rightly so) is a SIP. 

This is helpful in the current stakeholder debate. Just because one is a stakeholder does not mean that one has powers beyond one's "stake". We need to define this more.

Bruce Tonkin's suggestion of contract AND policy is a good first step. As long as the IANA Function Manager abides by the above Principles by policy all is well. 

However, if it doesn't, it depends whether the IANA Function Manager is actually entitled to act. 

At present the USG alleges the Teranode Contract gives it the right, though it uses the word "stewardship", which, as an aside probably means it does not have actual rights. 

But, once the USG relinquishes control, no amount of contract between the IANA Function Manager or ICANN with a third party (let's call it Contrac-Co) can bind a ccTLD (another third party).

greetings, el

Sent from Dr Lisse's iPad mini

> On Jan 16, 2015, at 13:33, dmitry kohmanyuk <dk at cctld.ua> wrote:
> 
> 
> 
>> On 16 січ. 2015, at 13:53, Stephen Deerhake <SDeerhake at nic.as> wrote:
>> 
>> 
>> Chris,
>> 
>> Speaking for .as, I can say that the idea that "the CCWG [be tasked] with
>> drafting/creating an accountability process re delegation and re-delegation"
>> is a complete non-starter.
>> 
>> How can this be even be a serious consideration of the CCWG?
> 
> I am seconding this.
> 
>> 
>> I believe this issue has been addressed by the work of the FoI-WG, and I
>> don't see the need to re-invent the wheel here.  Perhaps the larger problem
>> is getting ICANN to acknowledge and endorse  the work/findings of the
>> FoI-WG...  I've seen scant evidence of this to date.
> 
> And before FOIWG, there was another working group on delegation and redelegation (which work led to decision to start FOI-WG effort.)
> 
> 
>> 
>> Best,
>> 
>> /Stephen
>> 
>> Stephen Deerhake
>> Director of Registry Services
>> AS Domain Registry
>> GDNS LLC
>> +1 212 334 3660
>> +1 212 656 1982 (fax)
>> sdeerhake at nic.as
>> sdeerhake at gdns.net
>> 
>> 
>> -----Original Message-----
>> From: cctldcommunity-bounces at cctld-managers.org
>> [mailto:cctldcommunity-bounces at cctld-managers.org] On Behalf Of Chris
>> Disspain
>> Sent: Thursday, January 15, 2015 5:58 PM
>> To: ccTLD Community List; ccNSO Council; ccNSO Members; cctldworld at icann.org
>> Subject: [ccTLDcommunity] Fwd: Accountability measures required by CWG
>> Proposal(s)
>> Importance: High
>> 
>> All,
>> 
>>> 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.
>> 
>> 
>> I know I keep pressing on this but I want to make sure we all understand
>> before I stop and let it go.
>> 
>> Are we, the ccTLDs comfortable with the CCWG drafting/creating an
>> accountability process re delegation and re-delegation? 
>> 
>> Is this something we should be doing ourselves pursuant to the
>> interpretations of the FoI WG?
>> 
>> 
>> Cheers,
>> 
>> Chris
>> 
>> 
>> 
>> Cheers,
>> 
>> Chris Disspain | Chief Executive Officer .au Domain Administration Ltd
>> T: +61 3 8341 4111 | F: +61 3 8341 4112
>> E: ceo at auda.org.au | W: www.auda.org.au auDA - Australia's Domain Name
>> Administrator
>> 
>> Important Notice - This email may contain information which is confidential
>> and/or subject to legal privilege, and is intended for the use of the named
>> addressee only. If you are not the intended recipient, you must not use,
>> disclose or copy any part of this email. If you have received this email by
>> mistake, please notify the sender and delete this message immediately.
>> Please consider the environment before printing this email.
>> 
>> Begin forwarded message:
>> 
>>> From: "Gomes, Chuck" <cgomes at verisign.com>
>>> Subject: Re: [CWG-Stewardship] Accountability measures required by CWG
>> Proposal(s)
>>> Date: 16 January 2015 01:55:07 AEDT
>>> To: Alan Greenberg <alan.greenberg at mcgill.ca>, CWG IANA 
>>> <cwg-stewardship at icann.org>
>>> 
>>> 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.
>>> 
>>> 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.
>>> 
>>> 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.
>>> 
>>> 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.
>>> 
>>> 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).
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> CWG-Stewardship mailing list
>>> CWG-Stewardship at icann.org
>>> https://mm.icann.org/mailman/listinfo/cwg-stewardship
>> 
>> _______________________________________________
>> ccTLDcommunity mailing list
>> ccTLDcommunity at cctld-managers.org
>> http://www.lists.cctld-managers.org/mailman/listinfo/cctldcommunity
>> 
>> To unsubscribe please send a blank email to
>> ccTLDcommunity-unsubscribe at lists.cctld-managers.org
>> 