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@xxxxxxxxxxxxx or craig@xxxxxxx > > _______________________________________________ > Ietf mailing list > Ietf@xxxxxxxx > https://www1.ietf.org/mailman/listinfo/ietf > _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf