Skip to main content

RFC Document editing/ queueing suggestion

Document Type IAB Statement
Title RFC Document editing/ queueing suggestion
Published 2003-08-28
Metadata last updated 2023-08-09
State Active
Send notices to (None)
Date: Thu, 28 Aug 2003 16:04:50 -0400 
From: John C Klensin <> 
cc: Subject: 
RFC Document editing/ queueing suggestion


Under current published procedures, when an individual submission document is passed to the RFC Editor, it goes into the queue for evaluation and review. If it is returned to the author for any reason –even a few small editorial changes which, in the past, the RFC Editor would just make and then confirm with the author, the document is removed completely from the queue and, when a new draft appears, it is treated as a completely new submission.

Ever since this model was instituted, I’ve been uncomfortable with it as a matter of appropriateness, justice, and efficiency at getting documents out. But I haven’t been able to cleanly identify the problem, and an alternative, in a way that I find satisfactory. I finally have, so, a comment and a suggestion:

The problem with this model is that, especially when (possibly through no fault of your own) the RFC Editor takes many months to complete review on an individual submission, bouncing it with “please start over” can lead to even more delay. If these delays result from substantive difficulties with the document, they are quite reasonable. But I’m concerned about situations in which the RFC Editor is doing just that –editing– i.e., supplying exactly those changes that are preferred in a form that certainly takes more time than actually making the changes.

In most cases, if informational documents that really have value are to be published as RFCs, timely publication is important. If we are going to see indefinite delays, followed by bouncing a document for changes the RFC Editor knows how to make, we just aren’t operating efficiently. In the long term, if we were trying to kill the notion of individual submissions of significant material –including comments on or alternatives to IETF actions that ought to be in the record– long delays might be more efficient than any more formal procedure in doing so, or at least in ensuring that the RFC Editor gets only low-priority documents.

In addition, while I am sure it was not part of the reasoning, a “submit, review, bounce, treat as new document” model distorts RFC Editor queuing statistics, making it appear that more documents are being processed, and processed more quickly, than is actually the case.


  1. If a document is returned (actually rejected) for substantive reasons, the current procedure is retained, i.e., the document is removed from queue and a resubmission is treated as a new submission. “Substantive reasons” here are actual rejections of the document, i.e., a decision that the RFC Editor will not publish the document because its subject matter is inappropriate for RFC publication.
  2. If a document is returned for editorial reasons, it is returned with a timeout for resubmission. It remains in queue while the timer is running and, if resubmitted within that period, is processed in that order. If the timer runs out, the document is removed from the queue and, if eventually resubmitted, treated as a new document. Note that this optimizes getting documents out quickly and will tend to optimize the time of both authors and the RFC Editor, since the odds of people completely losing context and trains of thought about the document are reduced.
    The RFC Editor should determine an appropriate timeout formula, but I would suggest that, in fairness to authors and to optimize all of the right properties, it should be set at no less than 20% of the time the RFC Editor had the document in queue before returning it.

Would that be reasonable?