Re: [Diversity] Concerns about Singapore

Dave Crocker <dhc@dcrocker.net> Sun, 10 April 2016 19:49 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 484CA12D5C3 for <diversity@ietfa.amsl.com>; Sun, 10 Apr 2016 12:49:14 -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 l3jI9wOHGllM for <diversity@ietfa.amsl.com>; Sun, 10 Apr 2016 12:49:13 -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 1529512D0F2 for <diversity@ietf.org>; Sun, 10 Apr 2016 12:49:13 -0700 (PDT)
Received: from [192.168.1.168] (76-218-10-206.lightspeed.sntcca.sbcglobal.net [76.218.10.206]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id u3AJn7YW004030 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 10 Apr 2016 12:49:07 -0700
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>, nalini.elkins@insidethestack.com, Andrew Allen <aallen@blackberry.com>, Yoav Nir <ynir.ietf@gmail.com>
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>
From: Dave Crocker <dhc@dcrocker.net>
Organization: Brandenburg InternetWorking
Message-ID: <570AAE2E.9060000@dcrocker.net>
Date: Sun, 10 Apr 2016 12:49:02 -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]); Sun, 10 Apr 2016 12:49:08 -0700 (PDT)
Archived-At: <http://mailarchive.ietf.org/arch/msg/diversity/zdMa_mg1j8m2TQk_akHGZCpW8sM>
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: Sun, 10 Apr 2016 19:49:14 -0000

Stephen,


> (We're maybe wandering from the direct relevance to this list,
> but I think many of the right people are subscribed to most of
> the possible lists so let's continue...)

Actually, we're not.  There is a tendency to believe that diversity 
issues are solved by better awareness, or better documentation, or more 
diligent attention, or by enforcing well-intentioned-but-artificial 
membership quotas on committees.  None of those suffice for complex and 
emotional social concerns, of the sort we are currently seeing.

So discussion about the best ways to ensure on-going handling of such 
issues is entirely relevant.


>> The IAOC (and the Meetings Committee that I participate in) means well
>> and attempts to be diligent, but it simply is not certain (or IMO,
>> likely) to adequately assess these kinds of community concerns well
>> enough.  Last week demonstrated that.
>
> I do agree, both that folks are well meaning and that we're
> almost certainly going to have future surprises and issues
> to tackle no matter what we do.

What I am advocating -- and I'm not the one who put the idea forward -- 
/does/ ensure no further surprises about basic venue legal, 
environmental, political or social acceptability.


> 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.)
>
> - Publicly describe the specific kinds of information that are not
>    handled according to the default-open policy.

Stephen, that's an example of magical thinking about transparency. 
Sounds good but isn't practical for most administrative work or most 
administrative environments.  In ignores costs and inefficiencies and 
imposes unrealistic burdens on the folk doing the work.  (By the way, it 
also imposes unrealistic burdens on the community, who have to pay very 
close attention, all the time, to all this new detail being made 
available...)

Further, you are calling for massive operational changes, with only 
modest direct relationship to the problem at hand.  By contrast, the 
suggestion I'm advocating is simple, cheap, safe, and effective for 
exactly the kind of issue at hand.


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

I'm in favor of a great deal of openness.  And I concur that the IESG 
steps have been a Good Thing.  But IMO venue administrative work is 
quite different.

At the least, the politics of turning down a venue and/or a host 
involves far more delicacy than is possible with a fishbowl operational 
model.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net