Re: Cross-area review (was Meeting rotation)

Dave Crocker <dhc@dcrocker.net> Sun, 27 December 2015 22:48 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 9D3411A6FC2 for <ietf@ietfa.amsl.com>; Sun, 27 Dec 2015 14:48:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.9
X-Spam-Level:
X-Spam-Status: No, score=-0.9 tagged_above=-999 required=5 tests=[BAYES_50=0.8, J_CHICKENPOX_21=0.6, 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 O-QrINQ0nRYs for <ietf@ietfa.amsl.com>; Sun, 27 Dec 2015 14:48:06 -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 143901A6FBB for <ietf@ietf.org>; Sun, 27 Dec 2015 14:48:06 -0800 (PST)
Received: from [172.31.98.241] (STARBUCK-CO.edge4.LosAngeles1.Level3.net [4.15.243.34]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id tBRMm5Qw003022 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Sun, 27 Dec 2015 14:48:05 -0800
Subject: Re: Cross-area review (was Meeting rotation)
To: "Joel M. Halpern" <jmh@joelhalpern.com>, IETF discussion list <ietf@ietf.org>
References: <CAC8QAcf=yAAGVN35tUCpX38y6_qGstGhK4iYuyhK94LVWrz-+A@mail.gmail.com> <EMEW3|02dedadbe5e65aac9732e9359a7c2dberBHGjK03tjc|ecs.soton.ac.uk|E7D065D8-CADC-4A65-8AC7-6ECE9CF63D4F@ecs.soton.ac.uk> <CAHw9_iKtck6ZSp6ofNFKLRj7-o3_UR42McTNQqsqCXfcduxAeA@mail.gmail.c om> <5674460C.1000107@krsek.cz> <4B81FA54-F79C-42CB-8024-1C653B0C9406@cisco.com> <20151218233645.GG3294@mx2.yitter.info> <56749EA4.6040801@gmail.com> <20151219000743.GH3294@mx2.yitter.info> <5676EBE9.8050304@dcrocker.net> <970B54F5-2422-4588-A95A-63E5144A8D35@gmail.com> <56789BBB.7020709@dcrocker.net> <4AE6DC68FC9B8CA113CBCDFA@JcK-HP8200.jck.com> <5678D728.2080404@dcrocker.net> <5226A23C6E26B0350DE715AE@JcK-HP8200.jck.com> <D6278A46-19AB-48D8-B55A-48FF51B7E0EC@piuha.net> <2508B3C2-8F5F-4417-8052-E73B6F34BED1@standardstrack.com> <567ACCEE.9030503@dcrocker.net> <8D23D4052ABE7A4490E77B1A012B630797A0C2DE@mbx-03.WIN.NOMINUM.COM> <567B56A9.4030302@dcrocker.net> <567B86EB.9030600@joelhalpern.com>
From: Dave Crocker <dhc@dcrocker.net>
Organization: Brandenburg InternetWorking
Message-ID: <56806AA7.6090005@dcrocker.net>
Date: Sun, 27 Dec 2015 14:48:07 -0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0
MIME-Version: 1.0
In-Reply-To: <567B86EB.9030600@joelhalpern.com>
Content-Type: text/plain; charset="utf-8"; 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, 27 Dec 2015 14:48:05 -0800 (PST)
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/9CLlTIaqu83dQQp4IZfz7Vk33TU>
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: <https://mailarchive.ietf.org/arch/browse/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, 27 Dec 2015 22:48:07 -0000

Joel,

On 12/23/2015 9:47 PM, Joel M. Halpern wrote:
> I note in your earlier description you commented that these reviews
> (whose value you doubt)

Unfortunate that you'd toss that in as a distracting aside, especially 
since it is not an accurate summary of what I said.


>       take up AD time when they should be serving as
> managers.    I note that many areas now routinely turn the primary review
> over to a directorate.

You are implying that the use of directorate reviews is instead of AD 
reviews.  While sometimes it might be, at other times it isn't.

Since my core point is that AD reviews are a strategic problem, not a 
strategic benefit, the fact that there are other reviews done is largely 
unresponsive to my point.


 >  The ADs decide how much careful combing they do
> after the directorate.  That seems to enable the kind of delegating that
> can help, without mandating it, and without having rules that
> micro-manage how ADs do their job.

Ahh, good. Another convenient IETF cliche. "Micro-manage" has become 
such a facile way of dismissing substantive comments.  So is the cliche 
to leave everything up to someone else's discretion.

There are strategic issues, here, Joel.  The "AD under lampposts" focus 
is about requiring or encouraging or expecting area directors to do work 
that is not (very) productive, takes (significant) time, and 
(substantially) reduces the pool of area directors, by virtue of making 
the job's footprint larger than it needs to be.

Worrying about the community's basic requirements and expectations on 
ADs is as far from micro-managing as one can get.

Looking at AD Discuss text and listening to IESG Telecons[*] shows 
well-intentioned people who often indulge in pursuit of fine-grained 
detail that is possibly appropriate from an individual contributor and 
never appropriate from a second-level manager.  Alas, it also often 
shows ADs who are more inclined to be swayed by their personal 
preferences than by the formal constraints they are supposed to be 
operating under.

The current Nomcom's 'general' AD job description includes:

> For other Internet-Drafts an AD needs simply to be satisfied that
> adequate review has taken place, though many ADs personally review
> these documents as well.

That looks entirely compatible with your characterization, and my point 
is that having /any/ expectation that /any/ AD will review most or all 
I-Ds that come before the IESG is a mistake.  A strategic mistake.

We need to do a much better job of describing the AD job in ways that 
encourage and require doing specifically the work that the IETF needs to 
have an AD do, and to very carefully exclude tasks that bloat the job 
with time-consuming, low-benefit efforts. The efforts do not serve the 
community well and they reduce the population of AD candidates.

The view that reviews by ADs, themselves, are essential requires 
ignoring trade-offs and, worse, cherry-picking the data.  Let me repeat 
that even in those very rare cases that an AD catches something major, 
we should view that as documentation of a very deep and very serious 
error in a process that let's such basic problems get that far.

Even expecting an AD to be deeply familiar with the documents they are 
'sponsoring' is questionable; it's predicate is that the AD should be 
the primary representative for the work, in spite of not having been a 
principal in the work.  If IESG handling of a specific document is not 
controversial -- ie, no Discusses -- then the AD doesn't need deep 
knowledge.  If the IESG handling involves controversy, Discusses, or the 
like, then get some principals to be involved in the discussion, not the 
second-hand efforts of the AD.i

ADs should worry about basic wg functioning, about community 
participation in the work, about community assessment of the work, and 
about the likelihood of community update of the work.  Lines those ducks 
up and the spec will quack, independent of the AD review.

d/


[*] Jari and the rest of the IESG deserve very considerable community 
thanks for opening the formal telecon meetings to this community 
observation.

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net