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
