Cisco Systems GmbH

Richtistrasse 7 Wallisellen CH-8304 ZH Switzerland +41 1 878 9200 lear@cisco.com

UCLA

Computer Science Department 4532J Boelter Hall Los Angeles 90095 CA USA +1 310 267 2254 eggert@cs.ucla.edu

Timezone information serves as a basic protocol element in protocols, such as the calendaring suite and DHCP. The Timezone (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 IANA 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 timezone community. The intent of this memo is, to the extent possible, document existing practice and provide a means to ease succession.

The IETF has specified several standards that make use of timezone information. Timezone names are used in DHCP to configure devices with correct local time . Timezone names can appear in the TZID field of VEVENTs . The normative reference for these values is the TZ Database. Since the early 1980s, that database, which has been in use on nearly all UNIX systems, Java systems, and other sorts of systems has been hosted at the National Institutes of Health. 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 and IEEE 1003.1 POSIX time functions that can be used to convert time values. The database has been maintained by volunteers who participate in a mailing list that is 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 IANA provides registry services to the Internet community. Those registries are coordinated by technical experts who are designated by the Internet Engineering Steering Group (IESG). The IANA is also well suited as a distribution platform for the TZ Database itself. The IANA has for quite some time had the capability to maintain designated expert mailing lists. The TZ mailing list would fit nicely as just such a list.

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 . The TimeZone 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. 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 , except as regards to appeals, as discussed in . 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 work with the IANA to develop appropriate service metrics. There SHALL be a single lead individual and at least one backup individual for this function. The forum where matters relating to the TZ database and supporting code are discussed. The rest of this document specifies the following: Transferring and maintenance of the TZ mailing list; Procedures for selecting a technical expert who will play the role of TZ Coordinator and release manager for the TZ database; Procedures for updating the TZ database; Maintenance and ownership of reference code; and Ownership of the database.

For many years the TZ mailing list at the National Institutes of Health (NIH) 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 will be transitioned to the IANA mail server. 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.

Updates to the TZ database are made by the TZ Coordinator in consultation with the TZ mailing list. 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. The release itself today 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 signed prior to release using well known public keys, along with any appropriate supporting information and distributed from a well known location that is advertised by IANA in a manner of its choosing. The criteria for updates to the database include the following: 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. 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. 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 timezone 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.

From time to time it will be necessary to appoint a new TZ Coordinator. This could occur for a number of reasons: The TZ Coordinator is retiring (as Arthur Olson is) or has announced that he or she will be unable to continue to perform the function; The TZ Coordinator is missing, has become incapacitated, or has died; or 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.

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: Attempt to resolve the concern directly with the TZ Coordinator. 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. 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.

Currently the maintainer of the TZ database also maintains reference code, most of which is public domain. Several files from this software are currently distributed under license. Where they exist, licenses SHALL NOT be changed. IANA SHALL allow for the downloading of this reference code. The reference implementation shall be distributed along with an associated cryptographic signature verifiable by a public key that IANA will publish.

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, BCP 78 and BCP 79 do not apply to the TZ Database or contributions that individuals make to it. Should any claims be made and substantiated against the database, the IANA will act in accordance with all competent court orders. No ownership claims will be made by IANA 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.

If requested to do so, the IANA SHALL assist the IESG in selection of the TZ Coordinator, based on the procedures set forth above. The IANA SHALL act as 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. The IANA SHALL provide the TZ Coordinator with appropriate access to maintain the database, as well as necessary tooling that may be required, so long as no direct software costs are incurred. Both current and historical versions of the database will be stored and distributed via HTTP/HTTPs. IANA will be operationally responsible for the security of the system upon which the database resides. The IANA SHALL also securely maintain a cryptographic private key that is used to sign the database, and that will survive a change of TZ Coordinator.

The distribution of the database is currently not secured. This memo states that moving forward the TZ database SHOULD be distributed with a valid cryptographic signature.

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, and Barry Leiba for the improvements they made to this document. A special acknowledgment should be given to Arthur David Olson for his excellent stewardship.

UCLA National Institutes of Health"

RFC-EDITOR: Please remove this section prior to publication. 03: Reviewer comments. Take out ATTENTION: comment. Add backup coordinator. editorial nits. Add discussion of metrics. Modify both TZ Coordinator selection process and appeal process per Adrian's comments. Clarify process rules per Russ' comments. Clarify that the criteria are not an exhaustive list. 02: Separate out from RFC5226 a bit; Simplify language around submissions; host list to IANA; spelling corrections; clarify here and there. 01: Proper reference to RFC5226, add acknowledgments, several rewordings. Initial Revision