Re: [Ianaplan] control and negotiation (was Re: draft-ietf-ianaplan-icg-response-02 working group last call)

Eric Brunner-Williams <ebw@abenaki.wabanaki.net> Mon, 10 November 2014 19:09 UTC

Return-Path: <ebw@abenaki.wabanaki.net>
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 5331C1AC3C6 for <ianaplan@ietfa.amsl.com>; Mon, 10 Nov 2014 11:09:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.566
X-Spam-Level:
X-Spam-Status: No, score=-1.566 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334] 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 LqJQxPqyc4q0 for <ianaplan@ietfa.amsl.com>; Mon, 10 Nov 2014 11:09:03 -0800 (PST)
Received: from abenaki.wabanaki.net (nike.wampumpeag.net [67.42.198.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2A6F1AC3B5 for <ianaplan@ietf.org>; Mon, 10 Nov 2014 11:08:39 -0800 (PST)
Received: from frog.local ([67.42.198.93]) by abenaki.wabanaki.net (8.14.9/8.14.9) with ESMTP id sAAJ7n6B099129 for <ianaplan@ietf.org>; Mon, 10 Nov 2014 11:07:54 -0800 (PST) (envelope-from ebw@abenaki.wabanaki.net)
Message-ID: <54610CFB.1030709@abenaki.wabanaki.net>
Date: Mon, 10 Nov 2014 11:07:39 -0800
From: Eric Brunner-Williams <ebw@abenaki.wabanaki.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: ianaplan@ietf.org
References: <631e3e3d29c843bd9c23151c63612989@EX13-MBX-13.ad.syr.edu> <20141105154903.GI30379@mx1.yitter.info> <498a39b81b774192bd2d609b3feab35f@EX13-MBX-13.ad.syr.edu> <20141105234444.GM31320@crankycanuck.ca> <545ABCB0.5080206@meetinghouse.net> <8f3dcda6c3db4cd8be1b77444f987d59@EX13-MBX-13.ad.syr.edu> <D0805C27.136BE7%jon.peterson@neustar.biz> <059f2b06a7b44f09b7568d8966861fb8@EX13-MBX-13.ad.syr.edu> <D0824FAD.137A42%jon.peterson@neustar.biz> <E314302D-5179-4899-9DB7-A3AF18C134E8@gmail.com> <20141108155153.GB37292@mx1.yitter.info> <D083864D.138D18%jon.peterson@neustar.biz> <A6D94EF5-BD92-4080-8C18-E415BD0BB880@isi.edu>
In-Reply-To: <A6D94EF5-BD92-4080-8C18-E415BD0BB880@isi.edu>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/ianaplan/OS8_g54EXf6soy-qPDDSjlWSSLI
Subject: Re: [Ianaplan] control and negotiation (was Re: draft-ietf-ianaplan-icg-response-02 working group last call)
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: <http://www.ietf.org/mail-archive/web/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: Mon, 10 Nov 2014 19:09:11 -0000

On 11/8/14 4:36 PM, manning bill wrote:
> [...]
> Removal of or rehoming some of the trappings of power (who controls IANA.*) seems like a niche question at best.
>
> For me, the more fundamental problem is:  a) how to tell when an operator of one of these functions has lost it,  and  b) how to neutralize the impact
> of a rouge operator.

I agree that one particular name-to-resources mapping is not a 
fundamental question. There are important names within the namespace, 
but transition is not intractable, in my opinion.

I suggest that the illumination of a ns constellation by CNNIC in 
2001/2002 and the publication of a non-identical zone file in (IIRC) 
2004 is evidence of "when an operator of one of those functions has lost 
it", though I expect there will be disagreement as to which operator 
"lost it". I suggest that the subsequent continuous publication of a 
non-identical zone file is also evidence of "how to neutralize the 
impact of a rogue operator", though again I expect there will be 
disagreement as to which operator's action, or lack of action, will be 
seen as rogue.

See also the effect of precluding, by intent or lack of oversight, use 
of the GOST suite to sign zones.

My point being that we can treat failure as a hypothetical future, or we 
can take a look at some available technical consequences of recent 
policies, and extrapolate for equivalent or greater failures.

Eric