Re: [Rfced-future] AUTH48 and editing before approval (was: Re: Welcome to the RFC Editor Future Development Program)

John Levine <johnl@iecc.com> Thu, 02 April 2020 19:58 UTC

Return-Path: <johnl@iecc.com>
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 122B63A125D for <rfced-future@ietfa.amsl.com>; Thu, 2 Apr 2020 12:58:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.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 6GUG0TgltYmq for <rfced-future@ietfa.amsl.com>; Thu, 2 Apr 2020 12:58:34 -0700 (PDT)
Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 F34F23A125F for <rfced-future@iab.org>; Thu, 2 Apr 2020 12:58:33 -0700 (PDT)
Received: (qmail 12710 invoked from network); 2 Apr 2020 19:58:31 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=31a4.5e8643e7.k2004; bh=pRoi7Z4viyY6KaehGK9QWHPY9H1RfYwqiNctW1drTas=; b=uIrAALXxljs89m4h3/EpKam43fFV6jNLBJ4ZGGL7RnMgeI4rRfMVBikcehrAdR6acffK+jtIqtVLJ/nNa2kVzNkjOENg2jvj64nIQrwp+waHcPoq+OIDJAVFubcLu/UzQZG3ozTxrNH110y3/klbNUkD3vwdoKVwL57Qu3JULSNAXI6Q2gAQFQVsAYWbKVtMb94yC6zNh6dBuEPxojmt4ljz/m15+Mobx7jduKP03APzsK6JPrP/ikRd1OgBgTSc
Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 02 Apr 2020 19:58:31 -0000
Received: by ary.qy (Postfix, from userid 501) id 264FC16EE898; Thu, 2 Apr 2020 15:58:30 -0400 (EDT)
Date: Thu, 02 Apr 2020 15:58:30 -0400
Message-Id: <20200402195831.264FC16EE898@ary.qy>
From: John Levine <johnl@iecc.com>
To: rfced-future@iab.org
Cc: lear@cisco.com
In-Reply-To: <A5C7C919-4389-4D6E-82D0-6315456C8455@cisco.com>
Organization: Taughannock Networks
X-Headerized: yes
Mime-Version: 1.0
Content-type: text/plain; charset="utf-8"
Content-transfer-encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/rfced-future/sxsQR87A80xXv8xCUYp7qmgqTa0>
Subject: Re: [Rfced-future] AUTH48 and editing before approval (was: Re: Welcome to the RFC Editor Future Development Program)
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program <rfced-future.iab.org>
List-Unsubscribe: <https://www.iab.org/mailman/options/rfced-future>, <mailto:rfced-future-request@iab.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rfced-future/>
List-Post: <mailto:rfced-future@iab.org>
List-Help: <mailto:rfced-future-request@iab.org?subject=help>
List-Subscribe: <https://www.iab.org/mailman/listinfo/rfced-future>, <mailto:rfced-future-request@iab.org?subject=subscribe>
X-List-Received-Date: Thu, 02 Apr 2020 19:58:37 -0000

In article <A5C7C919-4389-4D6E-82D0-6315456C8455@cisco.com> you write:
>Can we distill the high level point that needs addressing in this process?
>
>Are the touch points and flow the responsibility of the RFC Editor to define, or should that be this group?

It is a fact of life that errors will always turn up at inconvenient
points in the process.  One time I found a mistake in one of my books
while doing the equivalent of AUTH48.  I found that the same error was
in two previous editions, and none of my coauthor, our quite competent
editors, or me had noticed it before.

We need to consider the tradeoffs between fixing them and living with
them, with the costs of fixing them being delay and perhaps rework,
and the possibility that the fix will be wrong, too.

R's,
John