Re: RANT: posting IDs more often -- more is better -- why are we so shy?

John C Klensin <john-ietf@jck.com> Fri, 03 March 2017 14:23 UTC

Return-Path: <john-ietf@jck.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 18C59129583 for <ietf@ietfa.amsl.com>; Fri, 3 Mar 2017 06:23:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 i3ebWRlPds6Q for <ietf@ietfa.amsl.com>; Fri, 3 Mar 2017 06:23:20 -0800 (PST)
Received: from bsa2.jck.com (ns.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 266A7129547 for <ietf@ietf.org>; Fri, 3 Mar 2017 06:23:19 -0800 (PST)
Received: from [198.252.137.70] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1cjo73-000FWt-VD for ietf@ietf.org; Fri, 03 Mar 2017 09:23:17 -0500
Date: Fri, 03 Mar 2017 09:23:10 -0500
From: John C Klensin <john-ietf@jck.com>
To: "ietf@ietf.org Disgust" <ietf@ietf.org>
Subject: Re: RANT: posting IDs more often -- more is better -- why are we so shy?
Message-ID: <ED57F388B27F7F5D5EC87B3A@PSB>
In-Reply-To: <434ad124-e46c-fab9-9859-78ac34621096@gmx.de>
References: <14476.1488384266@obiwan.sandelman.ca> <CAHw9_iKuZrxD=51QadPPnuofUdAeaHPQ4JvONz5Bno3HTAi71A@mail.gmail.com> <434ad124-e46c-fab9-9859-78ac34621096@gmx.de>
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.70
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/ietf/FXSEChdNi0yjVixWvtizo7mCxtU>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
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, 03 Mar 2017 14:23:21 -0000

An observation on part of this thread, stimulated by some recent
experiences...

As people think about what should go where and how rapidly, it
is easy to forget two things about working group documents.  

First, the people we call authors are supposed to be reflecting
WG decisions and preferences, not their own, and are accountable
to WG chairs in the latter's capacity as interpreters of WG
consensus.  Situations and preferences differ as do WG styles of
operation, but, for some situations, that responsibility may
justify semi-private "did I get this right?" checking and/or
wanting a draft to reflect all of the conclusions from a given
WG meeting or email thread rather than having those changes
posted incrementally and without context.

Second, we often end up with co-authors (or co-editors) on a
given document and do so for a wide variety of different
reasons.  For example, when a document is a revision of an
earlier RFC, authors of the previous version may be listed as
authors on the new one as a courtesy even if they are not
actively participating editing the revision or even in the WG
(whether that is appropriate is another discussion).  However,
there are also cases in which two or more author-editors are
active at the same time, passing the virtual pen back and forth
or otherwise collaborating in a fairly dynamic way.  For those
cases, "are these changes ok with you?" and "did I miss anything
important?" checks are appropriate and often result in document
improvements and saved WG time.

Either of those situations can justify a delay of some days in
getting an I-D posted -- longer than pushing micro-changes to
github or equivalent.  They also provide further justification
for  a snapshot-based model.   I would suggest that, if delays
for these reasons are weeks (or longer) rather then days, the WG
may have a management problem, but that, too, is a almost
entirely a separate issue.

    john