comments on <draft-mankin-pub-req-08.txt>

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]