Re: Cross-area review (was Meeting rotation)

Dave Crocker <dhc@dcrocker.net> Thu, 24 December 2015 02:21 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 475A51AD0BB for <ietf@ietfa.amsl.com>; Wed, 23 Dec 2015 18:21:30 -0800 (PST)
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
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 SCHpOBCRpSLX for <ietf@ietfa.amsl.com>; Wed, 23 Dec 2015 18:21:28 -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 DD05E1AD0B9 for <ietf@ietf.org>; Wed, 23 Dec 2015 18:21:28 -0800 (PST)
Received: from [192.168.1.99] (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 tBO2LSku005551 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT) for <ietf@ietf.org>; Wed, 23 Dec 2015 18:21:28 -0800
Subject: Re: Cross-area review (was Meeting rotation)
To: IETF discussion list <ietf@ietf.org>
References: <CAC8QAcf=yAAGVN35tUCpX38y6_qGstGhK4iYuyhK94LVWrz-+A@mail.gmail.com> <7A7519D5-FD9B-4F4D-A7E5-AC047F684623@netapp.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>
From: Dave Crocker <dhc@dcrocker.net>
Organization: Brandenburg InternetWorking
Message-ID: <567B56A9.4030302@dcrocker.net>
Date: Wed, 23 Dec 2015 18:21:29 -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: <8D23D4052ABE7A4490E77B1A012B630797A0C2DE@mbx-03.WIN.NOMINUM.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]); Wed, 23 Dec 2015 18:21:28 -0800 (PST)
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/DNiVoPtbpEZ8AfUHYTuQHRL4kF8>
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: Thu, 24 Dec 2015 02:21:30 -0000

On 12/23/2015 5:46 PM, Ted Lemon wrote:
> Dave Crocker wrote:
>> AD review appears to miss far more than it catches.  That's seems
>> to be difficult for some folk to accept, and so they point to the
>> individual exceptions rather than the longer pattern of misses.
>> (By way of some very strategic examples, consider IPv6 and DNSSec
>> and email security and key management and...)
>
> Do you have data on this?

Anecdotal. Mine. Over enough years to represent a pattern. (I'm not
alone in this, but I'm reporting my own experience) In 25 years, not one
single RFC I've worked on had a serious problem caught by an AD, though
many were eventually discovered to have serious problems. Some were
delayed by large numbers of non-substantive or flat-out-wrong AD
Discusses, however. So we got significant costs with insignificant
benefits and significant damage.

Yes, there are legitimate issues caught.  Again, my point is not enough
(and by the way, not nearly soon enough.)


> This doesn't match my experience.   I've found AD review to be very
> helpful.

I find /all/ reviews "helpful".  But that marginal benefit does not
justify the strategic costs of consuming scarce resources, calendar
delay, participant frustration, etc. by imposing them at the end of a
long development cycle.


> It's certainly inconvenient,

Inconvenient is such a mild word. The aggregate effect of these kinds of
hassles is decisions by potential participants to take their
specifications elsewhere.


> but I've seen AD reviews catch lots of things that were worth
> catching.

Again, that's not the issue.  Every review by every reviewer tends to be
performed honestly and well and to provide useful feedback.  However
that, unfortunately, does not justify the particulars of AD reviews.
Please go back and consider the /balance/ of costs and benefits I cited.

The benefit of periodically finding something significant needs to be
balanced against the costs of resource consumption, significant issues
missed, delays, and participant frustration.


> I would not go so far as to claim that my anecdote is more valid than
> yours, but I think that if we are going to make claims like this, we
> should probably back them up with data.   The current AD review
> process didn't just happen.

25 years ago, the IETF was a very, very different place.  We've kept the
formal structures put in place then, without adapting to the changes.
Simply put, what we put in place doesn't scale.  We're supposed to know
something about scaling issues, but we apply none of it to
administration of the IETF...



> On 12/23/2015 5:54 PM, Eric Burger wrote:
>> I think the analogy here is that AD review, cross-area review, and
>> sacrifices to Amaterasu will not find ALL of the bugs in a
>> specification. The best we can hope for is to do best practices to
>> keep the bugs to an acceptable, low level.

The last sentence if quite reasonable, as long as it include the balance 
clause, "at an acceptable cost" and as long as we then fairly consider 
costs.


d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net