Re: [Gendispatch] Large cluster [Re: I-D Action: draft-eggert-bcp45bis-01.txt]

[Eric Rescorla <[e-mail]>]

On Tue, Mar 30, 2021 at 3:06 PM Brian E Carpenter <
[e-mail]> wrote:

> Off topic, but just to clarify my intention:
>
> On 31-Mar-21 09:20, Eric Rescorla wrote:
> >
> >
> > On Tue, Mar 30, 2021 at 1:13 PM Brian E Carpenter <
> [e-mail] <mailto:[e-mail]>> wrote:
> >
> ...
> >     > We can always revise it again, when there is consensus on more
> fundamental changes.
> >
> >     Agreed, and that needs a much deeper analysis. And IMNSHO there are
> many much more important process issues to resolve than the occasional
> unruly threads on ietf@. Just to pick one at random, what can we do to
> prevent something like Cluster 238 ever happening again?
> >
> >
> > This is a bit hard to answer without having a clearer statement
> > of what went wrong with C238.
>
> There's a partial analysis at https://www.ietf.org/blog/webrtc-pandemic/


Yes, I've read that. I agree it's right substantively, but it's not clear
to me what the ill effects people are most concerned with are.




> > I could imagine several objections here:
> >
> > - We shouldn't have projects which require changes to large
> >   chunks of the protocol suite.
> >
> > - We shouldn't have to publish all the documents in those
> >   projects simultaneously.
> >
> > - It's hard for the RPC to manage the simultaneous publication
> >   of all those documents.
> >
> > - Something else?
> >
> > It seems like each of these might have different solutions.
>
> Indeed, and some of them are related to the old question of how to
> dynamically document complex standards with components at different
> maturity levels. My real question is: are we going to duck the hard
> questions about the IETF standards process?
>

I'm not sure it's so much a matter of ducking the hard questions as having
deep disagreements about their nature and the constraints we are operating
under. For instance, ISTM that the primary source of this problem is the
insistence on immutability of the published documents and therefore of only
publishing document X when all its dependencies are published, rather than
when it is otherwise "ready" with the expectation that it might be
necessary to revise it if issues are found in the dependencies. However, I
am aware that many disagree strongly with that position. Hence, it is
difficult to make progress.

-Ekr