doc: Add RFC documents

1 files changed, 507 insertions, 0 deletions

diff --git a/doc/rfc/rfc6557.txt b/doc/rfc/rfc6557.txt
new file mode 100644
index 0000000..4fc99e8
--- /dev/null
+++ b/doc/rfc/rfc6557.txt
@@ -0,0 +1,507 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                           E. Lear
+Request for Comments: 6557                            Cisco Systems GmbH
+BCP: 175                                                       P. Eggert
+Category: Best Current Practice                                     UCLA
+ISSN: 2070-1721                                            February 2012
+
+
+           Procedures for Maintaining the Time Zone Database
+
+Abstract
+
+   Time zone information serves as a basic protocol element in
+   protocols, such as the calendaring suite and DHCP.  The Time Zone
+   (TZ) Database specifies the indices used in various protocols, as
+   well as their semantic meanings, for all localities throughout the
+   world.  This database has been meticulously maintained and
+   distributed free of charge by a group of volunteers, coordinated by a
+   single volunteer who is now planning to retire.  This memo specifies
+   procedures involved with maintenance of the TZ database and
+   associated code, including how to submit proposed updates, how
+   decisions for inclusion of those updates are made, and the selection
+   of a designated expert by and for the time zone community.  The
+   intent of this memo is, to the extent possible, to document existing
+   practice and provide a means to ease succession of the database
+   maintainers.
+
+Status of This Memo
+
+   This memo documents an Internet Best Current Practice.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   BCPs is available in Section 2 of RFC 5741.
+
+   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/rfc6557.
+
+
+
+
+
+
+
+
+
+
+
+
+Lear & Eggert             Best Current Practice                 [Page 1]
+
+RFC 6557           Maintaining the Time Zone Database      February 2012
+
+
+Copyright Notice
+
+   Copyright (c) 2012 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.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+1.  Introduction
+
+   The IETF has specified several standards that make use of time zone
+   information.  Time zone names are used in DHCP to configure devices
+   with correct local time [RFC4833].  Time zone names can appear in the
+   TZID field of calendaring VEVENTs [RFC5545].  The normative reference
+   for these values is the TZ Database [TZDB].  From the early 1980s
+   through 2011, that database, which has been in use on nearly all UNIX
+   systems, Java systems, and other sorts of systems, was hosted at the
+   U.S. National Institutes of Health (NIH).  The database consists of
+   both historic and current entries for geographies throughout the
+   world.  Associated with the database is a reference implementation of
+   ISO/IEC 9899 C [ISO9899C] and IEEE 1003.1 [IEEE1003.1] POSIX time
+   functions that can be used to convert time values.
+
+   The database was previously maintained by volunteers who participated
+   in the <tz@elsie.nci.nih.gov> mailing list that was also hosted at
+   the NIH.  The database itself is updated approximately twenty times
+   per year, depending on the year, based on information these experts
+   provide to the maintainer.  Arthur David Olson has maintained the
+   database, coordinated the mailing list, and provided a release
+   platform since the database's inception.  With his retirement now
+   approaching, it is necessary to provide a means for this good work to
+   continue.
+
+   The time zone community has requested that the IETF adopt the ongoing
+   maintenance of the Time Zone Database.  The time zone community would
+   like the IETF to maintain it in a consistent fashion to its
+   administration of the Internet protocol parameters and values.
+
+
+
+
+
+
+
+Lear & Eggert             Best Current Practice                 [Page 2]
+
+RFC 6557           Maintaining the Time Zone Database      February 2012
+
+
+1.1.  Terminology
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [RFC2119].
+
+   IANA (Internet Assigned Numbers Authority):  For purposes of this
+      RFC, IANA is a role, not an organization.  The IANA Considerations
+      defined in this RFC will be provided by the Internet Corporation
+      for Assigned Names and Numbers (ICANN) in accordance with the
+      IETF-ICANN "Memorandum of Understanding Concerning Technical Work
+      of the Internet Assigned Numbers Authority", which was signed and
+      ratified in March of 2000[RFC2860].
+
+   TZ Database:  The Time Zone Database, sometimes referred to as the
+      "Olson Database".  This database consists of information about
+      offsets from UTC for different localities, including daylight
+      saving time (DST) transition information.
+
+   TZ Coordinator:  The person or people who maintain and manage release
+      of the TZ Database.  The TZ Coordinator also has responsibility
+      for managing the TZ mailing list.  The TZ Coordinator is an IANA
+      Designated Expert, as defined in Section 3.2 of [RFC5226], except
+      as regards to appeals, as discussed in Section 5 of this document.
+      Roughly speaking, this means that the IESG will choose one or more
+      experts to manage the TZ database, code, and mailing list.  The TZ
+      Coordinator will also lead work to develop appropriate service
+      metrics.  There SHALL be a single lead individual and at least one
+      backup individual for this function.
+
+   TZ mailing list:  The forum where matters relating to the TZ database
+      and supporting code are discussed.
+
+   The rest of this document specifies the following:
+
+   1.  Transferring and maintenance of the TZ mailing list;
+
+   2.  Procedures for selecting a technical expert who will play the
+       role of TZ Coordinator and release manager for the TZ database;
+
+   3.  Procedures for updating the TZ database;
+
+   4.  Maintenance and ownership of reference code; and
+
+   5.  Ownership of the database.
+
+
+
+
+
+
+Lear & Eggert             Best Current Practice                 [Page 3]
+
+RFC 6557           Maintaining the Time Zone Database      February 2012
+
+
+2.  The TZ Mailing List
+
+   For many years, the TZ mailing list has been the forum where
+   discussion of changes to the TZ database and support files would take
+   place.  In addition, the TZ mailing list is used to announce releases
+   of the database.  Currently, the TZ mailing list is administered by
+   the TZ Coordinator.
+
+   This list membership, formerly at the NIH, has been transitioned to
+   the IANA mail server.  Its address, moving forward, is <tz@iana.org>.
+   Subscriptions are processed at
+   <https://mm.icann.org/mailman/listinfo/tz/>.  The TZ Coordinator will
+   continue to manage the list.  While the TZ Coordinator may establish
+   other rules of governance for the list, members of that list will be
+   informed that a condition of participating on the list is that all
+   contributions to the list are released to the public domain, and that
+   by placing their contribution in the public domain, contributors
+   waive forever any intellectual property claims.
+
+   The list will be used just as it has been: to learn of, discuss, and
+   confirm TZ definition changes, as well as to serve as an announcement
+   list for new versions of the database.
+
+3.  Making Updates to the TZ Database
+
+   Updates to the TZ database are made by the TZ Coordinator in
+   consultation with the TZ mailing list.  The TZ Coordinator is
+   empowered to decide, as the designated expert, appropriate changes,
+   but SHOULD take into account views expressed on the mailing list.
+
+   The TZ Coordinator will also decide the timing of database releases.
+   Today, the release itself consists of several archive files that are
+   downloaded from a well-known location.
+
+   Moving forward, the TZ database, supporting code, and any appropriate
+   supporting information SHOULD be cryptographically signed prior to
+   release using well known public keys, along with any appropriate
+   supporting information and distributed from
+   <http://www.iana.org/time-zones>.
+
+   The criteria for updates to the database include the following:
+
+   1.  New TZ names (e.g., locations) are only to be created when the
+       scope of the region a name was envisioned to cover is no longer
+       accurate.
+
+
+
+
+
+
+Lear & Eggert             Best Current Practice                 [Page 4]
+
+RFC 6557           Maintaining the Time Zone Database      February 2012
+
+
+   2.  In order to correct historical inaccuracies, a new TZ name MAY be
+       added when it is necessary to indicate what was the consensus
+       view at a given time and location.  Such TZ names are usually not
+       added when the inaccuracy was prior to 1970.
+
+   3.  Changes to existing entries SHALL reflect the consensus on the
+       ground in the region covered by that entry.
+
+   To be clear, the TZ Coordinator SHALL NOT set time zone policy for a
+   region but use judgment and whatever available sources exist to
+   assess what the average person on street would think the time
+   actually is, or in case of historical corrections, was.
+
+4.  Selecting or Replacing a TZ Coordinator
+
+   From time to time it will be necessary to appoint a new TZ
+   Coordinator.  This could occur for a number of reasons:
+
+   o  The TZ Coordinator is retiring (as Arthur David Olson is) or has
+      announced that he or she will be unable to continue to perform the
+      function;
+
+   o  The TZ Coordinator is missing, has become incapacitated, or has
+      died; or
+
+   o  The TZ Coordinator is not performing the function in accordance
+      with community wishes.
+
+   In any of these cases, members of the community should raise the
+   issue on the TZ mailing list and attempt to reach consensus on a new
+   candidate to fulfill the role of TZ Coordinator.  If rough consensus
+   cannot be reached easily, the Area Directors of the IETF Applications
+   Area should attempt to guide the members of the community to rough
+   consensus.  The candidate that is agreed upon by the community
+   through rough consensus shall be presented to the IESG for
+   confirmation.  If rough consensus cannot be reached, even with
+   guidance from the Applications Area Directors, the IESG shall use
+   whatever means it has at its disposal to choose a candidate who in
+   its best judgment will be able to fulfill the role of TZ Coordinator.
+
+5.  Appealing Database Decisions
+
+   The TZ Coordinator makes decisions based on expertise, as well as
+   with guidance from the TZ mailing list.  If a member of the community
+   has a concern with an individual decision made by the TZ Coordinator
+   with regard to the TZ database, the individual shall proceed as
+   follows:
+
+
+
+
+Lear & Eggert             Best Current Practice                 [Page 5]
+
+RFC 6557           Maintaining the Time Zone Database      February 2012
+
+
+   1.  Attempt to resolve the concern directly with the TZ Coordinator.
+
+   2.  If a resolution cannot be reached directly with the TZ
+       Coordinator, express the concern to the community and attempt to
+       achieve rough consensus regarding a resolution on the TZ mailing
+       list.  The Area Directors of the IETF Applications Area may at
+       their discretion attempt to guide the members of the community to
+       rough consensus.
+
+   3.  As a last resort, if a resolution cannot be reached on the TZ
+       mailing list, appeal to the IESG for a resolution.  The appellant
+       must show that the decision made by the TZ Coordinator (a) was
+       materially in error and (b) has caused material harm.  In its
+       deliberations regarding an appeal, the IESG shall weigh all the
+       evidence presented to it and use its best judgment in determining
+       a resolution.
+
+6.  Maintenance and Distribution of Reference Code
+
+   Currently, the maintainer of the TZ database also maintains reference
+   code, most of which is public domain.  The reference implementation
+   shall be distributed along with an associated cryptographic signature
+   verifiable by a public key.  Several files from this software are
+   currently distributed under license.  Where they exist, licenses
+   SHALL NOT be changed.
+
+7.  Database Ownership
+
+   The TZ database itself is not an IETF Contribution or an IETF
+   document.  Rather it is a pre-existing and regularly updated work
+   that is in the public domain, and is intended to remain in the public
+   domain.  Therefore, BCPs 78 [RFC5378] and 79 [RFC3979] do not apply
+   to the TZ Database or contributions that individuals make to it.
+   Should any claims be made and substantiated against the TZ Database,
+   the organization that is providing the IANA Considerations defined in
+   this RFC, under the memorandum of understanding with the IETF,
+   currently ICANN, may act in accordance with all competent court
+   orders.  No ownership claims will be made by ICANN or the IETF Trust
+   on the database or the code.  Any person making a contribution to the
+   database or code waives all rights to future claims in that
+   contribution or in the TZ Database.
+
+8.  IANA Considerations
+
+   This section documents the following IANA actions:
+
+   o  Assistance on request of the IESG in selection of the TZ
+      Coordinator, based on the procedures set forth above.
+
+
+
+Lear & Eggert             Best Current Practice                 [Page 6]
+
+RFC 6557           Maintaining the Time Zone Database      February 2012
+
+
+   o  Maintenance of a repository for the TZ database and associated
+      reference code.  The TZ Coordinator SHALL be named by the IESG as
+      described above, and will act as the maintainer of the database
+      and code, as described above.
+
+   o  Creation of appropriate access for the TZ Coordinator to maintain
+      the database, as well as necessary tooling that may be required,
+      so long as no direct software costs are incurred.
+
+   o  Establishment of security of the system upon which the database
+      resides.  Both current and historical versions of the database
+      will be stored and distributed via HTTP/HTTPS.
+
+   o  Maintenance of a cryptographic private key that is used to sign
+      the database and that will survive a change of TZ Coordinator.
+
+9.  Security Considerations
+
+   The distribution of the database is currently not secured.  This memo
+   states that the TZ database SHOULD be distributed with a valid
+   cryptographic signature moving forward.
+
+10.  Acknowledgments
+
+   The authors would like to thank the TZ mailing list for their
+   remarkable achievements over the many years.  Thanks also to Marshall
+   Eubanks, S. Moonesamy, Peter Saint-Andre, Alexey Melenkov, Tony
+   Finch, Elwyn Davies, Alfred Hoenes, Ted Hardie, Barry Leiba, Russ
+   Housley, Pete Resnick, and Elise Gerich for the improvements they
+   made to this document.  A special acknowledgment should be given to
+   Arthur David Olson for his excellent stewardship, to Rob Elz for
+   continuing that stewardship, and to the team at ICANN for their good
+   efforts, moving forward.
+
+11.  References
+
+11.1.  Normative References
+
+   [RFC2119]    Bradner, S., "Key words for use in RFCs to Indicate
+                Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2860]    Carpenter, B., Baker, F., and M. Roberts, "Memorandum of
+                Understanding Concerning the Technical Work of the
+                Internet Assigned Numbers Authority", RFC 2860,
+                June 2000.
+
+
+
+
+
+
+Lear & Eggert             Best Current Practice                 [Page 7]
+
+RFC 6557           Maintaining the Time Zone Database      February 2012
+
+
+   [RFC5226]    Narten, T. and H. Alvestrand, "Guidelines for Writing an
+                IANA Considerations Section in RFCs", BCP 26, RFC 5226,
+                May 2008.
+
+   [TZDB]       Eggert, P. and A. Olson, "Sources for Time Zone and
+                Daylight Saving Time Data", 1987,
+                <ftp://ftp.iana.org/tz/code/tz-link.htm>.
+
+11.2.  Informational References
+
+   [IEEE1003.1] Institute of Electrical and Electronics Engineers,
+                "Standard for Information Technology - Portable
+                Operating System Interface (POSIX) - Base Definitions",
+                IEEE Standard 1003.1-2008, December 2008.
+
+   [ISO9899C]   International Standards Organization, "Information
+                technology -- Programming languages -- C", ISO/
+                IEC Standard 9899:2011, December 2011.
+
+   [RFC3979]    Bradner, S., "Intellectual Property Rights in IETF
+                Technology", BCP 79, RFC 3979, March 2005.
+
+   [RFC4833]    Lear, E. and P. Eggert, "Timezone Options for DHCP",
+                RFC 4833, April 2007.
+
+   [RFC5378]    Bradner, S. and J. Contreras, "Rights Contributors
+                Provide to the IETF Trust", BCP 78, RFC 5378,
+                November 2008.
+
+   [RFC5545]    Desruisseaux, B., "Internet Calendaring and Scheduling
+                Core Object Specification (iCalendar)", RFC 5545,
+                September 2009.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lear & Eggert             Best Current Practice                 [Page 8]
+
+RFC 6557           Maintaining the Time Zone Database      February 2012
+
+
+Authors' Addresses
+
+   Eliot Lear
+   Cisco Systems GmbH
+   Richtistrasse 7
+   CH-8304  Wallisellen
+   Switzerland
+
+   Phone: +41 1 878 9200
+   EMail: lear@cisco.com
+
+
+   Paul Eggert
+   UCLA
+   Computer Science Department
+   4532J Boelter Hall
+   Los Angeles, CA  90095
+   USA
+
+   Phone: +1 310 267 2254
+   EMail: eggert@cs.ucla.edu
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lear & Eggert             Best Current Practice                 [Page 9]
+