Hi Melinda,
On Sat, Nov 7, 2015 at 4:44 PM, Melinda Shore
<melinda(_dot_)shore(_at_)gmail(_dot_)com>
wrote:
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 think that the chartering effort is when there's a great opportunity
to affect how the WG focuses and how productive it is. I know that
for both BIER and DETNET, spending time on the chartering let us
clarify that we wanted WGs that were going to produce implementable
work within two years. It's a chance to explicitly state that work on
use-cases or requirements can be captured well in ephemeral documents
that will not be permanently published as RFCs.
Similarly, rechartering is a chance to clearly make decisions about the
direction that work should go and clearly state decisions about disputes
that may have paralyzed the WG.
While I agree that it may take time to have a clear and better outcome,
I have been startled and pleased by how efficacious rechartering has been.
NVO3 was able to focus on its direction; granted, now we have too many
encapsulations but the paralyzing discussions about control-plane
(distributed
vs. orchestrated and so on) went away. RTGWG is successfully serving
to incubate new ideas and has taken up a number of YANG drafts that
had no other appropriate place to be in Routing.
I do feel like the chartering time is one where there is significant
leverage
to be gained by focused AD effort. I am curious to hear where you think
an AD should be better spending her or his time.
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.
Well, think about how focused many of the drafts in preparation for
a BOF are. With the IRTF, there isn't really an expectation of getting
something useful and implementable within a moderate time-frame.
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.
Absolutely! I completely agree and am happy that many of the
ADs and IESG are pushing back against these during chartering
or rechartering and when drafts come to the IESG. Unfortunately,
by the time a draft gets to the IESG, there's a lot of pressure from
WG consensus, the time spent, and the "but does it do any harm"
front.
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.
I would add that as people get more involved with the IETF, there
may be less time to spend on other things. I agree with the problems
though different environments encourage that less than others.
It's one thing to see the problem - but what would be useful is ideas
on how to resist and improve?
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.
I have sometimes regretted that not all WGs are like IDR, which requires
at least two implementations before progressing a PS draft.
It would be great to have more implementers involved. That means
being more dependent on the mailing lists and less on in-person meetings
and making it clearer how to participate with a low time-commitment and
making it easier to be connected into the community for trading of ideas
and getting support. We might also need to do outreach so that the
implementers know they are welcome and the IETF isn't yet practiced or
good at that.
Regards,
Alia
Melinda