[rfc-i] [IAB] Intended Publication: RFC Editor Model (draft-iab-rfc-editor-model-02.txt)

Olaf Kolkman 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  
implementation.

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 guide.  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  
> 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  
needed here.


== 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  
> 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  
other streams.


Jim:
> 2. For the independent submission editor,  I note that both  
> editorial skills
> and competency in English are not requisite qualifications.  Is 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 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  
> 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.  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.

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 communities time for dealing with documents  
> that
> 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.


= Continuity

Joel wrote:
> 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.


--Olaf




-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
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 mailing list