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 protected]
https://www1.ietf.org/mailman/listinfo/techspec
