Network Working Group                                          A. Mankin
Request for Comments: 4714
Category: Informational                                         S. Hayes
                                                               Ericsson
                                                           October 2006


         Requirements for IETF Technical Publication Service

Status of This Memo

  This memo provides information for the Internet community.  It does
  not specify an Internet standard of any kind.  Distribution of this
  memo is unlimited.

Copyright Notice

  Copyright (C) The Internet Society (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               Informational                      [Page 1]

RFC 4714         IETF Technical Publisher Requirements      October 2006


Table of Contents

  1. Introduction ....................................................2
  2. Scope ...........................................................3
     2.1. Stages in the Technical Specification Publication
          Lifetime ...................................................4
  3. Technical Publication Tasks and Requirements ....................5
     3.1. Pre-approval Review or Editing .............................6
     3.2. Preliminary Specification Availability .....................6
     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. Insertion of Parameter Values .............................10
     3.7. Post-approval, Pre-publication Technical Corrections ......10
     3.8. Allocation of Permanent Stable Identifiers ................11
     3.9. Document Format Conversions ...............................12
     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 (errata) ....................15
     3.16. Indexing: Maintenance of the Catalog .....................15
     3.17. Access to Published Documents ............................16
     3.18. Maintenance of a Vocabulary Document .....................17
     3.19. Providing Publication Statistics and Status Reports ......17
     3.20. Process and Document Evolution ...........................18
     3.21. Tutorial and Help Services ...............................18
     3.22. Liaison and Communication Support ........................19
  4. Technical Publisher Performance Goals ..........................20
     4.1. Publication Timeframes ....................................20
     4.2. Publication Throughput ....................................21
  5. IETF Implications of Technical Publication Requirements ........21
  6. IANA Considerations ............................................22
  7. Security Considerations ........................................22
  8. Acknowledgements ...............................................23
  9. Informative References .........................................23

1.  Introduction

  The work of the IETF is to discuss, develop, and disseminate
  technical specifications to support the Internet's operation.
  Therefore, an important output of the IETF 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.



Mankin & Hayes               Informational                      [Page 2]

RFC 4714         IETF Technical Publisher Requirements      October 2006


  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 otherwise,
  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.  It is
  expected to be used in the preparation of future contracts.  This
  document is not a discussion of how well the current technical
  publisher (the RFC Editor) fulfills those requirements.

2.  Scope

  The scope of this document is the requirements for the technical
  publication process for the 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.  The functions provided by the
  technical publisher are sometimes referred to as editorial management
  [RFC2850].

  This document specifically addresses those documents published by the
  IETF technical standards process.  In all cases, the requirements
  have been written in generic terms, so that they may be used to
  express the requirements of other publication streams, elsewhere.

  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.

  This requirements document focuses on process issues in how the IETF
  technical publisher 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.)



Mankin & Hayes               Informational                      [Page 3]

RFC 4714         IETF Technical Publisher Requirements      October 2006


  It is realized that the above policies are also important aspects in
  determining that the final published document is a product of the
  IETF.  These policies are likely to evolve as part of the ongoing
  IETF dialog.  The IETF technical publisher should 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
  standards process.  This figure shows a Working Group (WG) document
  and the reviews including Working Group Last Call (WGLC), Area
  Director (AD) review, IETF Last Call (IETF LC), IANA review, and IESG
  review.  The document shepherd (shown in the diagram as "Shepherd")
  is an individual designated by the IESG to shepherd a document
  through the reviews and the publication process and is often not an
  AD.  The lifetime is very similar for AD-sponsored IETF documents,
  such as documents that update IETF protocols for which there is no
  longer a working group, or documents on interdisciplinary topics.

             Actors      Formal       Actors            Actors
                         Reviews

          |  Author,   | WGLC      | IESG,      |    |  IANA,
          |  Editor,   | AD        | Shepherd,  |  A |  Tech
          |  IETF Sec- | IETF LC   | Editor,    |  P |  Publisher,
          |  retariat  | IANA      | WG,        |  P |  input from
          |            | IESG      | AD         |  R |  authors, et al.
          |            |           |            |  O |
  Actions |  Creation, |           | Resolution |  V |  Non-author
          |  Editing,  |           | of all     |  A |  editing,
          |  Draft Pub,|           | reviews    |  L |  other
          |  Tracking  |           |            |    |  publication

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

               In WG               Out of WG          Post-approval

              Figure 1: Stages of a Working Group Document

  Note that in some cases a single submission may actually consist of
  multiple source documents (supporting files, code, etc.).

  Under the IETF standards process stream, the post-approval processing
  is initiated by the IESG after technical approval.



Mankin & Hayes               Informational                      [Page 4]

RFC 4714         IETF Technical Publisher Requirements      October 2006


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.

  1.  Pre-approval review or editing

  2.  Preliminary specification availability

  3.  Post-approval editorial cleanup (non-author editing)

  4.  Validation of references

  5.  Validation of formal languages

  6.  Insertion of parameter values

  7.  Post-approval, pre-publication technical corrections

  8.  Allocation of permanent stable identifiers

  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




Mankin & Hayes               Informational                      [Page 5]

RFC 4714         IETF Technical Publisher Requirements      October 2006


  20. Process and document evolution

  21. Tutorial and help services

  22. Liaison and communication support

  For each of these tasks, we discuss its relevance to the IETF and how
  it is realized within the IETF processes.  Based upon this
  information, we derive requirements on the IETF technical publisher.

3.1.  Pre-approval Review or Editing

  Task Description: This provides 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 pre-approval boilerplate, document
  structure, etc.

  Discussion: Pre-approval review is not part of the current IETF
  standards process, but this concept has been explored in the early
  copyediting experiment.  Early feedback from the experiment has been
  promising; however, the effectiveness of early editing is still being
  evaluated.

  Derived Requirements:

  Req-PREEDIT-1: The IETF technical publisher should be capable of
  performing an editorial review of documents early enough to allow
  changes to be reviewed within the technical review process, should
  the IETF choose to implement pre-approval editing.  For the IETF
  standards process stream, this review should be performed before WG
  Last Call and provide feedback to the authors to improve the quality
  of the documents.  For the IETF standards process stream, the
  publisher should not perform a technical review of the document.

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.








Mankin & Hayes               Informational                      [Page 6]

RFC 4714         IETF Technical Publisher Requirements      October 2006


  Discussion: This is not required.  A final approved version is
  available as an internet draft.  If publication can take more than 6
  months, it may be necessary to request that 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, etc.  Since any
  proposed changes occur after approval, a review and signoff mechanism
  should 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-on text.

  Discussion: Within the 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, to

  o  rewriting of all documents to the dictates of a style manual.

  At times in the past year, stylistic editing has resulted in a
  substantial number of 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.

  In specific instances, it may be necessary to require that text be
  published "verbatim" even if doing so introduces what is perceived as




Mankin & Hayes               Informational                      [Page 7]

RFC 4714         IETF Technical Publisher Requirements      October 2006


  poor readability or stylistic inconsistency.  Examples of this
  include:

  -  "Boilerplate" agreed on in an IETF working group to apply to all
     instances of derivative works (e.g., IANA registration documents
     and Management Information Bases (MIBs)).

  -  Text referring to other organizations' work that has been
     carefully phrased and arranged with representatives of that other
     organization to deal with some politically sensitive issue.

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

  Derived Requirements:

  o  Req-POSTEDIT-1 - The IETF technical publisher should review the
     document for grammar, spelling, formatting, alignment with
     boilerplate, document structure, etc.  The review should strive to
     maintain consistency in appearance with previously published
     documents.  In the IETF standards process stream, the publisher
     should not perform a technical review of the document.

  o  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.  For the IETF standards
     process stream, this includes the authors, the document shepherd
     (if there is one), and the Area Director.  The Area Director is
     the authority for approval of all changes.

  o  Req-POSTEDIT-3 - The IETF technical publisher should exercise
     restraint in making stylistic changes that introduce a substantial
     review load but only provide an 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  Req-POSTEDIT-4 - The IETF technical publisher should exercise
     restraint in making 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               Informational                      [Page 8]

RFC 4714         IETF Technical Publisher Requirements      October 2006


  o  Req-POSTEDIT-5 - In specific instances, where some or all of
     document text is the result of a careful negotiation of
     contributions (within or between working groups, reviewers, etc.),
     the technical publisher may be required to publish that text
     verbatim.  In the IETF standards process, verbatim publication may
     be requested by the IESG.  It is the expectation of the IETF
     community that this will not be done often.

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 (including referenced
  clauses and figures).  Although some editorial cleanup 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 while waiting
  for the availability of other IETF documents.  Incorrect references
  are handled like any other fault detected in the editorial review.

  Derived Requirements:

  o  Req-REFVAL-1 - The IETF technical publisher should ensure that all
     references within specifications are currently available and are
     expected to remain available.

  o  Req-REFVAL-2 - The IETF technical publisher should delay
     publication until all required (normative) 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 syntactically validates sections of a
  document containing MIBs, Augmented Backus Naur Form (ABNF),
  eXtensible Markup Language (XML), Abstract Syntax Notation One
  (ASN.1), and possibly other formal languages.






Mankin & Hayes               Informational                      [Page 9]

RFC 4714         IETF Technical Publisher Requirements      October 2006


  Derived Requirements:

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

3.6.  Insertion of Parameter Values

  Task Description: The technical publisher is expected to work with
  IANA (or possibly other organizations maintaining registries) to
  populate assigned protocol parameter values when required, prior to
  publication.  The population of these parameters values should not
  require technical expertise by the technical publisher.

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

  Derived Requirements:

  o  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 post-publication errata would be treated.  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 (see
  Section 3.13).

  Discussion: The IETF allows minor technical corrections during the
  publication process.  This should ideally be a rare occurrence.
  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.




Mankin & Hayes               Informational                     [Page 10]

RFC 4714         IETF Technical Publisher Requirements      October 2006


  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  Req-POSTCORR-1 - The IETF technical publisher should permit the
     incorporation of technical changes detected after approval but
     pre-publication.

  o  Req-POSTCORR-2 - The IETF technical publisher should only allow
     post-approval technical changes that have been approved by the
     appropriate party.  In the IETF standards process stream, this
     includes the authors and the Area Director.  The document shepherd
     (if there is one) should be kept informed of these changes.

  o  Req-POSTCORR-3 - The IETF technical publisher should alert the
     appropriate authority when it feels that a requested change is
     suspect (e.g., an unapproved technical alteration) or unreasonable
     (e.g., massive editorial changes).  Further processing of the
     draft should be suspended pending a response by that authority.
     For the IETF standards process stream, that authority is the Area
     Director.  If there is a document shepherd working with the Area
     Director, the shepherd should be notified and kept informed as
     well.

  o  Req-POSTCORR-4 - The IETF technical publisher should ensure that
     any source documents associated with a publication are updated in
     conjunction 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 organizations, 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 RFC numbers and other
  identifiers (the current IETF stable identifiers) when the document
  is near the end of the publication process.  Having identifiers
  allocated early was considered, but a definite need could not be
  established.

  Derived Requirements:

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




Mankin & Hayes               Informational                     [Page 11]

RFC 4714         IETF Technical Publisher Requirements      October 2006


  o  Req-PERMID-2 - The IETF technical publisher should assign
     additional permanent identifiers associated with various classes
     of documents as directed by the appropriate authority.  For the
     IETF standards process stream, that authority is the IESG.

3.9.  Document Format Conversions

  Task Description: The technical publisher is responsible for
  converting the documents into one or more output formats (e.g., text,
  Portable Document Format (PDF)).  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.

  Discussion: Currently, the RFC Editor accepts input as an ASCII text
  file.  The RFC Editor has also accepted supplementary formats that
  were used to generate the ASCII text (XML and NROFF).  The documents
  are published as ASCII text and PDF files.

  Derived Requirements:

  o  Req-DOCCONVERT-1 - The IETF technical publisher should accept as
     input ASCII text files and publish documents as ASCII text files
     and PDF files.

  o  Req-DOCCONVERT-2 - The technical publisher should accept
     supplemental files that may contain information such as code,
     formal descriptions (e.g., XML, ASN.1) graphics, data files, etc.
     Supplemental files may also include enhanced versions of the
     document containing graphics or sections not presentable in text
     format.  Any supplemental files, barring any changes to the IETF
     process rules, will be associated with the published IETF
     documents, but may not be editable by the publisher.

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



Mankin & Hayes               Informational                     [Page 12]

RFC 4714         IETF Technical Publisher Requirements      October 2006


  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 (e.g.,
  AUTH48, RFC-EDITOR, IANA, ISR).  Items may stay in 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
  Process and Tools (PROTO) team is considering requirements for
  marking the token-holder accurately during long waiting periods, and
  others are looking into improved notification tools.  Requirements on
  the IETF technical publisher for improved status integration and
  visibility could be met by collaborations with these efforts, by
  providing public access to email logs regarding publications, or by
  some other proposal.

  Derived Requirements:

  o  Req-STATUSTRK-1 - The IETF technical publisher should make state
     information publicly available for each document in the
     publication process.  It is desirable that this information be
     available through a documented interface to facilitate tools
     development.

  o  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.  For the documents in the IETF
     standards process stream, it is expected that documents should be
     able to move seamlessly from the IETF standards tracking system
     into the technical publication tracking system.

  o  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 expedited publication of a
  document.  Ideally, this should not skip any of the publication
  steps, but allocates it higher priority in the work queue to ensure
  earlier publication than normal.  Expedited publication should be
  used sparingly since as with any priority scheme, overuse will negate
  its benefits.




Mankin & Hayes               Informational                     [Page 13]

RFC 4714         IETF Technical Publisher Requirements      October 2006


  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 Editor's queue.  Having short publication times would likely
  reduce the need for fast-tracking.

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

  Derived Requirements:

  o  Req-EXPEDITE-1 - The IETF technical publisher should expedite the
     processing of specific documents at the request of an appropriate
     authority.  For the IETF standards process stream, that authority
     is the IESG or the IAB.

3.13.  Exception Handling

  Task Description: It should be possible for various reasons for a
  document to be withdrawn from publication or the publication to be
  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  Req-EXCEPTIONS-1 - The IETF technical publisher should permit
     documents to be withdrawn from publication at the direction of an
     appropriate authority.  For the IETF standards process stream,
     that authority is the IESG.

  o  Req-EXCEPTIONS-2 - The IETF technical publisher should permit
     documents to be put on hold awaiting the outcome of an appeal at
     the direction of an appropriate authority.  For the IETF standards
     process stream, that authority is the IESG.

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.





Mankin & Hayes               Informational                     [Page 14]

RFC 4714         IETF Technical Publisher Requirements      October 2006


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

  Derived Requirements:

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

3.15.  Post-publication Corrections (errata)

  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.

  Derived Requirements:

  o  Req-ERRATA-1 - The IETF technical publisher should maintain errata
     for published documents.  The process for review, updating, and
     approval of errata for IETF documents will be defined by the IETF.

  o  Req-ERRATA-2 - The IETF technical publisher should provide
     information on relevant errata as part of the information
     associated with an 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
  the maintainer of the database of published documents.  This also
  includes the cataloging and storage of meta-information associated
  with documents such as their history, status (e.g., updated,
  obsoleted), document categories (e.g., standard, draft standard,
  BCP).

  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.






Mankin & Hayes               Informational                     [Page 15]

RFC 4714         IETF Technical Publisher Requirements      October 2006


  Derived Requirements:

  o  Req-INDEX-1 - The IETF technical publisher should maintain the
     index of all IETF published documents.  It is desirable that the
     interface to the index be documented to facilitate tools
     development.

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

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

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

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

  o  Req-INDEX-6 - An appropriate authority 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.  For the
     IETF standards process stream, the indicating authority is the
     IESG.

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 (e.g.,
  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  Req-PUBACCESS-1 - The IETF technical publisher should provide
     search tools for finding and retrieving published documents.

  o  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




Mankin & Hayes               Informational                     [Page 16]

RFC 4714         IETF Technical Publisher Requirements      October 2006


     track), obsoleted by or updated by information, associated
     errata).

  o  Req-PUBACCESS-3  - The IETF technical publication search tools
     should be integrated with the IETF search tools.  For the IETF
     standards process stream, this refers to integration with the
     search tools used by the IETF standards process.

3.18.  Maintenance of a Vocabulary Document

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

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

  Derived Requirements: none

3.19.  Providing Publication Statistics and Status Reports

  Task Description: The technical publisher may be required to
  periodically or continuously measure its 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.  Other
  statistics can be used to judge the health of the editing process.
  Many of these statistics could be gathered using sampling techniques
  to avoid excessive load on the technical publisher.

  Derived Requirements:

  o  Req-STATS-1 - The IETF technical publisher should provide publicly
     available monthly statistics on average queue times and documents
     processed.  The presentation should provide a historical context
     to identify trends (see Goal-THROUGHPUT-1).  For the IETF
     standards process, this should include queue arrivals,
     completions, documents in the queue, and the number of documents
     in each state at the end of the month.

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




Mankin & Hayes               Informational                     [Page 17]

RFC 4714         IETF Technical Publisher Requirements      October 2006


  o  Req-STATS-3 - The IETF technical publisher should provide publicly
     available monthly statistics on the types of editorial corrections
     being found during reviews as well as the percentage of
     corrections that are rejected by the authors.

  o  Req-STATS-4 - The IETF technical publisher should provide publicly
     available monthly statistics on author-requested changes to
     documents under publication.  This statistic should also include
     changes required by other authorities outside of the technical
     publisher empowered to make changes.  For the IETF standards
     process, the designated authority would be the IESG or its
     designees.

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.  Processes interfacing with the
  publisher have also 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  Req-PROCESSCHG-1 - The IETF technical publisher should participate
     in the discussions of changes to author guidelines and publication
     process changes.

  o  Req-PROCESSCHG-2 - The IETF technical publisher should participate
     in and support process experiments involving the technical
     publication process.

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
  smooth interaction with the technical publisher and to increase the
  IETF community's 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.



Mankin & Hayes               Informational                     [Page 18]

RFC 4714         IETF Technical Publisher Requirements      October 2006


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

  Derived Requirements:

  o  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.  For the IETF standards process stream,
     the technical publisher should follow IESG guidance in specifying
     documentation guidelines.

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

  o  Req-PUBHELP-3 - The IETF technical publisher should provide a
     contact email address and correspond as required to progress the
     publication work.  The publisher should address queries from both
     inside and outside of the IETF community.

  o  Req-PUBHELP-4 - The IETF technical publisher should provide a help
     desk at IETF meetings.

3.22.  Liaison and Communication Support

  Task Description: It is very valuable for the technical publisher of
  an organization to have good information and communication about the
  work streams that will result in publication streams.  In order to
  ensure a wide communication channel for the work, the technical
  publisher holds a liaison position on the IESG, where there can be
  valuable give-and-take about matters concerning the IETF standards
  stream.

  Discussion: The RFC Editor currently maintains a liaison position
  with the IESG.  Although not specifically addressed in these
  requirements, the RFC Editor also maintains a liaison position toward
  the IAB.

  Derived Requirements:

  o  Req-LIAISON-1 - Through a liaison participant, the technical
     publisher should take part in meetings and activities as required
     in order to be aware of ongoing activities related to the work
     streams.  For the IETF standards stream the technical publisher
     should participate in IESG formal meetings, IESG face-to-face
     activities at IETF, and other activities such as retreats.



Mankin & Hayes               Informational                     [Page 19]

RFC 4714         IETF Technical Publisher Requirements      October 2006


4.  Technical Publisher Performance Goals

  Technical publishers are typically measured not only on what they do
  but how well they perform the tasks.  The expectations in this
  section are treated as goals instead of requirements because:

  -  Achieving a given level of performance is not totally under the
     control of the technical publisher.  Publication is a process and
     the goals are of the process, not just the publisher.

  -  The actual performance objectives will be set contractually.  The
     values herein represent values that the IETF community feels are
     desirable and reasonable for work progress without consideration
     of financial or other factors.

  Goals are set forth in the following areas:

  1. Publication timeframes

  2. Publication throughput

4.1.  Publication Timeframes

  Goal Description: This is a measure of the time from entry into the
  RFC Editor queue until the documents are published.  The metrics are
  defined in (req-STATS-1).

  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
  inability of other standards organizations to reference IETF
  publications for lack of an RFC number.

  Derived Goals:

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

  o  Goal-TIMEFRAMES-2 - The consensus of the IETF community is that
     the time required for a pre-approval review should be under 10
     days.  The actual performance targets and metrics are expected to
     be determined as part of the contract negotiation process.




Mankin & Hayes               Informational                     [Page 20]

RFC 4714         IETF Technical Publisher Requirements      October 2006


4.2.  Publication Throughput

  Goal Description: The number of documents published during a given
  time period is a measure of publisher throughput.  Some publishers
  also provide the data in terms of pages produced.  The counts should
  be separated by categories of documents.  The metrics are defined in
  (req-STATS-1).

  Discussion: The RFC Editor currently provides monthly statistics on
  the arrival and completion of documents into the RFC queue.  This is
  sorted by category of document.  This provides a measure of the
  delays in the publication process.

  Derived Goals:

  o  Goal-THROUGHPUT-1 - Although minor variations are expected, there
     should be no long-term growth trend in the length of the
     publication queue.  The actual performance targets and metrics are
     expected to be determined as part of the contract negotiation
     process.

5.  IETF Implications of Technical Publication Requirements

  Requirements on the 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 for the processes and tools within the IETF itself.  It
  is anticipated that these processes will be documented in companion
  documents.

  The following is a list of potential issues that should be addressed
  within the IETF based on the requirements applied to 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  Post-approval Editorial Cleanup: The IETF must define under what
     conditions the publisher should be instructed to bypass or
     minimize post-approval editing.

  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.




Mankin & Hayes               Informational                     [Page 21]

RFC 4714         IETF Technical Publisher Requirements      October 2006


  o  Allocation of Permanent Stable Identifiers: The 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  Expedited Handling: If publication timelines can be reduced
     sufficiently, then expedited handling may no longer be needed.

  o  Post-publication Corrections: Appropriate processes must be
     defined with the IETF to ensure that errata are 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.

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 is affected.

  Interactions with IANA on population of parameter values 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
  Section 3.3.

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










Mankin & Hayes               Informational                     [Page 22]

RFC 4714         IETF Technical Publisher Requirements      October 2006


8.  Acknowledgements

  Bert Wijnen has provided input on the early copyedit experiment and
  made useful comments throughout the document.  Leslie Daigle has
  contributed strongly to this text.  Thanks to 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, and Henrik Levkowetz.

9.  Informative References

  [RFC2850] Internet Architecture Board and B. Carpenter, "Charter of
            the Internet Architecture Board (IAB)", BCP 39, RFC 2850,
            May 2000.

Authors' Addresses

  Allison Mankin
  Bethesda, MD
  USA

  Phone: +1 301 728 7199
  EMail: [email protected]
  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: [email protected]















Mankin & Hayes               Informational                     [Page 23]

RFC 4714         IETF Technical Publisher Requirements      October 2006


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

  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.

Intellectual Property

  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
  this standard.  Please address the information to the IETF at
  [email protected].

Acknowledgement

  Funding for the RFC Editor function is provided by the IETF
  Administrative Support Activity (IASA).







Mankin & Hayes               Informational                     [Page 24]