[rfc-i] Some questions about the RFC Editor restructuring plan
olaf at NLnetLabs.nl
Thu Aug 7 03:20:32 PDT 2008
First a few answers to your questions, then a few words on what I
picked up in the hallways.
On Jul 31, 2008, at 4:44 PM, Bob Braden wrote:
> * Please give a concise summary of how this restructuring model
> from the current model. Note that the proposed model is so general
> that it includes as
> one case the current ISOC contract with ISI for RFC Editor services.
This is the _first_ model of the RFC editor function. Under the
current contract ISI performs almost all of the functions indicated in
the diagram. The notable exception is that some early copy editing is
done under direct contract under contract with ISOC, managed by the
> * What will be the lengths of tenure of the independent submissions
> supervisor and of the RFC Editor? Also, what length of time will
> the contract with
> the Production House cover? This is relevant to stability,
> continuity, and staff
> morale under the restructured organization.
Currently the contracts that the IETF maintains with its vendors (ISI
and AMS) are for 2 years with a possible extension of 1 year.
My personal view on this is that the choice for contract terms is an
IAOC matter. The trade-offs include stability, continuity and morale
during the time that contracts are up for re-bid, the costs for the
IETF (not only monetary) to have to change vendor, and allowing for a
> * Clearly indicate whether the positions described will be funded by
> ISOC, or will get only travel and similar "administrative" expenses
Actually, this is one of the open questions in the model. There are
two alternatives for the selection of the persons/institutions filling
the role of Independent Stream Approver and the RFC Editor functions:
Through a nomcom like process or trhough RFP-ing. Also the funding of
those roles are subject to guidance from the community. Clearly, the
selection and payment are tightly bound.
> * The (new) RFC Editor position is implied to be a manager and have
> responsibilities, yet this position has no authority.
> without authority is a well-known "bog".
I realize that there is a risk that my answer will start a debate
Within the IETF community there are a number of positions (ADs, WG-
chairs, IAB membership, Nomcom membership) where by taking
responsibility folk are being granted authority. And although folk in
those positions have a small toolkit if it comes to the available
carrots and sticks this all seems to work to some extend.
It is up to the parties involved in the model, including the IAB and
IAOC, to grant the authority to the RFC editor. I hear you pointing
out that there are risks that that may fail.
Some feedback I got in the hallway. Paraphrasing various folk, without
giving attribution. Mainly because I forgot who said what and I may
actually misquote them.
1. The Independent Stream Approver job title
The Independent Stream Approver is an unattractive name for the
function. It sounds like an accountant/auditing function not as the
"Chief Editor" of a important and relevant publication stream.
Personally I think that this is a fair point. Suggestions for another
title that is more attractive are welcome.
2. Coupling of production house and the RFC Editor role.
A few folks mentioned that it is probably not a good idea to separate
the RFC Editor role from the Production house role.
Here we have to make a distinction between the model and its
implementation. The model currently separates the roles while it
allows for an implementation that awards the responsibilities to
separate persons/institutions. The model also allows an implementation
that bundles those roles (and the others) and award them in a single
contract. The last point that Bob made above argues to bundle the roles.
However, the question is wether on the long term there are benefits
for maintaining a distinction between the roles. It occurs that
maintaining the rfc-editor and production house as seperate roles from
a model that describes the production and its processes allows for
some flexibility in the future.
I hope that with this mail more comments and feedback are triggered.
--Olaf (wearing no particular hats)
 For the benefit of folk not familiar with this: an example of such
contract can be found at http://iaoc.ietf.org/documents/CopyEdit_Contract.pdf
-------------- 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/20080807/01bea1b6/PGP.bin
More information about the rfc-interest