Re: Internet-Draft draft-rsalz-2026bis-00.txt is now available.

[Keith Moore <[e-mail]>]

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