summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc4714.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc4714.txt')
-rw-r--r--doc/rfc/rfc4714.txt1347
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]
+