One slogan that runs through my head in response to some of
the recent posts is "No rights without responsibilities; no responsibilities
without rights."
The IETF's purpose is to provide an engineering community that can
work on issues of security, stability, and infrastructure from
a whole-Internet perspective. From the point of view of responsibilities,
we are all taking on the responsibility of "doing the right thing for
the Internet"
rather than for our little corner or employer or patent. The exact nature
of what a participant does to react to that responsibility varies, but
engaging in cross-area review, committing to considering Internet-scale views
on the issues when writing or discussing a document, and trying to avoid goring
other folks' oxen when designing protocols are certainly part of it. You can
also volunteer for an organizational responsibility like NomCom.
Past a certain point, the IETF may ask you to take on additional
responsibilities:
run a working group so that it produces good engineering output with
rough consensus behind it; edit documents that are going to be standards;
serve on directorates that provide pools of expertise when they are needed.
Almost no rights accrue to the individuals who take on these responsibilities;
some ability to set an agenda and some ability to make limited choices
do go with the territory, but only subject to "agenda bashing" and later
review. Mostly, the individuals taking these on are expected to get them
done using the same rights as everyone has: the right to be heard and the
right to put their ideas to paper (okay, bits).
The NomCom may also ask you to serve on the IESG or IAB. In the
latter case, it's
asking you to take a long view of the Internet, as well as a broad one, and
to imagine how the infrastructure's needs will be met as timescales lengthen
and numbers increase. Again, the numbers of rights that go along with that
responsibility are few; a slightly different document track is about
the only one.
The IESG's job has been described (non-normatively) in 3710, and the number
of things it takes responsibility for is very large:
The IESG charters and terminates working groups, selects their
chairs, monitors their progress and coordinates efforts between them.
The IESG performs technical review and approval of working group
documents and candidates for the IETF standards track, and reviews
other candidates for publication in the RFC series. It also
administers IETF logistics, including operation of the Internet-Draft
document series and the IETF meeting event.
We should be able to strike that last sentence any day now, to the
sound of much rejoicing. But the rest of it boils down to: "make sure
the standards process works and that the standards produced really are
good for the Internet", which is a big, big set of responsibilities.
I sometimes call it a "rubber band" job, in that it will absorb almost
any amount of time or energy you put into it.
What I'm hearing argued here is that the IESG should be able to do the
document review aspect of its job using the same rights as everyone else:
the right to be heard and the right to put their ideas on paper.
It's a very nice
theory. If the IESG were given infinite time in which to do their jobs,
it might even work. But I suspect part of the reason we have experienced
such a slow down is exactly because this responsibility is handled
with a variant of that set of rights.
In order to write a review well and discuss a problem in a document, the
review must expend time. That time has to come from somewhere. Right now it
comes with ever increasing queue delay. We could choose to optimize instead
so that it came at the expense of something else (e.g. consistency).
But there
will be a cost with this match of responsibility and rights. The
cost to the IESG
member is also highly variable; some folks will and do force ADs to spend so
much time on single documents that the ADs give up, despite deep and fixable
problems, just so that the queue delay on other documents doesn't get worse.
The stress of balancing that has burned out many good folks and worsened
the user interface of almost everyone who has ever held the job.
Term limits will not solve this problem, because it will simply load
the same responsibilities on new folks; while you benefit from a small
increase in net energy (as the new folks jump in), it does not fix
the structural problem. Worse, term limits historically put power in
the hands of lobbyists and career assistants, which is contrary to
our general interest.
Functional differentiation can help, in that we could hand some
of the non-document responsibilities off further. BoF chartering is
one I've mentioned before; so is non-Standards track document review. But
I'm not sure that even that will make this work. Moving review earlier
helps; moving coordination to the working group chairs level helps.
But ultimately, I think they won't be enough, as the document volume
will simply increase until this problem comes back. I personally believe
that the only real solution here is to change the standards track, so
that the idea of iteration to achieve quality comes back. That has to be
tied to cross-area review at iteration to succeed, but it need not be
through a single body. Since it is the working groups who would produce those
iterative specifications, the bottle neck problem can be the energy
in the working
group and its cross-area reviewers, rather than the attention of N NomCom
selected folks. Though that seems like more of a match to where we should be,
I recognize that it increases the risks and costs to early adopters
and may slow
things at that end of the flow. But it seems like that approach is a
better match
in the long term.
Just my opinion,
regards,
Ted Hardie
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf