[rfc-i] [IAB] Intended Publication: RFC Editor Model (draft-iab-rfc-editor-model-02.txt)
ietf at augustcellars.com
Sun Nov 16 14:18:36 PST 2008
While I am happy to hear that this is not an endpoint, statements in the
document like "The IAB approved the RFC Editor model on October 1, 2008" do
not lead a casual reader to assume that this document is still a work in
progress, but rather is a final document.
Other comments below
> -----Original Message-----
> From: Olaf Kolkman [mailto:olaf at NLnetLabs.nl]
> Sent: Sunday, November 16, 2008 10:58 AM
> To: Jim Schaad; Joel M. Halpern
> Cc: RFC Interest; IAB IAB
> Subject: Re: [IAB] Intended Publication: RFC Editor Model (draft-iab-
> 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?
> Joel wrote:
> > 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
> Jim wrote:
> > 1. One of the tasks of the RFC Series Editor is to oversee the
> > consistency of the RFCs with both prior RFCs and with the style
> > As things currently stand, this person is not a gateway on path from
> > the production 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 that the RFC Series Editor will flag
> > lapses in consistency to the IAOC after publication as they are noted
> > either by the editor or the general public?
> Joel argued:
> > 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
> > 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
> needed here.
Personally I found the response from Ray as less than useful. Like John, I
was not sure what he was proposing.
IMO, the document should be modified so that the RFC Series Editor has the
explicit duty/opportunity to approve every document prior to publication.
It would be up to the RFC Series Editor to decide if this was a full review
or a pro-forma review. I would not understand how to implement the
suggestion - well maybe review some of them sometimes from the view of
either the production house or the series editor.
As you have so often pointed out, the model and the instantiation are
suppose to be separate. We are suppose to be creating a workable model at
this point and ignoring what the actual instantiation will be.
> == The Editorial role of the Independent Stream Editor
> Joel wrote:
> > 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
> > 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 other
> > 2. For the independent submission editor, I note that both editorial
> > skills and competency in English are not requisite qualifications.
> > this intentional?
> > 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
> > to the production house meet some minimal criteria for readability?
> > As a member of the current RFC Editorial board, I have review a
> > of submissions where the clarity of the document was lacking. I
> > be loath to say that the Independent Submissions Editor should have
> > passed these 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 documents that are really clear.
> > 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.
I completely agree that it is the responsibility of the stream approver to
make sure that the documents meet some minimum standard.
I read with interest the fact that there are apparently editors that work on
readability before Alice, Sandy and Bob get these documents. Are these
editors provided by the Independent stream approver? No - I think that what
you mean are editors that reside in the production house in the proposed
model. Are you suggesting that these are the editors that the independent
stream approver should be using in getting documents up to a minimum
technical standard? I don't think so.
While I agree that it is not the stream approver's job to do the edits, it
is their responsibility to be able to read and understand the documents and
make suggestions about how to improve the readability to the authors. I
have never gotten a good response from anybody by saying "Re-write your
document, it is not understandable" without giving examples of how and
where. It would be very difficult to this without the ability to both
fluently read in English (the language of all current RFCs) and the ability
to identify what is both good and poor English. This ability is currently
provided by one or more members of each of the different groups that do
document approval. I know that in the past I have received comments from
the IESG that required that I clean up language in some places.
> == Funding of the Independent Submission editor.
> Jim wrote:
> > 4. The statement on funding for the Independent Submissions Editor
> > worries me. I believe that this job is currently funded as part of
> > the contract with ISI. (Bob, please correct me if I am wrong.) This
> > document is making 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
> > problem.
> > 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 for 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 should not be published or the
> > time for dealing with documents that should never have been
> 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.
Great - Put this in the document as an argument as to why we are no longer
going to fund this position. I think that a simple statement that we
believe it SHOULD be funded by some party would also be reasonable.
> = Continuity
> Joel wrote:
> > The document explicitly states that contract durations, etc. are out
> > of scope for this document. Which seems quite reasonable. However,
> > 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
> > 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.
More information about the rfc-interest