[CWG-Stewardship] Update on the Integrated model.

[Jonathan Robinson]

Suzanne,

 

Thanks for this. 

 

The points you make below are interesting to me because they happen to align
with my current understanding on the issue (of IANA accountability AOT ICANN
accountability).

 

Moreover, it seems to me that dealing with an intransigent IANA here (i.e. a
contractor that does  not do things they *are* supposed to do, or does
things they are *not* supposed to do) is the point where an Independent
Appeals Process may be relevant. And this (the conditions for when an IAP
may be relevant) represents to me a good example of the type of focused
issue of what I had envisaged a design team might be able to work on.

 

Jonathan 

 

From: Suzanne Woolf [mailto:suzworldwide at gmail.com] 
Sent: 22 February 2015 18:48
To: Andrew Sullivan
Cc: cwg-stewardship at icann.org
Subject: Re: [CWG-Stewardship] Update on the Integrated model.

 

 

On Feb 22, 2015, at 1:22 PM, Andrew Sullivan <ajs at anvilwalrusden.com> wrote:





The IANA function is really extremely small.  It's a critical but
basically boring book-keeping function.  As near as I can tell, there
have been practically no cases where there was any accusation that
IANA did not do exactly what it was supposed to do.  There were
historically some complaints that IANA didn't act expeditiously, and
there were _lots_ of historic complaints that an IANA function was
being used by ICANN to try to impose ICANN policies.  The former is an
SLA issue; the latter is actually a policy matter with enforcement
attempts in the policy side of the organization, and is not actually
an issue with IANA at all.  So in my opinion, accountability _for
IANA_ would help with the SLA stuff (and also with the case that IANA
"goes rogue") but would not help with the policy issues.

Does that match the accountability concerns others have?

 

Possibly as a help in thinking about this question..

 

There's a question here of what people are being held accountable *for*.

In addition to separability as a final backstop, the other feature of the
model the IETF has, and the RIRs are seeking, is that their contractor for
the IANA functions that affect them is held accountable for two things: 
            1. Doing what they're told, in a timely and correct fashion
            2. Not doing anything else

If the contractor doesn't do things they *are* supposed to do, or does
things they are *not* supposed to do, they're accountable for their poor
performance-- but the directions come from the policy body, as
implementation of its policies, and the contractor's accountability is to
the policy body. In ICANN's case, this is where the Board's accountability
touches IANA as an operational function, and is separate from any role of
the Board or accountability of the Board regarding ICANN as a policy body.

The contractor is not accountable for following improper directions from the
policy body, as long as the agreed-upon processes between the policy body
and the contractor are followed. It doesn't matter whether those directions
are improper because process wasn't followed internally to the policy body,
or because properly-executed policy nonetheless leads to unacceptable
outcomes. In both of those cases, there's no wrongdoing by the contractor,
and the only accountability that matters is that of the policy body to its
users. 

In the IETF model, accountability for making bad decisions about what to
tell IANA to do is maintained in a number of ways, but they're outside of
the IANA SLAs and I don't see any of them changing in the event that a new
contractor is selected for the protocol parameters registries. 

Bluntly, isn't the major accountability concern for root zone management
that ICANN will give inappropriate directions to IANA staff in the course of
implementing policy? If so, in the case we're concerned about, what's broken
is the policy body. Changing the status of IANA staff from employees to
outside contractors, or changing contractors, wouldn't help at all; the
problem is internal to the policy body, and any IANA contractor (internal or
external) would be obligated just the same to follow its directions.  The
place to prevent or stop or fix the results of bad directions to IANA is in
ICANN, not IANA.

 

I think this argues that the group needs to refine the definition of what
kind of accountability belongs in the IANA transition discussion. It also
argues for some care in applying the IETF/RIRs' model for names, or
expecting them to participate in a model that may fit names better than
protocol parameters or addresses.

 

 

Suzanne

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/cwg-stewardship/attachments/20150222/1bd27bb6/attachment.html>