[CWG-Stewardship] Narrow focus (was: CWG-Stewardship Chairs' Statement - Summary of ICANN 52 Meeting)

[Andrew Sullivan]

Hi Milton,

On Thu, Feb 19, 2015 at 05:04:33AM +0000, Milton L Mueller wrote:
> 
> To me, "narrow" is code for "let's pretend that NTIA oversight with contracting authority wasn't an critical and essential aspect of the status quo." In other words, this approach seems like a way of pretending that we don't need significant new accountability mechanisms to deal with the post-NTIA world. 
> 

Well, sure, if you redefine it that way then it's obviously a bad
idea.  Just to be explicit, however, I am not advocating that
pretending.  I do wonder how live an option it ever was that NTIA
would remove ICANN from the IANA operator role, but I think that is
the sort of counterfactual question that is interesting to
philosophers but not a very useful guide to action.

You touch on the point I was trying to make, however:

> worst. And the latter simply shifts the problem to bylaw changes and
> accountability changes within ICANN.

Yes.  And what I was suggesting was that there is an entirely other
group that is supposedly responsible to deliver such mechanisms.
Therefore, we need not repeat that work, and instead need only to
specify the necessary and sufficient conditions for what "adequate
accountability" is.  Then we (or anyone else) have a simple matter to
determine whether CCWG-accountability's "track 1" delivers what is
necessary and sufficient.  But we at least will have a proposal ready
against which others could work.  And it prevents us from having to
make decisions about (e.g.) structural separation vs. external
contracting co. when another group is supposed to be doing that work
too.

>  This is a false hope. Either the community has separability or it
> doesn't. It is a binary possibility in the end.

I'm not entirely sure I agree that this is as clear dichotomy as you
say.

What I understand we're (supposed to be) worried about is the IANA
function.  That's quite limited.  AFAIK nobody has ever suggested that
IANA has well and truly screwed up.  AFAIK, there have been complaints
that IANA moved too slowly in the past, but that has mostly been
remedied in recent years.  There remain some concerns about
redelegations (particularly of ccTLDs), but nobody seems to suggest
that IANA is not following the policy they have; instead, the
objection is to the policy as such.

I _think_, however, that what you're arguing is that things are
different between the names community and the policy-generation
organization for names, and the other communties and the
policy-generation organization for those topics.  The IETF is outside
ICANN, and the problem you're concerned about is that the IANA staff
ultimately report to the organization that also generates the names
policy for IANA publication.  Is that right?

If so, perhaps the way forward is to turn things on their head.  (This
is not a well-developed idea, please note, but just a suggestion that
occurs to me and that might be worth batting about.)  In the IETF and
RIR cases, what we have (roughly) is an expectation that the output of
the policy organization (whatever it is) will be faithfully
implemented by IANA, and we have a mechanism to do something about it
if that does not happen.  Perhaps because IANA is inside ICANN, the
right thing to do here is to put a firewall around IANA, and state
what it shall do _unless_ other conditions come to bear, and specify
what those conditions are.  This gets us out of the bind of deciding
what kind of separation would be possible and so on, and gives us a
nice place to state the necessary and sufficient conditions for
acceptable IANA behaviour.  We then do have a problem of what to do in
case IANA goes completely rogue and violates these requirements, but
apart from either "fire rogue employee" or "root server operators
refuse to load the IANA zone" it's hard to see how to handle that.
I'm aware that some people want desperately to completely specify how
to handle that case, but it leads us into attempting to tell all
network operators which root nameservers they use -- a power that we
do not have.

I think this is _sort_ of like the current "internal" proposal, but it
changes the dynamic because we only have to specify a bounded set of
contingencies, and clearly leaves the rest of the accountability stuff
for the CCWG-accountability.  I may have misunderstood the current
proposal, though, so I anxiously await correction.

Best regards,

A

-- 
Andrew Sullivan
ajs at anvilwalrusden.com