Re: [Diversity] Concerns about Singapore

Dave Crocker <dhc@dcrocker.net> Tue, 19 April 2016 13:57 UTC

Return-Path: <dhc@dcrocker.net>
X-Original-To: diversity@ietfa.amsl.com
Delivered-To: diversity@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C6F812D4FD for <diversity@ietfa.amsl.com>; Tue, 19 Apr 2016 06:57:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham 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 cYfFTR6gSC_F for <diversity@ietfa.amsl.com>; Tue, 19 Apr 2016 06:57:55 -0700 (PDT)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0466212D7EB for <diversity@ietf.org>; Tue, 19 Apr 2016 06:57:54 -0700 (PDT)
Received: from [192.168.1.168] (76-218-8-128.lightspeed.sntcca.sbcglobal.net [76.218.8.128]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id u3JDvntH013927 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 19 Apr 2016 06:57:49 -0700
References: <20160410063603.6283348.44889.10575@blackberry.com> <459690655.171220.1460293717474.JavaMail.yahoo@mail.yahoo.com> <6.2.5.6.2.20160410074445.0de30c68@resistor.net> <570A8B0E.5060505@cs.tcd.ie> <570A9419.5090009@dcrocker.net> <570AA89F.5050302@cs.tcd.ie>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
From: Dave Crocker <dhc@dcrocker.net>
Organization: Brandenburg InternetWorking
Message-ID: <57163956.5020902@dcrocker.net>
Date: Tue, 19 Apr 2016 06:57:42 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2
MIME-Version: 1.0
In-Reply-To: <570AA89F.5050302@cs.tcd.ie>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Tue, 19 Apr 2016 06:57:49 -0700 (PDT)
Archived-At: <http://mailarchive.ietf.org/arch/msg/diversity/ac3aUjZcPX6t2zYYYLJpgA6dhVc>
Cc: diversity@ietf.org
Subject: Re: [Diversity] Concerns about Singapore
X-BeenThere: diversity@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: Diversity open mailing list <diversity.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/diversity>, <mailto:diversity-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/diversity/>
List-Post: <mailto:diversity@ietf.org>
List-Help: <mailto:diversity-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/diversity>, <mailto:diversity-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 19 Apr 2016 13:57:56 -0000

Meant to respond to this back when it was posted, but there is a basic 
point that still is worth pursuing...


On 4/10/2016 12:25 PM, Stephen Farrell wrote:
>> My own view is that the only way to make sure that a venue is acceptable
>> to the community is to publish a list of candidate venues, as early as
>> possible, and let the community debate any concerns it might have.
>
> That is one necessary aspect of transparency. But if the IAOC
> consider that making just this one change is enough to tackle
> the longer term issue (i.e. things not specific to IETF-100)
> then we are heading for more failures. Personally, I do not
> think that making just that one entirely obvious change is
> anywhere near sufficient - IMO the IAOC needs to re-examine
> all the things it does that are not open.

I specified a single, narrow issue and offered a specific approach that 
responds to it.  My personal view is that with respect to the concern 
about whether a city is acceptable for an IETF meeting, the approach is 
sufficient.

No one has suggested that this one action resolves larger concerns about 
community insight into IAOC activities.  No one, that is, until you 
introduced it here, as a strawman.

My understanding is that the IAOC is, in fact, looking at the larger 
issues more broadly.

My own view is that the larger issues should be decoupled from the basic 
question of assessing whether a city is acceptable, first because the 
latter has become a more immediate issue, second because (IMO) it is 
relatively simple to resolve, and third because the larger issues are 
significantly more complicated to resolve well.


> But since I apparently was not clear enough before, here's another
> attempt to say what, in addition to handling IETF-100 specifics,
> I think the IAOC needs to do now:
>
> - Decide to, and announce, that the default position is to be open
>    with all data, email etc. That should happen now. (Or should have
>    happened already perhaps.)

As you have phrased it, in my view, that's an entirely irresponsible 
starting point, given the nature of the administrative work the IAOC does.

Having a goal of sharing as much as is reasonable certainly makes sense. 
  But the downsides of disclosing the wrong information or disclosing 
information at the wrong time are too high to have a 'default open' 
model be practical.  This is a topic that requires some nuance and 
simplistic rules don't suit it.  However the pressure to be more open is 
good and I hope the dialogue about it continues.


> Lastly, having seen the incremental increases in open-ness that the
> IESG has made in the last 5 years, and that not one of those has had
> a bad effect that I can recall, despite some fears each time we opened
> up more, I think that while some IAOC folks might understandably
> be a bit afraid of a default-open policy, I reckon doing so is likely
> to just work, if done well.

If the work covered the same range of sensitivities, then yes, using the 
same model would make sense.  Since it doesn't, it doesn't.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net