The only way to make sure deliveries of product -- in this case, IETF documents -- are timely is to decide when they are needed by and set firm deadlines. The IETF currently does not do that. Instead, we leave everything open-ended.
This gives the unfortunate impression that setting firm deadlines is all it takes
to get product out. This is contrary to my experience, and I suspect nearly
everyone else's. I assume this is not what Dave meant, but that he is simply
pointing out the usefulness of having a deadline in planning, allocation of
resources, and setting up follow-on activity.
I'd like to suggest, though, that a better model for the problem is queuing. At the moment, every "packet" (document) emitted by IETF working groups and every document reviewed for the RFC Editor ultimately goes through the same queue, which is not allowed to drop any item. The traffic is bursty and the resources used for processing the packets have priority interrupts for other tasks (in the individuals: day jobs, family life; for the group: appeals, other critical IETF business).
That the queue depth gets longer should be no surprise. That moving things around in the queue starts to happen is no surprise, even though moving them takes energy that could have been otherwise spent on throughput. Making deadlines ever firmer creates priority interrupts or causes more energy to be expended in queue management instead of throughput.
My personal belief is that we need to implement multiple queues instead. If the IETF continues to believe that reviewing RFCs for end-runs is valuable, okay; let's select individuals who can undertake that review, and get it out of the "make standards" queue. I've pushed that idea before; I stopped because the simpler solution (ensure that there are sufficiently different publication avenues for standards and RFC editor documents) seemed to be gaining support and that pushed even the development of the new queue to the RFC Editor.
The fundamental idea, though, remains: important to the IETF does not mean "needs to pass through the IESG". regards, Ted Hardie
PS. I almost got through the whole email without saying "functional differentiation".
_______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf