Re: [Ianaplan] on considering consensus

John C Klensin <john-ietf@jck.com> Wed, 26 August 2015 15:00 UTC

Return-Path: <john-ietf@jck.com>
X-Original-To: ianaplan@ietfa.amsl.com
Delivered-To: ianaplan@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D9651B2FB8 for <ianaplan@ietfa.amsl.com>; Wed, 26 Aug 2015 08:00:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.79
X-Spam-Level:
X-Spam-Status: No, score=0.79 tagged_above=-999 required=5 tests=[BAYES_50=0.8, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nlIrPnZIBXpK for <ianaplan@ietfa.amsl.com>; Wed, 26 Aug 2015 08:00:45 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 574B31B2EAE for <ianaplan@ietf.org>; Wed, 26 Aug 2015 08:00:45 -0700 (PDT)
Received: from [198.252.137.10] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1ZUcBv-0005KA-RF; Wed, 26 Aug 2015 11:00:43 -0400
Date: Wed, 26 Aug 2015 11:00:38 -0400
From: John C Klensin <john-ietf@jck.com>
To: Olivier MJ Crepin-Leblond <ocl@gih.com>
Message-ID: <8942451ED29E2CC2FFA2D91F@JcK-HP8200.jck.com>
In-Reply-To: <55DC9F86.40002@gih.com>
References: <55DBFC39.5000701@cisco.com> <55DC0030.5080809@gmail.com> <55DC00CD.9040804@cisco.com> <A446C143EF3E8721BB647FA6@JcK-HP8200.jck.com> <55DC8ABD.7010304@cisco.com> <55DC9F86.40002@gih.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <http://mailarchive.ietf.org/arch/msg/ianaplan/WzsLsYlonCMc5YnNRDxTsvlWmbQ>
Cc: ianaplan@ietf.org
Subject: Re: [Ianaplan] on considering consensus
X-BeenThere: ianaplan@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IANA Plan <ianaplan.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ianaplan>, <mailto:ianaplan-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ianaplan/>
List-Post: <mailto:ianaplan@ietf.org>
List-Help: <mailto:ianaplan-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ianaplan>, <mailto:ianaplan-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Aug 2015 15:00:47 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


- --On Tuesday, August 25, 2015 19:01 +0200 Olivier MJ
Crepin-Leblond
<ocl@gih.com> wrote:

>...
>> There are two problems with this devil's advocate statement.
>> The first is that not all the authority is left in assorted
>> ICANN entities. Rather it is found in the three communities.
>> Second, any debate about the individual proposals should have
>> happened within the communities.

> FWIW, I agree with the points Eliot is making in this thread &
> others. The IETF & RIRs can walk away from the agreement with
> ICANN if they want to, so I do not see any "decision authority
> left in assorted ICANN entities". If you see IETF & RIRs being
> assorted ICANN entities (god forbid! :-) ) then I'd agree with
> you. But IMHO the decision authority is in the Operational
> Communities.

Olivier,

I think there are some important distinctions to be made in this
discussion.  If we cannot agree that they exist, I doubt that
either of us
will be able to persuade the other.   There are more general
cases (see
below), but this specific one, from my perspective, looks like
this:  

To at least some degree, most of us believe that splitting the
IANA
function into two or three separate pieces, with completely
separated
management, decision processes, staffing, and accountability
would be
undesirable.  Probably keeping the function together is less
important
today than it was 20 or more years ago when IANA had and
exercise real
decision-making authority, but it is notable that, AFAIK, no one
has
seriously made what might have been the most simple and
straightforward
transition proposal, which would simply be to split things up
now, making
each of the three functions separately accountable to the three
customer
communities with no interactions that require agreement among
them (or with
ICANN).  

To the degree to which that "it is better to keep IANA together"
view is
relevant, the "walk away" plan has to be understood as a
last-resort and
very drastic (aka "nuclear") option.  It may be vital to
preserve that
option (I think it is), but saying "you have that option, so
there is no
problem" is really not helpful except as rhetoric.    In
addition, as
others have pointed out several times on this list, the only
plan so far
for an IANA income source involves ICANN resources, which means
the IANA
budget decisions are in the hands of "ICANN entities".
Similarly, PTI is
specified as an ICANN subsidiary (whatever the terminology) and
is hence
also an ICANN entity.  

Obviously, a response to those concerns is that the various
safeguards and
authority built into the system --the budget veto, the board
removal
provisions, etc.-- are adequate protections against abuse or
external (to
IANA) control or capture of the IANA function.  However, that
isn't the
argument I understand you to be suggesting, i.e., that ICANN
entities are
not involved or don't have significant authority.  More
important, for at
least two reasons I don't believe those provisions are likely to
be
effective.  First, if the groups that have the ability to make
those "reset
and reboot" decisions are at all responsible, those options are,
themselves, last-resort moves, sufficiently likely to be
disruptive and
destructive to be undertaken (rather than, e.g., threatened)
only after
things have already reached meltdown status.  Second, ICANN
Counsel have
consistently taken the position that the principal obligation of
the ICANN
leadership is the preservation and best interests of ICANN as an
organization, not that of the Internet, the multistakeholder
community, or
other lofty abstractions.  As long as that attitude prevails as
a key part
of the ICANN culture, I have little or no confidence that any
structural
change that it designed to force ICANN to act against its
organization best
interests will survive in effective form for very long... at
least absent
an external guarantor (for which see my previous notes about
"transitioning" any external guarantor(s) out of the system).

> The real concern I have about the current discussions (Devil's
> Advocate aside, which I think is helpful) is the complete loss
> of the optics of the wider picture. Are Operational
> Communities in this Internet Boat together or are they living
> a "Life of Pi"? In the longer term, if we do not find a way to
> have more trust across all three operational communities, how
> are we going to ever stand as one to defend the
> multi-stakeholder model of governance?

This gets to the more general part of the problem, again with
multiple
aspects.   If the "operational communities" (a term that, I
note, started
being used only during these "transition" discussions) are
really in the
"Internet Boat" together and more or less tightly bound to each
other in
that boat, then the argument that the ability to walk away
solves all
possible problems becomes even weaker than my characterization
of it above.
 Reaching meaningful consensus among those groups ultimately
depends on a
shared model of what constitutes success, but I see at least
three models
floating around.  One is the successful and smooth "technical"
operation of
the Internet, perhaps with an underlying assumption that such an
Internet
will route around damage (technical, economic, or political).
Another is
the notion of a successful, profitable, and maybe competitive
market in
domain names.   And a third is preservation and strengthening of
the
sociopolitical concept of a "multistakeholder model" (see
below).  Those
goals/ success criteria are not necessarily mutually exclusive.
I believe
that is enough goodwill in the various communities that people
can accept
other groups having their needs satisfied as long as their own
needs are
met -- a view that, I believe, has dominated recent discussions
on this
list.  

On the other hand, the history of these discussions --for the
technical /
engineering community going back to the first set of pre-ICANN
"the
Internet is too important to be left to the engineers"
comments-- suggests
that each of the communities needs to be cautious about the
others.

That is, IMO, particularly important when "multistakeholder
model" becomes
a goal rather than a description of a process.  In the ISO
world, the
phrase "materially concerned party" is often used and I
personally wish the
ICANN-related (and "Internet governance"-related) criteria had
found an
expression closer to that.  "Multistakeholder" should, arguably,
mean the
same thing, but seems in practice to include a lot of parties
whose are
less involved; have, as the saying used to go, far less "skin in
the game"
of a well-working Internet; who are interested in disrupting the
current
model and discussions in favor or an entirely different vision;
who see
these discussions and the entire "governance" discussion as an
opportunity
to test or demonstrate theories about non-governmental world
governance or
other personal theories; or who, in the words of a prominent
ICANN staff
member, just have too much time on their hands.   Put
differently, it is
sometimes hard to differentiate between a constructive and
Internet-focused
multistakeholder model and a leaderless and unfocused mob each
of whose
members have managed to find a large pointed object somewhere.

Until and unless something changes in that version of the
"multi-stakeholder model of governance", standing together to
defend it may
not only be impossible but undesirable.

best regards,
   john

-----BEGIN PGP SIGNATURE-----
Version: Encryption Desktop 10.3.0 (Build 8741)
Charset: utf-8

wj8DBQFV3dSJ5pJ/EbOJ8NoRAh9sAJwO9JKYZGYfvSJ+6CjdxeX1TXguWwCgnR4L
BE47UjdF7LwvC5JTickWPbo=
=Iq6L
-----END PGP SIGNATURE-----