Re: Out-of-area ADs [Re: IETF areas re-organisation steps]

Dave Crocker <dhc@dcrocker.net> Sun, 28 December 2014 21:20 UTC

Return-Path: <dhc@dcrocker.net>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEECE1AD65C for <ietf@ietfa.amsl.com>; Sun, 28 Dec 2014 13:20:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.301
X-Spam-Level:
X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham
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 ieYgV78q2X3u for <ietf@ietfa.amsl.com>; Sun, 28 Dec 2014 13:20:38 -0800 (PST)
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 737231AD65A for <ietf@ietf.org>; Sun, 28 Dec 2014 13:20:38 -0800 (PST)
Received: from [172.29.101.70] (wsip-72-214-58-13.sd.sd.cox.net [72.214.58.13]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id sBSLKYhL015634 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for <ietf@ietf.org>; Sun, 28 Dec 2014 13:20:38 -0800
Message-ID: <54A07420.2030507@dcrocker.net>
Date: Sun, 28 Dec 2014 13:20:32 -0800
From: Dave Crocker <dhc@dcrocker.net>
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: ietf@ietf.org
Subject: Re: Out-of-area ADs [Re: IETF areas re-organisation steps]
References: <5614C286-0CD2-4DAD-A846-510EE38D1B9A@ietf.org> <549DAE1C.5080400@gmail.com> <54A02C8A.3020707@qti.qualcomm.com> <54A04CDC.8020009@dcrocker.net> <54A05568.705@gmail.com> <20141228201401.GB24442@localhost>
In-Reply-To: <20141228201401.GB24442@localhost>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Sun, 28 Dec 2014 13:20:38 -0800 (PST)
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/l-VT19-wGQmm3GipHThcmMtVANQ
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: dcrocker@bbiw.net
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: <http://www.ietf.org/mail-archive/web/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: Sun, 28 Dec 2014 21:20:40 -0000

On 12/28/2014 12:14 PM, Nico Williams wrote:
> I get the fear.  But I think the risks are manageable with a simple
> prescription:

The belief that any of this can be made simple increases my fear, rather
than reducing it.

The reality is that we -- as in, 'the world' -- understand these
dynamics poorly.  Theere a cliche among organizational change folk:
Every change carries unintended consequences, and they are usually bad.
 This does not mean we should make no changes; but it does mean we must
approach the design of changes with caution -- starting with some
modesty about expected benefits -- and make on-going evaluations, to
look for those consequences and consider tweaks.


>>                     [...]. But it means that we would indeed change the
>> criteria for picking ADs. [...]
> 
> Here's my high-level proposal:
> 
>    We need an IESG mostly populated by generalists who can specialize,
>    and a few specialists who can generalize.
> 
> It's a compromise, of course. 

Forgive me, but it's much worse than that.

In the IETF today, what does it mean to be a generalist?  What are their
skills and how do we measure them reliability?  And do we have enough
such folk to fill the IESG pool on an on-going basis?

I think the practical answers to these questions are not at all
encouraging, so I'll offer a variant that is meant to carry some of the
spirit of Nico's suggestion, but is more pragmatic:

Make a list of the range of knowledge and skills we want on the IESG.
Some are low-level technical component skills, like ABNF and JSON.  Some
are intermediate-level, such as YANG and MIBs.  Some are higher-level
technical skills, such as system architectures, interaction analysis.
Some are organizational and communications, such as writing and management.

Consider an extensive list of such relevant skills and then decide what
amounts are needed for the IESG.  For some, like writing, we probably
need most/all of folk on the IESG to possess the skill.  For others,
like routing design/dynamics, we might need only two -- I'll suggest we
never need fewer than two, for any single skill.

Note that the nomcom process of filling the IAB has long had a version
of this approach, with a balancing effort across the full set of nominees.

Most of these skillsets are probably best dominated by directorates,
groups of 'doctors', or the like, with the IESG folk in the roles of
coordination and monitoring.

Having an IESG meeting take extensive time discussing a fine-grained
technical point might be entertaining for the principals engaging in the
debate, but it's impressively inefficient and mostly represents too
little, too late.  At best, having an IESG meeting take time to consider
a fine-grained issue means that the early-stage evaluations that should
have resolved this failed.  (At worst, it means that the ADs are
literally wasting everyone's time, while those ADs are taught why the wg
choice was valid/correct.)

Given the directorates, etc., what is the need for an AD to have these
skills?  Oversight, IMO.  It's difficult to assess a debate if one knows
nothing of the topic.  By the same token, being able to assess a debate
does not require being a world leader in the topic.


d/
-- 
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net