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
- Out-of-area ADs [Re: IETF areas re-organisation s… Brian E Carpenter
- Mashing areas [Re: IETF areas re-organisation ste… Brian E Carpenter
- Re: Out-of-area ADs [Re: IETF areas re-organisati… Stephen Farrell
- Re: IETF areas re-organisation steps Eliot Lear
- Re: IETF areas re-organisation steps Fred Baker (fred)
- Re: IETF areas re-organisation steps Nico Williams
- Re: Mashing areas [Re: IETF areas re-organisation… Ted Lemon
- Re: Mashing areas [Re: IETF areas re-organisation… John Leslie
- Re: IETF areas re-organisation steps Brian E Carpenter
- Re: IETF areas re-organisation steps Nico Williams
- Re: IETF areas re-organisation steps Nico Williams
- Re: Mashing areas [Re: IETF areas re-organisation… John C Klensin
- Re: IETF areas re-organisation steps Jari Arkko
- Re: IETF areas re-organisation steps Jari Arkko
- Re: Mashing areas [Re: IETF areas re-organisation… Ted Lemon
- Re: Out-of-area ADs [Re: IETF areas re-organisati… Pete Resnick
- Re: Out-of-area ADs [Re: IETF areas re-organisati… Dave Crocker
- Re: Out-of-area ADs [Re: IETF areas re-organisati… Brian E Carpenter
- Re: Out-of-area ADs [Re: IETF areas re-organisati… Pete Resnick
- Re: Out-of-area ADs [Re: IETF areas re-organisati… Nico Williams
- General view of re-org proposal (was : Out-of-are… Andrew Sullivan
- Re: Out-of-area ADs [Re: IETF areas re-organisati… Dave Crocker
- Re: Out-of-area ADs [Re: IETF areas re-organisati… Andrew Sullivan
- Re: Out-of-area ADs [Re: IETF areas re-organisati… Nico Williams
- Re: Out-of-area ADs [Re: IETF areas re-organisati… Nico Williams
- Re: Out-of-area ADs [Re: IETF areas re-organisati… Nico Williams
- term for 3rd RTG AD Michael Richardson
- Re: term for 3rd RTG AD Brian E Carpenter
- RE: term for 3rd RTG AD Adrian Farrel
- Re: term for 3rd RTG AD Yoav Nir
- Re: term for 3rd RTG AD Michael Richardson
- Re: term for 3rd RTG AD John Leslie
- Re: term for 3rd RTG AD Brian E Carpenter
- Re: term for 3rd RTG AD Murray S. Kucherawy
- RE: term for 3rd RTG AD Adrian Farrel
- RE: term for 3rd RTG AD Michael StJohns
- Re: term for 3rd RTG AD Allison Mankin
- Re: term for 3rd RTG AD joel jaeggli
- Re: term for 3rd RTG AD Michael Richardson
- Re: term for 3rd RTG AD Michael StJohns
- Re: term for 3rd RTG AD Michael Richardson
- IETF areas re-organisation steps IETF Chair
- Re: IETF areas re-organisation steps Ted Hardie
- Re: General view of re-org proposal (was : Out-of… Jari Arkko
- Re: IETF areas re-organisation steps Jari Arkko
- Re: General view of re-org proposal (was : Out-of… Brian E Carpenter
- Re: IETF areas re-organisation steps Phillip Hallam-Baker
- Re: IETF areas re-organisation steps Jari Arkko
- Re: IETF areas re-organisation steps Donald Eastlake