Re: Transparency of IAOC

"Scott O. Bradner" <sob@sobco.com> Tue, 12 April 2016 21:45 UTC

Return-Path: <sob@sobco.com>
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 1EC0112D8E5 for <ietf@ietfa.amsl.com>; Tue, 12 Apr 2016 14:45:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.109
X-Spam-Level:
X-Spam-Status: No, score=-1.109 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no 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 tcup5Yq1gNQA for <ietf@ietfa.amsl.com>; Tue, 12 Apr 2016 14:45:37 -0700 (PDT)
Received: from sobco.sobco.com (unknown [136.248.127.164]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90C6612D855 for <ietf@ietf.org>; Tue, 12 Apr 2016 14:45:37 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by sobco.sobco.com (Postfix) with ESMTP id 378FC1BA634C; Tue, 12 Apr 2016 17:45:36 -0400 (EDT)
X-Virus-Scanned: amavisd-new at sobco.com
Received: from sobco.sobco.com ([127.0.0.1]) by localhost (sobco.sobco.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XTrmLspJBisN; Tue, 12 Apr 2016 17:45:34 -0400 (EDT)
Received: from [10.0.1.16] (173-166-5-69-newengland.hfc.comcastbusiness.net [173.166.5.69]) by sobco.sobco.com (Postfix) with ESMTPSA id 23DAD1BA633E; Tue, 12 Apr 2016 17:45:34 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Subject: Re: Transparency of IAOC
From: "Scott O. Bradner" <sob@sobco.com>
In-Reply-To: <570D69E0.30209@cs.tcd.ie>
Date: Tue, 12 Apr 2016 17:46:19 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <ECD0A4B2-7C8C-4FB0-B9BD-D3C6B3E96E0A@sobco.com>
References: <6.2.5.6.2.20160412031201.0da034e8@elandnews.com> <6.2.5.6.2.20160412114424.0e7061b0@resistor.net> <570D5B51.8090307@gmail.com> <570D69E0.30209@cs.tcd.ie>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
X-Mailer: Apple Mail (2.3124)
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/YuXHubgTQkcYO-UbJXsnDafxrWI>
Cc: SM <sm@resistor.net>, ietf@ietf.org, Dave Crocker <dcrocker@bbiw.net>
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:45:39 -0000

such an exercise is worthwhile & has been underway for a few weeks 
you will see some results very soon

Scott

> On Apr 12, 2016, at 5:34 PM, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:
> 
> 
> 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
> 
> 
>