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

"John Levine" <johnl@taugh.com> Tue, 25 August 2015 21:42 UTC

Return-Path: <johnl@taugh.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 2E9661A8BB1 for <ianaplan@ietfa.amsl.com>; Tue, 25 Aug 2015 14:42:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.663
X-Spam-Level: *
X-Spam-Status: No, score=1.663 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no
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 XJ-oz_Js2Vk5 for <ianaplan@ietfa.amsl.com>; Tue, 25 Aug 2015 14:42:36 -0700 (PDT)
Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4F411ACE8D for <ianaplan@ietf.org>; Tue, 25 Aug 2015 14:42:35 -0700 (PDT)
Received: (qmail 5282 invoked from network); 25 Aug 2015 21:42:51 -0000
Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 25 Aug 2015 21:42:51 -0000
Date: 25 Aug 2015 21:42:12 -0000
Message-ID: <20150825214212.60865.qmail@ary.lan>
From: "John Levine" <johnl@taugh.com>
To: ianaplan@ietf.org
In-Reply-To: <F53CA370-823C-4D7D-ADA3-420061CE6EA5@thinkingcat.com>
Organization:
X-Headerized: yes
Mime-Version: 1.0
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/ianaplan/OYmlG628E8go1hJpI9I1qI5vVew>
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: Tue, 25 Aug 2015 21:42:37 -0000

>2. Those issues largely have to deal with clarity about scope of this 
>WG’s comments.  As I noted on Friday,  we have a charter item to 
>review the whole proposal but only in the light of the protocol 
>parameter function.  This does not take anything away from our 
>individual right and responsibility to review the whole proposal, and it 
>also does not touch the fact that the IETF as a whole may have a broader 
>responsibility to review the whole proposal, in the light of the future 
>of the IANA entity in its entirety.

Quite right.  Personally, I think the transition plans for parameters
and for numbers are fine, and that the plan for names is not.  If you
asked me whether I'd support the combined three part plan, the answer
would be no.  It sounds like I'm not the only one who feels that way.

At this point I don't understand what reviewing the whole proposal in
light of the protocol parameter function really means.  If it means do
we think son-of-IANA will handle parameters well and we have an escape
route if they don't, we all seem to agree on that.  If it means that
the whole proposal will work to maintain the stability of the DNS, I
see no consensus there.

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.  So far we've managed to dodge the
bullets, but that seems to me largely due to the moral suasion that we
have over ICANN, due in no small part to personal relationships with
leaders who, although vigorous, are not immortal.

So if we're going to make a statement about the combined proposal, we
need to make it clear that we endorse the parameter parts and make no
statement either way about the rest of it.  If the press spins that as
saying the IETF doesn't endorse the names PTI, they wouldn't be wrong.

Beyond that, I don't see that we have any particular expertise related
to what the names community should do beyond being particularly aware
of what's likely to go wrong if they screw it up.  So even though some
of us might like to comment on the names part, or on the whole thing,
we probably shouldn't.

R's,
John