Re: [Ianaplan] Consensus call -- text reply for ICG proposal review

John C Klensin <> Sun, 23 August 2015 15:46 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 6017C1ACEC2 for <>; Sun, 23 Aug 2015 08:46:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.09
X-Spam-Status: No, score=0.09 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jIyoqsJe-bAe for <>; Sun, 23 Aug 2015 08:45:58 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 571CD1ACEC0 for <>; Sun, 23 Aug 2015 08:45:58 -0700 (PDT)
Received: from [] ( by with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <>) id 1ZTXSy-000GK7-CP; Sun, 23 Aug 2015 11:45:52 -0400
Date: Sun, 23 Aug 2015 11:45:47 -0400
From: John C Klensin <>
To: Richard Hill <>, 'Eliot Lear' <>, "'Leslie Daigle (ThinkingCat)'" <>
Message-ID: <>
In-Reply-To: <020001d0dc2c$b5514ba0$1ff3e2e0$@ch>
References: <> <018901d0dc22$4efb3870$ecf1a950$@ch> <> <01a801d0dc24$531bab40$f95301c0$@ch> <> <020001d0dc2c$b5514ba0$1ff3e2e0$@ch>
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-Scanned: No (on; SAEximRunCond expanded to false
Archived-At: <>
Cc: "'Ianaplan@Ietf. Org'" <>, 'Marc Blanchet' <>
Subject: Re: [Ianaplan] Consensus call -- text reply for ICG proposal review
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IANA Plan <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 23 Aug 2015 15:46:00 -0000

--On Friday, August 21, 2015 18:16 +0200 Richard Hill
<> wrote:

> The problem is that by supporting the entire proposal you are
> also taking a position on the names and addressing proposals.
> And it seems to me that that goes beyond the mandate of this
> group.


I've been traveling for the last week or two and haven't read
the various discussions during that period carefully.  But I
think I disagree with your statement above.    Breaking this
down, it seems to me that it must be acceptable for the IETF to

(i) We have read the complete proposal and conclude that it
addresses our specific issues and concerns, stated earlier, in
an acceptable way.

(ii) While we see a variety of ways in which assorted other
issues could be worked out and specified, that list and the
choices about them in the current proposal appear to us to not
pose a risk to the things we've identified as important.
Consequently, as the good members of a broader community that we
aspire to be, we are supportive of those things simply because
the other communities want them and they don't seem to pose a
problem or challenge for us.

Now, that is, I believe, more or less what Eliot is suggesting.
It doesn't mean we would be willing to spill blood (especially
IETF blood) to make sure that the proposals from the names and
addresses groups are adopted, but we can still support them as
consistent and non-harmful.

I don't see why you consider such a pair of statements, in that
form or another one, a problem.

Now, whether the IETF actually believes in those statements is
another matter.  I've concluded personally that I do not, but I
think it is quite likely that I'm "in the rough" on these
issues.  In particular:

(1) ICANN and its many non-IANA roles (some of which I agree
with, others I don't) have become extremely large and complex.
Consequently, I think it is important to distinguish provisions
in this proposal (and elsewhere) that are directly related to
IANA, the US Government role under the current arrangements, and
the transition of that role (either eliminating it or replacing
it with some other arrangement) from provisions whose purpose is
to improve those other ICANN functions.  Those other provisions
might change how those ICANN functions are carried out,
controlled, or managed,  or protect against abuse of or due to
those functions.  I personally wish that the proposal would be
rejected by the ICG and the various communities until the
extraneous "let's fix ICANN" elements --including all
reflections of desires to make ICANN the focus of questions
about how to "govern" the Internet or to use ICANN or the
Internet more generally to test assorted interesting
sociopolitical or organizational theories -- were removed.  

(2) I think the broader Internet community, or at least the
IETF, should be working to insure that IANA operations are
adequately responsible to the relevant customer groups _and_
that the IANA function is accountable to the Internet community.
I've expressed this concern earlier but gotten no improvements
as a result, however, I see the PTI model as potentially (but
only potentially) improving accountability for a small number of
communities, some of them with significant vested economic or
equivalent interests, at the price of reducing accountability to
the Internet at large and maybe even the other customer groups.
I don't see that as an improvement, regardless of its other real
or imaginary organizational benefits (see comment about
theory-testing above).

(3) Whatever one might say about the NTIA role (and that of the
US Government more generally), how it has been applied, and,
perhaps most important in practice, the horrible optics
associated with it, the fact remains that it has provided an
important independent mechanism for both moderating possible bad
behavior on ICANN's part and for appeals that lie completely
outside ICANN's ability to design and define the procedures and
to appoint those who will consider the specifics of particular
cases.  Sometimes just having such external mechanisms is
important.  They inhibit bad behavior because of the possibility
of intervention if things get bad enough.  Equally or more
important, if one were worried about capture by a collection of
stakeholders who are not fully representative of the Internet
community, the odds that NTIA could be captured by that same
collection of stakeholders are vanishingly small.

A key part of the issue here is that "multistakeholder" has,
many times in this context, come to mean "anyone with an
opinion, regardless of knowledge or actual material concern and
involvement with the substantive issues".  That is very much
different from IETF values and traditions: we tend (and try) to
value knowledge, experience, and actual involvement with the
subject matter over what we evaluate as wild theorizing.  That
particular version of "multistakeholder", especially in its
ICANN incarnation, tends to give great power to factions with
the interest and resources to make seemingly-unlimited
investments in the process.  That doesn't require malfeasance,
only the ability to create many committees, meetings, and long
and complex documents until no one other than those particular
interested and invested parties (and those subsidized by ICANN)
can afford to participate in practice.

To transition away from having the US Government in the
oversight and appeal (whether from the broad community or from
governments via diplomatic channels) role described above
requires that one either have a separate oversight and appeal
mechanism that is similar to the NTIA one in not being under
control of ICANN or any constituency that might capture or
dominate ICANN decision making... or one must have complete
trust that ICANN cannot be captured, has conflict of interest
policies that protect against decisions being dominated by a
single self-interested party or cluster of them, and that it
will always (now and in the future) act in the best interests of
the Internet, even when those interests conflict with the
organizational best interests of ICANN as an organization.
Absent that level of trust, "independent" review mechanisms
created by ICANN don't do the job because ICANN can control the
criteria for appointments, the working procedures, and,
ultimately, the membership of those bodies whether the criteria
are satisfied or not.   Sadly, I don't have that level of trust,
if only because ICANN has, even in the last few years,
repeatedly provided examples that contradict it.

It seems clear to me that most of that latter group of concerns
are out of scope for IANAPlan, although not necessarily so for
the IETF and IAB.   I hope that various of us who do have them
will comment more generally on the process and situation and, if
necessary, on any public call for comment that NTIA and other
institutions may produce in the future.