[rfc-i] RFC Editor structure

John C Klensin john+rfc at jck.com
Mon Sep 8 13:56:59 PDT 2008


My apologies for this note being so late and for its length.  As
I told you when we talked in Seoul, I've been having trouble
formulating my real problem with this proposal and that
difficulty has continued through to the present.

I think I've finally figured out how to do so, so, for whatever
it may be worth at this late date...

My suspicion is that you and the IAB don't even want to hear
this, but maybe it needs to be said.  And, unfortunately,
everything interacts with everything else in this area, so the
decisions it implies should not be those that the IAB, or even
the IETF community in isolation from broader Internet technical
community, can or should make without a wider discussion.

Almost all of the comments on the list so far have been along
lines that I would summarize as "if you are going to do this,
here are the issues and risks and the ways in which it should be
fine-tuned to possibly improve on some of them".  That is
reasonable given the premise.  However, I think it is the
premise itself --that this sort of reorganization is
appropriate-- that needs to be examined carefully and in context.

I believe that our basic problem is that, in the last decade, we
haven't figured out as a community what an RFC Editor function
means, and how to perform it, without Jon Postel and his
extremely broad perspective, active participation in the IAB and
other processes, and trust level in the community.   In the case
of the IANA, we have responded to essentially the same problem
by making the role largely clerical, rather than
decision-making, and shifting the decision process to the IESG
and collections of "experts".  That has worked out well in some
ways but badly in others.  I suggest that, while the IAB
proposal essentially tries to turn the RFC Editor function into
a de-skilled administrative one in much the same way, doing so
has far worse consequences. 

I don't believe that the current RFC Editor staff has completely
figured out how to proceed without Jon either; that may be part
of the problem.   Certainly, few of the people who are now on
the IAB had the opportunity to either work with Jon or see how
the system worked, especially in the "pre-Kobe" period (prior to
the 1972-1974 reorganization process).  The question of how to
reorganize ourselves to function in new ways while preserving
important functionality, rather than trying to simulate Jon with
some of the pieces missing, have not really ever been asked (at
least as far as I know).  The system was not perfect even with
Jon, but I fear that, having never asked some of the important
questions in a serious way, we are in danger of --to use a
saying common in the US whose origins I don't know-- discarding
the baby with the bath water... and maybe discarding the bathtub
as well.

If we can look back several years, the RFC Editor had the
unquestioned right (and responsibility) to push back on authors
and the IAB (and then IESG) about fundamental issues of
technical and editorial quality.   That capability was not just
an editorial matter; it was a fundamental element in the various
balances and checks that made up the IETF (and pre-IETF)
specification review, approval, and standardization processes.
Jon also had the option of making corrections to presentation of
specifications, an option that occasionally got us into trouble
when something fell outside his very broad range of expertise.
AUTH48 was instituted to at least give authors a final check on
such changes.  As a process change, AUTH48 has been, IMO, a
complete success (despite some recent moves in the direction of
using it as a general mechanism for last-minute changes, the
most recent discussed on the IETF list in the last month).

I am less sure about the other changes that have been made in
the last decade or so.  These changes have included a "the IESG
gets its way on any text that it approves" attitude, the
perceived need of the IESG to finely-check and fine-tune text,
and even to involve itself in RFC formatting conventions, rather
than trusting those activities to the RFC Editor (I don't know
whether that is a cause or an effect), increased IESG
involvement and interventions in the independent submission
process (including RFC 3932, which, I'm pleased to see, the IESG
is reconsidering), and a need to try to create some firewalls
around RFC Editor authority and independence in a few areas
(e.g., RFC 4846). 

In that regard, RFC 4844 was an improvement in some ways over
the previous ambiguities but, judging from the current document,
it started the baby headed toward the drain.

I think it is time to remember and consider the hypothesis that
the IETF and the Internet community would be better served by a
strong RFC Editor model and process, one that can take an active
role promoting the speed and quality of our work.  

If one believes that, then breaking up the function in a way
that guarantees that no one entity can exert real oversight of
the process on a document-by-document basis (or even strategic
oversight unless the IAB is going to make a meaningful
commitment to doing that itself) is not the right way forward.
No amount of changing titles and dotted lines or fine-tuning
allocation of responsibilities is going to change that.

Conversely, if one does not believe that --if one, instead,
believes that we simply want a copy-level editorial/production
and a new recommendation/ oversight person with no real
authority except as a consequence of the contractual
arrangements in a given year-- then I think we need to see an
"environmental impact" analysis, including an analysis of how we
are going to staff the IESG out to assume even more of the
document quality control role.

We are already seeing the consequences of the shifts that the
new proposal seems to confirm and advance.  Not that long ago,
someone who noticed that a document had replaced another one,
but that was improperly recorded in the index and databases,
would have just dropped the RFC Editor a note explaining that.
The claim would have been checked and the database entry fixed.
Now we go through a formal errata procedure, IESG review, then
an IETF Last Call, and presumed IESG consensus determination.
Maybe that is how the community wants it --and how the community
wants to be spending its time and having the IESG prioritize
things-- but I somehow rather doubt it.

If one wanted a strong RFC Editor who could (again) be an
important part of the process --the standards process as well as
the independent submission one-- and who could unload work from
the IESG rather than increasing the IESG's workload, I think
there are ways to do that which are less dependent on particular
individuals or organizations than what we have attempted in the
recent past.   I'm not going to include them in this note in
order to keep it from getting much longer, but am happy to share
one such model with you if you are interested... with the caveat
that it requires the IAB, and the community more broadly, to
face some hard realities.   But if, as I believe, the IAB and
IAOC have determined that the only reasonable model is to break
the RFC Editor function into small enough pieces that it can
never again assume a substantive role in the process (whether
that is an explicit goal or not), then there is little point in
trying to discuss fundamentally different models further -- I
certainly don't have the time and assume that you don't either.

Speaking for myself only,


More information about the rfc-interest mailing list