On 8/20/24 09:16, John C Klensin wrote:
The ADs need to be part of the process, and hopefully part of the rough consensus, *before* any resulting documents get near to being ready for formal IESG review. So I've added a Cc.Again agreed, and see above. Unfortunately, that view appears to me to be at variance with an IESG that, several times in recent years, has taken the position that, once WG leadership is appointed and the WG chartered and launched, there is no need for the IESG to pay much attention to it until document publication is requested, at least unless they get a request from the WG Chair or a formal appeal. Given the (completely understandable) circumstances that seem to have led to that view, it may be yet another reason to separate work concerning IETF processes or operations from work that is more technical.
IMO this isn't related to whether the work is about IETF process
or protocols that run over IP, as much as it's just an indication
of IESG workload. IESG is already busy enough with WG
chartering, last call reviews, and just trying to keep track of so
many working groups even at a superficial level, and then there's
the occasional controversy that IESG has to deal with (some of it,
perhaps, self-inflicted, but not all of it).
And there's often kind of a community expectation that the IESG really needs to charter every working group that the public thinks is a good idea, WHEN the public thinks it's a good idea, and not manage its own workload.
Adding more ADs doesn't necessarily lower the workload much, because (for example) more ADs means more input into IESG-wide discussions, more DISCUSS votes, etc.
As for deliberations about IETF processes, I'm pretty sure that those need to be informed by people who have lots of experience with, and active engagement in, those processes. So I'm not sure that separating work is a good idea.
There's a point of diminishing returns to increased federation.
It has seemed to me since the mid-1990s that there are some
fairly serious scaling limits to IETF's structure, and there's no
way to address those limits without fairly significant (and likely
painful) changes to that structure.
Keith
