On 4/27/21 2:20 PM, Donald Eastlake wrote:
This process is central to our way of working; we even commissioned specific datatracker functionality for it ten years ago (RFC6174) and discussed the common practice in RFC7221.I agree. Indeed, becoming a WG draft represents a fundamental change in the status and process for a draft in that before that the author(s) can change the body of the draft however they want and add/remove authors as they want but after it is a WG draft the WG is in charge of the content and the WG Chairs how the power to appoint and remove authors/editors. Thus it is reasonable and beneficial that there be some difference in marking and/or draft name between these two cases.
I still maintain that this notion of "fundamental change" is a Bad Idea, or at least, that it is often done prematurely and perhaps too often.
Every author or editor of a WG document intended for standards track (whether or not it is "adopted") understands that their document has to earn WG rough consensus before it can go to IESG. But this isn't really determined until the results of a WGLC because basically it's premature to do so and also too much trouble. Until then, the authors/editors are (hopefully) trying to earn consensus and also to have their document be of the required quality for the intended status (both are requirements). But something's wrong if anyone thinks that the early drafts of a document (whether or not adopted by a WG) are, or should be, consensus documents. They are drafts, after all. Inherent in the concept of "draft" is that it's subject to revision.
Certainly in early stages of revision, and sometimes later,
authors/editors need the freedom to make significant changes to a
document, including major structural changes or even complete
rewrites, for a variety of reasons, e.g.: to make the document
more readable, to address major or minor flaws in earlier
versions, to improve justification of the technical decisions with
more comprehensive analysis, etc. It's even possible that as a
result of such editing, version -N of a document will be less
reflective of consensus than version -(N-1). The document is
hopefully still overall converging on consensus, even if it
oscillates around that point a bit from one revision to another.
(This is one reason why I doubt that using github as a
collaborative editing tool is a good idea for documents in early
stages, as I believe this can discourage major changes
prematurely.)
If you try to insist that documents always strictly approach
consensus, the effect of this is to slow the process down
drastically and also produce specifications that are overly
complex and don't interoperate well.
The whole concept of Internet-Drafts were that they were supposed to be lightweight, have minimal overhead, minimal requirements for publication, not subject to any central control. These attributes are/were important precisely because people need to be able to sketch out proposals in rough form before trying to get the details right. But people keep wanting to make them more and more formal. Please stop. That defeats their purpose.
It should be possible to crudely scribble some notes or drawings
on a piece of paper, scan it, add some minimal metadata (like a
title, authors' names, and a date) and publish that as an
Internet-Draft. We need to stop trying to make them look and
behave like RFCs.
Keith
