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

Nico Williams <nico@cryptonector.com> Mon, 29 December 2014 00:12 UTC

Return-Path: <nico@cryptonector.com>
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 2AF6E1AC3C2 for <ietf@ietfa.amsl.com>; Sun, 28 Dec 2014 16:12:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.233
X-Spam-Level:
X-Spam-Status: No, score=0.233 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=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 1-kIYL-D938Y for <ietf@ietfa.amsl.com>; Sun, 28 Dec 2014 16:12:48 -0800 (PST)
Received: from homiemail-a113.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id F29221AC3C0 for <ietf@ietf.org>; Sun, 28 Dec 2014 16:12:47 -0800 (PST)
Received: from homiemail-a113.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a113.g.dreamhost.com (Postfix) with ESMTP id 978A620058D84; Sun, 28 Dec 2014 16:12:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=HYcAMXQ/bxopFK 0ki/AwnTraouQ=; b=fwFgTLkM5CPfWDd5shZxOIbgHmqXtUJQ60R74l85Pj7pwh vobsKxPOIoH9CtrEbQPNrfWdM0oh7wdgWIJQhm7bj1FWJ8RLD85gmdOJYfbRq69Y adx0D/45GLEEsNdChMEhar4WrtWujpzhqWLEmWqukcibB5n1zrAl8vDtJNYRk=
Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a113.g.dreamhost.com (Postfix) with ESMTPA id 5391C20058D82; Sun, 28 Dec 2014 16:12:47 -0800 (PST)
Date: Sun, 28 Dec 2014 18:12:46 -0600
From: Nico Williams <nico@cryptonector.com>
To: dcrocker@bbiw.net
Subject: Re: Out-of-area ADs [Re: IETF areas re-organisation steps]
Message-ID: <20141229001241.GD24442@localhost>
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> <54A07420.2030507@dcrocker.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <54A07420.2030507@dcrocker.net>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/SHDizuackz6y0cDG0mAHTKoAh1g
Cc: ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
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: <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: Mon, 29 Dec 2014 00:12:49 -0000

On Sun, Dec 28, 2014 at 01:20:32PM -0800, Dave Crocker wrote:
> 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.

If we get WG/AD assignments wrong, or fill vancancies with people with
the wrong skills, then we can have several kind of sub-optimal outcomes:

 - Less review for WG documents, leading to lower quality outputs (in
   some cases harmful documents might get through).

   But this seems unlikely: we have so many opportunities for review
   already...  WG LC, IETF LC, AD shepherding, IESG review, reviews by
   the various directorates.

 - Unstated-but-very-real moving of review burdens onto the directorates
   and the larger IETF as the IESG drops the ball.

What mechanism do we have for addressing these outcomes _now_?

We get to chime in when the IESG makes a proposal like this one.  Else
we get to complain at the plenaries and on this list and hope the
complaints don't fall on deaf ears.  In particular we can't appeal
inaction, and appealing a set of individual bad outcomes is not likely a
useful mechanism for dealing with organizational problems.

Whereas a process that permits frequent WG/AD reassignments would allow
our complaints to lead to IESG action: because the action sought would
cost the IESG relatively little effort, we might actually get it.

> The reality is that we -- as in, 'the world' -- understand these
> dynamics poorly.  [...]

We have trouble predicting results, and trouble understanding social
problems, but we know when we are having problems.  The IESG is saying
"we're having problems".  We could do nothing out of fear of unintended
consequences, but even inaction has unintended consequences.

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

That's a fair point, but if you look around you'll see that we have
generalists.  Cross-area reviews tend to force people out of their
comfort areas.

"Has demonstrated expertise in unrelated areas" is a predictor of
"ability to develop new expertise".  That seems like a meta directive to
give to the NOMCOM.

Incidentally, if you look around, there's a short-hand for this sort of
specializable-generalist: full stack engineer.  The market is clamoring
for them.  I'm not sure how many there are, nor how many can find
employment or funding that allows them to serve on the IESG.  But one
happy consequence of market demand will probably be increased supply.

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

Absolutely.  This is a detail that goes fine with my proposal, but I'd
also go a bit more meta:

   Has demonstrated expertise in unrelated areas.

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

My experience is that ADs bring a lot more to the table than merely
following a script, dotting i's, crossing t's, and lending authority to
directorate reviews.  I'd like this to continue to be the case.

I don't think ADs bring value because _areas_ bring value.

I think ADs bring value because they are a small but varied group of
experienced and accomplished engineers.  The first part (small group) is
a given, the second (varied) is up to the IESG and NOMCOM themselves,
and the third part is a happy accident (namely, that the NOMCOM has had
a decent supply of decent candidates with employer support).

"Areas" strike me as accidental, or at least incidental, not remotely
fundamental.  Perhaps that perception is quite wrong, you'd have to tell
me.  But if it's right, then why do we bother with "areas" when they
start to cause friction?  A: because generally a "restructuring" makes
the immediate problem go away, so areas survive as an organizing
principle.

Nico
--