Re: [Ianaplan] Our impossible job, was Where we're at/going forward

John C Klensin <> Wed, 26 August 2015 16:45 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 0F4761B2C60 for <>; Wed, 26 Aug 2015 09:45:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id p6T6D10DiOie for <>; Wed, 26 Aug 2015 09:45:05 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F40A01B2C1C for <>; Wed, 26 Aug 2015 09:45:03 -0700 (PDT)
Received: from [] ( by with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <>) id 1ZUdoq-0005Wi-Jn; Wed, 26 Aug 2015 12:45:00 -0400
Date: Wed, 26 Aug 2015 12:44:55 -0400
From: John C Klensin <>
To: Eliot Lear <>, John Levine <>,
Message-ID: <>
In-Reply-To: <>
References: <20150825214212.60865.qmail@ary.lan> <>
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: <>
Subject: Re: [Ianaplan] Our impossible job, was Where we're at/going forward
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: Wed, 26 Aug 2015 16:45:07 -0000

--On Wednesday, August 26, 2015 10:03 +0200 Eliot Lear
<> wrote:

> Hi John,
> On 8/25/15 11:42 PM, John Levine wrote:
>> The IETF interacts indirectly with IANA via the names world
>> in lots of ways.  The obvious recent example is the
>> discussion about .onion and other non-DNS name use, but there
>> are technical stability issues for changes to top level
>> records (.google asked for a wildcard last year), for DNSSEC
>> (will we ever invent a workable way to provision it) and all
>> of the various ways to bundle names that are semantically
>> related, a problem that the marketing community appears to
>> believe is trivial, but that we have found intractable.
> Indeed, and you haven't even touched on Unicode.

The above actually identifies another issue that I think we have
been (correctly) trying to avoid: In what, from my point of
view, would be a more reasonable approach, those are not
interactions with IANA at all but are interactions with the
domain names policy part of ICANN.  The parallels to more
traditional protocol parameters should be clear: if someone
believes a particular value should, or should not, be allocated,
they may have an issue with the IESG, some expert responsible to
the IESG, or even the IETF's definition of the relevant
registry, but they don't have an issue with IANA.  IANA should
be fulfilling an almost entirely administrative function: the
things that have turned it into a leverage point are
understandable historically but almost certainly undesirable
from the standpoint of _all_ of the customer/ "operational"
communities and we should probably be working, at least
post-transition, to reduce their scope.

It is possible that something like a root-level wildcard would
be an exception, in that the policy process might direct IANA to
do such a thing and IANA might, perhaps with IETF advice, plead
technical feasibility or technical implications as a reason to
not do so.   But those examples are very few and most of the
cases described above are really interactions between the
technology and IETF interests and expertise and ICANN policy

> The problem is that you continue to treat this proposal as
> three.  It's not.  It's one integrated proposal.  Further, a
> binary decision will eventually be made.  Ours is as follows:
> do we support it or not, and why or why not?  Does the ICG
> have more information if we simply support only our portion of
> the proposal?  I would say not.  They gain a little
> information if we tell them that they haven't cocked it up.
> But a very little more.  We have the opportunity to say more.
> If we pass on that opportunity, the decision will be ceded to
> others; and we may not like their view or their goals at all.
> Thus we perform a risk analysis.  Are the risks of not
> supporting the proposal outweighed by the risks of supporting
> it?  Note "it" and not "them".

Sorry to be splitting hairs, but I'm trying to suggest a
narrower goal and analysis.  I don't want to see us be forced to
pull out of the IANA arrangements either pre-transition or
post-transition.  I recognize that, official/formal statements
aside, enough of the ICG is following this list that it would be
irresponsible of them to not be aware of the concerns.   I
don't, for example, want to see the IETF opposing the PTI idea
because the WG hasn't studied it and, more important, the
organizational behavior and culture issues it involves and
assumptions it makes are not areas of strength and expertise for
the IETF.    It is, it seems to me, reasonable that we express
misgivings, but, for that reason, not reasonable for us to
either oppose or endorse.  I can tell you that, in my very
personal opinion, having PTI, and, e.g., various of the
boundary-condition budget issues in the mix significantly
increase the odds that we will eventually have to pull out, but,
for the reasons above and because it would surely be construed
as a threat, I'm opposed to the WG saying that.

If the discussion is broadened beyond "what do we need to make
the protocol parameters work well, at least as long as everyone
continues to recognize their importance and to act in good
faith, another question comes into the equation, one that we
(and the ICG) have generally assumed away.  That question is
whether, if this type of very complex proposal, with little
identification of what problems some of the mechanisms are
intended to solve and no external and truly independent
oversight or review capability, is the best the community can
do, whether the Internet would really be better off with the
potential for US Government oversight withdrawn.  Politically
and symbolically, I think the answer is "get the US Government
out at almost any cost".   Operationally, procedurally, and in
the actual best interests of a technically functional Internet,
I'm not quite so sure -- not because I view the US Government's
role as entirely benign but because there is a possibility that
the other alternatives may be worse.

--On Wednesday, August 26, 2015 15:14 +0200 Eliot Lear
<> wrote:

> From the IETF point of view, if that trouble from the names
> community is heading our way, we should express our concerns
> and any proposed changes.  Even if some trouble *is* headed
> our way (and nobody has really seriously argued that it is),
> we should perform a a risk analysis, like with many other
> business decisions to determine what path is best to take.
> The level of meta-conversation in this thread has obscured
> nearly all of that because nobody has actually shown a
> substantial risk to us. 

OK, if that is the elephant in the room, let me be the bad guy
and identify the problem.  First, very little of what follows is
the IETF's problem and I hope we can keep it that way.  While
the role and "community" that make up the IETF and RIR/address
communities are fairly clear, it is less clear that that even is
a "names community".   Insofar as there is, it is widely
believed that the representation and decisions of that community
have been captured by those seeking profit in names rather than,
e.g., considering accurate identification (including
anti-phishing concerns) or Internet navigation issues paramount.
Should the balance within that community shift, perhaps because
there actually is a bubble in the "names market" and it bursts,
it is entirely unpredictable how that "community" would behave,
especially if they are expected to bear the costs of operations
in which some fractions of that community has not seen
themselves as involved or concerned.  

If the possibility of a de-funded, or financially seriously
constrained, protocol parameter function is a substantial risk,
then that is the source of such a risk.    If we believe that
our ability to walk away provides adequate protection against
that risk and that it would be painless enough to mitigate some
associated risks, then there is no issue and we should just move
on.  But, as I tried to explain in my note to Olivier, I don't
believe that having only a choice between putting up with an
unacceptable situation and having to pull the plug in the event
of a crisis is a desirable position to be in and, for that
standpoint, that choice of options is another substantial risk.