Re: A couple of meta points -- IETF 100, Singapore, onwards

Stephen Farrell <> Tue, 24 May 2016 02:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A2FC612DC35 for <>; Mon, 23 May 2016 19:11:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.727
X-Spam-Status: No, score=-5.727 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 93xwST9scM5r for <>; Mon, 23 May 2016 19:11:07 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1A7F412DC36 for <>; Mon, 23 May 2016 19:10:49 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id A4BA3BE47; Tue, 24 May 2016 03:10:47 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7UlJJl0EGNk4; Tue, 24 May 2016 03:10:46 +0100 (IST)
Received: from [] ( []) by (Postfix) with ESMTPSA id DBFF2BE39; Tue, 24 May 2016 03:10:45 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=mail; t=1464055846; bh=aLwJyaZPy+Pn8W9aDR18PdFIqrS9FAnVAI0lFRUIswA=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=af0CaeDYodeG6ZCFFWCFvadLdFB5tQidvzhzn/qZsc2FBeGFQhO+tPch9b+ZiF0y6 A85t7zWOh42HlZ/809/86TW7EGAXtRvVx2G5VeqB5WQJHi3eGblMd4AC8pORiCvRzy GBw+3TSK5XrojvGAvYSsBy3HiitPofEHaEk185X8=
Subject: Re: A couple of meta points -- IETF 100, Singapore, onwards
To: Alissa Cooper <>, Leslie Daigle <>
References: <> <>
From: Stephen Farrell <>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <>
Date: Tue, 24 May 2016 03:10:45 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="------------ms010809000708070701080402"
Archived-At: <>
Cc: IETF discussion list <>
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 24 May 2016 02:11:09 -0000

On 23/05/16 22:13, Alissa Cooper wrote:
> I raise this in particular because Cisco happens to be the host for
> IETF 100. In chatting with folks around the company, it didn't seem
> to me that anyone had been contacted by the IAOC about the
> possibility of helping to offset costs associated with relocating the
> meeting, prior to you sending your mail last week. 

I think that is a point that the IAOC can and really must specifically
address. I don't need to know the content of the communication between
the IAOC and the meeting sponsor, but the IAOC do I think need to tell
us if there was communication between the IAOC (or a subcommittee of, or
other body reporting to, the IAOC) and the meeting sponsor for IETF-100
about the controversy over this meeting and the potential practicality
and/or costs for switching it to another venue.

I don't ask in an attempt to catch folks out or cast aspersions as to
individual folks' capabilities, so I'm not trying to apportion blame.
I'm really wondering if maybe a) the IAOC don't know the answer, (thus
calling into question whether internal IAOC structures are actually
blocking transparency), or b) if the IAOC does know that discussion
with the IETF-100 sponsor happened, then I just don't get why that
wasn't communicated to the community already (calling into question the
apparent intent to switch to a more open mode of operation), or c) if
there was no such communication, then...really? And doesn't that seem
to imply that structures within/reporting-to the IAOC don't seem to
be sensitive to community concerns or even IAOC statements?

I hope there's a (d) answer though, as none of (a), (b) or (c) reflect
very well on how the IAOC is operating. (And again, I'm not trying to
criticise any individual - I think if there are such problems, they are
likely inherent how the IAOC-confidential-by-default setup and similar
systems naturally evolve over a decade or so.)