Re: Evolving Documents (nee "Living Documents") side meeting at IETF105.)

"Joel M. Halpern" <jmh@joelhalpern.com> Fri, 19 July 2019 03:58 UTC

Return-Path: <jmh@joelhalpern.com>
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 59B2812013B for <ietf@ietfa.amsl.com>; Thu, 18 Jul 2019 20:58:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.68
X-Spam-Level:
X-Spam-Status: No, score=-1.68 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com
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 f7K3WzspHyyo for <ietf@ietfa.amsl.com>; Thu, 18 Jul 2019 20:58:09 -0700 (PDT)
Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (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 20C5B120043 for <ietf@ietf.org>; Thu, 18 Jul 2019 20:58:09 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 45qcfn0L6QzVmmG for <ietf@ietf.org>; Thu, 18 Jul 2019 20:58:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1563508689; bh=o3oMTddZnqE3Pf2HcuI6cBhRpLBIMnsOs9xVpg4RGqU=; h=Subject:Cc:References:From:Date:In-Reply-To:From; b=heqF10ulEYsNZ5AjXsesdOYRxM/NtmyBb6MCqdcLhQ3aero3q9/KzKF7vA/yFM+us 3iZpVMC0eFC+KQABl4xhPkRv1ss4SDrJs2YIC2CnRAPQrRtKbB8tVbGrysdZd5nCS2 nGLpNVgrnXvEYvrqkC2go7uYxOzIvI7MphzoSdu4=
X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net
Received: from [172.20.7.244] (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 45qcfm4XLKzVfbX for <ietf@ietf.org>; Thu, 18 Jul 2019 20:58:08 -0700 (PDT)
Subject: Re: Evolving Documents (nee "Living Documents") side meeting at IETF105.)
Cc: ietf@ietf.org
References: <6317584D-4C9B-46E9-8197-D2A488701868@fugue.com> <20190704140552.GE49950@hanna.meerval.net> <b0943792-1afc-0c94-51b7-f2d393ef39c5@network-heretics.com> <20190705205723.GI55957@shrubbery.net> <20190706185415.GB14026@mit.edu> <CABcZeBPgNr5UqQ0pLwwNu5wh0g9L9wCd6YyYKCUDO37SPru-_Q@mail.gmail.com> <20190708202612.GG60909@shrubbery.net> <9ae14ad1-f8d5-befb-64e4-fff063c88e02@network-heretics.com> <20190717004659.GC67328@shrubbery.net> <00618698-deec-64cf-b478-b85e46647602@network-heretics.com> <20190718231911.GA75391@shrubbery.net> <ed9d3b5b-7442-fdee-8f0f-c614ca4b59e4@network-heretics.com> <CACWOCC-T13zD1DVKA1H3UTNG9iKdNz5TDzObYPk_A6sjfPKFug@mail.gmail.com> <8F980759-324F-49C5-925A-DF0EEABBBD21@network-heretics.com> <d08dbee2-7844-d813-0b93-5db503501c7e@gmail.com> <50E6B4DF-83FC-46A5-94E9-1FF08F597CCF@network-heretics.com> <F2D5DCCF-4051-444B-9522-9E11F9F93005@fugue.com> <869599E9-7571-4677-AB9A-961027549C54@network-heretics.com>
From: "Joel M. Halpern" <jmh@joelhalpern.com>
Message-ID: <144ff436-a7a2-22f7-7b06-4d0b3bcfefac@joelhalpern.com>
Date: Thu, 18 Jul 2019 23:58:06 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <869599E9-7571-4677-AB9A-961027549C54@network-heretics.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/Y1JA78vpstrCk6nCxadol_wzfxc>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
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: <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: Fri, 19 Jul 2019 03:58:11 -0000

(Supporting Keith on this.)

One of the key benefits of IETF meetings is cross-area review.  One of 
the key reasons for having WG last call is the observed need for review 
outside the working group.  One of the observation from many such 
reviews is that it is amazing how much a working group can miss while 
getting its core stuff right.
Yes, this also means that periodically folks raise objections that are 
spurious, miss the point, or have been addressed already.  But the cost 
of not having the review is VErY high.

Yes, folks have suggested that the review should be lightened or 
eliminated.  So far, the community has refused to do that.  And I for 
one am very glad that is so.  In spite of having had to deal with some 
frustrating objections in many cases.

Yours,
Joel

On 7/18/2019 10:10 PM, Keith Moore wrote:
> 
> 
> Sent from my iPhone
> 
> On Jul 18, 2019, at 10:00 PM, Ted Lemon <mellon@fugue.com 
> <mailto:mellon@fugue.com>> wrote:
> 
>> On Jul 18, 2019, at 9:50 PM, Keith Moore <moore@network-heretics.com 
>> <mailto:moore@network-heretics.com>> wrote:
>>> Yes, and I’ve repeatedly said I could see optimizing in corner 
>>> cases..  But I think it’s a rare WG that doesn’t have any potential 
>>> to adversely affect other interests.
>>
>> Another way to look at this is a well-known cognitive bias: “I am 
>> right.”   If you look at what a working group is doing and don’t 
>> understand it, there is a tendency to think they don’t know what they 
>> are doing, and that you know what they should have done.   This bias 
>> is frequently wrong, and I’ve seen it turned against good work 
>> numerous times.
> 
> That argument applies equally well to itself.
> 
> This is silly.  I’ve lost count of the number of WGs I’ve seen for which 
> I did understand what they were doing, and did understand how they could 
> harm other interests.  And in general Last Call is too late to fix those 
> problems.  I agree with Brian that that’s not a description of _every_ 
> WG, for the reasons he stated.  But as long as we’re talking about 
> process in general, the discussion needs to consider the potential for 
> tussles and how to manage that.