[discuss] [IANAxfer] [ccnso-igrg] Two accountability questions - help pls- Workshop 23 - ICANN accountability
Carlos A. Afonso
ca at cafonso.ca
Fri Sep 5 07:34:37 UTC 2014
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.
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
> 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.
> discuss mailing list
> discuss at 1net.org
More information about the discuss