Re: [Ianaplan] Question from the ICG

Andrew Sullivan <> Tue, 29 September 2015 17:34 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id EFB6C1ACD54 for <>; Tue, 29 Sep 2015 10:34:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id UDIMzIrIuEvJ for <>; Tue, 29 Sep 2015 10:34:30 -0700 (PDT)
Received: from ( [IPv6:2600:3c03::f03c:91ff:fedf:cfab]) by (Postfix) with ESMTP id 3CAD91ACD52 for <>; Tue, 29 Sep 2015 10:34:30 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id AE62D10739 for <>; Tue, 29 Sep 2015 17:34:29 +0000 (UTC)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id TSPmy97UD4ML for <>; Tue, 29 Sep 2015 17:34:29 +0000 (UTC)
Received: from ( []) by (Postfix) with ESMTPSA id E75581072D for <>; Tue, 29 Sep 2015 17:34:28 +0000 (UTC)
Date: Tue, 29 Sep 2015 13:34:27 -0400
From: Andrew Sullivan <>
Message-ID: <>
References: <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <>
Subject: Re: [Ianaplan] Question from the ICG
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IANA Plan <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 29 Sep 2015 17:34:32 -0000


On Tue, Sep 29, 2015 at 06:23:45PM +0100, Olivier MJ Crepin-Leblond wrote:

> recommendation was made by several entities, including the ALAC. We were
> concerned that whilst today there appears to be several informal
> channels, the future might not keep it this way. So we felt that it
> would be a good idea to keep at least a formal channel open so that we
> don't end up with one operational community deciding to split without
> finding a way to keep the three functions operated by the same IANA
> functions operator.

With respect, that is exactly how bureacracies get built: people try
to replace a functioning rough-and-ready system with something that is
formal and well-built.  Once you establish such formal rules, it is
almost impossible to resist the temptation to continue to build more
formalism, and soon you have people following the rules instead of
getting the work done.  It is far from clear to me that the much more
formal communication paths among the various intra-ICANN
constituencies are more resilient or reliable than the informal
communication paths that exist inter-community.

> idea what the next generations will be like and whether this collegial
> collaboration will continue.

If we (as communities) see those bonds start to fray, then we will
have a responsibility to set up the relevant communication mechanisms,
with that responsibility being one of the tasks that is handed along
between generations of people.  The IAB already has this
responsibility not just with ICANN but with any other organization
that impinges on the IETF.  I don't think the IANA-community
relationships are unusual in any important way as compared to other
such relationships, so I think the formal commitment from the IETF
already exists.  This is expressed in RFC 2850 section 2 item (f).

So if something special is wanted, we can point to that.

Best regards,


Andrew Sullivan