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

From: Craig Partridge <[email-masked]>
Date: Wed, 10 May 2006 13:29:38 -0400

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: [email-masked] or [email-masked]

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Dave Crocker <[email-masked]>
Date: Sun, 14 May 2006 11:01:10 -0700

>     only addresses IETF documents processed by the IESG."

The IRTF certainly used to be parallel to, and independent of, the 
IETF.  However, that has changed. 

In terms of both public perceptions and community operational 
interactions, the term "IETF" now subsumes classic IETF components, as 
well as the IAB and the IRTF.

On the other hand, your proposed language change probably characterizes 
this particular document more accurately.

-- 

Dave Crocker
Brandenburg InternetWorking
<http://bbiw.net>

---

From: Pekka Savola <[email-masked]>
Date: Mon, 15 May 2006 09:31:40 +0300 (EEST)

Hi,

On Sun, 14 May 2006, Dave Crocker wrote:
> IETF. However, that has changed. In terms of both public perceptions 
> and community operational interactions, the term "IETF" now subsumes 
> classic IETF components, as well as the IAB and the IRTF.
>
> On the other hand, your proposed language change probably characterizes this 
> particular document more accurately.

Dropping IAB and IRSG out of this document's scope would likely demote 
those documents to second-class citizens (or drop them completely), 
which is likely not desirable.  So, I think most folks would agree 
that such documents should be included in the scope, while language 
might be tuned.

That said, a couple of comments of my own.  (I think the document is 
rather good as it is.)

...

In section 3.1 you say that early experience from early copy editing 
has been promising but the effectivess is still being evaluated -- yet 
still there is a requirement to technical publisher to provide such 
service.  This seems a bit premature as we haven't even figured out 
yet whether it's worth the trouble.  Maybe reword s/should 
perform/should be capable [or willing] to perform/ or the like..

In section 3.3, Req-POSTEDIT-5, s/will require..verbatim/may 
require..verbatim/ to emphasize that even if a particular text is a 
result of careful negotiation, marking it as "no-touch" is optional.

In section 3.9, Req-DOCCONVERT-2 says that the tech pub should accept 
supplemental source files, e.g., code, formal descriptions, graphics, 
etc.  It's not clear to me where this comes from.  What should it do 
with those in any case?  Is this reserved for future proofing if the 
output format at some later date would be something other than ASCII. 
I'd expect that all the relevant material be in the input ascii files. 
Even a .PS source file format (for some RFCs) is ascii..

In section 3.16, Req-INDEX-7 says that the IETF can request publisher 
to purge a document from the index, and that it should remove all 
traces of the document.  If the goal is removing all the traces of the 
document (from the sites under IETF control in any case), this 
requirement should also include removing the publication itself as 
well, not just removing it from a [web or tex] index (that's the way I 
understand "index").

I'd like to hear legal advice from the IETF legal counsel on this. 
Having this kind of option would likely increase the probability of 
requests to eliminate documents as it can be argued we have an 
established process to do so.  So, I'm not sure if we need this, 
because court orders (etc.) should be compelling (or not) with or 
without such a requirement.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings