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

Eliot Lear <lear@cisco.com> Thu, 27 August 2015 14:59 UTC

Return-Path: <lear@cisco.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 12BAA1A902B for <ianaplan@ietfa.amsl.com>; Thu, 27 Aug 2015 07:59:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -11.811
X-Spam-Level:
X-Spam-Status: No, score=-11.811 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 EO7KvwVQIX8E for <ianaplan@ietfa.amsl.com>; Thu, 27 Aug 2015 07:59:21 -0700 (PDT)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 623A41A8AA7 for <ianaplan@ietf.org>; Thu, 27 Aug 2015 07:59:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6094; q=dns/txt; s=iport; t=1440687560; x=1441897160; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=XHD4R6c6wgfEpiyY3/1wKgahz9RzGCIPzr1lsuzinGk=; b=P9JV6mwpZiKbh2hSUzKvVyUVhUV94BobxLBiG+FhnQc6litnfhlizfJa YM8KytdP6z9ZS4RGhoBDSPJZS6BwFTeiVZEBxC5A2FRGFDbNh/apTHhk5 n+K2W+PwZ6Sc5Us3jn2IXwj9IQ/cqmJIC3iij0IuhbrD9g2S6UzaoPCwD w=;
X-Files: signature.asc : 481
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DMBABCJd9V/xbLJq1TCod7wlECgXwBAQEBAQGBC4QkAQEDAQ4VQhMRCyEWCwICCQMCAQIBRQYBDAgBARCIEgizP5UTAQEBAQEBBAEBAQEBARyKXoEDhCcHZIJpgUMBBJU9gkCBXIhXgUqHLY1+g2smgg8cgVY8gwABAQE
X-IronPort-AV: E=Sophos;i="5.17,422,1437436800"; d="asc'?scan'208";a="604739427"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Aug 2015 14:59:17 +0000
Received: from [10.61.202.147] ([10.61.202.147]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t7RExGor002432; Thu, 27 Aug 2015 14:59:16 GMT
To: John C Klensin <john-ietf@jck.com>, ianaplan@ietf.org
References: <20150825214212.60865.qmail@ary.lan> <55DD72CE.40403@cisco.com> <9DF9275062A9D2D50F1FD1C4@JcK-HP8200.jck.com>
From: Eliot Lear <lear@cisco.com>
X-Enigmail-Draft-Status: N1110
Message-ID: <55DF25C3.2090007@cisco.com>
Date: Thu, 27 Aug 2015 16:59:15 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <9DF9275062A9D2D50F1FD1C4@JcK-HP8200.jck.com>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="XeiC1Sfc3IsRo2Wfa8TOxE0TJNUmnf0bK"
Archived-At: <http://mailarchive.ietf.org/arch/msg/ianaplan/DsGzBTB_yBX8eq1SSaeqXr53Gks>
Subject: Re: [Ianaplan] Our impossible job, was Where we're at/going forward
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: Thu, 27 Aug 2015 14:59:24 -0000

Hi John,

Skipping down...

On 8/26/15 6:44 PM, John C Klensin wrote:

>
> 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.

I would say that where we split hairs, if you can call it that, is that
I view the alternatives as far worse.  As I've said, this is a risk
analysis.  But on to the meat of the matter...

>
> 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.
>

Well, first, thanks for being specific.  I think we run better as an
organization on this sort of fuel.  Since you did me the courtesy of
commenting along these lines I feel obliged to respond in kind.

I agree that the budget is an issue, but I do not view it as an
overriding one for several reasons.  First, if the bubble bursts, the
structure of ICANN won't matter that much because the revenue shortfall
will hit the organization as a whole.  There is no alternate revenue
stream today and none is proposed post-transition.  Second, the overall
IANA budget is relatively small compared to the ICANN budget.  Third,
ICANN has sufficient reserves that in the event of a shortfall, there
will be time to find alternate funding sources and, if needs be,
organizations that perform the function.  In addition, ICANN has
undertaken an obligation to this community.  I suspect they will be
loathe to relinquish their responsibilities, as they are the basis of
the organization's raison d'etre.  Does this make it certain that the
budget will forever be funded?  No.  There are no certainties.

Still, I think it is worth it for the IAB to raise this sort of concern
with regard to the CCWG proposal, where the budget is discussed, and I
hope they will.

In regard to your note to Olivier, I know you know that the nuclear
option is called that for a reason, and that you know many intervening
steps exist.  Those steps should make one confident that the button will
not need to be pushed for a very long time, if ever.  Again, confidence,
not certainty.

In the end, therefore, I personally weight the risks of not proceeding
higher than proceeding.

Related, the charter of this list has necessitated thinking about nasty
"What if" scenarios that make it sound like The End Draws Nigh.  That's
just not the case, nor is there any real reason to think that the
situation will change.  And so it's probably good to remember that from
time to time.  We are all, after all, trying to do what is right for the
Internet.

Eliot