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

John C Klensin <john-ietf@jck.com> Thu, 02 April 2020 03:51 UTC

Return-Path: <john-ietf@jck.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 7EB3A3A094E for <rfced-future@ietfa.amsl.com>; Wed, 1 Apr 2020 20:51:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 sOlPzYNk_P3r for <rfced-future@ietfa.amsl.com>; Wed, 1 Apr 2020 20:51:28 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F96E3A094D for <rfced-future@iab.org>; Wed, 1 Apr 2020 20:51:28 -0700 (PDT)
Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1jJqt2-0003N8-VQ; Wed, 01 Apr 2020 23:51:24 -0400
Date: Wed, 01 Apr 2020 23:51:18 -0400
From: John C Klensin <john-ietf@jck.com>
To: Christian Huitema <huitema@huitema.net>, "Joel M. Halpern" <jmh@joelhalpern.com>
cc: rfced-future@iab.org
Message-ID: <75FEFDC1BB902A9091739F47@PSB>
In-Reply-To: <4BC58577-8CC7-48CB-803F-F4E6E080188B@huitema.net>
References: <d95d9ca5-77d4-490d-1fe7-35b20db01016@joelhalpern.com> <4BC58577-8CC7-48CB-803F-F4E6E080188B@huitema.net>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/rfced-future/aqP8qQwMSM8tOlXcVYBryIk7ouM>
Subject: [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 03:51:30 -0000

(I've changed the subject line because I really hope we can
split this off and either set it aside until other work is
finished or find another way to handle it as an issue.)

--On Wednesday, April 1, 2020 19:30 -0700 Christian Huitema
<huitema@huitema.net> wrote:

> I did not write that we should remove copy editing. But we
> could certainly find models in which it happens before
> approval, not after it.

Christian, see my earlier note and Mike's response, with while I
agree.  

However, fwiw, models are well-known in which documents reach a
certain state before the final community decision process that
would be nearly equivalent (as process steps) to the combination
of our Last Call and IESG final review are pulled out and
subjected to what is essentially final editing.  There is then
usually an opportunity for the group that produced the draft
document to review it and argue with the editors.  The edited,
document then goes into final reviews.  If those reviews
identify changes that require changes, the changes are made and
the document re-edited, and then, depending on the extent of the
changes, either the whole document or the changes go through the
review process again.

A few details and small differences aside, that is the method
used in ITU-T, in ISO and ISO/IEC JTC1, in many (perhaps most)
ISO National Member Bodies, and in a variety of other SDOs.  The
IETF is probably not unique in the way we do things, but I
suspect we don't have a lot of company.

I'm aware of a number of proposals to shift to something closer
to the other model, at least on during Heather's term and the
first probably in the late 1980s.  The decision to not do so was
always based on what were considered bad tradeoffs with multiple
issue, almost always including:

(1) The editing process takes time. The IETF has never been
willing to have a WG finish a document and then go into a wait
state for some weeks or months while that document is being
edited, then wake up, review it, and recommend that it be put
out for Last Call.   At least in the past, our way of working
was perceived as incompatible with that.

(2) Editing documents that may never be approved, or that will
be approved only with significant changes (and then edited
again), is costly in people and hours.  I vaguely recall Heather
(probably with help from Sandy and/or Alice) making some rough
estimates of how much additional staff would be needed.  I don't
remember the numbers, but it was certainly enough to affect the
bottom line.  When I remember the idea being reviewed, those
potential costs were a consideration.

I do think that things have changed enough that it is time to
ask the question again.  But, again, I think this effort is not
the right place or time.

  best,
    john