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

manning bill <bmanning@isi.edu> Mon, 10 November 2014 04:44 UTC

Return-Path: <bmanning@isi.edu>
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 049FE1A88F8 for <ianaplan@ietfa.amsl.com>; Sun, 9 Nov 2014 20:44:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.794
X-Spam-Level:
X-Spam-Status: No, score=-4.794 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594] 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 wsrECv_L1rC6 for <ianaplan@ietfa.amsl.com>; Sun, 9 Nov 2014 20:44:00 -0800 (PST)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB9A61A88F5 for <ianaplan@ietf.org>; Sun, 9 Nov 2014 20:44:00 -0800 (PST)
Received: from dhcp-8972.meeting.ietf.org (dhcp-8972.meeting.ietf.org [31.133.137.114]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id sAA4h82o015156 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 9 Nov 2014 20:43:20 -0800 (PST)
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Content-Type: text/plain; charset="us-ascii"
From: manning bill <bmanning@isi.edu>
In-Reply-To: <7aa8ad9b2ec544f9a238f98ea8c0143f@EX13-MBX-13.ad.syr.edu>
Date: Sun, 09 Nov 2014 20:43:07 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <0B54A3F1-80ED-49B2-B2EE-8EBD39A03AFA@isi.edu>
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> <7aa8ad9b2ec544f9a238f98ea8c0143f@EX13-MBX-13.ad.syr.edu>
To: Milton L Mueller <mueller@syr.edu>
X-Mailer: Apple Mail (2.1878.6)
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: bmanning@isi.edu
Archived-At: http://mailarchive.ietf.org/arch/msg/ianaplan/qPmdUVA0jY3aY90N4J_V7QdvXH0
Cc: "ianaplan@ietf.org" <ianaplan@ietf.org>
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 04:44:02 -0000

thank you for your understanding of  a) my dyslexia and b) autocorrect 

i am  glad that the fundamental questions are answered and there is now time and interest to work on the minor details.
Have we started to grapple with the issues of IANA.ORG in alternate encodings/scripts yet?

/bill
PO Box 12317
Marina del Rey, CA 90295
310.322.8102

On 9November2014Sunday, at 18:41, Milton L Mueller <mueller@syr.edu> wrote:

> 
> 
>> -----Original Message-----
>> 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 assume you mean rogue. (Hope pointing out this typo doesn't make you red-faced.)
> 
> Well of course, the issue of when to abandon a particular operator is more fundamental, and the ability to switch is critical to the ability to neutralize a rogue operator. 
> 
> But I am perfectly content to let the IETF make that decision as they see fit at some point in the future. All we can do now is ensure that if or when they do have to make such a decision, the path will be as smooth as possible for them to make a switch. That is, by handling the domain and TM correctly, we can lower switching costs. 
> 
> _______________________________________________
> Ianaplan mailing list
> Ianaplan@ietf.org
> https://www.ietf.org/mailman/listinfo/ianaplan