My quick reaction on a light read.
One bit of text put my teeth on edge:
* section 2, 2nd para "This draft only addresses those documents
published by the IETF family. These include IETF documents processed
by the IESG, IAB documents, and IRTF documents processed by the IRSG."
I don't think the IAB and IRSG are part of the IETF family. If they
are part of a family, it would be ISOC. So I'd just say "This draft
only addresses IETF documents processed by the IESG."
Another problem spot was 4.1, post-approval timeframes. I have two
concerns:
* One month turnaround is a swift requirement in any publishing system.
I suspect it is unreasonable.
* The metric has no discussion of document length. There's a big
difference between a 20 page document and a 100 page document and
it affects turnaround times.
* There's no discussion of arrival process -- my bet is that things
come in pulses. Again, that's a workload issue we need to be
aware of. If work comes in pulses, that tends to increase
turnaround times.
* There's no discussion of the interaction between the requirement to
validate format languages (in 3.5) and post-approval turnarounds.
Yet if the Editor is validating ASN.1 or the like, that will delay a
document. (And such validation can't occur in the earlier phases
as the ASN.1 may change).
Note that I'm all in favor of a tracking queue and measuring how fast things
pop out. But a one-size fits all view doesn't work. If an RFC arrives with
all the lights on (100+ pages of ASN.1 in a batch of 10 RFCs from the
latest IETF), don't expect swift turnaround.
I also had trouble with 4.2. The statement is the queue length should
show no growth trend. In government this is known as an unfunded mandate :-).
Keeping queue lengths short if the rate of document arrival increases costs
money (cf. professional society journal queues).
Craig
E-mail: craig@xxxxxxxxxxxxx or craig@xxxxxxx
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf