[CWG-Stewardship] Names Community Organising Outside ICANN

[Guru Acharya]

I forward below a vital discussion that is happening outside CWG but
relates to the names proposal.

I've added Avri's suggestion as Option 5 here:
https://docs.google.com/document/d/1B46mlsyZUFF4bZfeWgGCdqIQHCP2BMOy4KZU4RiRiE8/edit?usp=sharing

---------- Forwarded message ----------
From: Avri Doria <avri at acm.org>
Date: Thu, Oct 23, 2014 at 9:07 AM
Subject: Re: [ianatransition] [] A thought re accountability...
To: ianatransition at icann.org


 Hi,

Well if the GNSO and ccNSO can't leave ICANN, maybe the IANA could leave if
necessary.  Wasn't that always the point of the NTIA being able to transfer
the contract?  So if we want to keep things similar, we need to maintain
the ability for the contract to move from ICANN to another organization, or
perhaps to a standalone organization.  We need 'separability' of the IANA
function to remain one of its attributes.

Stability and security demand that it stay where it is for the moment.  But
I believe that one outcome of the transition should be that it remains as
separable as it is now.  It  must be separable from ICANN if things go
badly.  Just as IETF can move its data to somewhere else it the
relationship with ICANN turns sour, the GNSO and ccNSO should be able to
move their data to somewhere else.  Personally I do not believe multiple
little IANAs is the best solution so perhaps we need something similar to
the ICG on a periodic basis (e.g. 5 years) to be created from the various
parts of the community to review the performance, the audit reports,
consultation based evidence &c. and to decide whether changes are
required.  These changes could be minor fixes or could be major and involve
transfering the responsibility.

Such a mechanism based solution would be easier to craft than one that
invovles creating yet another permanent superstructure that serves the same
set of stakeholders involved in the current operational communities.  The
idea that we would create an oversight for ICANN somewhat like ICANN itself
reminds me of tortoises stacked on the backs of tortoises all the way up as
we reach for true accountabity.  It would also not create a new
organization with the risk that brings of recapitulating ICANNs all the way
up.

A separability mechanism gives the GNSO and ccNSO the same ability that the
IETF and the RIRs have of finding another provider if necessary.  And
working together with the advice and participation of global stakeholders,
a decision can be made periodically on whether it has become necessary to
do so.  One thing we have to remember, it is not ICANN the corporation that
is the operational policy community for names.  It is the GNSO and the
ccNSO and the advising AC's that are.  Just as the ICG does not require the
ICANN Board's approval before sending its decision to the NTIA, so to this
periodic review committee of IETF, RIRs, GNSO ccNSO and related policy
advice mechanisms from the I* ecosystem, like ISOC, ALAC, GAC, SSAC, RSSAC,
& others, would not require ICANN Board approval to move the IANA function.

There may be some legal issues to be resolved in the creation of such a
mechanism, again the problem of how does one make ICANN corporate do what
ICANN corporate doesn't want to do.  Perhaps the construction of an IANA
trust to hold the contract, could solve that problem.

Just a thought.

avri



On 18-Oct-14 12:39, Milton L Mueller wrote:

I'm not Jordan but will answer this anyway ;-)

I would say it is _possible_.

The problem is that moving GNSO and CCNSO out of ICANN at this point
would involve such a complex set of organizational arrangements and
such destabilizing potential for power shifts among the stakeholder
groups involved that it could not be contemplated within anything like
the time frame we have.
Would it involve the creation of a new board? What would happen to GAC
and ALAC? Just 2 examples of the kind of knotty questions that would
have to be answered.

--MM


 -----Original Message-----
On Oct 15, 2014, at 3:18 PM, Jordan Carter <jordan at internetnz.net.nz>
<jordan at internetnz.net.nz>
wrote:

 If we are going to have a successful transition, it's really important for the

 numbers and protocols folks to understand that:

 ...
b) the names people cannot copy number/protocol accountability
mechanisms because they aren't organised outside ICANN
c) it isn't possible for names to organise outside ICANN in the way
numbers/protocol people do

 Jordan -

   Could you elaborate on why "c" isn't possible?



-----Original Message-----
On Oct 15, 2014, at 3:18 PM, Jordan Carter <jordan at internetnz.net.nz>
<jordan at internetnz.net.nz>
wrote:


A thought that has been bubbling away here at ICANN LA this week for me:

If we are going to have a successful transition, it's really important for
the numbers and protocols folks to understand that:

a) they have superior accountability situations to the names people today
b) the names people cannot copy number/protocol accountability mechanisms
because they aren't organised outside ICANN
c) it isn't possible for names to organise outside ICANN in the way
numbers/protocol people do
d) there may need to be structural changes or new bodies to provide a
workable settlement for names
e) without a workable settlement for names, there isn't going to be a
transition.

I raise this now because both for numbers and protocols there's a clear
direction to try and rule out any institutional changes.

I strongly caution against any part of the community being dogmatic about
any of these, because it will a) attract some attention that'll risk the
whole transition process failing (esp. from governments), and b) means that
a negotiated outcome is harder to achieve, also risking failure.

Wonder how others feel about this.

cheers
Jordan


_______________________________________________
ianatransition mailing list
ianatransition at icann.org
https://mm.icann.org/mailman/listinfo/ianatransition
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/cwg-stewardship/attachments/20141023/3b514b2f/attachment-0001.html>