[rfc-i] Some comments draft-kowack-rfc-editor-model-v2-00 and a suggestion
ajs at shinkuro.com
Wed Nov 10 18:34:17 PST 2010
This note is intended to do two things. First, it is a more complete
statement of some remarks I made at the mic the other day. Second, it
makes a suggestion about trying to resolve an apparent fundamental
issue in the current discussion. I put headers on the two parts so
that if you don't care what I think about this draft but want the
suggestion, you can skip ahead.
1. Comments about the draft
I think almost all of the historical claims in this draft could be
removed, and the draft would be better for it. I have to agree with
some others that expansive claims such as
The RFC Series is the Internet technical community's official medium,
through which it communicates with itself and the rest of the world.
6,000 RFCs since 1969 comprise one of the most extensive and
influential technical series in history. Without openly available
RFCs, the Internet could not have been built, could not operate, and
could not continue its remarkable advance.
are at least distracting and at worst nonsense. (Any time I see a
counterfactual impossibility claim, for instance, I immediately want
to make up the world in which it is false.) Cut it. If you think you
need background, it is enough to provide a list of previous RFCs on
the topic, that the hiring process that came out of them didn't work
as planned, and that the current text provides a proposal for how to
alter RFC 5620 so that the next attempt to hire someone will succeed.
As nearly as I can tell, that's all the background needed to
understand why this draft exists.
b. Two models
After the plenary, it seemed to me that it could be extremely valuable
to outline the two broad models for the RSE in the end. One is what
we might call the narrow construction. In this model, the RSE is the
senior line editor, with editorial policy and so on completely under
the control of some other body or bodies. Note that this is very much
in line with the notion in RFCs 4844 and 5620 that there is an RFC
Editor _function_, which might happen to be performed by several
different people. The second is what we might call the broad
construction. This is effectively the model in the draft now: the RSE
has a senior management function, and broad chunks of editorial policy
fall to it. This amounts to a senior management role for the RSE.
In contrast to the history outline, the actual experiences of the TRSE
over the course of his tenure seem to me to be the sort of thing that
nobody else could provide. Those experiences would be valuable
evidence with respect to the proposals. For instance, the draft
recommends that the broad construction of the RSE is the right one,
and makes recommendations about how to alter the RSE job so that it is
a more effective instantiation of that broad construction. But there
is not enough evidence in the draft for a reader to evaluate whether
the broad construction is the right one. Neither is there enough
evidence in the draft for a reader to evaluate whether the specific
recommendations would actually achieve the desired goal. So more
reporting of those experiences, and analysis of them, would be a
valuable addition to the document.
d. Something valuable in the draft
The draft as it stands makes a particular recommendation for how to
restructure the RSE job along particular lines. I think that, if one
accepts the broad construction of the RSE, the suggestions are pretty
good. As others have noted, RFC 5620 sets up the RSE in such a way
that the job can't really be done by anyone who wants it, because it
has responsibility and no authority. Nobody we would want to do the
job will accept it, and the responsibility without authority is
presumably part of the reason. The very fact of having a TRSE is
evidence of this, and I think that if we accept the broad
construction, we should proceed with something like the
recommendations in this draft.
e. Overall structure that would be useful to me
If the above is right, then the draft needs to be about two things:
why the broad construction is the right one for the RSE, and what the
specific job description should be in that case. I think the draft as
it stands has the latter (in section 4), and not really the former.
As it stands, the draft also contains some other material irrelevant
to these two categories. I suggest that all of that should be
There have been, in the discussion on the list and at the plenary,
several strong claims about whether the broad construction or the
narrow construction is the right way to think about the RSE.
I think the changes I suggested in part 1 of this message would make
for a complete proposal for the broad construction.
Often, in the IETF, we like to have a sort of scratch alternative
proposal in order to evaluate whether the direction we're going is the
right one. I therefore suggest that those who are sure the narrow
construction is the right one ought to provide the arguments why it
is, and also provide a sort of point-form job description to compare
with the one in the draft. The reason for this is that there seems to
be a longish list in the draft of functions for the RSE, and a
competing proposal would need to say whether the RSE would do those
things, whether someone else would do those things, or whether those
things just aren't needed or actually ought not to be done. I simply
can't tell, from the discussion so far, how the broad and narrow
constructions stack up against one another.
ajs at shinkuro.com
More information about the rfc-interest