A tech spec requirements draft

1. A tech spec requirements draft mankin@psg.com IETF 64 TECHSPEC BOF

2. You Are Here • draft-mankin-pubreq-01.txt • Discussion • motivation of the draft • individual requirements • next action on draft

3. Document Lifetime (skeleton of Fig. 1) Tech Publication |_________________| |______________________| |_________________| In WG Pre-Approval Post-Approval APPROVAL PUBLICATION

4. Beginning-to-End Status Tracking • Req-2 • IETF documents move seamlessly from IETF tracking system into Tech Pub tracking system [not talk about how, but do we want this] • Req-3 • IETF have as detailed visibility into Tech Pub tracking as into IETF tracking

5. Non-Author Editing • This is the same topic the early editing experiment, but there are more aspects • Pre-Req 7 • Does the IETF shepherd/editor group appoint one person to coordinate the editor process? • Pre-Req 8 • How does the IETF handle non-author editing which affects consensus wording?

6. Post-Approval, Pre-Publication Changes • Non-author changes in post-approval may be many; so are the author changes. Limitation would make the publication process more efficient • Req-9 • Authors/IETF Editors must not initiate stylistic changes • Req-10 • Any other small technical changes that have merit must be submitted to the document shepherd within a short window of the document approval rather than at the time of publication. Large flaws may of course be identified any time.

7. Fast Tracking • The IETF has a current requirement to request expedited publication • Used quite frequently • Req-6 • The IETF continues to require this service, but the goal is for it to become a very rarely used requirement

8. What Is the Stable Permanent Identifier • This is not stated clearly in the draft, but list discussion included some comments about this • Req-11 • Should the IETF Stable Permanent Identifier for its documents indicate that they are IETF documents?

9. Post-Approval Timeframe • Much list discussion • Partly about the business, service level agreement • We are giving that input • Publication ahead of the RFC 2026 appeal window? • What window to IETF to the technical publisher? • What management for the end-users if the technical publisher has a backlog in some future exigency (IETF-side budget issue, publisher side staff issue)?

10. Post-Publication, Maintaining and Updating Errata • See the document on this • Has the IETF defined the errata service correctly? • What service is required here and who plays what roles? • I suggest we conduct a list discussion

11. Mechanisms for Changes to Tech Spec Style • The current draft suggests a document approval by the IETF • The requirement for interacting on tech publication style change and impact may be lighter • A suggestion to visualize this requirement are discussions just for this purpose among a small group with document interest and experience: • An ad hoc, publicly known small group with a few from the technical publisher, working group chairs, editors, iesg, iab

12. Indexing: Publisher Catalog • What does the IETF require the technical publisher to provide as its cataloging service? • The IETF defines which documents obsolete and update which • This and what else should be in this area of the requirements?

13. Requirements suggested since the document: • Technical publisher include a permanent record of provenance • IETF not pass documents into the technical publisher unless their normatively referenced documents ready for the technical publisher as well

14. As Participant: Section 5.2 • Much list discussion on Experiment on Stable Permanent Identifier on Approval • Proposal - develop an experiment • Not use Fast Tracks (8 for December) • Last during current backlog period • Only for documents whose normative references are also eligible

15. Next Steps?