[discuss] [IANAxfer] [ccnso-igrg] Two accountability questions - help pls- Workshop 23 - ICANN accountability

John Curran jcurran at istaff.org
Tue Sep 2 16:21:05 UTC 2014

On Sep 2, 2014, at 6:15 PM, Burr, Becky <Becky.Burr at neustar.biz> wrote:

> I think we need to be clear about what kind of accountability we are
> talking about in any point in time-
> -  ICANN must be accountable to the IANA user community for performing the
> IANA functions in accordance with agreed upon SLAs etc.  There are a lot
> of ways to handle this - contracts with individual users or organizations
> representing users, etc.

Becky - 

I believe that the "IANA Operator" must be accountable to the IANA 
user communities (specifically, the policy development bodies that 
provide the IANA with the policies to be followed in registry 
administration) for performing the IANA functions.

The "IANA Operator" is today ICANN, should tomorrow be ICANN, but 
that should be because ICANN is doing a great job with IANA services 
and that it makes sense to continue; i.e. there should not be anything 
structural that locks the IANA services to any particular organization,
as it should always be possible for the registry policy development 
bodies to move the IANA registry administration tasks to a new 
operator in cases of chronic failure to perform by the present IANA

I do not believe that the IANA Operator can be "accountable" to 
"individual users", if by that term you mean end-users rather than
communities of users who are making use of a particular registry.
At the end of the day, the IANA Operator needs to perform according
to adopted policy, and that means accountability to the parties that 
develop that policy.  

(Questions of how to keep policy development bodies accountable to 
their communities of interest are equally important, but quite a 
distinct question.)

If one supposes that IANA is to be simultaneously accountable to a
registry policy development body (e.g. the IETF, or gNSO) and also
to an association of individual users, and then there is a conflict
in expectations, the IANA would need to make a "judgement" and that
should not be IANA task.  Setting up any structure where the IANA 
may decide not to follow the adopted policy is actually making it 
_less accountable_ to the direct IANA user community for accurate

> -  ICANN must be accountable to the ICANN community and to others
> materially harmed by its actions that are not consistent with a set of
> baseline, agreed upon behaviors (set out in a compact, for example,
> reflecting core values and principles of non-discrimination, due process,
> etc.).  In this context, I don’t think we should be talking about
> “external” v. “internal.”  I would like to see a dispute resolution
> function that is internal but independent.  The current arbitration
> process produces completely incoherent responses, as we have seen in the
> context of new gTLDs.  It would be better to have arbitrators who
> understand what ICANN is and how it works, and who can- through dispute
> resolution - provide guidance for the future.  Of course, this probably
> reflects a common law bias, but it seems a better fit for ICANN.

That's certainly one approach; however, it's going to be very challenging
to provide evidence that these mechanisms (a "compact of agree behaviors",
a "internal but independent" dispute resolution process, etc.) are going
to be durable in nature and still in existence and operating correctly in
decades to come.  To the extent that they are all structures within the
corporation, and subject to change by Board at its discretion, there is 
no assurance that these would not be swept aside when found inconvenient
with the Board's perception of serving the public interest.

Compare/contrast that to a membership-based structure (wherein the rights 
can be anchored in bylaws in a manner not subject to change without clear
consent) or a contractual model (wherein the rights are explicit between
parties including the conditions for amendment); either of those models
provide for very clear accountability including traditional legal redress;
it is not clear how the equivalent is provided in your compact/internal
dispute resolution approach.


Disclaimers: my views alone.

More information about the discuss mailing list