Re: Status of this memo

"Joel M. Halpern" <jmh@joelhalpern.com> Tue, 27 April 2021 23:12 UTC

Return-Path: <jmh@joelhalpern.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 4E52F3A2749 for <ietf@ietfa.amsl.com>; Tue, 27 Apr 2021 16:12:48 -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, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, 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 45LG5Y7y5SzZ for <ietf@ietfa.amsl.com>; Tue, 27 Apr 2021 16:12:43 -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 E42C13A267E for <ietf@ietf.org>; Tue, 27 Apr 2021 16:12:09 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 4FVHbF2C2sz6G9xN; Tue, 27 Apr 2021 16:12:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1619565129; bh=iCKw4Fgh49nlC0jJ9ThLnmeQ5qP7u35GWIkutq+x2Xw=; h=Subject:To:References:From:Date:In-Reply-To:From; b=nj+5i5Hw6qr49Ltf60EnkwlXQ5H6gwp5qMbcHOPikoZVcebHldn19IPBvQBw+TeLJ gCoTCRR5a4mc/zmWuhRrw1IfZYTdSpqptk4UDYNtwPG6SjK2Dqc5qybtjduMY2kHGS XEUt/HqoHsQhw2xBbPfx4tCQlebv2ILYoeO08U7k=
X-Quarantine-ID: <q8rN9R4P7X7W>
X-Virus-Scanned: Debian amavisd-new at a2.tigertech.net
Received: from [192.168.128.43] (unknown [50.225.209.66]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 4FVHbD4gRGz6G9xK; Tue, 27 Apr 2021 16:12:08 -0700 (PDT)
Subject: Re: Status of this memo
To: Keith Moore <moore@network-heretics.com>, ietf@ietf.org
References: <9ACE59FA-30B6-475A-AF6B-4B874E4A2788@eggert.org> <1804294246.5904.1619512137931@appsuite-gw2.open-xchange.com> <D653D3B2-7666-409A-B856-2A4B1BA958CA@eggert.org> <3DBB64B1-40B8-4BC3-B66C-7F9B7F395874@akamai.com> <b5210c71-9500-3dba-05d2-4ae1c6ad16e9@network-heretics.com> <CAA=duU1VJs2vCE=uCF=fXO7FNedn9yPAaZWTgcaAiHTexA8uWA@mail.gmail.com> <CAF4+nEEz4x3HtUhWQ0ONYCpyHy27E4u7_chVEuHi3rDr+sc39A@mail.gmail.com> <b3762d56-bff2-6f71-caa2-69d34e81b9dc@network-heretics.com> <20210427215415.GK79563@kduck.mit.edu> <aafedd93-0f90-aaa4-966e-8fef9573149e@network-heretics.com> <20210427222219.GN79563@kduck.mit.edu> <b5741e60-fd4c-ca3d-3973-ae1652bb42e9@network-heretics.com>
From: "Joel M. Halpern" <jmh@joelhalpern.com>
Message-ID: <a6b57eef-1a1e-2416-a98d-dfeda824dcf0@joelhalpern.com>
Date: Tue, 27 Apr 2021 19:12:07 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0
MIME-Version: 1.0
In-Reply-To: <b5741e60-fd4c-ca3d-3973-ae1652bb42e9@network-heretics.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/YJZYZ8OiZtjl3vKN6aoiXiQr8R8>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
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: Tue, 27 Apr 2021 23:12:50 -0000

Keith, I have to fundamentally disagree with you.
Once the WG adopts the document, the WG owns it, and the document pen 
holder (original author or otherwise) is expected to work according to 
the direciton of the WG.

For practicality and expediency, we do expect and allow the pen holder 
to make changes they consider appropraite, as long as substantive 
changes are confirmed with the working group.

If the pen holder will not make changes in accordance with the WG, the 
pen holder needs to be replaced.  As AD, when I had chairs and an editor 
who would not do so, I told the chairs to replace the editor.  When they 
resigned, I replaced them too.  (This was well over 20 years ago, which 
gives you an idea of how long this has been the understood process.)

If the pen holder can do whatever they want, then we have made a mess, 
as all decisions are deferred until WG last call.  WG decisions about 
document content do get revisisted.  But we have reasoanble expectation 
that the document reflects what the WG is likely to want.

this also allows the chairs a variety of points to make sure general 
IETF process (like does this document comply with the relevant PS and 
BCP RFCs) are being followed.

There are of course working groups that malfunction.
There are also likely other working groups where the chairs allow 
somewhat more latitude, because it is effective for the WG.  But even 
then, the WG retains the actual authority over the document.

The pen holder retains their rights in their original contribution.  But 
in fact, once it is incorporating text from the WG, it belongs to the WG.

Yours,
Joel

On 4/27/2021 6:58 PM, Keith Moore wrote:
> On 4/27/21 6:22 PM, Benjamin Kaduk wrote:
> 
>> My understanding is that you are objecting to statements that "a WG
>> draft is one where the WG has taken over change control".  I see your
>> comments elsewhere that the author/editor should have freedom to make
>> drastic changes, especially in earlier revisions, to attempt to 
>> improve the
>> document.  I think I agree with you in the sense that requiring
>> pre-approval to all changes to the text of a WG document hinders 
>> progress,
>> but I also think that if there is a conflict between what the editor 
>> wants
>> to do and what the WG wants to do, the editor must yield to the WG (or be
>> replaced).  In this sense I would say that the WG has change control, 
>> since
>> the WG consensus prevails.
> 
> I think I would say that, ideally, there is a tension between the role 
> of the WG and the role of the document editor.   The WG often has very 
> specific issues, concerns, and directions; the editor generally needs to 
> think a bit more holistically.   The document editor needs to interpret 
> the WG's instructions in such a way that the resulting document has 
> coherence.   Sometimes that includes sorting out ambiguities and 
> conflicts in the WG's direction, sometimes that can even mean 
> synthesizing entirely new language that attempts to capture or address 
> the spectrum of the WG participants' inputs.  If, early in the 
> document's life cycle, the WG is directing the document editor to use 
> exactly specific language, that's maybe a bad sign - the WG is trying to 
> do the editor's job.
> 
> Now if an editor flatly refuses to try to make the document address the 
> WG's concerns, or if perhaps, the WG loses faith in the editor's ability 
> or willingness to do that - the WG can certainly fork that document and 
> begin producing its own derivative works of that document.   In 
> principle a WG can do this with any document that's within the scope of 
> their charter and for which the WG has permission to create derivative 
> works.   That permission is granted to the IETF Trust as part of the 
> boilerplate (by reference, BCP 78, section 5.3 paragraph c).  The WG 
> does not need to take any formal action to create a derivative work of a 
> document when the IETF Trust already has permission to do this (I assume 
> that the IETF Trust granted permission applies to the WG - though not 
> sure precisely how that happens).
> 
> Note that creating a derivative work is not quite the same thing as 
> delegating change "control", since the author of an original work still 
> has the right to create derivative works of that work, and the license 
> granted to the IETF Trust in BCP78 is explicitly non-exclusive.   Of 
> course, in practice the WG decides which document it's going to forward 
> to IESG.   But I don't know why the original authors should be forbidden 
> to continue to revise their work in hopes of earning WG consensus... 
> just as anyone else can submit their own draft to the WG and hope to win 
> WG consensus for that draft over the WG's "adopted" version.   Mostly I 
> think it's just important to minimize the potential for confusion 
> between the two (or more) drafts.
> 
> If both the WG and the original author(s) can create derivative works, 
> and the WG can decide which work to forward to IESG, the only real issue 
> is who gets to keep the I-D identifier and produce revisions that retain 
> that draft-ietf-wgname-xxx-yyy prefix.   I have a feeling that I know 
> who would win that fight if it came to that, but my recommendation would 
> be that neither the author nor the WG get to continue using the old 
> prefix.   That seems like the least confusing result and also the one 
> least likely to cause pointless conflicts.   Whether the datatracker can 
> deal sanely with that case, I have no idea.
> 
> So, anyway, I don't think of "adopting" a I-D as asserting change 
> control, and AFAIK there's nothing in the process of adopting an I-D 
> that requires the original authors to relinquish their rights to create 
> derivative works of their contribution.
> 
> Keith
> 
>