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

[Carlos A. Afonso]

At the opening of today's IGF main session on IANA functions' 
transition, a speaker talked about IANA as if it were an entity in itself.

I now see this phrase from John Curran's msg below: "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 operation."

Of course John knows what IANA means. And of course a set of functions 
is unable to make judgements -- humans/institutions do (for the good or 
the bad of it). I wonder if other discussants have the same clarity, so 
I think we should be extra-careful with our terminology.

IMHO

--c.a.

On 09/02/2014 01:21 PM, John Curran wrote:
> 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
> operator.
>
> 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
> operation.
>
>> -  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.
>
> /John
>
> Disclaimers: my views alone.
>
>
>
>
> _______________________________________________
> discuss mailing list
> discuss at 1net.org
> http://1net-mail.1net.org/mailman/listinfo/discuss
>