doc: Add RFC documents

1 files changed, 1011 insertions, 0 deletions

diff --git a/doc/rfc/rfc8153.txt b/doc/rfc/rfc8153.txt
new file mode 100644
index 0000000..d21e725
--- /dev/null
+++ b/doc/rfc/rfc8153.txt
@@ -0,0 +1,1011 @@
+
+
+
+
+
+
+Internet Architecture Board (IAB)                            H. Flanagan
+Request for Comments: 8153                                    RFC Editor
+Category: Informational                                       April 2017
+ISSN: 2070-1721
+
+
+         Digital Preservation Considerations for the RFC Series
+
+Abstract
+
+   The RFC Editor is both the publisher and the archivist for the RFC
+   Series.  This document applies specifically to the archivist role of
+   the RFC Editor.  It provides guidance on when and how to preserve
+   RFCs and describes the tools required to view or re-create RFCs as
+   necessary.  This document also highlights gaps in the current process
+   and suggests compromises to balance cost with best practice.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   This document is a product of the Internet Architecture Board (IAB)
+   and represents information that the IAB has deemed valuable to
+   provide for permanent record.  It represents the consensus of the
+   Internet Architecture Board (IAB).  Documents approved for
+   publication by the IAB are not a candidate for any level of Internet
+   Standard; see Section 2 of RFC 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc8153.
+
+Copyright Notice
+
+   Copyright (c) 2017 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.
+
+
+
+
+
+
+
+Flanagan                      Informational                     [Page 1]
+
+RFC 8153                  Digital Preservation                April 2017
+
+
+Table of Contents
+
+   1. Introduction ....................................................2
+      1.1. Terminology ................................................4
+      1.2. Life Cycle of Digital Preservation .........................4
+   2. Updating Policy and Procedure ...................................5
+      2.1. Acquisition of Documents ...................................6
+      2.2. Ingestion of Documents .....................................6
+      2.3. Metadata and Document Registration .........................7
+      2.4. Normalization and Standardization of Canonical File
+           Structure and Format .......................................9
+           2.4.1. 'Best Effort' Data Retention .......................10
+           2.4.2. Single Format for Archival Purposes ................11
+           2.4.3. Holistic Archiving of the Computing Environment ....12
+      2.5. Transformation/Migration to Current Publication Formats ...12
+      2.6. System Parameters .........................................13
+      2.7. Financial Impact ..........................................13
+   3. Recommendations ................................................14
+   4. Summary ........................................................15
+   5. IANA Considerations ............................................15
+   6. Security Considerations ........................................15
+   7. Informative References .........................................16
+   IAB Members at the Time of Approval ...............................18
+   Author's Address ..................................................18
+
+1.  Introduction
+
+   The RFC Editor is both the publisher and the archivist for the RFC
+   Series, a series of technical specifications and policy documents
+   that includes foundational Internet standards [RFC6635] [RFC-SERIES].
+   The goal of the RFC Editor is to is to produce clear, consistent, and
+   readable documents for the Internet community.  Over time, the RFC
+   Editor will use as many modern features, such as hyperlinks and
+   content markup, within the document as necessary to convey the
+   information the authors intended for their audience.  As the
+   archivist, however, the main goal is to preserve both the information
+   described and the documents themselves for the indefinite future.  To
+   meet both of these goals, the RFC Editor must find the necessary
+   balance between the publication needs of today and the archival needs
+   of tomorrow, while acknowledging a finite set of resources to
+   complete both aspects of the RFC Editor function.
+
+   While many files are created during the editing process, this
+   document focuses on the archival needs of the Internet-Drafts (I-Ds)
+   that were approved for publication and the RFCs that resulted from
+   these I-Ds; I-Ds before they are approved for publication by the
+   appropriate stream-approving body are out of scope.
+
+
+
+
+Flanagan                      Informational                     [Page 2]
+
+RFC 8153                  Digital Preservation                April 2017
+
+
+   To summarize, the key areas of tension between the roles of publisher
+   and archivist are:
+
+   o  the desire of the publisher to meet the needs expressed by authors
+      who want to use the latest technology (e.g., vector graphics, live
+      links, and a rich set of metadata) within their documents; and
+
+   o  the desire of the archivist to support only the simplest format
+      for documents possible -- currently held by the Series to be
+      plain-text, ASCII-only documents -- so that the tools needed to
+      view the documents are equally simple and resistant to changes in
+      technology, resulting in a set of documents that will be easier to
+      archive for at least the next several decades, if not centuries.
+
+   Through most of the history of the RFC Series, the file format for
+   RFCs has been plain text with an ASCII-only character set.  This
+   choice offered the simplest format likely to remain available to the
+   largest number of consumers and the format most likely to be
+   resistant to changes in technology over time.  Increasingly, however,
+   consumers and authors are requesting additional features that would
+   allow for easy reading on a wider array of devices while retaining
+   all the metadata authors intended in their documents.  In 2013, RFC
+   6949 ("RFC Series Format Requirements and Future Development")
+   captured the high-level requirements for the Series; the fundamental
+   issue was that plain-text, ASCII-only documents no longer meet the
+   needs of the communities interested in using and producing RFCs
+   [RFC6949].
+
+   The assertion that plain-text, ASCII-only documents no longer meet
+   the needs of the community suggests that the simple archival process
+   maintained by the RFC Editor is also no longer sufficient.  More
+   complex tools and file formats require a more complex process to
+   ensure that RFCs can be read and rendered far into the future.  This
+   document describes the considerations that must inform any changes in
+   policy and procedure, and it describes a model for the RFC Series to
+   follow when additional formats beyond plain-text, ASCII-only RFCs are
+   published.  The functional model that provides the framework for the
+   archival process described in this document was derived from the ISO
+   Open Archival Information System (OAIS) reference model, defined in
+   "Space data and information transfer systems -- Open archival
+   information system (OAIS) -- Reference model" [ISO14721].
+
+
+
+
+
+
+
+
+
+
+Flanagan                      Informational                     [Page 3]
+
+RFC 8153                  Digital Preservation                April 2017
+
+
+1.1.  Terminology
+
+   Acquisition: The point at which a document is accepted by the RFC
+   Editor for future inclusion into the archive.
+
+   Ingestion: The point at which a digital object is assigned all
+   necessary metadata to describe the object and its contents and is
+   added to the archive.
+
+   Bitstream preservation: The process of storing and maintaining
+   digital objects over time, ensuring that there is no loss or
+   corruption of the bits making up those objects.
+
+   Content preservation: The retention of the ability to read, listen,
+   or watch a digital file in perpetuity.  Content preservation is not
+   about the bits being stored; it is about being able to access and
+   present those bits to the user.
+
+1.2.  Life Cycle of Digital Preservation
+
+   The basic process for preserving digital information has been
+   described by a variety of organizations.  From the Life cycle
+   Information For E-Literature (LIFE) project [LIFE] in the United
+   Kingdom to the ongoing digital preservation work in the U.S. Library
+   of Congress [USLOC], the basic digital preservation process is
+   straightforward.  Documents are acquired and processed, metadata is
+   recorded, physical media is refreshed, and content is regularly
+   checked to see if it is still accessible by interested parties.
+   Complexities arise when one considers the need to preserve both the
+   bits of the digital objects themselves and the tools with which to
+   express those bits in an environment that experiences rapid changes
+   in technology.
+
+   For most of the existence of the RFC Series, the digital preservation
+   process has been fairly simple, focusing on bitstream preservation
+   and relying on paper copies of digital files.
+
+   The current archival process for the RFC Series is as follows:
+
+   1.  Acquisition: The RFC Editor database is updated to indicate an
+       I-D has been approved for publication.  At this point, the
+       document is taken through the editorial process on the way to
+       publication [RFC-PUB].
+
+   2.  Ingestion: The RFC is added to the archive at the time of
+       publication.
+
+
+
+
+
+Flanagan                      Informational                     [Page 4]
+
+RFC 8153                  Digital Preservation                April 2017
+
+
+   3.  Metadata creation: The details regarding an RFC, including RFC
+       number, author, title, abstract, etc., are created at time of
+       publication.  Additional metadata in the form of status and
+       errata can be added or changed at any time, following the process
+       of the originating document stream.
+
+   4.  Bitstream preservation: This part of the process is handled as
+       part of the IT system administration; all servers, disks, and
+       backup technology are refreshed on a regular cycle.
+
+   5.  Content preservation: All RFCs since January 2010 have been
+       printed out on standard office paper at time of publication, and
+       the electronic files have been preserved on disk and in backups
+       with no particular focus on preserving the entire computing
+       environment used to create the electronic documents.  Most RFCs
+       prior to January 2010 are also available on paper, but there are
+       gaps in the record and issues of ownership around the paper
+       copies before that date.
+
+   When the format for RFCs transitions from plain-text, ASCII-only
+   files to an XML format with multiple outputs, the overall archival
+   process will become more complex.  Additional metadata and some (or
+   possibly all) of the computing environment may need to be added to
+   the archive.
+
+2.  Updating Policy and Procedure
+
+   RFCs are created and published as digital objects.  Unlike paper-
+   based publications, a digital collection requires a focus on
+   retaining the details of the technology as well as retaining the
+   object itself.  Specifically, a digital archive needs to:
+
+   o  consider the inherent instability of digital media,
+
+   o  plan for a relatively short path to technological obsolescence,
+
+   o  schedule regular media updates,
+
+   o  apply predefined criteria for technology evaluation, and
+
+   o  ensure the continued authenticity and integrity of documents
+      through any changes in technology.
+
+   As the custodian and canonical source of RFCs and associated errata,
+   the RFC Editor must consider how to ensure the availability and
+   integrity of this document series far into the future and determine
+   whether the focus must be on bitstream preservation, content
+   preservation, or both.
+
+
+
+Flanagan                      Informational                     [Page 5]
+
+RFC 8153                  Digital Preservation                April 2017
+
+
+   The RFC Editor has several advantages in acting as the digital
+   archivist for the Series.  Since the RFC Editor is the publisher as
+   well as the archivist, the RFC Editor controls the format of the
+   material and the process for adding that material to an archive and
+   can add any additional metadata considered necessary.  External
+   material, while a major consideration for more general archives, is
+   no longer accepted by the RFC Editor.  (See "Internet Archaeology:
+   Documents from Early History" [RFC-HISTORY] for the list of non-RFC
+   digital objects held by the RFC Editor.)
+
+   This document describes several different preservation models that
+   may fit the needs of the Series and raises several points for
+   community consideration.  Specifically, this document covers
+   information on:
+
+   o  Acquisition of documents
+
+   o  Ingestion of documents
+
+   o  Metadata and document registration
+
+   o  Normalization and standardization of canonical file structure and
+      format
+
+   o  Transformation/migration to current publication formats
+
+   o  Content and computing environment preservation
+
+   o  System parameters
+
+   o  Financial impact
+
+2.1.  Acquisition of Documents
+
+   The acquisition process for documents intended for the archive starts
+   with the submission of an approved I-D for publication.  During the
+   editorial process, information such as the document metadata is
+   finalized prior to publication.  However, the initial I-D as
+   submitted and the RFC produced from it do not formally enter the
+   archive until the time of publication, which is considered the point
+   of ingestion from an archival perspective.
+
+2.2.  Ingestion of Documents
+
+   Once an RFC is published, the canonical format is considered
+   immutable.  At this point, the RFC Production Center, one of the
+   internal roles within the RFC Editor, assigns the document metadata
+   that an archivist needs to identify the unique object.
+
+
+
+Flanagan                      Informational                     [Page 6]
+
+RFC 8153                  Digital Preservation                April 2017
+
+
+   In the case of RFCs, the metadata assigned to a document at the time
+   of publication includes:
+
+   o  the RFC number
+
+   o  ISSN
+
+   o  publication date
+
+   o  Digital Object Identifier (DOI)
+
+   Additional metadata, such as author name, is assigned earlier in the
+   document creation process, but it is subject to change up to the
+   point of publication.  More information on metadata is available in
+   Section 2.3 ("Metadata and Document Registration").
+
+   In terms of deciding what to accept in the archive -- a major
+   question for most archives and yet a simple one for the RFC Series --
+   the RFC Editor accepts documents that are approved for publication by
+   the approving body of one of the document streams: the IETF, IAB,
+   IRTF, or Independent Submission streams [RFC7841].  Each document
+   stream has defined processes on when and how I-Ds are approved and
+   submitted to the RFC Editor for publication.  The RFC Editor does not
+   select documents for publication and archiving; the RFC Editor edits
+   and publishes documents approved for publication by the document
+   streams.
+
+   The RFC Editor holds no copyright on I-Ds or RFCs.  As per the IETF
+   Trust Legal Provisions [TLP], the copyright for RFCs is held by the
+   authors and the IETF Trust.  At any point in time, the current
+   entities providing RFC Editor services must be able to release the
+   archive of RFCs to the IETF Trust.
+
+   Note: The RFC Editor is currently only responsible for RFCs; any
+   associated datasets or other research data is not considered within
+   the RFC Editor's mandate at this time; therefore, no consideration to
+   the archival requirements of such datasets is covered in this
+   document.
+
+2.3.  Metadata and Document Registration
+
+   Metadata is data about data.  In the field of digital archiving, this
+   is the data that clearly identifies every aspect of a document, from
+   its identifier (i.e., the RFC number and the I-D draft string) to the
+   size and file format of the document and more.  Metadata is stored in
+   a central registry that records information on exactly what is being
+
+
+
+
+
+Flanagan                      Informational                     [Page 7]
+
+RFC 8153                  Digital Preservation                April 2017
+
+
+   preserved and where it is located, information on authenticity and
+   provenance, and details on the hardware and/or software needed to
+   view or create the documents.
+
+   The RFC Editor maintains this registry in the form of a database that
+   includes all metadata available for documents being edited and for
+   published RFCs.  This database feeds the search engine on the RFC
+   Editor website and the info pages available for every RFC (e.g.,
+   http://www.rfc-editor.org/info/rfc####).
+
+   Following is the current list of metadata presented in the RFC info
+   pages:
+
+   o  RFC number
+
+   o  Canonical URI
+
+   o  Title
+
+   o  Status
+
+   o  Updates (if applicable)
+
+   o  Updated by (if applicable)
+
+   o  Obsoletes (if applicable)
+
+   o  Obsoleted by (if applicable)
+
+   o  Authors
+
+   o  Stream
+
+   o  Abstract
+
+   o  Content-Type
+
+   o  Character Set
+
+   o  ISSN
+
+   o  Publication date
+
+   o  Digital Object Identifier (DOI)
+
+   The following metadata will be added in the future:
+
+   o  Publication format URIs
+
+
+
+Flanagan                      Informational                     [Page 8]
+
+RFC 8153                  Digital Preservation                April 2017
+
+
+   Info pages also include links to errata, IPR searches, and both
+   plain-text and XML citation files.
+
+   In terms of best practice, all documents used as normative references
+   within an RFC would also be stored in the archive.  While this is
+   done automatically when the normative reference is another RFC (the
+   usual case), retaining a copy of third-party documents is considered
+   out of scope for the RFC Editor.  As the digital archive industry
+   stabilizes, services such as Perma.cc [PERMACC] may be a reasonable
+   compromise.  These services provide a permanent URI and image capture
+   of online documents, with a goal of buffering against URI and online
+   availability changes.
+
+2.4.  Normalization and Standardization of Canonical File Structure and
+      Format
+
+   The normalization process is perhaps the most technically critical
+   part of digital archiving.  The purpose is content preservation --
+   making sure the data accepted for archiving are in the most stable
+   and easily accessed formats possible for the long-term future and
+   require the least amount of re-engineering and emulation of
+   environments in order to view the document in the future.
+   Normalization is about enabling long-term access to the information
+   within a document.
+
+   Over the history of the RFC Series, documents have been submitted for
+   publication in a variety of formats, including paper for the earliest
+   RFCs.  Today, the majority of RFCs are available in both a canonical
+   plain-text format and PDF format.  For exceptions, see the RFC Online
+   Project [RFC-ONLINE].
+
+   Currently, all RFCs are printed out to paper and stored at time of
+   publication.  This has been a reasonable backup plan for several
+   decades.  With few of the features one might expect from a digital
+   document format (such as links, metadata within the document, and
+   line drawings), plain-text files do not lose much, if any,
+   information when printed out to paper.  However, as the published
+   formats change (see RFC 6949), printing to paper provides less value
+   as much of the metadata that is an intrinsic yet invisible part of
+   the rendered document will be lost in such printing.  With that in
+   mind, the focus needs to change to preserving the new file formats
+   electronically.
+
+   While each RFC today is printed to paper and all electronic versions
+   stored on multiple hard drives, no particular effort is made to
+   ensure copies of the software used to render or read the canonical
+
+
+
+
+
+Flanagan                      Informational                     [Page 9]
+
+RFC 8153                  Digital Preservation                April 2017
+
+
+   plain-text RFC are also archived.  The RFC Editor has several choices
+   on how to adapt to the need to archive a more complex set of data and
+   follow best practice as defined by the digital archive community:
+
+   o  a simplified bitstream preservation model that focuses on standard
+      "best effort" data-retention practices, which rely on backups,
+      upgrades, and regular equipment change to preserve the data.  This
+      model assumes that emulators may be built when needed if the
+      formats used go out of common use (a significant part of the model
+      currently followed by the RFC Editor).
+
+   o  a content preservation model that focuses on one publication
+      format as the version most likely to be viewable and provide all
+      necessary metadata in the future.  This is a viable option
+      considering that PDF/A-3 [PDF], one of the intended publication
+      formats, was designed for this type of archiving.
+
+   o  a complex bitstream and content preservation model that focuses on
+      archiving the canonical XML and the entire computing environment
+      required to create, view and render all outputs from that file.
+      This is the "best practice" from an archivist's perspective.
+
+   Those options are listed in order of least to greatest complexity and
+   expense.  More detail on each option is described below.
+
+2.4.1.  'Best Effort' Data Retention
+
+   When dealing with very simple data structures such as plain-text,
+   ASCII-only files, the experience of the RFC Series suggests that for
+   the last few decades, hardware and operating system changes have had
+   minimal impact on the document files being stored.  While a complete
+   failure of an operating system migration corrupted the dataset in the
+   past, that situation represents a somewhat different problem than the
+   tools themselves changing such that plain-text files are not easily
+   read with existing technology.  Given that the basic plain-text
+   format and ASCII encoding remain in common use, the standard
+   protections against file corruption and data loss, such as disk
+   mirroring, off-site backups, and periodic restoration testing, will
+   continue to provide access to the entirety of the RFC Series for the
+   foreseeable future.  As has been pointed out, both in this document
+   and in broader community discussion, that is not sufficient for
+   complex formats such as XML, HTML, PDF, or other proprietary formats
+   offered by today's large IT companies.  The risk of technological
+   change resulting in the file formats mentioned being deprecated or
+   changed without backwards compatibility is fairly high when looking
+   decades or centuries into the future.
+
+
+
+
+
+Flanagan                      Informational                    [Page 10]
+
+RFC 8153                  Digital Preservation                April 2017
+
+
+   It is recommended that this model of archiving the RFC Series cease
+   to be the primary model after the plain-text, ASCII-only format is no
+   longer the canonical format.  Best effort data retention is a
+   necessary but not sufficient level of effort for preserving a digital
+   archive.  For more guidance on how to define best effort data
+   retention, the section on "Media and Formats, Summary
+   Recommendations" in the 2009 version of the Digital Preservation
+   Handbook [DPC2009] provides useful and concrete information.
+
+2.4.2.  Single Format for Archival Purposes
+
+   If preserving the information described by a document, rather than
+   the document itself, is the primary purpose of an archive, then
+   focusing efforts on a single file format is a reasonable option.
+   Some well-supported archival tooling projects follow this route, such
+   as Archivematica [ARCHIVEMATICA].  By selecting a feature-rich yet
+   fundamentally stable file format for documents, an organization may
+   avoid expensive whole-environment reconstruction in order to view the
+   document.  The PDF/A formats were designed to be an archival format
+   for electronic documents, and PDF/A-3 is one of the options intended
+   for publication as the RFC Series moves from a plain-text canonical
+   format to an XML canonical format with multiple publication formats.
+   A PDF/A-3 file can be produced that embeds the XML from which the
+   PDF/A-3 file was created; this allows for both original and rendered
+   document validation if one has the correct tools available to see the
+   source of the PDF/A-3 file [RFC7995].  The XML is not otherwise
+   visible when viewing the PDF/A-3 file through typical PDF reader
+   software.
+
+   When looking at the need to archive RFCs in a resource-limited
+   environment, a content-preservation-only model has merit, but it is
+   not without risks.  First, PDF/A-3 will not be the canonical format;
+   it is intended to be one of the rendered outputs.  It may contain
+   rendering bugs that were not intended to be in the document.  Second,
+   while the various PDF/A formats were designed to be archival, they
+   have not been put to the test of time to determine if they will
+   actually live up to the design goals.
+
+   This is a valid option to consider, but the risks, priorities, and
+   costs must be discussed by the community before a decision is made to
+   follow this path.  The best option may be to combine this with one of
+   the other methods of archiving described in this document to help
+   minimize both risk and cost.
+
+
+
+
+
+
+
+
+Flanagan                      Informational                    [Page 11]
+
+RFC 8153                  Digital Preservation                April 2017
+
+
+2.4.3.  Holistic Archiving of the Computing Environment
+
+   Preserving everything published by the RFC Editor in order to have a
+   permanent record of information, standards, and best practice is
+   arguably the whole point of being an archival series.  One can argue
+   that it is not only about the information described in an RFC, it is
+   also about supporting Intellectual Property Rights (IPR) and
+   retaining the history of the Internet.  In following this model,
+   however, one must consider the complexity of the archival environment
+   as matching, and possibly exceeding, the complexity of the file
+   formats being preserved.
+
+   Consider a future where XML has been obsoleted for half a century,
+   HTML5 was a format used three to four human generations ago, and PDF/
+   A-3 is no longer supported by any existing company's reading
+   software.  For RFCs that were produced with XML as their canonical
+   format, an archive must not only hold the data, it must also hold the
+   entire computing environment that allows the data to be rendered and
+   viewed.  Operating systems and hardware on which those OSs can run,
+   each major version of each piece of software used or relied upon
+   during the publication of an RFC, browsers and readers for HTML, PDF,
+   and any other publication format must be preserved in some fashion.
+   This is considered best practice when archiving digital documents.
+   This is also the most expensive method, and the cost only increases
+   over time as more and more instances of the computing environment
+   must be preserved over the lifetime of the Series.
+
+   This is a valid option to consider, but the sheer scope of resources
+   required suggests that this must be discussed by the community before
+   a decision is made.  Pursuing this may require an entirely different
+   paradigm for the RFC Editor from what has been considered in the
+   past; expanding the scope and resources for the RFC Editor, finding a
+   third party to take over the responsibilities of archiving, or some
+   other option may be necessary.
+
+2.5.  Transformation/Migration to Current Publication Formats
+
+   Because normalization is a complex subject, it is important to
+   consider how to mitigate the risk of failure of the normalization
+   process.
+
+   The RFC Editor is responsible for making RFCs available to the
+   Internet community.  The canonical version of an RFC does not change
+   once published; any formats officially rendered from the canonical
+   version, however, may change.  One way to mitigate the need to
+   preserve the entire computing environment for an RFC, including web
+   browsers and PDF readers, would be to take advantage of the non-
+   canonical nature of the publication formats and re-render them from
+
+
+
+Flanagan                      Informational                    [Page 12]
+
+RFC 8153                  Digital Preservation                April 2017
+
+
+   the canonical source at the point that browser or reader technology
+   has changed sufficiently to make RFCs largely unavailable to 'modern'
+   tools.
+
+   For example, the RFC Editor may develop the practice of annually
+   reviewing the tools needed to view the publication formats created by
+   the RFC Editor to determine whether or not the current common and
+   popular reader technologies (i.e., web browsers, PDF viewers,
+   e-readers) can view the existing publication formats.  During that
+   review, the RFC Editor would work with the community to determine if
+   the current publication formats meet the needs of the community and
+   whether any should be retired or added to improve the availability of
+   information to the community at that time.
+
+2.6.  System Parameters
+
+   While the industry best practice on the backup and restoration of
+   data is not sufficient as a long-term archival solution, it is still
+   a necessary part of keeping the Series available now and into the
+   future.  In the past, nearly 800 RFCs had to be manually transcribed
+   from paper back to electronic format due to a failed server migration
+   and insufficient backups.
+
+   The underlying servers hosting the tools, database, RFCs, and errata
+   are the physical link in the archival environment.  While such
+   systems cannot and should not remain static and unchanging, there
+   must be clear documentation regarding the environment, in particular,
+   the storage, backups, and recovery processes for all RFC-related
+   material.  The documentation must include information on the refresh
+   cycle for the physical storage and backup media and describe a
+   regular cycle of data restoration and/or migration testing.
+
+2.7.  Financial Impact
+
+   Having a policy regarding digital archiving provides input into the
+   budget process.  The main costs associated with digital archives come
+   from the complexity and quantity of the material being archived, as
+   described in Section 2.4 on normalization.
+
+   Estimating potential costs and providing figures are outside of the
+   scope of this document, but it should be noted that costs are a major
+   factor when determining what level of archival practice an
+   organization will follow.
+
+   For more information on potential business plans and cost modeling
+   for digital preservation, see the "Business cases, benefits, costs,
+   and impact" section of the Digital Preservation Handbook [DPC].
+
+
+
+
+Flanagan                      Informational                    [Page 13]
+
+RFC 8153                  Digital Preservation                April 2017
+
+
+3.  Recommendations
+
+   Given the need to balance cost and complexity with retention of
+   information for historic, legal, and informational purposes,
+   preservation efforts should focus on the XML canonical format files,
+   the PDF/A-3 format files, the xml2rfc tool and its documentation, and
+   at least two PDF reader applications capable of extracting the
+   embedded XML.  Care should be taken that the software being included
+   in this archive has a provision for free copies for backup or
+   archival purposes.  All other formats and the overall computing
+   environment should be stored as described in "best effort" data
+   retention (Section 2.4.1), which should in turn be described in the
+   appropriate vendor contract for the RFC Publisher.
+
+   Particular preservation efforts should be made by:
+
+   o  choosing a format designed for archiving RFCs (PDF/A-3 as
+      indicated by [RFC7995])
+
+   o  embedding the canonical XML format within the PDF/A-3 file for
+      RFCs
+
+   o  retaining a copy of the plain-text or XML file submitted for
+      approved I-Ds
+
+   o  retaining all major versions of the tools and their associated
+      documentation used to acquire and ingest an RFC
+
+   o  retaining the final XML file as well as the PDF/A-3 file with the
+      embedded XML
+
+   o  retaining at least two software reader applications to ensure the
+      PDF/A-3 and XML files can be viewed in the future
+
+   o  partnering with other digital archives around the world to mirror
+      copies of the target data
+
+   In order to control costs and focus the archiving effort on the
+   entire content of an RFC, including the metadata and other features
+   embedded within each RFC published in more than just plain text,
+   printing each RFC to paper upon publication is no longer reasonable.
+   Proper data storage and mirrored copies of RFCs provide more
+   efficient and effective copies in case of catastrophic failure of the
+   existing archive of material.
+
+   Particular focus should be given to finding partners that specialize
+   in digital preservation to ingest RFCs.  Ideally, they will ingest
+   all material associated with an RFC, including all metadata, digital
+
+
+
+Flanagan                      Informational                    [Page 14]
+
+RFC 8153                  Digital Preservation                April 2017
+
+
+   signatures, and the approved I-D that was submitted to the RFC
+   Editor.  The possibilities and options should be discussed with each
+   archival partner; at minimum, they must ingest copies of RFCs as they
+   are published, with the basic metadata associated with each document.
+
+   Preservation efforts should be reviewed and validated through a
+   biennial audit that will verify that the targeted content and all its
+   associated metadata can be read with existing tools.  The full
+   process from acquisition to ingestion should be reviewed to ensure
+   that best current practice is being followed from the perspective of
+   the digital archive community.  Since the overall model for the
+   digital archive maintained by the RFC Editor follows the OAIS
+   reference model, the associated audit guidelines should also be
+   followed.  While the RFC Editor does not seek to be recognized as
+   'OAIS-compliant' at this time, use of the ISO standard "Space data
+   and information transfer systems -- Audit and certification of
+   trustworthy digital repositories" [ISO16363] would provide a solid,
+   accepted method for structuring an audit for this digital archive.
+
+4.  Summary
+
+   The RFC Series is worth archiving.  It contains the history of the
+   early Internet, as well as some of the key standards for Internet
+   technology and best practice today.  Who knows what the community
+   will create in the future?  There are many ways to preserve the
+   Series, from relying on preservation of the bits, to focusing on a
+   single file format, to preserving the entire computing environment.
+   Each possibility, or permutations of them, involves risks and
+   requires varying levels of resources.  The goal of this document is
+   to describe the possibilities and associated risks so that the
+   community can come to an informed decision regarding what it is
+   willing to see supported far into the future.
+
+5.  IANA Considerations
+
+   This document does not require any IANA actions.
+
+6.  Security Considerations
+
+   This document assumes that the origination of RFCs via the RFC Editor
+   is secure and trusted.  With that assumption, the activities
+   discussed in this document do not affect the security of the
+   Internet.
+
+
+
+
+
+
+
+
+Flanagan                      Informational                    [Page 15]
+
+RFC 8153                  Digital Preservation                April 2017
+
+
+7.  Informative References
+
+   [ARCHIVEMATICA]
+              "Archivematica", <https://www.archivematica.org/wiki/
+              Main_Page>.
+
+   [DPC]      Digital Preservation Coalition, "Digital Preservation
+              Handbook", 2015, <http://dpconline.org/handbook>.
+
+   [DPC2009]  Digital Preservation Coalition, "Digital Preservation
+              Handbook", 2009, <http://www.dpconline.org/docman/digital-
+              preservation-handbook/304-digital-preservation-handbook-
+              media-and-formats>.
+
+   [ISO14721] International Organization for Standardization, "Space
+              data and information transfer systems -- Open archival
+              information system (OAIS) -- Reference model",
+              ISO 14721:2012, 2012.
+
+   [ISO16363] International Organization for Standardization, "Space
+              data and information transfer systems -- Audit and
+              certification of trustworthy digital repositories",
+              ISO 16363:2012, 2012.
+
+   [LIFE]     Hole, B., "LIFE^3: Predictive Costing of Digital
+              Preservation", July 2010,
+              <http://www.life.ac.uk/3/docs/Hole_pasig_v1.pdf>.
+
+   [PDF]      International Organization for Standardization, "Document
+              management -- Electronic document file format for long-
+              term preservation -- Part 3: Use of ISO 32000-1 with
+              support for embedded files (PDF/A-3)", ISO 19005-3:2012,
+              2012.
+
+   [PERMACC]  "Perma.cc", <http://perma.cc/>.
+
+   [RFC-HISTORY]
+              RFC Editor, "Internet Archaeology: Documents from Early
+              History", <http://www.rfc-editor.org/history.html>.
+
+   [RFC-ONLINE]
+              RFC Editor, "History of RFC Online Project",
+              <http://www.rfc-editor.org/rfc-online-2000.html>.
+
+   [RFC-PUB]  RFC Editor, "Publication Process",
+              <http://www.rfc-editor.org/pubprocess.html>.
+
+
+
+
+
+Flanagan                      Informational                    [Page 16]
+
+RFC 8153                  Digital Preservation                April 2017
+
+
+   [RFC-SERIES]
+              RFC Editor, "About Us",
+              <http://www.rfc-editor.org/RFCoverview.html>.
+
+   [RFC6635]  Kolkman, O., Ed., Halpern, J., Ed., and IAB, "RFC Editor
+              Model (Version 2)", RFC 6635, DOI 10.17487/RFC6635, June
+              2012, <http://www.rfc-editor.org/info/rfc6635>.
+
+   [RFC6949]  Flanagan, H. and N. Brownlee, "RFC Series Format
+              Requirements and Future Development", RFC 6949,
+              DOI 10.17487/RFC6949, May 2013,
+              <http://www.rfc-editor.org/info/rfc6949>.
+
+   [RFC7841]  Halpern, J., Ed., Daigle, L., Ed., and O. Kolkman, Ed.,
+              "RFC Streams, Headers, and Boilerplates", RFC 7841,
+              DOI 10.17487/RFC7841, May 2016,
+              <http://www.rfc-editor.org/info/rfc7841>.
+
+   [RFC7995]  Hansen, T., Ed., Masinter, L., and M. Hardy, "PDF Format
+              for RFCs", RFC 7995, DOI 10.17487/RFC7995, December 2016,
+              <http://www.rfc-editor.org/info/rfc7995>.
+
+   [TLP]      IETF Trust, "Trust Legal Provisions (TLP)",
+              <https://trustee.ietf.org/trust-legal-provisions.html>.
+
+   [USLOC]    LeFurgy, B., "Life Cycle Models for Digital Stewardship",
+              February 2012,
+              <http://blogs.loc.gov/digitalpreservation/2012/02/
+              life-cycle-models-for-digital-stewardship/>.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Flanagan                      Informational                    [Page 17]
+
+RFC 8153                  Digital Preservation                April 2017
+
+
+IAB Members at the Time of Approval
+
+   The IAB members at the time this document was approved were (in
+   alphabetical order):
+
+      Jari Arkko
+      Ralph Droms
+      Ted Hardie
+      Joe Hildebrand
+      Lee Howard
+      Erik Nordmark
+      Robert Sparks
+      Andrew Sullivan
+      Dave Thaler
+      Martin Thomson
+      Brian Trammell
+      Suzanne Woolf
+
+Author's Address
+
+   Heather Flanagan
+   RFC Editor
+
+   Email: rse@rfc-editor.org
+   URI:   http://orcid.org/0000-0002-2647-2220
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Flanagan                      Informational                    [Page 18]
+