Re: Transparency of IAOC

Stephen Farrell <stephen.farrell@cs.tcd.ie> Tue, 12 April 2016 21:48 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 15FE512D80D for <ietf@ietfa.amsl.com>; Tue, 12 Apr 2016 14:48:52 -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 88idzF2kkvB5 for <ietf@ietfa.amsl.com>; Tue, 12 Apr 2016 14:48:50 -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 7AE7912D632 for <ietf@ietf.org>; Tue, 12 Apr 2016 14:48:50 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 42FBFBE33; Tue, 12 Apr 2016 22:48:49 +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 ZkVSvltaQKCt; Tue, 12 Apr 2016 22:48:47 +0100 (IST)
Received: from [10.87.49.100] (unknown [86.42.21.187]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 130A5BDF9; Tue, 12 Apr 2016 22:48:47 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1460497727; bh=uM2nHBXuBO+dGvtLsfZtLzOyNEFfIuaTbNIBv3dV38s=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=fjPA6fHHrZ3fjwBCLdXxfX/kMHjtECA577jlkcMcvEdEkPIVuir6kYddpImy481bC SbuAVRQIzgUyS0FLb6/gcWujtTg62B86EhOfrkY9XoA0iinqCZSWoPNRO7dgMQi5wq 8DIoMdMxSiS/Vy4swBN8znz/gCz7yjX3Tj8M6IN0=
Subject: Re: Transparency of IAOC
To: "Scott O. Bradner" <sob@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> <ECD0A4B2-7C8C-4FB0-B9BD-D3C6B3E96E0A@sobco.com>
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <570D6D3E.1060904@cs.tcd.ie>
Date: Tue, 12 Apr 2016 22:48:46 +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: <ECD0A4B2-7C8C-4FB0-B9BD-D3C6B3E96E0A@sobco.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms040009040608000108040509"
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/BPSqd_JIG-f28kgiBgpP79PdSMI>
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:48:52 -0000


On 12/04/16 22:46, Scott O. Bradner wrote:
> such an exercise is worthwhile & has been underway for a few weeks 
> you will see some results very soon

Excellent!

Thanks,
S.

> 
> 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
>>
>>
>>
> 
>