Re: [Rfced-future] Welcome to the RFC Editor Future Development Program

"Joel M. Halpern" <jmh@joelhalpern.com> Thu, 02 April 2020 02:22 UTC

Return-Path: <jmh@joelhalpern.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 25B3E3A0A82 for <rfced-future@ietfa.amsl.com>; Wed, 1 Apr 2020 19:22:29 -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 (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 DBSPODufQH52 for <rfced-future@ietfa.amsl.com>; Wed, 1 Apr 2020 19:22:28 -0700 (PDT)
Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (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 D5ED63A0A58 for <rfced-future@iab.org>; Wed, 1 Apr 2020 19:22:27 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 48t6KH4pmkz6GHV9; Wed, 1 Apr 2020 19:22:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1585794147; bh=jFkVVcP+FAA9Oq9mxZwn0Guvxe+cdYwjCLXxmQJ5bXQ=; h=Subject:To:References:From:Date:In-Reply-To:From; b=EOL/cMxrNw+aJOx8gRQ7i7DOMPxbRiFtSa5OPh6IV0rjclhA4mVHGI8yz7WlbRSRR z3X5Gcgck//bfOjkjJ7DVuJm37gTYu61FQ6qEAznRmdhDN9H6/tqQ5csLvzM2Eij/a ArOkxgOM81YIdUYRCaJlqariNvi88u6htO9DQk/k=
X-Virus-Scanned: Debian amavisd-new at a2.tigertech.net
Received: from [192.168.128.43] (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 maila2.tigertech.net (Postfix) with ESMTPSA id 48t6KH09tDz6GHTt; Wed, 1 Apr 2020 19:22:26 -0700 (PDT)
To: Christian Huitema <huitema@huitema.net>, rfced-future@iab.org
References: <97B63B78-0D49-4007-B8A2-101FB7849C0F@cisco.com> <e1876470-c6aa-da6a-5282-5fe2a4d8d893@cs.tcd.ie> <612878B544D3F4BD620D9650@PSB> <c8b96911-e57f-e324-6c58-042a4ca0a3f2@cs.tcd.ie> <0a9001d60887$02d355e0$087a01a0$@acm.org> <450dc214-2606-d764-a24d-5b91a642f3bb@huitema.net>
From: "Joel M. Halpern" <jmh@joelhalpern.com>
Message-ID: <d95d9ca5-77d4-490d-1fe7-35b20db01016@joelhalpern.com>
Date: Wed, 01 Apr 2020 22:22:27 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <450dc214-2606-d764-a24d-5b91a642f3bb@huitema.net>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/rfced-future/jFFLn8sRgB7-3AWZUEFCW0YZRBo>
Subject: Re: [Rfced-future] 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 02:22:29 -0000

Christian, I am a bit confused by your message.  Removing post-approval 
editing, while it would reduce tension and delay, would also 
significantly reduce document quality.  The RPC does an impressive job 
of fixing the many minor but significant errors we put in our documents. 
  Ranging from inconsistent terminology to really bad grammar.
I, for one, would be really unhappy at trying to decide we did not need 
that.

Yours,
Joel

On 4/1/2020 9:39 PM, Christian Huitema wrote:
> 
> On 4/1/2020 5:38 PM, Larry Masinter wrote:
>>> I hope this process can find a way to deal with such divergent views, or find
>>> a role description with which we are all equally unhappy, but with which we
>>> can all live;-(
>> I think the question is how big a scope of "solutions" should be taken on.
>> At the "large scope" are changes to the nature of RFCs and the series
>> At the "small scope" end I'd suggest -- without any other change -- focusing on the "AUTH48" status since 48 hours and only the authors cannot proofread everything that needs proofreading.
>>
>> (History RFC2616 had several errors that were due to bugs in the process of converting Word to text/plain)
>>
>> I can't tell from the posts and intro material what level of changes to the process you'd want to contemplate.
> 
> 
> There is indeed an issue with AUTH48, but there is a more general issue 
> with "changing documents after consensus is declared".
> 
> For the IETF stream, the current process puts the final phase of editing 
> after the final vote by the IESG. This is a source of both tensions and 
> delays. The tension is obvious: if a document can be changed after it 
> has been approved, how do we guarantee that the changes do not change 
> the meaning of the documents in a way that alters consensus? The process 
> puts that responsibility on the authors and the AD, but the authors may 
> or may not have the time to examine the changes closely, and the AD may 
> or may not be already overloaded. So that create delays, not because the 
> copy editors are slow, but because the authors and AD end up responding 
> slowly.
> 
> Removing tensions and delays would make life easier for everybody.
> 
> -- Christian Huitema
> 
>