A tech spec requirements draft IETF 64 TECHSPEC BOF

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

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

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

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?

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.

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

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?

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)?

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

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

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?

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

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

Next Steps?