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

Brian E Carpenter <brian.e.carpenter@gmail.com> Thu, 02 April 2020 02:45 UTC

Return-Path: <brian.e.carpenter@gmail.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 A16A73A03EE for <rfced-future@ietfa.amsl.com>; Wed, 1 Apr 2020 19:45:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 WDxLpvhFOH83 for <rfced-future@ietfa.amsl.com>; Wed, 1 Apr 2020 19:45:05 -0700 (PDT)
Received: from mail-pf1-x433.google.com (mail-pf1-x433.google.com [IPv6:2607:f8b0:4864:20::433]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 106523A03ED for <rfced-future@iab.org>; Wed, 1 Apr 2020 19:45:05 -0700 (PDT)
Received: by mail-pf1-x433.google.com with SMTP id q3so1024765pff.13 for <rfced-future@iab.org>; Wed, 01 Apr 2020 19:45:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=sMbQTS0Ni7D3EOHs1AuCQEOAHaqTebflWClT9sF831c=; b=a19Uc0PCxcR5NV6DLG9q7zF0quWPv3Qt8ih4Au7KjCX3XvktqSV3CyRROOpCNlMhC0 0lERpcgcXl1lTbWX6U77FexAYqunhSnBJLwjY2II40Oj2NriFiQK0XoRZELQTpYARdhX oogmwHmn1b0ufuCmjEhGBvdiLJBGa3qfqJ2LksiEezgVPD+k0Vg6/AdAr3ETB6HhNUK5 OR/Ee88Ut8fZYlSsKjDmsPbg/oIeGewGHXKcnO5YKvBzXgb6etUrHmxgYxvuvo100Wfu vYIqZxMRHRe3NlxRteffvqLzeBhK5hlxp+I73vCguB4mt5zkp48pAGc9CJO92ElKem+u BcFg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=sMbQTS0Ni7D3EOHs1AuCQEOAHaqTebflWClT9sF831c=; b=Kieea/GL0NXp4Sn6MUE3PM2x2ZWsAzOGGl2Ba4GZ8l1z5NZnfgBVE3utMJSxBxAldb SR2MPEKvGt9yoDD5KyvMFt+xxMO6NHqJJsk9s5JSaZPoMeDiVtN3GKDokLTaQ6hkooHC QyHW553WB7peSAA1TfA7ITJiIM3xZgjtEv5OqmDY3sn8HuIjp8aqdpX88V1xXWdPNybZ tMn803N+jCkNq1+s+hqEBn8eZ4Nbb4uylYYb/WQGXiabbzjot6aFJsGNQ78h4L48w7G7 7CFS2kL53HpwWquGj1wTujoifQVFxFkXSF/6v3vQsC0DtpdcSRuNjTAMGNDQCmr90Ve7 ZJrg==
X-Gm-Message-State: AGi0PuZi8Gr2B6JKKAh/GrmYN1nntkij8XMCJrpD3KksV71JKE9Op4Nf /xBJ6JOG69Z4bdtJE25vUrtMnhFz
X-Google-Smtp-Source: APiQypJOtHtssHc3aVDujdtj23DyyP9qD6sf5dACLaXN2XlVCjG70yUhA5YGnTAWf2TFYEwBx3hIjg==
X-Received: by 2002:a62:2b05:: with SMTP id r5mr899773pfr.120.1585795503199; Wed, 01 Apr 2020 19:45:03 -0700 (PDT)
Received: from [192.168.178.30] ([165.84.25.143]) by smtp.gmail.com with ESMTPSA id j96sm2613229pje.32.2020.04.01.19.45.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 01 Apr 2020 19:45:02 -0700 (PDT)
To: "Joel M. Halpern" <jmh@joelhalpern.com>, 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> <d95d9ca5-77d4-490d-1fe7-35b20db01016@joelhalpern.com>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-ID: <ecb18a07-6968-08e6-5552-ec2cec71303f@gmail.com>
Date: Thu, 02 Apr 2020 15:44:58 +1300
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <d95d9ca5-77d4-490d-1fe7-35b20db01016@joelhalpern.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/rfced-future/eoQETYrawpSkpkdO_6EylKgVXaY>
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:45:07 -0000

On 02-Apr-20 15:22, Joel M. Halpern wrote:
> 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.

Fully agreed. The WG Chairs and Area ADs are CCed on AUTH48 and I assume they will look out for changes of semantics. If not, why are they copied?

Certainly any substantive changes must be properly reviewed, in the worst case by going back to WGLC. But that is vanishingly rare, I think.

    Brian

> 
> 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
>>
>>
>