draft-mankin-pub-req-06 is available 
http://www.ietf.org/internet-drafts/draft-mankin-pub-req-06.txt.  The changes 
were based upon the meeting comments and agreements as well as a few items 
received before the meeting and offline comments.  Feedback appreciated. Given 
that the timeline calls for last call starting April 15, rapid response is 
requested.

Stephen

1. In Figure 1: Stages of a Working Group Document, add IANA to the post 
approval column (but also keep it in the pre-approval column).

2. Section 3.7 Post Approval, Pre-Publication Technical Corrections.  Replaced 
"This should ideally be a rare occurrence, but as publication times increase, 
the number of minor technical improvements increases." with "This should 
ideally be a rare occurrence." since the last part could be read to imply an 
expected trend towards longer publication times.

3. Removed the reference and references to rfc2223bis.  Specifically:

Removed from section 2: "To allow progress on developing the process 
requirements, this document assumes the policies for document format, etc. as 
are currently defined in [1]."

Modified sections 3.1 and to say "This review should strive to maintain 
consistency in appearance with previously published documents." instead of 
referencing 2223bis.

4. Also removed the reference and references to proto-wgchair-doc-shepherding 
since it doesn't look like this will be referencable in time.

5. Modified Req-POSTCORR-2 to indicate that approved technical changes could 
come from the appropriate party (usually the shepherd, but sometimes the IESG).

6. In requirement       Req-PUBHELP-1 Added the following sentence at the end: 
"The technical publisher should follow IETF guidance in specifying 
documentation guidelines."  This is to make it clear that although it is the 
publisher who may prepare training materials, the IETF is the authority on 
those guidelines. 

7. Added new requirement:
Req-PUBHELP-3 - The IETF technical publisher shall provide a contact e-mail 
address and correspond as required to progress the publication work.  The 
publisher should address queries from both inside and outside of the IETF 
community.

8. Fuzzed the performance metrics section.  Now reworded to:

Req-TIMEFRAMES-1 - The consensus of the IETF community is that an average 
publication time of under a month is desirable.  It is understood that in some 
cases there will be delays outside of the publisher's control. The actual 
performance targets and metrics are expected to be determined as part of the 
contract negotiation process.

Req-TIMEFRAMES-2 - The consensus of the IETF community is that the time 
required for a pre-publication review should be under 10 days.  It is 
understood that in some cases there will be delays outside of the publisher's 
control. The actual performance targets and metrics are expected to be 
determined as part of the contract negotiation process.

Also removed the note about actual numbers determined in the contract since it 
was superfluous.

9. Add a steady state metric for throughput.  Added a new requirement:

Req-THROUGHPUT-3 - Although minor variations are expected, there should be no 
long term growth trend in the length of the publication queue.

Also added some text to Req-Stats-2 tying in the need to present historical 
trending data.

10. Removed the requirements associated with early permanent ID allocation.  

11. Removed the requirement associated with accepting input in xml2rfc.

12. Change the requirement for how the publisher deals with excessive or too 
late changes:
Req-POSTCORR-3 - The publisher should alert the IESG (or IAB or IRSG) when it 
feels that a requested change is unreasonable.  Further processing of the draft 
should be suspended pending a response by the IESG (or IAB or IRSG) on how to 
proceed.

13. Added a new requirement to purge a document from the index:
Req-INDEX-7 - The IETF can indicate to the publisher that it should purge a 
document from the index.  This should remove all traces of the document.

14. Added a note at the end of section 2.1 clarifying that a submission may 
actually consist of multiple source documents.
 
"Note that in some cases a single submission may actually consist of multiple 
source documents (supporting files, code, etc.)."

15. Removed all the Current and Potential prefixes for the requirements.

16. Correction of some typos, grammar, etc.


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

Reply via email to