Re: [Ianaplan] A draft for your review

John Curran <jcurran@istaff.org> Sun, 02 November 2014 01:34 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 9F9641A3B9C for <ianaplan@ietfa.amsl.com>; Sat, 1 Nov 2014 18:34:14 -0700 (PDT)
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 R_1c9-STbUuR for <ianaplan@ietfa.amsl.com>; Sat, 1 Nov 2014 18:34:13 -0700 (PDT)
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 2366F1A2130 for <ianaplan@ietf.org>; Sat, 1 Nov 2014 18:34:12 -0700 (PDT)
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 1Xkk3Y-0003jI-5X; Sun, 02 Nov 2014 01:34:12 +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: U2FsdGVkX19IvSUIRBnQOZ1dIe0Ce8sM
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: <54553797.1070605@gmail.com>
Date: Sun, 02 Nov 2014 01:34:08 +0000
Content-Transfer-Encoding: quoted-printable
Message-Id: <3DED6118-9757-4288-BF9F-290EDB942751@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>
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/a_N22OD9EO8sozbiRmylwUOkkjg
Cc: ianaplan@ietf.org
Subject: Re: [Ianaplan] A draft for your review
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 01:34:14 -0000

On Nov 1, 2014, at 7:42 PM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
> ...
> Trying to go up a level, what I see here is a very senior member of
> our wider community (that would be Mr Conrad) telling us of at least
> two cases (the recent RFC 6761, and the ancient blunder of IPv6
> Top Level Aggregation, RFC 2374) where he feels that the IETF side of
> the house did not in practice consult adequately with the registry or
> operators sides of the house. And if he feels that, then it's true
> by definition: we didn't consult enough, period.

I actually think we have been doing a pretty good job of policy 
coordination when it comes IETF and the Internet numbers registries.
There have been lots of small issues that have arisen over the years 
(special purpose addresses, documentation prefixes, transition blocks) 
all of which have been worked out, and often with specific coordination
efforts, i.e. folks from both communities attending others meetings.
While the initial IPv6 address format could have benefited by having
more operator input incorporated, that lack can probably be claimed
for most aspects of IP next generation design process (as opposed to 
being the result of any lack of coordination among policy bodies.)

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.

/John

Disclaimer: my views alone.