Subject: [Techspec] Comments on draft-mankin-pub-req-05.txt

From: Elwyn Davies <[email-masked]>
Date: Tue, 21 Mar 2006 15:10:12 -0600

Some comments on draft-mankin-pub-req-05.txt:

s3.7, second para:
>
> Discussion: IETF allows minor technical corrects during the
>
>    publication process.  This should ideally be a rare occurrence, but
>
>    as publication times increase, the number of minor technical 
> improvements increases.
>
(editoral aside: s/corrects/corrections/)
The phrase 'but as publication times increase' reads like a criticism of 
throughput , and whilst we may have a problem with this, the issue here 
is 'in the abstract'.  I suggest s/but as publication times increase.. 
increases/but should time from initial approval to final publication 
increase, the number of minor technical improvements that might be 
incorporated is likely to increase correspondingly./ - Certainly we need 
to keep this time down: the s4.1 proposal seems reasonable and should 
limit the opportunity for thinking of cunning new tweaks to sneak in 
under the wire.

s3.7:
>
> Current Req-POSTCORR-2 - The IETF technical publisher should only
>
>       allow post approval technical changes which have been approved by
>
>       the IESG.
>

> Potential Req-POSTCORR-3 - The IETF technical publisher should
>
>       have the discretion to reject post-approval corrections as too
>
>       late in the process and propose that it be handled as errata.
>
This requires a certain level of technical savvy and judgment in the 
technical editors to ensure that they can tell the difference between 
editorial and technical so as they don't have the wool pulled over their 
eyes by authors.  This is a significant requirement for any organisation 
that might bid for this work.

s3.7, last para: the implication is that there might be multiple source 
documents - what these are is not really discussed until 3.9: it might 
be good to either put 3.9 before 3.7 or move the discussion of what 
constitutes source documents to at or before  this point.

s3.9, Discussion: I was under the impression that at present the RFC 
Editor would accept postscript and pdf as well as ascii but does the RFC 
Editor actually do conversions?  In the recent past (last few hundred 
RFCs) anything other than txt is rare (about 3 pdfs I could find).  In 
general terms the RFC Editor needs more than ascii input to create pdf 
or postscript output and this certainly doesn't happen by default.

s3.16, Potential Req-INDEX-5: Also need to archive any necessary tools 
and know what version of tools was used to create corresponding output.

s3.17: Should be an additional requirement to give access to archived 
source to (?appropriately authorized) people for the purposes of making 
derived works (like new versions) or getting MIB sources etc.  This may 
result in an extra item in s5.

s3.19: I think that we should explicitly require that the editorial 
style guide is published.

s4.1, Potential Req-TIMEFRAMES-2: 'Documents held up due to references 
or...': I don't see why this should be a cause for delay of early 
allocation of an identifier. '...or due to a
      protocol action should be excluded from this statistic.': I am not 
sure which action this might refer to.  I think this whole sentence is 
probably a cut and paste error.

s4.1/s4.2: The metrics in these two sections define the overall scale of 
the operation which the IETF is requiring/expecting the technical 
publisher to perform. I think we could usefully add an extra section 
indicating how we would task the technical publisher (and hence how the 
IETf would be charged).  Depending on whether we are looking for a Time 
and Materials contract (the IETF sends documents, the contractor agrees 
to process them according an SLA based on s4.1 and charges per unit 
processed) or we agree a Fixed Price contract based on a throughput per 
unit time as measured in s4.2, and any additional documents have to wait 
(or are done on a special basis - expedited handling again!).

s6: Potential Req-DOCCONVERT-2 in s3.9 would require additional work in 
the IETF to complete and maintain xml2rfc  if it is adopted.

Editorial:
s3.5, last para (Current Req-FORMALVAL-1): s/xml/XML/

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

---

From: Allison Mankin <[email-masked]>
Date: Wed, 22 Mar 2006 08:05:33 -0800

I too want to thank Elwyn for the detailed somments.

> This is an open issue I will raise at the techspec BOF.

I see as the not the IETF technical publisher's discretion.

I would see this as the IETF's policy determination and an Area
Director determining.  The technical publisher could propose
errata but the document shepherd and the final greenlighter
of the document (currently the AD) should be the ones who
exercise the technical discretion.  They should strongly
respect the technical publisher's motivation in pushing
back post-approval corrections, but not give up their technical
accountability.  My view.

Allison

---

From: "Stephen Hayes (TX/EUS)" <[email-masked]>
Date: Wed, 22 Mar 2006 11:24:48 -0600

> back post-approval corrections, but not give up their technical
I agree.  The IETF should have final say.  The question is how to engineer the process so that the technical publisher's objection and the IETF decision to proceed anyway (or take it back and process) is documented and the decision doesn't fall through the cracks.

If the publisher highlights a problem, then the publication of the document should be put on hold.  Until the IETF decides what to do with the publisher's objection it is premature to publish the document either with or without the offending changes.  The IETF can decide to tell the publisher to:
1. Publish without the changes
2. Publish with all or some subset of the changes
3. Take the document out of the queue to allow rework in IETF.

So having the technical publisher reject the offending changes (which is what I had proposed earlier) is insufficient because it implies that publication goes ahead without the offending changes.  Having the technical publisher just highlight the concerns to the IETF and proceed with including them and publishing is also inappropriate.  So what we need is a state in the publication process where the publication is on hold awaiting feedback from the IETF.  This hold shouldn't count against the publisher's performance statistics.

My revised opinion (after further thought)
Stephen

Stephen