[Gendispatch] Re: [procon] dispatching draft-carpenter-rfc7221bis

[Carsten Bormann <[e-mail]>]

On 25. Mar 2025, at 11:23, Michael Richardson <[e-mail]> wrote:
> 
> 
> Carsten Bormann <[e-mail]> wrote:
>>> substantive changes to the document […] need to represent working group rough consensus.
> 
>> I hope this never gets IETF consensus.
> 
>> The whole point of a WG draft is to have documents that can be used to
>> *test* WG consensus.  If they already have to reflect WG consensus, do
>> you do a WG last call before publishing each revision?  On *what*?
> 
> 1) you need WG consensus to adopt a document

Yes, but very explicitly at the time a document is adopted it itself is not a consensus document!

> 2) you need WG consensus to substantially change a document

Well, no.
The authors are supposed to change the document in a way that
(a) makes sense (technical quality!)
(b) is conducive to achieving consensus eventually.

Often, document authors have spent a bit longer with thinking about its content, so they can manage (a) and (b) in a more productive way than just layering bureaucracy (i.e., committee IQ).

If the WG says no (judged by the authors or ultimately the chairs!), the authors can always revert.

> Noting that WG chairs judge these two things.

The evolution of a document is managed by its authors.
If the chairs don’t like how things go, they can install a new author team.
But the chairs are not the authors!

(Obviously, there are WGs that operate based on pull requests, but one or two approvals of a PR before it is merged do not consensus make.)

> But, you are ironically, applying document-must-be-perfect-before-adoption to
> this document :-)

Not at all, I just says I hope this passage never achieves consensus (which was a statement about the future!).

> None of that section is new.  Maybe you dislike the wording, but the question
> is: do you agree that there is a problem?

As so often, there may be a problem, but that would not be with the process, but with the lack of *applying* the process (including the choice of the author team).

I generally knee-jerk when someone argues for replacing a process when the real problem is that the process isn’t even used (or known!) in the first place.

(Of course, a process can be unworkable, but I’d like to know why.
The put-as-many-roadblocks-in-the-way-of-progress-as-possible process *is* unworkable, and it is easy to explain why [I could point to a recent example].)

Grüße, Carsten