[rfc-i] Conclusions about the RFC Editor/ RSE function

John Klensin john+rfc at jck.com
Fri Jan 21 12:12:56 PST 2011

I've reached some very general observations and conclusions
from following these discussions in recent weeks.  They
motivate a lot of my view on the general subject.  Much of this
overlaps comments made by others; for those topics, this is
just my attempt as a synthesis.  If it is useful, treat the
points below as me trying to make my conclusions and
assumptions explicit.  I am obviously speaking for no one other
than myself.

(i) The RFC Editor function needs to evolve and keep evolving.
It has probably evolved too little over the last decade (for
the record, I attribute that much more to the style we have
used in managing the function from the "outside" than to, e.g.,
resistance on the part of RFC Editor management).  That view
obviously puts me at some disagreement with those who believe
that things are working so well that no strategic changes are
needed now or likely to be needed in the near future.  In my
experience, including watching the RFC Editor staff over the
years, expecting people who are down in the trenches, under
pressure to get as many pages of documents per month out as
possible, to be able to think through and make strategic
decisions about evolution and priorities is simply unrealistic
even if there were no other considerations.

A critical part of that evolution has more to do with inputs
than with outputs.  As the IETF (and even the Independent
Submission function) becomes more international, we can expect
--and had best accept-- the typical English technical writing
quality of the documents that are input to the stream approval
functions to decrease.  We will need to find some balance
between expecting the RFC Editor function to fix those
documents up (with due attention to the responsibility of the
authors and streams for actual technical content) or we will
have to accept increased responsibilities, time commitment, and
skill set expectations for the stream approval bodies.  My
guess is that we will have to regularly adjust that balance
over time.  It does not appear to me that large-scale increases
in the requirements on the stream approvers are feasible --
everyone is already flat-out, the community hasn't wanted to
make the relevant bodies larger (for good reason, IMO), and the
Nomcom does not seem to be finding really large surpluses of
volunteers anyway.

(ii) There are ways I'd like to see oversight and strategy for
the RFC Editor managed that do not align with the way the
community works in practice.  As an important example, I'd like
to believe that the IAB could assume a strategic and informed
leadership role when needed.  In practice, not only are IAB
members not selected for the skills and experience needed to do
strategic evaluations in this area but every IAB I have served
on (or observed from the IESG) has had a significant number of
members who would prefer to be doing "something else" (usually
called "architecture", but definitions of that are not as
consistent as one might assume) rather than dealing with RFC
Editor issues.  Often there is a significant subset of that
number --often even a majority-- who would strongly prefer to
spend zero time on RFC Editor issues: some just tune out,
others look for ways to be sure that the IAB has little or no
responsibility on which it needs to spend time, etc.  That is
not a criticism of the people involved.  Rather it is an
observation that expecting in-depth involvement from a majority
of the Nomcom-appointed members of the IAB is not realistic.
Worse, because neither the Nomcom nor the IAB members it
selects normally have significant background in either
publications or management, the expectation is unreasonable
that either will be able to select people skilled in those
areas (at least without very significant investments) because
they simply do not have experience with the relevant roles.

As others have pointed out, if we want knowledgeable people in
RFC Editor oversight, strategy, and decision-making roles, we
better not assume that having people who are well-intentioned
and want to help is sufficient, even if we get such people.
Given the history of controversy about particular possible
changes in publication formats, we even run the risk of getting
volunteers who are basically trying to get resolution to a
single issue on which they have very strong opinions but might
not be well-informed.

(iii) In general, the volunteer leadership of the various
streams are very busy getting their primary jobs done.
Probably that is a good thing.  But it means that their input
to the RFC Editor process, with rare and fortunate exceptions,
is likely to be --and should be-- "make the status quo work
better and faster" or "status quo is fine, let's be sure we
don't make changes that reduce service" and occasionally
"change things to fix this narrowly-defined problem".  

(iv) The historical track record of management by committee for
_any_ function is not good.  Committees can be good at
oversight, at review, and at verification that some particular
strategy is likely to work adequately.  Sometimes they can even
be good at refining a proposed policy model.  But, as a policy
development or direct management body, the history has been one
of almost nothing but failure.  A committee approach is likely
to be particularly ill-advised in our community where finding a
committee that is highly-skilled in the documentary, editorial,
and publications subject matter of RFC Editor work is likely to
be very difficult.  We seem to forget it regularly when we
venture outside our particular network technology specialties,
but strong opinions are not a good substitute for in-depth

I think that the context and value of many of the discussions
on the rfc-interest list would be much more clear if we had
developed a culture in which people felt obligated to say "I am
not a publications expert, but..." or "I am not a management or
organizational behavior expert, but..." before some of the
statements they make just as "I am not a lawyer, but..." has
become common enough to have acquired an abbreviation that
broadly recognized in the community.

(v) One of the only things that is worse than management by one
committee is management by multiple committees with boundaries
of responsibility and authority that are ill-defined in
practice.  I see no problem with separating the
responsibilities and authority of a finance/contractual group
(e.g., the IAOC) from the responsibilities and authority of a
strategy and line management/ technical oversight function,
even if success depends on their being able to work
cooperatively (fwiw, lots of organizations do that and do that
in a variety of ways).  Indeed, a certain amount of tension
between those two functional areas might actually be helpful
and constructive.  But multiple committees in the latter area,
especially committees that consist largely of volunteers who,
on average, are well-meaning but have little specific
background in the relevant areas, is nothing but an invitation
for battles about control, _even_ if we have a pile of
documents that try to specify where the control lies.

(vi) The community has a habit of overspecifying things and
especially overspecifying the things it thinks it understands
while leaving things that are actually more important
underspecified or badly specified.  That combination inevitably
gets us into trouble and leads to the need for either frequent
updates to base documents (the IPR work may be an example of
this) or simply ignoring the published rules (some of the
provisions of RFC 2026 and perhaps some of the ways that the
IAOC and Trust have found it necessary to operate may be
examples of that).  In this context, that is less a complaint
than an observation about a fact we should accept and face.
Whatever emerges as a revision of update to 5260 should, to the
extent possible, avoid specifying details unless they are
really important and really well-understood.  It would be much
better, for example, to give the IAB the ability to do a lot of
tuning, presumably in consultation with whomever needs to be


More information about the rfc-interest mailing list