[rfc-i] [IAB] Intended Publication: RFC Editor Model (draft-iab-rfc-editor-model-02.txt)
olaf at NLnetLabs.nl
Sun Nov 16 09:58:18 PST 2008
Jim and Joel,
I noticed the points you brought up were similar albeit with a some
what different perspective. So I tried to cut and paste the fragments
of both your replies together and reply to the points.
Before attending to the meat of the matter I like to point out that
the document is certainly not an endpoint but hopefully a clear enough
starting point. The intention is to draw the contours sharp enough to
have everybody understand what we are working from while realizing
that some of the details will need to be worked out during the
Your comments do, in my personal opinion, not identify new issues.
Allow me to try to categorize your remarks and respond.
== Technical competence is assumed to be where?
> To the best of my ability to tell, from reading this document, this
> structure assumes that the production of RFCs from IDs produced by
> IETF, IAB, abd IRTF sources is a relatively mechanistic task with
> relatively little technical content. This does not match at all my
> understanding of the realities of the handling of such documents.
Yes and Yes.
The model assumes a minimum level of understanding of the technical
content while editing by the Production Center. On the other hand your
understanding is shared: Editing of RFCs takes some competence to
assess where an edit may have a technical meaning. If those
assessments are done wrong there will be a burden on the various
parties mentioned in the following Production center responsibility:
Establishing publication readiness of each document
through communication with the authors, document shepherds,
IANA and/or stream dependent contacts, and if needed with
the RFC Series Editor.
Note that "minimal level understanding of technical content" is not
the same as "zero level". During the selection of the vendor an
assessment will need to be made on that level of understanding. I
would actually argue that this assessment is needed regardless what
the form and shape of the model is. There is always a danger that a
vendor will not be able to edit the documents with the expected
technical competence and put a burden on the folk that provide the
input. In that context you may recall that the RFC editor function was
up for bids two years ago and as part of the process an assessment was
done on the quality of editing by the various bidders.
The subcommittee that assists with the selection is likely to do such
tests going forward.
== Implementation of RFC Series Editor oversight
> 1. One of the tasks of the RFC Series Editor is to oversee the
> of the RFCs with both prior RFCs and with the style guide. As things
> currently stand, this person is not a gateway on path from the
> center to the publisher. Is it intended that the RFC Series Editor
> is going
> to be a gateway on each document to do a judgment, or is it intended
> the RFC Series Editor will flag lapses in consistency to the IAOC
> publication as they are noted either by the editor or the general
> There is one aspect that must be in the document somewhere, but I
> can not find it. There does not appear to be any actual oversight
> of the RFC Production center by any individual who is both editorial
> and technically competent to ensure that a good job is being done.
> This needs to occur on an ongoing basis, and there needs to be some
> authority behind it. Waiting until the contract is up for rebid
> would be a disaster.
The interface between the RFC Series editor and the RFC production
house is clearly a point of worry, it has been brought up before, and
the IAB is aware of this.
However, while the functions in the model are separable, they do not
have to be separated during implementation. Separability is decided
based on an RFI that will be issued in December. If there are credible
responses to the RFI that suggest benefits of the coupling (remaining)
strong it may well be that the IAOC will look for one vendor for both
functions. However the IAOC may also see responses that suggests
benefits from decoupling. Note that during the selection processes the
selection will not be based on purely financial benefits (or harm):
benefits of quality, benefits of continuity, etc all go into the mix.
Practically, if the two functions are executed by different persons/
institutions, I think Ray's suggestion, that initially there would be
a high "this-passes-the-series-editors-desk" level while later the
mode would be 'trust-but-verify', is a likely implementation.
Implicitly I think there is a question whether the RFC Series editor
maintains the technical quality of the series.
The RFC Series Editor may engage in a dialogue if she thinks that the
technical quality of a particular stream is technically sub-standard
('Identifying appropriate steps for RFC Series continuity'). The stick
that the model provides the RFC Series editor to deal with such issues
is: "Liaising with the IAB". I guess there is some clarification text
== The Editorial role of the Independent Stream Editor
> The similar assumption about the amount of work associated with the
> Independent Submissions editor depends very heavily on both what the
> real technical work of such an editor is, and on whether this is
> supposed to be an active and vibrant part of the work, or merely a
> side-note. Particularly if the RFC Series Editor is not providing
> strong technical review (and assuming they are two separate
> individuals) then the Independent sumbissions editor must be able to
> provide strong technical review in an onging fashion as documents
> work through the process, since there is no other part of the system
> to provide such.
Reading this I realize that we could make one of the responsibilities
of the Independent Submissions Editor more explicit: "Maintain
technical quality of the Independent stream". So yes, the technical
work of that job is the core.
I think it is unfair to assume that most of the burden for the review
after the edits (AUTH48) is with the Indep. Sub. Ed. It is with the
authors (with a little oversight by the Editor). Just like in the
> 2. For the independent submission editor, I note that both
> editorial skills
> and competency in English are not requisite qualifications. Is this
> 3. I would like the document to clarify the following question. Is
> it the
> job of a series editor to ensure that a document that is passed to the
> production house meet some minimal criteria for readability?
> As a member of the current RFC Editorial board, I have review a
> number of
> submissions where the clarity of the document was lacking. I would
> be loath
> to say that the Independent Submissions Editor should have passed
> documents on to the production house to clean up the language
> problems and
> then take them back to determine if they should really be
> published. As I
> understand things the submissions gatekeepers should only send on
> that are really clear. This however is not stated as a requirement or
> responsibility for the independent submissions editor.
IMHO the responsibility for presenting a readable document lays with
the stream approver. This does not mean that the output needs to be of
the quality of a native English novelists but some base quality may be
expected. One could argue that processing an I-D to be readable is
part of the "Independent Submissions approval and processing". That is
not to say that the Indep. Stream Approver should do that editing
herself. I think it would be perfectly valid to ask an author to
improve the readability. Currently, within the IETF stream we have had
editors improving the readability before Alice, Sandy and Bob got to
do the final edits.
Obviously there is an opportunity for conflict and tussle. If the
document is 'unreadable' and the Production function needs to start
interpreting intended meaning than technical modifications may sneak
in and those will need to be sorted out in AUTH 48.
While the above issues are not mentioned in the model (should they?)
they should definitely go into the statements of work.
== Funding of the Independent Submission editor.
> 4. The statement on funding for the Independent Submissions Editor
> me. I believe that this job is currently funded as part of the
> with ISI. (Bob, please correct me if I am wrong.) This document is
> the statement at that it will no longer be funded through IASA and,
> implicitly, says that we don't believe that the job is of sufficient
> importance for the IAB to make sure that the job is funded at all.
> If we
> believe that this job is basically a sinecure, then this is not a
> If we believe that this job actually would require a substantial
> amount of
> work, then this is an issue. I would not be surprised to find out
> that we
> are paying for this work either via the use of the production house
> dealing with documents that are not actually ready for production,
> the RFC
> Series editor's or the IESG's time for dealing with documents that
> not be published or the communities time for dealing with documents
> should never have been published.
That the IASA is not funding the effort does not mean that it is not
of sufficient importance for the IAB to make sure the job is funded at
all. It is not the case that the IAB has deep pockets, but we can
certainly work towards assisting in finding funds for e.g. a stipend.
The problem is that when the IETF is paying the function its
independence from the IETF is obviously at stake.
> The document explicitly states that contract durations, etc. are out
> of scope for this document. Which seems quite reasonable. However,
> if one notes that most of these jobs are quite complex jobs which
> take time to learn to do well (6 months with good training and
> oversight to become a good part of the Production process is what I
> have been told), this has implications for duration of contract and
> contract oversight needs. We have to plan on not shifting too
> often, or the task will simply not get done.
In general the IAOC have been contracting for 2 years with possible
extension to a 3rd year. After those 3 years there is a commitment for
a rebid. As said, financial benefits are not the only selection
criteria during a bid.
-------------- 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/20081116/82f1e7f0/PGP.bin
More information about the rfc-interest