Re: To "lose the argument in the WG"

Dave Crocker <dhc@dcrocker.net> Tue, 14 February 2017 15:32 UTC

Return-Path: <dhc@dcrocker.net>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F06E9129624 for <ietf@ietfa.amsl.com>; Tue, 14 Feb 2017 07:32:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.792
X-Spam-Level:
X-Spam-Status: No, score=-1.792 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=dcrocker.net
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 xzweTCsZ1Krz for <ietf@ietfa.amsl.com>; Tue, 14 Feb 2017 07:32:48 -0800 (PST)
Received: from simon.songbird.com (simon.songbird.com [72.52.113.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F17C1295CE for <ietf@ietf.org>; Tue, 14 Feb 2017 07:32:48 -0800 (PST)
Received: from [192.168.1.168] (76-218-8-128.lightspeed.sntcca.sbcglobal.net [76.218.8.128]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id v1EFYSVO029993 (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 14 Feb 2017 07:34:28 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=default; t=1487086469; bh=5D8lDf1M5ghkPHS3V55D6FvQlxPJQkpiae+oGCeLwn8=; h=Subject:To:References:Cc:From:Reply-To:Date:In-Reply-To:From; b=GQfL6YssZwD7EsIVWmbP+5y7Cv2bzMX3NC9DM6XHbIfKRg8punIBqXmObhCK15hPl RBgPMogT6qg8LLMp4hXfi1Vonnkwoi7WQph9P9z6WLAILPeUvcw7gLurD8VWBSDpxA MpvTiNBLhxARdkaKypJk5Db97Vbn2YBbOz2ftsRc=
Subject: Re: To "lose the argument in the WG"
To: Stewart Bryant <stewart.bryant@gmail.com>, John C Klensin <john-ietf@jck.com>, Pete Resnick <presnick@qti.qualcomm.com>
References: <66A86016-0382-4B2C-B9E8-30638237CB68@qti.qualcomm.com> <00e13499-7cea-a79a-7de1-dd9bad4bc530@dcrocker.net> <F4592855-640C-4A32-989F-275C359C89EE@qti.qualcomm.com> <C8DC848672108BF32D41ADAC@PSB> <bce0454f-9c51-b5ca-3270-19486f72c972@gmail.com>
From: Dave Crocker <dhc@dcrocker.net>
Organization: Brandenburg InternetWorking
Message-ID: <b317aeb0-ea9b-e70c-17a8-d75d8fb24e83@dcrocker.net>
Date: Tue, 14 Feb 2017 07:32:36 -0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1
MIME-Version: 1.0
In-Reply-To: <bce0454f-9c51-b5ca-3270-19486f72c972@gmail.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/hvI0uP8HiZbqKoKxaHcKBLsYax0>
Cc: IETF discussion list <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
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: Tue, 14 Feb 2017 15:32:49 -0000

On 2/14/2017 12:40 AM, Stewart Bryant wrote:
>
> Yes, it is the prospect of a complete re-run of the argument at IETF LC
> that keeps WGs honest.


In theory, perhaps.  In practice, no it doesn't.

What it does do is to help make the IETF process onerous, and therefore 
aid in making the IETF a place to avoid when possible.

Having folk spend months (or years) working on a detailed specification 
and then have to go through a detailed defense at the end is 
disrespectful of their effort.  It is also impractical, because it 
essentially requires re-creating the context for making various 
decisions made along the way, months (or years) later, to folk who have 
no skin in the game.

For those rare cases in which there really is a problem that needs 
fixing, forcing a wg to go through this random defense process mostly 
speaks to failures in oversight and review that should be happening 
along the way, not at the end of the process.

And, again, note that it almost never works.  While it creates 
additional work and pain for those who are tired from the lengthy 
process, it rarely (if ever) produces serious benefit.

For the folk who think this is an essential bit of IETF quality control, 
please produce documentation of the times this defense is required and 
compare when it has produced meaningful change and when it hasn't.  Just 
coming up with stray examples of benefits ignores the larger number of 
cases where it incurs costs without benefits.[*]

To the extent that a working group does need course-correction, then 
let's look for ways to do that that are effective and efficient and 
much, much earlier.

d/

[*] Please remember that the trigger for this sub-thread is a 
sour-grapes effort by an existing wg participant to force review of a 
(potentially much) earlier wg decision they didn't like.  A separate 
case is of fresh, non-wg eyes that might see something none of the 
older, more-tired eyes of wg participants caught.  The former case 
really is sour grapes.  The latter case could be naivete or it could be 
insight.  Mostly of the time it is the former.  That ought to mitigate 
the certitude of the fresh eyes, but it usually doesn't.

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net