1 / 15

A tech spec requirements draft

A tech spec requirements draft. mankin@psg.com 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).

mahlah
Télécharger la présentation

A tech spec requirements draft

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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?

More Related