Re: [Ianaplan] closing the working group

Steve Crocker <steve@shinkuro.com> Thu, 13 October 2016 14:11 UTC

Return-Path: <Steve@shinkuro.com>
X-Original-To: ianaplan@ietfa.amsl.com
Delivered-To: ianaplan@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 014651298D4 for <ianaplan@ietfa.amsl.com>; Thu, 13 Oct 2016 07:11:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.896
X-Spam-Level:
X-Spam-Status: No, score=-4.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.996, SPF_HELO_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=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 omxFg8AgdZ3s for <ianaplan@ietfa.amsl.com>; Thu, 13 Oct 2016 07:11:26 -0700 (PDT)
Received: from execdsl.com (remote.shinkuro.com [50.56.68.178]) by ietfa.amsl.com (Postfix) with ESMTP id 053741298AF for <ianaplan@ietf.org>; Thu, 13 Oct 2016 07:11:25 -0700 (PDT)
Received: from dummy.name; Thu, 13 Oct 2016 14:11:25 +0000
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Steve Crocker <steve@shinkuro.com>
In-Reply-To: <15E19BC7-0CA4-4C49-B36A-C0D9D96281F3@piuha.net>
Date: Thu, 13 Oct 2016 10:11:24 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <0866241D-73BB-40B9-AE5A-81272E691CE4@shinkuro.com>
References: <15E19BC7-0CA4-4C49-B36A-C0D9D96281F3@piuha.net>
To: Jari Arkko <jari.arkko@piuha.net>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ianaplan/UlJPP_d892R-RdCs6p_91bGwPQU>
Cc: "Stephen D. Crocker" <steve@shinkuro.com>, "Ianaplan@Ietf. Org" <ianaplan@ietf.org>
Subject: Re: [Ianaplan] closing the working group
X-BeenThere: ianaplan@ietf.org
X-Mailman-Version: 2.1.17
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: Thu, 13 Oct 2016 14:11:28 -0000

Jari, et al,

This is indeed an important milestone and let me again add thanks and congratulations to everyone.

Let me also take a moment to reflect on where we were and where we are now.  Some years ago I looked at the interactions between ICANN and the operational communities and wondered why there was a sense of distance.  ICANN had, after all, been purpose built to be the home of the IANA function and each of the operational communities were represented on the ICANN Board as well as having multiple pathways into the organization.  I concluded it would be helpful for the operational communities to have more direct representation for the IANA function.  Also as a separate matter, when I was chair of ICANN’s Security and Stability Advisory Committee, I saw first hand there was a hole in the system, namely a way of making informed decisions about technical changes to the root zone.  This hole resulted in a multi-year delay in putting IPv6 addresses for root servers into the root zone, and it led to a deadlock for another multi-year period before DNSSEC was implemented in the root zone.

Meanwhile, the effort to find a way to bring the NTIA contract for IANA services to an end reached a critical point of success in March 2014 with NTIA’s announcement.  That kicked off the two-and-a-half year process that just ended.  That process included two major streams, one focused on the IANA function, and the other focused on the structure, function and accountability of ICANN itself.

The encapsulation of the IANA function in the newly formed Public Technical Identifiers organization, a legally separate but wholly owned subsidiary — the technical terminology for non-profits is a bit different but the concept is the same — is ICANN was a heavier weight solution than I had originally imagined, but since it includes two new review groups, the Customer Standing Committee (CSC) and the Root Zone Evolution Review Committee (RZERC), I am confident that the problems I observed some years ago are unlikely to recur.

I fully expect the IANA function to continue to function smoothly and effectively.  With the transition to the new structure and simplification of no longer having the contract from NTIA in place, I also expect an even higher degree of transparency and responsiveness.

Thanks,

Steve Crocker
Chair, ICANN Board of Directors
(Writing from my Shinkuro email address because that’s how I’m subscribed to the ianaplan list)


> On Oct 13, 2016, at 9:42 AM, Jari Arkko <jari.arkko@piuha.net> wrote:
> 
> Dear all,
> 
> With our chartered work done, I plan to close this working group.
> 
> I would like to thank everyone who has participated in the effort for their contribution, and their desire to stay on the rational, practical, and implementable course. It worked :-)
> 
> Closing this working group does not mean that there will be no further evolution in the IANA system. Like other parts of the IETF or the Internet organisations ecosystem, there may be room for improvements and new ways of working. If we need a broad community discussion for any future change, we will create new working groups as needed.
> 
> Thank you,
> 
> Jari Arkko
> IETF Chair and AD for IANAPLAN WG
> 
> _______________________________________________
> Ianaplan mailing list
> Ianaplan@ietf.org
> https://www.ietf.org/mailman/listinfo/ianaplan