Re: [Ianaplan] A draft for your review - more (policy coord vs IANA operator coord)

John Curran <jcurran@istaff.org> Sun, 02 November 2014 09:51 UTC

Return-Path: <jcurran@istaff.org>
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 AFCCB1A86EA for <ianaplan@ietfa.amsl.com>; Sun, 2 Nov 2014 01:51:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] 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 Pu_FTs2e4mcA for <ianaplan@ietfa.amsl.com>; Sun, 2 Nov 2014 01:51:43 -0800 (PST)
Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AE0F1A86E6 for <ianaplan@ietf.org>; Sun, 2 Nov 2014 01:51:43 -0800 (PST)
Received: from [80.169.25.242] (helo=[192.168.41.103]) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from <jcurran@istaff.org>) id 1Xkrp0-000I4c-Ag; Sun, 02 Nov 2014 09:51:42 +0000
X-Mail-Handler: Dyn Standard SMTP by Dyn
X-Originating-IP: 80.169.25.242
X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information)
X-MHO-User: U2FsdGVkX1+G4ck+KkwTGsOG/6y8q+1o
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\))
From: John Curran <jcurran@istaff.org>
In-Reply-To: <3DED6118-9757-4288-BF9F-290EDB942751@istaff.org>
Date: Sun, 02 Nov 2014 09:51:40 +0000
Content-Transfer-Encoding: 7bit
Message-Id: <F6089109-FC7B-4148-A74F-942F5B6D7C6B@istaff.org>
References: <54017E09.8060504@cisco.com> <6.2.5.6.2.20140830052032.0c96c880@resistor.net> <54047E4A.30503@cisco.com> <6.2.5.6.2.20140901094544.0b305698@resistor.net> <54059587.8070608@cisco.com> <6.2.5.6.2.20141024004255.0b5ef5d8@resistor.net> <4C1255B9-68C3-45D5-A618-2C7553386DF4@gmail.com> <54522E43.5020709@acm.org> <545428AC.3090802@gmail.com> <7471A339-3938-4D65-81ED-9E27A80EC32B@virtualized.org> <20141101165234.GA25533@mx1.yitter.info> <660C2734-F8AF-44FB-95B4-D04AF1DF1361@virtualized.org> <54553797.1070605@gmail.com> <3DED6118-9757-4288-BF9F-290EDB942751@istaff.org>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
X-Mailer: Apple Mail (2.1990.1)
Archived-At: http://mailarchive.ietf.org/arch/msg/ianaplan/c6N4j8_r0xb1ivysLa1KqXS_Kmo
Cc: ianaplan@ietf.org
Subject: Re: [Ianaplan] A draft for your review - more (policy coord vs IANA operator coord)
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: Sun, 02 Nov 2014 09:51:45 -0000

On Nov 2, 2014, at 1:34 AM, John Curran <jcurran@istaff.org> wrote:
> ...
> I do think it is worth documenting the need for good coordination 
> between the IETF and delegated registries, predominantly because 
> the RFP does specifically ask about independencies and good policy 
> coordination keeps the IANA operator(s) an administrative function
> rather than becoming an arbitration role.

I'll also note that this type of coordination among policy authorities
for those registries that have less than algorithmic boundaries (e.g. 
the need for technical/specialized IPv4 reservations from the nearly 
fully allocated IPv4 unicast space, the insertion of a technical entries
into the DNS root zone, etc.) is also quite distinct from the excellent 
IANA operational coordination in registry space publication, e.g. building 
a single in-addr.arpa zone with data from various sources, getting the 
.arpa entry into DNS root alongside other entries, etc.  

These IANA operational coordination tasks work well with a single IANA 
functions operator, and we should note that care is necessary to provide 
the same coordination if multiple IANA operators should ever be the norm.

/John

Disclaimer: my views alone.