[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 RFC 4714

Network Working Group                                         A. Mankin
Internet Draft                                            Shinkuro, Inc
Expires: September 2006                                        S. Hayes
                                                                Ericsson
                                                           March 4, 2006


            Requirements for IETF Technical Publication Service
                        draft-mankin-pub-req-05.txt




Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
        http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
        http://www.ietf.org/shadow.html

   This Internet-Draft will expire on July 4, 2006.



Abstract

   The work of the IETF is to discuss, develop, and disseminate
   technical specifications to support the Internet's operation.
   Technical publication is the process by which that output is
   disseminated to the community at large. As such, it is important to
   understand the requirements on the publication process.






Mankin & Hayes            Expires September 4, 2006                  [Page 1]

Internet-Draft          draft-mankin-techspec-pubreq-05             March 2006


Conventions used in this document

   Requirements are designated as either current requirements (Current
   Req-xx) to indicate requirements that seem to currently exist and
   potential requirements (Potential Req-xx) to indicate requirements
   that are speculative.

Table of Contents


   1. Introduction...................................................3
   2. Scope..........................................................3
      2.1. Stages in the Technical Specification Publication Lifetime4
   3. Technical Publication Tasks and Requirements...................5
      3.1. Pre-approval review or editing............................6
      3.2. Preliminary Specification Availability....................7
      3.3. Post-Approval Editorial Cleanup (non-Author Editing)......7
      3.4. Validation of references..................................9
      3.5. Validation of formal languages............................9
      3.6. Assignment of Parameter Values............................9
      3.7. Post Approval, Pre-Publication Technical Corrections.....10
      3.8. Allocation of Permanent Stable Identifiers...............11
      3.9. Document Format Conversions..............................11
      3.10. Language Translation....................................12
      3.11. Publication Status Tracking.............................12
      3.12. Expedited Handling......................................13
      3.13. Exception Handling......................................14
      3.14. Notification of publication.............................14
      3.15. Post Publication Corrections............................14
      3.16. Indexing: maintenance of the catalog....................15
      3.17. Access to Published Documents...........................16
      3.18. Maintenance of a Vocabulary Document....................16
      3.19. Providing Publication Statistics and Status Reports.....17
      3.20. Process and Document Evolution..........................17
      3.21. Tutorial and Help Services..............................17
   4. Technical Publisher Performance Metrics.......................18
      4.1. Post-approval timeframes.................................18
      4.2. Publication Throughput...................................19
      4.3. Non author changes Generated during Publication..........20
      4.4. Author changes generated during publication..............20
   5. IETF Implications of Technical Publication Requirements.......21
   6. IANA Considerations...........................................22
   7. Security Considerations.......................................22
   8. Acknowledgments...............................................22
   9. Informative References........................................22
   Author's Addresses...............................................23
   Intellectual Property Statement..................................23


Mankin & Hayes            Expires September 4, 2006                  [Page 2]

Internet-Draft          draft-mankin-techspec-pubreq-05             March 2006


   Disclaimer of Validity...........................................24
   Copyright Statement..............................................24
   Acknowledgment...................................................24

1. Introduction

   The work of the IETF is to discuss, develop, and disseminate
   technical specifications to support the Internet's operation.  An
   important output of the IETF, then, is published technical
   specifications. The IETF technical publisher is responsible for the
   final steps in the production of the published technical
   specifications.  This document sets forth requirements on the duties
   of the IETF technical publisher and how it interacts with the IETF in
   the production of those publications.

   The term "technical specification" is used here purposefully to refer
   to the technical output of the IETF. This document does not engage in
   the debate about whether it is expressed as RFCs or ISDs, what "is"
   an RFC, how to classify them, etc.  These issues are considered out
   of scope.

   The intention of this document is to clarify the IETF's consensus on
   its requirements for its technical publication service.  This
   document is not a discussion of how well the RFC Editor fulfils those
   requirements.

2. Scope

   The scope of this document is the requirements for the technical
   publication process for IETF.  Requirements on a technical publisher
   can be expressed in terms of both what tasks the IETF technical
   publisher is responsible for and performance targets the IETF
   technical publisher should meet.

   This draft only addresses those documents published by the IETF
   family. These include IETF documents processed by the IESG, IAB
   documents, and IRTF documents processed by the IRSG.  It
   specifically excludes independent submissions that go directly to
   the Technical Publisher.  The handling of independent submissions
   may well be a requirement on the technical publisher, but it is not
   one associated with the IETF publication process and hence is
   outside the scope of this document

   The list of potential technical publication tasks was derived by
   considering the tasks currently performed by the RFC editor as well
   as the responsibilities of the technical publishers in other
   standards organizations including 3GPP, ATIS, ETSI, IEEE, and ITU.


Mankin & Hayes            Expires September 4, 2006                  [Page 3]

Internet-Draft          draft-mankin-techspec-pubreq-05             March 2006


   This requirements documents focuses on process issues in how the IETF
   technical editor serves the IETF.  There are related issues regarding
   non-technical aspects of document content that are not addressed in
   this requirements document.  Issues not addressed in this document
   are:

   o  Policies governing the acceptable input and output document
      formats (including figures, etc.),

   o  Policies governing the acceptable character sets
      (internationalization)

   o  Policies governing the layout and style of published documents

   o  Policies governing the contents of non-technical sections
      (acknowledgement sections, reference classifications, etc.)

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

   It is realized that the above policies are also an important aspect
   in determining the final published product from IETF.  These policies
   are likely to evolve as part of the ongoing IETF dialog.  The IETF
   technical publisher must be part of the discussions of these policies
   and be prepared to implement and facilitate policy changes as they
   are determined by IETF consensus.  This requirement is captured under
   the discussion of process and document evolution.

2.1. Stages in the Technical Specification Publication Lifetime

   Figure 1 below provides a useful summary of where technical
   publication falls in the current lifetime of a document in the IETF.
   This figure shows a working group document and the review includes an
   IETF Last Call (LC).  The lifetime is very similar for AD-sponsored
   IETF documents, such as document that update IETF protocols where
   there is no longer a working group, or documents on interdisciplinary
   topics.











Mankin & Hayes            Expires September 4, 2006                  [Page 4]

Internet-Draft          draft-mankin-techspec-pubreq-05             March 2006



            |  Author    | WGLC      | IESG,      |    |  Tech
    Actors  |  or        | AD        | Shepherd,  |  A |  Publisher,
            |  Editor    | IETF LC   | Editor,    |  P |  input from
            |            | IANA      | WG         |  P |  authors, et al
            |            | IESG      |            |  R |
    Actions |  Creation  |           | Resolution |  O |  non-author
            |  and       | Formal    | of all     |  V |  editing,
            |  Editing   | Reviewing | reviews    |  A |  other
            |            |           |            |  L |  publication

            |---------------| |---------------------| |----------------|

                  In WG               Out of WG          Post-Approval

               Figure 1: Stages of a Working Group Document

3. Technical Publication Tasks and Requirements

   Standards development organizations all have technical publication as
   part of their process.  However, the boundaries between what is done
   by the technical committees and the technical publisher vary.

   The following are potential tasks of a technical publisher.  The
   following list was derived after analyzing the technical publication
   policies of the IETF and other standards development organizations.
   For each of these tasks we discuss its relevance to IETF and how it
   is realized within the IETF processes.  Based upon this information
   we derive current or potential requirements on the IETF technical
   editor:

   1. Pre-approval review or editing

   2. Preliminary specification availability

   3. Post-approval editorial cleanup

   4. Validation of references

   5. Validation of formal languages

   6. Assignment of parameter values

   7. Post approval, pre-publication corrections

   8. Allocation of permanent stable identifiers



Mankin & Hayes            Expires September 4, 2006                  [Page 5]

Internet-Draft          draft-mankin-techspec-pubreq-05             March 2006


   9. Document format conversions

   10.Language translation

   11.Publication status tracking

   12.Expedited handling

   13.Exception handling

   14.Notification of publication

   15.Post-publication corrections (errata)

   16.Indexing: maintenance of the catalog

   17.Access to published documents

   18.Maintenance of a vocabulary document

   19.Providing publication statistics and status reports

   20.Process and document evolution

   21.Tutorial and help services

3.1. Pre-approval review or editing

   Task Description: In many cases the technical publisher may provide a
   review or editing service to improve document quality prior to the
   approval of a document.  This review process would normally address
   issues such as grammar, spelling, formatting, adherence to
   boilerplate, document structure, proper use of keywords (RFC 2119),
   etc.

   The primary advantage of pre-approval review is that review of the
   changes is handled as part of the regular review and approval
   process.

   Discussion: Pre-approval review is not part of the normal process
   flow with the IETF but this concept has been explored with promising
   results in the early copy editing experiment.

   Derived Requirements:





Mankin & Hayes            Expires September 4, 2006                  [Page 6]

Internet-Draft          draft-mankin-techspec-pubreq-05             March 2006


   o  Potential Req-PREEDIT-1: The IETF technical publisher should
      perform an editorial review of documents before WG last call and
      provide feedback to the authors to improve quality of the
      documents.  This review should address the areas outlined in [1].

3.2. Preliminary Specification Availability

   Task Description: Some standards organizations require their
   publisher to make available a preliminary version of a document (with
   appropriate caveats) to make the information available to the
   industry as early as possible.  This document is provided "as is"
   after the approval.  This document is withdrawn once the final
   document is published.

   Discussion: This is not required.  A final approved version is
   available as a draft.  If publication can take more than 6 months, it
   may be necessary to take measures to ensure the draft version remains
   available.

   Derived Requirements: none

3.3. Post-Approval Editorial Cleanup (non-Author Editing)

   Task Description: Most technical publishers do an editorial review to
   ensure the quality of published documents.  Typically this may
   address issues such as grammar, spelling, readability, formatting,
   adherence to boilerplate, document structure, proper use of keywords,
   etc.  Since any proposed changes occur after approval, a review and
   signoff mechanism must usually be established to ensure that the
   required changes are truly editorial.  Since such changes occur
   outside of the normal approval process, it is desirable that such
   changes are minimized.  Most standards organizations target "light"
   editing due to the dangers of changing agreed text.

   Discussion: Within IETF, the RFC Editor does post approval cleanup
   review and editing.  The ambition level for cleanup can vary from:

   o  Corrections to errors only,

   o  Light rewriting,

   o  Significant editing of documents with less skillful WG editors,
      and minimal editing when the WG editors were skilled,

   o  Rewriting of all documents to the dictates of a style manual




Mankin & Hayes            Expires September 4, 2006                  [Page 7]

Internet-Draft          draft-mankin-techspec-pubreq-05             March 2006


   At times in the past year, stylistic editing has resulted in 40-100
   substantive changes in many documents.  These changes must then be
   vetted by all the authors followed by subsequent rounds of author
   acceptance and re-vetting.  This can add up to a substantial delay in
   the publication process which must be weighed against the incremental
   gain in communication improvement accomplished by the cleanup.

   Changes to improve readability (or possibly even grammar) can end up
   inadvertently affecting consensus wording or technical meaning.  Note
   that pre-approval editing to some extent avoids this problem.

   If pre-approval editing or review is done it may be possible to
   greatly reduce or even eliminate entirely the post-approval editing
   task.  Pre-approval editing is generally more efficient since a
   separate change control process is not required.

   Derived Requirements:

   o  Current Req-POSTEDIT-1 - The IETF technical publisher should
      review the document for grammar, spelling, formatting, adherence
      to boilerplate, document structure, proper use of keywords, etc.
      as defined in [1].

   o  Current Req-POSTEDIT-2 - All changes made to post-approval
      documents should be tracked and the changes must be signed off on
      by the appropriate technical representatives as defined in the
      IETF processes.

   o  Potential Req-POSTEDIT-3 - The IETF Technical editor should
      refrain from stylistic changes that introduce a substantial review
      load but only provides incremental increase in the clarity of the
      specification.  Specific guidelines on the types of changes
      allowed may be further specified, but ultimately restraint in
      editing must be imposed by the IETF technical publisher.  Changes
      for stylistic consistency should be done only when there are major
      problems with the quality of the document.

   o  Potential Req-POSTEDIT-4 - The IETF Technical editor should
      refrain from changes to improve readability that may change
      technical and consensus wording.  Specific guidelines on the types
      of changes allowed may be further specified, but ultimately
      restraint in editing must be imposed by the IETF technical
      publisher.






Mankin & Hayes            Expires September 4, 2006                  [Page 8]

Internet-Draft          draft-mankin-techspec-pubreq-05             March 2006


3.4. Validation of references

   Task Description: Most standards organizations require that normative
   references be publicly available.  Some technical publishers verify
   the validity and availability of references (included referenced
   clauses and figures).  Although some editorial clean-up of references
   may be obvious, the issue becomes more severe when reference links
   are broken, are not publicly available, or refer to obsoleted
   documents.  Such faults may be viewed as a post-approval fault found
   in the document.  Most publishers have the ability to put a document
   on hold awaiting the publication of a reference expected to be
   available soon.

   Discussion: The RFC Editor may put a document on hold waiting for the
   availability of other IETF documents.  Incorrect references are
   handled like any other fault detected in the editorial review.

   Derived Requirements:

   o  Current Req-REFVAL-1 - The IETF technical publisher should ensure
      that references within specifications are available.

   o  Current Req-REFVAL-2 - The IETF technical publisher should delay
      publication until all required IETF references are ready for
      publication.

3.5. Validation of formal languages

   Task Description: If the Specification contains a formal language
   section (such as a MIB), the technical publisher may be required to
   validate this using a tool.

   Discussion: The RFC Editor validates sections of a document
   containing MIBs, ABNF, XML, and possibly other formal languages.

   Derived Requirements:

   o  Current Req-FORMALVAL-1 - The IETF technical publisher should
      validate sections of documents containing formal languages.  In
      particular ASN.1, ABNF, and xml should be verified using
      appropriate tools.

3.6. Assignment of Parameter Values

   Task Description: The Technical Publisher is expected to work with
   IANA (or possibly other organizations maintaining registries) to
   populate protocol parameters when required prior to publication.  The


Mankin & Hayes            Expires September 4, 2006                  [Page 9]

Internet-Draft          draft-mankin-techspec-pubreq-05             March 2006


   population of these parameters should not require technical expertise
   by the technical publisher.

   Discussion: Within IETF, IANA normally does its allocations as an
   early step in the technical publication.

   Derived Requirements:

   o  Current Req-PARAMEDIT-1 - The IETF technical publisher should work
      with IANA in the population of required parameter values into
      documents.

3.7. Post Approval, Pre-Publication Technical Corrections

   Task Description: Regardless of efforts to minimize their occurrence,
   it is always possible that technical flaws will be discovered in the
   window between document approval and publication.  The technical
   publisher may be requested to incorporate technical changes into the
   document prior to publication.  Such changes necessitate a review and
   sign-off procedure.  Another option is to disallow such corrections
   and treat them as you would post-publication errata.  Note that this
   task is distinct from post approval changes that might originate due
   to editorial review because they originate from outside the technical
   publisher.  For severe flaws, it should always be possible to
   withdraw the document from the publication queue.

   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.  Since any changes introduced during the
   post-approval phase can lead to publication delays it is important
   that only changes with technical merit be permitted.  In particular
   stylistic changes should be discouraged.  IETF processes must be in
   place to vet changes proposed by the author, but this is not
   specifically a requirement on the technical publisher.

   The interaction between the authors and the technical publisher must
   be sufficiently well policed that untracked and unapproved changes
   cannot be introduced by the author or other parties.

   Derived Requirements:

   o  Current Req-POSTCORR-1 - The IETF technical publisher should
      permit the incorporation of technical changes detected after
      approval, but pre publication.




Mankin & Hayes            Expires September 4, 2006                 [Page 10]

Internet-Draft          draft-mankin-techspec-pubreq-05             March 2006


   o  Current Req-POSTCORR-2 - The IETF technical publisher should only
      allow post approval technical changes which have been approved by
      the IESG.

   o  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.

   o  Potential Req-POSTCORR-4 - The IETF technical publisher should
      ensure that any source documents associated with a publication
      are also updated in concert with their associated specifications.

3.8. Allocation of Permanent Stable Identifiers

   Task Description: For a document to be referenced, it must have a
   unique permanent identifier.  In some standards organization, it is
   the technical publisher that generates this identifier.  In other
   cases the identifier may be allocated earlier in the process.

   Discussion: Currently, the RFC Editor allocates these numbers when
   the document is near the end of the publication process.  When the
   delay between technical approval and publication of a document is
   long, this creates a problem for external standards organizations
   that cannot reference the specification until this identifier is
   available.

   Derived Requirements:

   o  Current Req-PERMID-1 - The IETF technical publisher should
      allocate stable identifiers as part of the publication process.

   o  Potential Req-PERMID-2 - The IETF technical publisher should
      permit early allocation of stable identifiers for or by the IESG
      to satisfy referencing requirements of external bodies.

   o  Current Req-PERMID-3 - The IETF technical publisher should assign
      additional permanent identifiers associated with various classes
      of documents as directed by the IETF.

3.9. Document Format Conversions

   Task Description: The technical publisher is responsible for
   converting the documents into one or more output formats (text, pdf,
   ps, etc.).  In some standards organizations, the technical publisher
   may be required to accept input documents in various formats and
   produce a homogeneous set of output documents.



Mankin & Hayes            Expires September 4, 2006                 [Page 11]

Internet-Draft          draft-mankin-techspec-pubreq-05             March 2006


   Discussion: Currently, the RFC Editor accepts input as an ascii text
   file (supplemented by xml if available).  The documents are published
   as ascii text, postscript, and pdf files.

   Derived Requirements:

   o  Current Req-DOCCONVERT-1 - The IETF technical publisher should
      accept as input ascii text files and publish documents as ascii
      text files, postscript files, and pdf files.

   o  Potential Req-DOCCONVERT-2 - The IETF technical publisher should
      accept as input xml2rfc files.

   o  Potential Req-DOCCONVERT-3 - The technical publisher should
      accept supplemental source files that may contain information
      such as: code, formal descriptions (XML, ASN.1, etc.) graphics,
      data files, etc.

3.10. Language Translation

   Task Description: Some standards organizations require publication of
   documents in multiple languages.  This translation is the
   responsibility of the technical publisher.

   Discussion: IETF specifications are published only in English.

   Derived Requirements: none

3.11. Publication Status Tracking

   Task Description: The technical publisher should have the ability to
   provide status information on the status of a document.  This may
   involve developing a process model or a checklist and providing
   information on a document's state, outstanding issues, and
   responsibility tokens.  Depending on the need for transparency, this
   information may need to be available online and continuously updated.

   Discussion: The RFC Editor currently provides status information via
   the RFC editor queue.  Each document is attributed a status (AUTH48,
   RFC-EDITOR, IANA, ISR, etc.)  Items may stay of the queue for a long
   time without changing status.  This status tracking information is
   not integrated with the IESG tracking tools.  Within the IETF, the
   PROTO team is considering requirements for marking the token-holder
   accurately during long waiting periods, and others are looking into
   improved notification tools [2]. Requirements on the IETF technical
   publisher for improved status integration and visibility could be met



Mankin & Hayes            Expires September 4, 2006                 [Page 12]

Internet-Draft          draft-mankin-techspec-pubreq-05             March 2006


   by collaborations with these efforts, or by providing public access
   to email logs regarding publications, or by some other proposal.

   Derived Requirements:

   o  Current Req-STATUSTRK-1 - The IETF technical publisher should
      provide state information for each document in the publication
      process.

   o  Potential Req-STATUSTRK-2 - The IETF technical publisher should
      integrate its state information with the IETF tools to provide
      end-to-end status tracking of documents.  IETF documents should be
      able to move seamlessly from the IETF tracking system into the
      technical publication tracking system.

   o  Potential Req-STATUSTRK-3  - The IETF technical publisher should
      provide external visibility of not only the fact that a document
      is in an extended waiting period, but also the token-holder and
      circumstances of the wait.

3.12. Expedited Handling

   Task Description: In some cases (such as when the documents are
   needed by another standards body), it should be possible for the
   approving organization to request expedites publication of a
   document.  Ideally, this should not skip any of the publication
   steps, but allocates it higher priority in the work queue that should
   ensure earlier publication than normal.  Expedited publication should
   be used sparingly since as with any priority scheme, overuse will
   negate its benefits.

   Discussion: The fast-tracking procedure is used to expedite
   publication of a document at the request of the IESG. Fast-tracking
   is generally employed when an external organization has a looming
   publication deadline and a need to reference a document currently in
   the RFC editors queue.  Having short publication times or providing
   stable identifiers early in the publication process would likely
   reduce the need for fast-tracking.

   Since fast tracking is disruptive to the workflow it is recommended
   that expedited handling be phased out as soon as alternative ways of
   achieving timely publication are in place.

   Derived Requirements:





Mankin & Hayes            Expires September 4, 2006                 [Page 13]

Internet-Draft          draft-mankin-techspec-pubreq-05             March 2006


   o  Current Req-EXPEDITE-1 - The IETF technical publisher shall
      expedite the processing of specific documents at the request of
      the IESG.

3.13. Exception Handling

   Task Description: It should be possible for various reasons for a
   document to be withdrawn from publication or the publication put on
   hold.  Reasons for this could be due to an appeals process, detection
   of a serious technical flaw, or determination that the document is
   unsuitable for publication.

   Discussion: For various reasons a document can be withdrawn before
   publication.

   Derived Requirements:

   o  Current Req-EXCEPTIONS-1 - The IETF technical publisher should
      permit documents to be withdrawn from publication at the direction
      of the IETF.

   o  Current Req-EXCEPTIONS-2 - The IETF technical publisher should
      permit documents to be put on hold awaiting the outcome of an
      appeal.

3.14. Notification of publication

   Task Description: The technical publisher should provide a mechanism
   for alerting the community at large of the availability of published
   documents.

   Discussion: The RFC Editor notifies of document publication on the
   rfc-dist and ietf-announce mailing lists.

   o  Current Req-PUBNOTIFY-1 - The IETF technical publisher should
      announce the availability of published documents.

3.15. Post Publication Corrections

   Task Description: If corrections are identified after publication,
   the technical publisher should be able to publish errata that can be
   linked with the original document.

   Discussion: The RFC Editor maintains a list of errata.  Pointers to
   relevant errata are presented as output from the RFC Editor search
   engine.



Mankin & Hayes            Expires September 4, 2006                 [Page 14]

Internet-Draft          draft-mankin-techspec-pubreq-05             March 2006


   Derived Requirements:

   o  Current Req-ERRATA-1 - The IETF technical publisher should
      maintain errata for published documents.

   o  Current Req-ERRATA-2 - The IETF technical publisher should provide
      information on relevant errata as part of the information
      associated with a RFC.

3.16. Indexing: maintenance of the catalog

   Task Description: The technical publisher normally provides and
   maintains the master catalog of publications of that organization.
   As the publishers of the organization's output, the technical
   publisher is expected to be the definitive source of publications and
   maintainer of the database of published documents.   This also
   includes the cataloging and storage of meta-information associated
   with documents such as its history, status (updated, obsoleted,
   etc.), document categories (standard, draft standard, bcp, individual
   submission etc.)

   Discussion: The RFC Editor maintains the catalog.  The RFC editor is
   also responsible for the permanent archival of specifications.  Meta
   information associated with an RFC should also be maintained.  Since
   this is the definitive archive, sufficient security should be in
   place to prevent tampering with approved documents.

   o  Current Req-INDEX-1 - The IETF technical publisher should maintain
      the index of all IETF published documents.

   o  Current Req-INDEX-2 - The IETF technical publisher should provide
      the permanent archive for published documents.

   o  Current Req-INDEX-3 - Meta information associated with a published
      document must be stored and updated as its status changes.

   o  Current Req-INDEX-4 - The archive must be sufficiently secure to
      prevent the modification of published documents by external
      parties.

   o  Potential Req-INDEX-5 - The IETF technical publisher should
      provide the permanent archival of any source documents associated
      with a published specification.

   o  Current Req-INDEX-6 - The IETF can indicate to the publisher that
      it should change the status of a document (e.g., to Historical)
      and this should be reflected in the index.


Mankin & Hayes            Expires September 4, 2006                 [Page 15]

Internet-Draft          draft-mankin-techspec-pubreq-05             March 2006


   o  Potential Req-INDEX-7 - When an permanent ID is allocated early,
      the technical publisher must provide a disclaimer and pointer in
      the index to resolve searches on that permanent ID.  The post
      approval version of the draft must be stored until the document
      is published since it could expire before publication.

3.17. Access to Published Documents

   Task Description: The technical publisher should facilitate access to
   the documents published.  It is assumed that the technical publisher
   will provide online tools to search for and find information within
   the archive of published documents.  These access tools should
   facilitate understanding the state of the document (identification of
   replacement or updated documents, linkage to pertinent errata)

   Discussion: Documents and status may be accessed via the RFC Editor's
   web page

   Derived Requirements:

   o  Current Req-PUBACCESS-1 - The IETF technical publisher should
      provide search tools for finding published documents

   o  Current Req-PUBACCESS-2 - The IETF technical publisher tool should
      return relevant meta information associated with a published
      document (e.g., category of document, type of standard (if
      standards track), obsoleted by or updated by information,
      associated errata)

   o  Potential Req-PUBACCESS-3  - The IETF Technical Publication search
      tools should be integrated with the IETF search tools.

3.18. Maintenance of a Vocabulary Document

   Task Description: Some standards organizations require the technical
   publisher to maintain a vocabulary document or database containing
   common terms and acronyms. The goal is provide consistency of
   terminology between documents.

   Discussion: The RFC Editor does not maintain a document or database
   of terms or acronyms.

   Derived Requirements: none






Mankin & Hayes            Expires September 4, 2006                 [Page 16]

Internet-Draft          draft-mankin-techspec-pubreq-05             March 2006


3.19. Providing Publication Statistics and Status Reports

   Task Description: The technical publisher may be required to
   periodically or continuously measure their performance.  In many
   standards organizations performance targets are set in terms of
   timeliness, throughput, etc.

   Discussion: The IETF technical publisher currently provides monthly
   statistics on arrivals and completions of documents by category.  In
   addition a status report is provided at each IETF meeting.

   Derived Requirements:

   o  Current Req-STATS-1 - The IETF technical publisher should provide
      monthly statistics on average queue times and documents processed
      sorted by category of document.

   o  Current Req-STATS-2 - The IETF technical publisher should provide
      periodic status reports to the IETF meetings to apprise the
      community of their work and performance.

3.20. Process and Document Evolution

   Task Description: The guidelines and rules for an organization's
   publication output will change over time.  New sections will be added
   to documents, styles and conventions will change, boilerplate will be
   changed, etc.  Similarly, the specific processes for publication of a
   specification will change.  The technical publisher is expected to be
   involved in these discussions and accommodate these changes as
   required.

   Discussion: Over time, the IETF consensus on what should be in a
   published document has changed.  Such changes are likely to continue
   in the future.  The RFC editor has been involved in such discussions
   and provided guides, policies, faqs, etc. to document the current
   expectations on published documents.

   Derived Requirements:

   o  Current Req-PROCESSCHG-1 - The IETF technical publisher should
      participate in the discussions of changes to author guidelines and
      publication process changes.

3.21. Tutorial and Help Services

   Task Description: The technical publisher may be required to provide
   tutorials, mentoring, help-desks, online tools, etc. to facilitate


Mankin & Hayes            Expires September 4, 2006                 [Page 17]

Internet-Draft          draft-mankin-techspec-pubreq-05             March 2006


   smooth interaction with the technical publisher and IETF community
   awareness of document guidelines, procedures, etc.  In many
   organizations the publisher maintains a style manual giving explicit
   guidance to authors on how to write a specification.

   Discussion: Guidelines are provided to the authors on how to write a
   RFC as well as occasional tutorial presentations.  The RFC Editor
   provides a help desk at IETF meetings.

   Derived Requirements:

   o  Current Req-PUBHELP-1 - The IETF technical publisher should
      provide and maintain documentation giving guidance to authors on
      the layout, structure, expectations, etc. required to develop
      documents suitable for publication.

   o  Current Req-PUBHELP-2 - The IETF technical publisher should
      provide tutorials to the IETF community to educate authors on the
      processes and expectations of the IETF technical publisher.

4. Technical Publisher Performance Metrics

   A Technical Publisher is typically measured not only on what they do
   but how well they perform the tasks.  Here are some metrics that
   could apply to the IETF technical publisher.

   1. Post-approval timelines

   2. Publication throughput

   3. Non author changes generated during publication

   4. Author changes generated during publication

4.1. Post-approval timeframes

   Metric Description: This is a statistical measure of the time from
   entry into the RFC editor queue (via IESG approval, individual
   submission, etc.) until the documents are published.  The statistics
   should be separated by categories of documents.  It may be desirable
   to also provide statistics along the distribution curve (90%
   completed within x weeks, 95% completed within y weeks, etc.)

   Discussion: Long publication times create both internal and external
   difficulties.  Internal difficulties include the migration of authors
   to other activities and the accumulation of tempting post-approval
   fixes to be added to the document.  External difficulties include the


Mankin & Hayes            Expires September 4, 2006                 [Page 18]

Internet-Draft          draft-mankin-techspec-pubreq-05             March 2006


   inability of other standards organizations to reference IETF
   publications for lack of a RFC number.

   Derived Requirements:

   o  Potential Req-TIMEFRAMES-1 - The IETF technical publisher should
      have a goal of an average publication time of no more than 4
      weeks and at least 90% of all documents should be published
      within 8 weeks. Documents held up due to references or due to a
      protocol action should be excluded from this statistic.

   o  Potential Req-TIMEFRAMES-2 - For those documents for which early
      allocation of an identifier is requested, The IETF technical
      publisher should have a goal of an average allocation time of no
      more than 1 week and at least 90% of early allocation documents
      should have a stable identifier allocated within 2 weeks of
      approval. Allocation implies being able to resolve the reference
      in the index. Documents held up due to references or due to a
      protocol action should be excluded from this statistic.

   o  Potential Req-TIMEFRAMES-3 - The IETF technical publisher should
      have a goal of an average time for completing the pre-approval
      editorial review of no more than 10 days and at least 90% of all
      documents should be reviewed within 15 days.  The review interval
      starts when the editorial review is requested and ends when the
      review results are provided

   NOTE: The values given in this section represent targets desired by
   the IETF community. It is understood that the actual values are
   subject to negotiation and will be determined as part of contractual
   agreements.

4.2. Publication Throughput

   Metric Description: The count of documents published during a given
   time period.  Some publishers also provide the data in terms of pages
   produced.  The counts should be separated by categories of documents.

   Discussion: The RFC currently provides monthly statistics on the
   arrival and completion of documents onto the RFC queue.  This is
   sorted by category of document.

   Derived Requirements:






Mankin & Hayes            Expires September 4, 2006                 [Page 19]

Internet-Draft          draft-mankin-techspec-pubreq-05             March 2006


   o  Current Req-THROUGHPUT-1 - The IETF technical publisher should
      provide monthly reports giving RFC queue arrivals, completions,
      and documents on the queue sorted by document source of the
      document (IAB, IESG, individual submission)

   o  Potential Req-THROUGHPUT-2 - The IETF technical publisher should
      indicate the number of documents in each state at the end of each
      month sorted by document source category.

4.3. Non author changes Generated during Publication

   Metric Description: To judge the effectiveness of the editorial
   review and comment resolution, it is useful to provide aggregate
   statistics on post approval changes generated (separated by type of
   error) as well as the resolution of the comments (% rejected)

   Discussion: To understand trends in the types of errors occurring and
   how editing effort is being expended, it is useful to gather
   aggregate statistics on the types of errors being uncovered by the
   editors.

   Derived Requirements:

   o  Potential Req-EDITCHGSTATS-1 - The IETF technical publisher should
      provide monthly statistics on the types of editorial corrections
      being found during reviews as well as the percent of corrections
      which are rejected by the authors.

4.4. Author changes generated during publication

   Metric Description: To judge the stability of documents during the
   publication process it is desirable to provide aggregate statistics
   on the number and type of changes introduced by the authors after
   document approval.

   Discussion: This provides a measure of the stability of the documents
   and can indicate if the delays in publication are leading to
   excessive changes in the documents.

   Derived Requirements:

   o  Potential Req-AUTHCHGSTATS-1 - The IETF technical publisher should
      provide monthly statistics on author requested changes to
      documents under publication.





Mankin & Hayes            Expires September 4, 2006                 [Page 20]

Internet-Draft          draft-mankin-techspec-pubreq-05             March 2006


5. IETF Implications of Technical Publication Requirements

   Requirements on technical publication process have so far been stated
   in terms of requirements on the technical publisher.  However it must
   be recognized that many of these requirements have implications on
   the processes and tools within the IETF itself.  It is anticipated
   that these processes will be documented in companion documents which
   will be generated by various bodies within the IETF.

   The following is a list of potential issues that must be addressed
   within the IETF depending on the requirements selected for the
   technical publisher:

   o  Pre- vs Post-Approval Editing: If emphasis switches from post-
      approval editing to pre-approval editing, then IETF processes must
      be adapted to make use of this service.  The processes for post-
      approval editing can also be streamlined.

   o  Approval of post-approval, pre-publication technical corrections:
      Since the technical publisher can only accept approved changes, it
      must be clear who is allowed to approve technical changes.  This
      process within the IETF needs to be decided and documented.

   o  Allocation of Permanent Stable Identifiers: IETF needs to clearly
      identify the naming/numbering schemes and classes of documents to
      which those names and numbers apply.  Furthermore, the
      responsibility for allocation of those names/numbers needs to be
      identified.

   o  Early allocation of Permanent Stable Identifiers: If early
      allocation of permanent stable identifiers is agreed as a
      requirement, then the IETF processes must be adapted to either
      generate or use these early identifiers.

   o  Exception Handling: If publication timelines can be reduced
      sufficiently or permanent identifiers allocated early, then
      expedited handling may no longer be needed.

   o  Post Publication Corrections: Appropriate processes must be
      defined with the IETF to ensure that errata is appropriately
      vetted and authorized.

   o  Indexing: Appropriate processes must be defined within the IETF
      to decide and inform the technical publisher of status changes to
      published documents as the result of an appeal, legal action, or
      some other procedural action.



Mankin & Hayes            Expires September 4, 2006                 [Page 21]

Internet-Draft          draft-mankin-techspec-pubreq-05             March 2006


   It is expected that as decisions are made on the technical
   publication requirements, that this section will expand to include
   any associated requirements on the IETF processes.

6. IANA Considerations

   Any new requirements that result from this discussion need to be
   reviewed by IANA and the IETF to understand to what extent, if any,
   the work flow of the documents through IANA are affected.

   Interactions with IANA on parameter validation is discussed in
   section 3.6.

7. Security Considerations

   There is a tussle between the sought-for improvements in readability
   and the specific language that has often been negotiated carefully
   for the security content of IETF documents.  As with other text,
   extreme caution is needed in modifying any text in the security
   considerations.  This issue is assumed to have been dealt with under
   the section 3.3.

   The processes for the publication of documents must prevent the
   introduction of unapproved changes (see section 3.7).  Since the IETF
   publisher maintains the index of publications, sufficient security
   must be in place to prevent these published documents from being
   changed by external parties (see section 3.16)

8. Acknowledgments

   Bert Wijnen has provided input on the early copy edit experiment and
   made useful comments throughout the document.  Leslie Daigle has
   contributed strongly to this text.  Steve Barclay, John Meredith,
   Yvette Ho Sang, and Sami Trabulsi for discussions of the publication
   practices of ATIS, ETSI, IEEE, and ITU.  Other acknowledgements to
   date: a discussion on the wg chairs mailing list, Henning
   Schulzrinne, Henrik Levkowetz.

9. Informative References

   [1]   Reynolds, J. and Braden, R., "Instructions to Request for
         Comments (RFC) Authors", draft-rfc-editor-rfc2223bis-08 (work
         in progress), August 2004

   [2]   Levkowetz, H. and D. Meyer, "The PROTO Process: Working Group
         Chair Document Shepherding", draft-ietf-proto-wgchair-doc-
         shepherding-05 (work in progress), March 2005


Mankin & Hayes            Expires September 4, 2006                 [Page 22]

Internet-Draft          draft-mankin-techspec-pubreq-05             March 2006




Author's Addresses

   Allison Mankin
   Shinkuro, Inc.
   1025 Vermont Avenue
   Washington, DC 20005
   USA

   Phone: +1 301 728 7199
   Email: mankin@psg.com
   URI: http://www.psg.com/~mankin/


   Stephen Hayes
   Ericsson
   3634 Long Prairie Rd.
   Ste 108-125
   Flower Mound, TX 75022
   USA

   Phone: +1 469 360 8500
   Email: stephen.hayes@ericsson.com


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement


Mankin & Hayes            Expires September 4, 2006                 [Page 23]

Internet-Draft          draft-mankin-techspec-pubreq-05             March 2006


   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org

Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Copyright Statement

   Copyright (C) The Internet Society (2006).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.
























Mankin & Hayes            Expires September 4, 2006                 [Page 24]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/