[rfc-i] RFC Editor structure
housley at vigilsec.com
Mon Sep 8 16:05:49 PDT 2008
I was not along for the whole journey that provides the context for
you perspective. The only think I can do is respond from my
perspective. It is quite clear to me that they are very different on
the way we want to RFC Editor to function in a few years.
I think that RFC 4844 plot the general direction. With four streams
that make up the RFC series, it makes a lot of sense to look at
making the management of each of these stream as independent as
reasonable. It seems pretty clear to me that most people support
this aspect of the proposed model.
There are many largely mechanical aspects to publication. I think we
want to clear the way for a highly respected member of the community
to oversee the continuity and quality of the series without having to
be burdened with those mechanical aspects of publication.
To me, these are the major things addressed by the proposed model.
At 04:56 PM 9/8/2008, John C Klensin wrote:
>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
>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,
>rfc-interest mailing list
>rfc-interest at rfc-editor.org
More information about the rfc-interest