doc: Add RFC documents

1 files changed, 1347 insertions, 0 deletions

diff --git a/doc/rfc/rfc4714.txt b/doc/rfc/rfc4714.txt
new file mode 100644
index 0000000..5639cba
--- /dev/null
+++ b/doc/rfc/rfc4714.txt
@@ -0,0 +1,1347 @@
+
+
+
+
+
+
+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: 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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+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
+   ietf-ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Mankin & Hayes               Informational                     [Page 24]
+