[rfc-i] RFC Editor structure
John C Klensin
john+rfc at jck.com
Tue Sep 23 10:52:17 PDT 2008
Responding to comments from Brian and Ray from last week....
I'm sorry to have been so slow about this, but substantially all
of my time in the last couple of weeks has been taken up by a
work emergency and I'm only now able to start digging out.
> My personal view at the moment is that the proposal put
> forward by Olaf as a consensus candidate is more complicated
> than necessary. I see nothing in the current model that will
> cause difficulty in the processing and publication of the
> variously approved streams defined in RFC 4844. There is a
> tactical argument for separating out the Publisher function so
> that it could, in theory, be jointly contracted with other IT
> services such as I-D publication. But that doesn't justify the
> separation of the nominal "RFC Editor" warm body as a separate
> contractual entity. I'd roll that into the Production contract.
We have fundamentally different perspectives on several aspects
of this, including on the rather basic subject of whether RFC
4844 and RFC 4846 have worked well and, more generally, whether
the community-based mechanisms for selecting people for tasks
that require very specific skills have worked well. I infer
from your note and other recent comments that you believe that
they have. I believe that they have not, something I'll explain
in more detail below. To the extent to which one believes that
the model described in those documents has not worked as
expected, one can say "whether they worked as expected or not,
the community agreed to them a year ago and we must proceed down
the path they appear to set without looking sideways". The
other possibility is to consider whether 4844 and/or 4846 should
be reconsidered and possibly modified or improved as part of any
next steps in RFC Editor [re]organization.
Because I believe that the first, "proceed down the path we set
out on, no matter what", option involves the possibility that
the next step may take us over a cliff, I believe that
consideration of this organizational model also requires review
of 4844 and 4846. If we conclude that they still work for us,
that is fine. If not, we should be looking at the RFC Editor
structure as an implementation case, working it out correctly,
and then modifying the existing documents so that they match.
That is, of course, exactly what we do with technical
This is one of the fundamental sources of our disagreement. You
see completely separating these functions as an important
objective. I see it is nearly impossible in practice without
loss of important functionality and perspective. I also see the
entire idea of designating two individuals and giving them the
sole responsibility, while separating them from each other and
the people who do the work as, at bst, fundamentally naive.
On Tue, 16 Sep 2008 09:34:53 -0400, Ray Pelletier
<rpelletier at isoc.org> wrote...
> On Sep 15, 2008, at 6:00 PM, Brian E Carpenter wrote:
>> On 2008-09-12 04:08, Bob Braden wrote:
>>> SM wrote: *
>>> *> As in any structure, there is a need for accountability.
>>> How is the
>>> *> Independent Streams Editor accountable to the community?
>>> To whom is
>>> *> the RFC Editor accountable?
>>> The accountability and transparency of the Independent
>>> Streams Editor function are spelled out in some detail in
>>> RFC 4846.
> Question is how to pick the RFC Editor to sustain the RFC
> Series. Shall the IAOC do it by RFP and see what XYZ, ABC
> and 123 Corp proffer as the Editor, or should there be a
> community based process by which one is selected?
> I don't know who the companies will propose every 2 - 3 years,
> but I have a high degree of confidence in a community based
> process to select from a significant number of highly
> qualified individuals, and do so time after time.
> In community hat
This is part of our second major disagreement. Dave Crocker
often points out (generalizing a bit and paraphrasing
significantly) that the community expects people who are
deliberately selected without any consideration of how much
experience they have with particular roles to then select others
to perform those roles. They don't have the background and
perspective needed to evaluate the needed skills and attitudes
and (at least he and I believe) they often do fairly poorly as a
result. His usual example involves randomly-selected Nomcom
members picking the IESG and then expecting the IESG to show
strong and effective management skills. Probably we get lucky
and end up with people who can manage in the IETF environment
much more often than, given the process model, we deserve.
However, we have an even worse and more risky example if we
expect the IAB and/or IAOC, neither of whose membership are
selected for a deep understanding of editorial matters or
understanding of the special role of the RFC Editor (even if the
Nomcom were required to have enough knowledge of those editorial
roles to make it plausible that they could select an IAB or IAOC
that did have the needed understanding and experience) to be
able to competently pick single individuals to perform the roles
called for in the draft.
We also need to be careful what we wish for when we demand
"openness", "accountability", and "transparency". While all of
them are good ideas in principle, we also need to optimize for
expertise, we also need to optimize, IMO, for expertise and
especially careful review and balanced discussion by those who
actually have significant competence in the relevant issues. I
don't see that as being inconsistent with openness, but I am
concerned about the flavors of openness that assume that anyone
with an opinion ought to be a candidate for any position in
which they might express interest and that bodies who have
opinions are appropriate to make selections to bodies that
require expertise. If we need proof of where an excess of
"everyone who can mouth off gets an equal vote" leads, all we
need to do is look at the processes and careful decision-making
of ICANN (another component that used to be closely connected to
the RFC Editor role), activities that are of course based on
deep understanding of the Internet.
More information about the rfc-interest