Craig Partride wrote:
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."
The intention was that these requirements would apply when processing documents
that come from the IETF (via the IESG), the IRSG, or the IAB. We can perhaps
find a different name for the group of entities, but the idea was to have
consistent publication requirements between the organizations. IESG processed
documents is too restrictive.
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.
Before starting the requirements I checked with several other standards
organizations on what their publication policies are. An under one month
average is quite achievable. Many of the other organizations have tighter
deadlines and much burstier load. It is realized that there is a tradeoff
between speed and cost. The contractual targets have to be contractually
decided. This is intended to represent what the IETF community feels is
desirable.
* 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.
The one-month average is a statistical measure. It is realized some documents
will take longer. It is expected that some documents would be processed faster.
* 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.
Again, the figure is statistical. Compared to a lot of other standards
organizations, the IETF volume is not so bursty (such as after a plenary where
lots of documents are approved).
* 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).
Formal language validation can take time. It is not really possible to list
all the special cases that could take time. The goal is that even including
these cases the average is under one month.
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).
Very true. Since we don't talk about money, all these requirements are an
unfunded mandate. If the technical publisher becomes overloaded, then
something has to give. And that may mean more money or reduced processing of
each document. A disclaimer can be added that this may require adjusting
resources if the input load increases over time. What this requirement
captures is the desire by the IETF that we can achieve at least steady state.
Contractual mechanisms to accomplish this are outside the scope of this
document.
Craig
E-mail: craig(_at_)aland(_dot_)bbn(_dot_)com or craig(_at_)bbn(_dot_)com
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf