I've recently been through several chartering efforts
and was quite surprised by the amount of effort ADs now put
into getting the charters sorted out, and correct. It
is very much appreciated but I do suspect one consequence
of this is that we're producing extremely high-quality
charters but the working group process and product is actually
not much improved. That is to say, IESG time and attention
are scarce and extremely valuable and I suspect that putting
this much effort into charters is not an optimal allocation
of these scarce resources, in the sense that it's consuming
more calories but doesn't appear to be leading to better
outcomes.
I'm very interested in what Lars is doing in the IRTF
(letting efforts go forward but waiting a year to charter,
to see if the group is successful in identifying a problem
and appears to be capable of addressing that problem) but
given that it depends on the ability to say "no" to work
already underway it seems unlikely to be successful in an
IETF where underperforming working group chairs aren't
fired and where it's nearly impossible to shut down even a
working group that's bound and determined to fail. So,
that doesn't seem to be an approach that's likely to translate
well to the broader IETF.
It also seems to me that the proliferation of the problem
statement/architecture/requirements/gap analysis pattern is
a problem. You wouldn't think that now that we're producing
tightly-focused, high-quality working group charters and
that in some cases it's taking several years to charter a
new working group we'd need problem statement documents,
but we're getting them anyway. It's not that we never need
a problem statement document, or an architecture, or a
separate requirements draft, or a gap analysis, but we
certainly don't need them nearly as often as we're getting
them, and I think they represent a significant part of the
problem with getting work done in a timely way. I think we'd
be well-served by a little more caution about committing
to those sorts of documents.
To be honest I think the core problem is that we've seen
a massive influx of participants whose job is to produce
standards - that's what they do. So they're being
incentivized to write lots and lots and lots and lots and
lots of internet drafts and to push very hard on chartering
new working groups. And as has been noted quite often
before, the increased IESG workload has tended to limit
the candidate pool for AD positions to those who can work
full-time on standards, which is a very, very bad thing,
both because it's going to tend to exclude very qualified
people whose main job is not standards but also because
it means that the people who are selected are going to tend
to be have a more positive attitude (or at least be less
unhappy with) the IETF's gradual transformation into a
more conventional standards body.
The IETF structure and processes are largely based on how
they were during a time when the focus was on producing useful
things. I do think we need to adapt to the new reality, although
I don't know what that means in practice. Personally, I'd like
to see working group efforts tied more closely to implementation
even though that won't solve the bigger problems around participant
incentives (although wouldn't it be *great* to have more implementers
involved?) and the proliferation of unhelpful and occasionally
windbaggy documents. But, as John Chambers likes to say, we need to
live in the world as it is, not as we'd like it to be.
Melinda