From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc6557.txt | 507 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 507 insertions(+) create mode 100644 doc/rfc/rfc6557.txt (limited to 'doc/rfc/rfc6557.txt') 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 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 . + Subscriptions are processed at + . 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 + . + + 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, + . + +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] + -- cgit v1.2.3