[rfc-i] RFC Editor Structure
Olaf at NLnetLabs.nl
Tue Jun 24 07:21:29 PDT 2008
[Dropping the independent list in order to keep the discussion
constrained to one place]
What follows are some clarifications and answers to issues brought up
during the discussion.
On Jun 4, 2008, at 3:59 PM, Frank Ellermann wrote:
> Olaf Kolkman wrote:
>> The proposed model is posted on the RFC interest list, see
>> and made available through
> Thanks for info. Some quick observations while looking at the
> picture of your model: You don't cover the rather convoluted
> interactions between IESG and "ISS", to fix that please sort
> the "stream" columns like that: IAB | IETF | community | IRTF.
Yes, the picture does take a high level view of the processes and
But to clarify:
The convoluted interactions are documented in RFC4846, with cross
reference to 3932, and thus well defined part of the existing review
process. Nothing here that is going to change that. It is the ISS that
in this model is responsible for following the process. Once the ISS
is done a document with appropriate boilerplates pops out and the RFC
production house takes over.
Frank also asked:
> What does "selected by the community and confirmed by the IAB"
> actually mean, is it the same idea as for area directors, i.e.
> NomCom representing a random set of volunteers from visitors of
> three out of five recent IETF meetings ?
That is one of the approaches, in the document we suggested an
approach similar to that of RFC4333. There may be other approaches to
selection of the ISS and the RFC Editor, and those selection processes
may be different. Ideas, suggestions, and opinions are most welcome
> Why should there be two persons - new "ISS" and new RFC-editor -
> instead of one ? In what way would a new "ISS" selected by the
> NomCom be really independent from IETF / IESG considerations,
> which is the whole point of this "independent" escape hatch as
> noted two years ago in the RFC 4844 discussions by John Klensin ?
The _intention_ is to recognize the independence of the stream and
construct an appointment process that matches that. This intention is
(attempted to be) captured in the profile of the ISS "Good standing in
the technical community in and beyond the IETF".
The reason why there are two _functions_ in the model is because they
are different in nature and responsibilities. The ISS being an
experienced technical person that understands the content and
organizes and manages the process for getting that content reviewed
and takes responsibility for approval. The RFC Editor being with a
focus on style, presentation, and series continuity. It seemed
natural to decouple to function description. But it is not said that
the same person, or organization cannot fill both of these functions.
In fact, observe that Brian Carpenter suggested coupling between the
Editor and the Production function.
> RFC number assignment should be the privilege of the RFC editor,
> not of some "outsourced" RFC production entity. This used to be
> great magic in the past, and it is a completely subjective magic.
In an earlier version the RFC assignment lived with the editor. It was
thought to be more pragmatic to move the magic to the production
house, this seemed to be more in line with the current practice, as
Bob Braden also argued in his June 4 reply.
And finally Frank remarked:
> Moving some "RFC publisher" functions to the IETF secretariat
> could make sense, if that is about maintaining a high traffic
> Web server with tricky forms. But the quality of some IETF Web
> server forms is not yet up to the standard of some RFC editor
> forms. Working Web forms can't be expensive, please don't try
> to fix it if it is not broken.
That is to some extend an implementation issue that should be
decoupled from the long term perspective that we are trying to make
with documenting this model.
Brian also had a number of queries:
> 1. What's the funding model for the "Independent Stream Supervisor"?
> That's not a job title that is very inspiring, and if it's a volunteer
> position, it would seem very unlikely to me that we'll find reliable
> and conscientious individuals willing to do it in the long term.
> I don't see it as comparable to an unpaid Editorship of an academic
> journal, for example, unless it is described in much more exciting
> language. But it also seems hard to justify as a funded service
> on its own. "Expenses to support the administrative operation of
> the Independent Stream Supervisor selected in this manner would
> be part of the IASA budget." Well, that is a very explicit extension
> of the scope of IASA beyond IETF activities. I'd want to see a
> consensus call on that.
Currently the funding is provided through the RFC-Editor contract that
is in place with ISI, so de-facto this is already covered by the IASA
budget. In fact all functions in the model are currently executed and
funded by IASA.
Calling out the ISS as a separate function allows us to think about
separate funding sources, although that also opens the question about
the selection process.
Brian also remarked:
> 2. Also re the Independent Stream: "...no changes to the Editorial
> Board are being proposed." Let's discuss that. I don't like the
> current degree of secrecy around the way the EB reviews independent
> submissions. Especially if we end up spending IASA money explicitly
> for this stream, I'd like to see all EB reviews being made public.
> People who want to publish via confidential peer review have lots
> of other places to try.
Although maybe not completely orthogonal I think it would be good to
have that discussion separate from this particular discussion. We
converged on the independent approval process about 1-2 years ago and
that cumulated in RFC 4846. What is important though is to assess if
this model would prevent any changes to the approval process. I do not
think it does.
Finally I observe that we have had no concrete feedback on the
selection process by which the ISS and the RFC Editor should be
selected. Would folk consent with a RFC 4333 type selection of those
-------------- next part --------------
An HTML attachment was scrubbed...
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 235 bytes
Desc: This is a digitally signed message part
Url : http://mailman.rfc-editor.org/pipermail/rfc-interest/attachments/20080624/2b4aba4d/PGP.bin
More information about the rfc-interest