Re: [Ianaplan] Our impossible job, was Where we're at/going forward
John C Klensin <john-ietf@jck.com> Wed, 26 August 2015 16:45 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 0F4761B2C60 for <ianaplan@ietfa.amsl.com>; Wed, 26 Aug 2015 09:45:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p6T6D10DiOie for <ianaplan@ietfa.amsl.com>; Wed, 26 Aug 2015 09:45:05 -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 F40A01B2C1C for <ianaplan@ietf.org>; Wed, 26 Aug 2015 09:45:03 -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 1ZUdoq-0005Wi-Jn; Wed, 26 Aug 2015 12:45:00 -0400
Date: Wed, 26 Aug 2015 12:44:55 -0400
From: John C Klensin <john-ietf@jck.com>
To: Eliot Lear <lear@cisco.com>, John Levine <johnl@taugh.com>, ianaplan@ietf.org
Message-ID: <9DF9275062A9D2D50F1FD1C4@JcK-HP8200.jck.com>
In-Reply-To: <55DD72CE.40403@cisco.com>
References: <20150825214212.60865.qmail@ary.lan> <55DD72CE.40403@cisco.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/49p69jAhUMpXam3_9uzQyDwuor4>
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: Wed, 26 Aug 2015 16:45:07 -0000
--On Wednesday, August 26, 2015 10:03 +0200 Eliot Lear <lear@cisco.com> 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 decisions. >... > 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 <lear@cisco.com> 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. best, john
- [Ianaplan] Where we're at/going forward Leslie Daigle (ThinkingCat)
- Re: [Ianaplan] Our impossible job, was Where we'r… John Levine
- Re: [Ianaplan] Where we're at/going forward Martin J. Dürst
- Re: [Ianaplan] Our impossible job, was Where we'r… Eliot Lear
- Re: [Ianaplan] Our impossible job, was Where we'r… John R Levine
- Re: [Ianaplan] Our impossible job, was Where we'r… Eliot Lear
- Re: [Ianaplan] Our impossible job, was Where we'r… John C Klensin
- Re: [Ianaplan] Our impossible job, was Where we'r… Eliot Lear
- Re: [Ianaplan] Our impossible job, was Where we'r… John C Klensin