Network Working Group E. Lear
Internet-Draft Cisco Systems GmbH
Intended status: BCP P. Eggert
Expires: July 31, 2011 UCLA
January 27, 2011
IANA Procedures for Maintaining the Timezone Database
draft-lear-iana-timezone-database-02
Abstract
ATTENTION: This memo contains a DRAFT proposal for the IANA to assume
operational responsibilities relating to the management of the
Timezone (TZ) Database. The authors seek comment and review of this
proposal. No action will be taken without rough consensus of the TZ
community.
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.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 31, 2011.
Lear & Eggert Expires July 31, 2011 [Page 1]
Internet-Draft Maintaining the Timezone Database January 2011
Copyright Notice
Copyright (c) 2011 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
ATTENTION: This memo contains a DRAFT proposal for the IANA to assume
operational responsibilities relating to the management of the
Timezone (TZ) Database. The authors seek comment and review of this
proposal. No action will be taken without rough consensus of the TZ
community.
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 [RFC4833]. Timezone names can appear in the
TZID field of VEVENTs [RFC5545]. The normative reference for these
values is the TZ Database [TZDB]. 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 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
Lear & Eggert Expires July 31, 2011 [Page 2]
Internet-Draft Maintaining the Timezone Database January 2011
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 just as such a list.
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].
TZ Database: 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.
TZ Coordinator: The person or people who maintain and manage release
of the TZ Database. The TZ coordinator also has responsibility
for maintaining the TZ mailing list. The TZ coordinator is an
IANA Designated Expert, as defined in Section 3.2 of [RFC5226].
Roughly speaking, this means that the IESG will choose one or more
experts to manage the TZ database, code, and mailing list.
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 for the technical
expert who will play the role of 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.
2. The TZ Mailing List
For many years the TZ mailing list at the 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
Lear & Eggert Expires July 31, 2011 [Page 3]
Internet-Draft Maintaining the Timezone Database January 2011
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 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. 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 and supporting code SHOULD be signed
prior to release using a well known key, 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 are as follows:
1. New keys are only to be created when the region a key was
envisioned to cover is not accurately reflected by an existing
key.
2. In order to correct historical inaccuracies, a new key MAY be
added when it is necessary to indicate what was the consensus
view at given time and location. Such keys 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 timezone policy 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:
Lear & Eggert Expires July 31, 2011 [Page 4]
Internet-Draft Maintaining the Timezone Database January 2011
o The coordinator is retiring (as Arthur Olson is) or has announced
that he or she will be unable to continue to perform the function;
o The coordinator is missing or has died;
o The 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 list. If a rough consensus can be formed easily, and
quickly, then the results should be presented to the IESG for comment
and review. The IESG selects the TZ coordinator(s). The IESG will
use rough consensus of the TZ mailing list as their primary guide to
further action, when it exists, and whatever other means they have at
their disposal, when rough consensus cannot be found.
5. Appealing Database Decisions
The TZ coordinator makes decisions based on expertise, as well as
with guidance from the TZ mailing lists. While individual decisions
MAY be appealed to the IESG, the IESG MUST give great deference to
the designated expert in its considerations. In particular,
apellants MUST show material harm from the decision, and that the
decision is materially in error. The IESG is not a normal avenue for
appeals of specific decisions of the coordinator, but rather a last
resort when a coordinator is thought not to be functioning in an
appropriate way.
N.B., the coordinator is a function, and may be filled by one or more
people, as the community sees fit.
6. Maintenance and Distribution of Reference Code
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 of an
identity that IANA will publish.
7. Database Ownership
The database itself is public domain. Should 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
Lear & Eggert Expires July 31, 2011 [Page 5]
Internet-Draft Maintaining the Timezone Database January 2011
making a contribution to the database or code waives all rights to
future claims.
8. IANA Considerations
The IANA SHALL assist the IESG, as required, in filling 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 database 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 maintain a cryptographic identity that is used to
sign the database, and that will survive a change of coordinators.
9. Security Considerations
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.
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, Elwin Davies, Alfred Hoenes, and Ted Hardie for the
improvements they made to this document. A special acknowledgment
should be given to Arthur David Olson for his excellent stewardship.
11. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4833] Lear, E. and P. Eggert, "Timezone Options for DHCP",
RFC 4833, April 2007.
Lear & Eggert Expires July 31, 2011 [Page 6]
Internet-Draft Maintaining the Timezone Database January 2011
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[RFC5545] Desruisseaux, B., "Internet Calendaring and Scheduling
Core Object Specification (iCalendar)", RFC 5545,
September 2009.
[TZDB] Eggert, P. and A. Olson, "Sources for Time Zone and
Daylight Saving Time Data",
<http://www.twinsun.com/tz/tz-link.htm>.
Appendix A. Changes
o 02: Separate out from RFC5226 a bit; Simplify language around
submissions; host list to IANA; spelling corrections; clarify here
and there.
o 01: Proper reference to RFC5226, add acknowledgments, several
rewordings.
o Initial Revision
Authors' Addresses
Eliot Lear
Cisco Systems GmbH
Richtistrasse 7
Wallisellen, ZH CH-8304
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 Expires July 31, 2011 [Page 7]
