Re: Transparency of IAOC

Stephen Farrell <stephen.farrell@cs.tcd.ie> Tue, 12 April 2016 21:34 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BFD412D6BB for <ietf@ietfa.amsl.com>; Tue, 12 Apr 2016 14:34:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.297
X-Spam-Level:
X-Spam-Status: No, score=-5.297 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=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
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 23vYA1QjFzeZ for <ietf@ietfa.amsl.com>; Tue, 12 Apr 2016 14:34:29 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86D0F12D764 for <ietf@ietf.org>; Tue, 12 Apr 2016 14:34:29 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id F29FABE25; Tue, 12 Apr 2016 22:34:26 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 67LpDRiN7yF0; Tue, 12 Apr 2016 22:34:25 +0100 (IST)
Received: from [10.87.49.100] (unknown [86.42.21.187]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id DB37EBE2F; Tue, 12 Apr 2016 22:34:24 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1460496865; bh=GkmcUfiU+uYxciEwZwiqYMysuz89K0E3xd9TBvatWQ0=; h=Subject:To:References:From:Date:In-Reply-To:From; b=pKGYae2mX9y9y2aVuV5tqY7KL+rFKlQLRPBGKn6Aa2k7xtOrccUmeus9tRakv1aje MmGT5u+wK8e1jI95LQDGzN4ey1WYzd4xml/J6SjEsn34Exp9Ihb/Q9/ORCrwD0clCE odpeBN+DDkbxnFSWi8ZvKgt42lN1yDUPOxOmn3RY=
Subject: Re: Transparency of IAOC
To: Brian E Carpenter <brian.e.carpenter@gmail.com>, SM <sm@resistor.net>, Dave Crocker <dcrocker@bbiw.net>, ietf@ietf.org
References: <6.2.5.6.2.20160412031201.0da034e8@elandnews.com> <6.2.5.6.2.20160412114424.0e7061b0@resistor.net> <570D5B51.8090307@gmail.com>
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <570D69E0.30209@cs.tcd.ie>
Date: Tue, 12 Apr 2016 22:34:24 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <570D5B51.8090307@gmail.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="------------ms040600010703070102050206"
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/C4Fm55jKeC_7UMI1htIXN8-rZkE>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 12 Apr 2016 21:34:32 -0000

Hi Brian,

On 12/04/16 21:32, Brian E Carpenter wrote:
> Of course it is. But (compared to the IESG) the IAOC does deal with
> a comparatively large fraction of issues that have confidential
> aspects - budget negotiation, contract negotiations, staff issues,
> operation security, and (with their Trustee hats on) legal issues. So
> there are going to be more problems about community access to IAOC
> proceedings than for the IESG.

What I'm wondering is if, given the above, anyone has done an
analysis of what the IAOC really needs to keep confidential and
what does not need to be confidential?

For example, recent events have fairly conclusively shown that
the "cities being considered" data which is related to "contract
negotiation" really ought not be confidential, at least in some
aggregated form. If you go back some years, the IETF meeting
hotel was also a not-so-well-kept secret until bookings opened,
and when we changed that the sky did not fall. So that's another
example. And if say the vmeet mailing list had been the place
where it was decided that IETF-95 remote attendees would have to
register, then we might have avoided that fuss. I can't see how
making that decision on that public list would have hurt anything
even though the fine meetecho support overall nvolves quite a few
of the issues related to confidentiality you list above.

I don't know if the IAOC has analysed such things more generally.
But I hope it does do that once it's sorted out what to do about
IETF-100. I suspect that to date, the IAOC has been treating too
much data as confidential when that's not really needed. I figure
ending up in that state is quite understandable, but is not in the
end a good plan.

And I don't believe we've actually heard the IAOC say that they
do think such a general exercise is or is not worthwhile. I do
think that some such statement now that the IAOC will consider a
switch to a default-open posture would be very very useful and
has not yet been made. (*)

Cheers,
S.

(*) Leslie's mail [1] only referred to reviewing meeting planning,
but not e.g. to any broader re-consideration which is what I'm
arguing would be better.

[1] https://www.ietf.org/mail-archive/web/ietf/current/msg97545.html