Network Working Group                                            E. Lear
Internet-Draft                                        Cisco Systems GmbH
Intended status: BCP                                           P. Eggert
Expires: November 20, 2011                                          UCLA
                                                            May 19, 2011

         IANA Procedures for Maintaining the Timezone Database


   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

   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 November 20, 2011.

Copyright Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

Lear & Eggert           Expires November 20, 2011               [Page 1]

Internet-Draft      Maintaining the Timezone Database           May 2011

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   ( 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 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 ISO/IEC 9899 C and
   IEEE 1003.1 POSIX time functions that can be used to convert time

   The database has been maintained by volunteers who participate in a
   mailing list [1] 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.

1.1.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",

Lear & Eggert           Expires November 20, 2011               [Page 2]

Internet-Draft      Maintaining the Timezone Database           May 2011

   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 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.  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.
   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.

2.  The TZ Mailing List

   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

Lear & Eggert           Expires November 20, 2011               [Page 3]

Internet-Draft      Maintaining the Timezone Database           May 2011

   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, 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:

   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
   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 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.

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 Olson is) or has
      announced that he or she will be unable to continue to perform the

Lear & Eggert           Expires November 20, 2011               [Page 4]

Internet-Draft      Maintaining the Timezone Database           May 2011

   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

   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.  Several files from this
   software are currently distributed under license.  Where they exist,
   licenses SHALL NOT be changed.  IANA SHALL allow for the downloading

Lear & Eggert           Expires November 20, 2011               [Page 5]

Internet-Draft      Maintaining the Timezone Database           May 2011

   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.

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, 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.

8.  IANA Considerations

   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.

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.

Lear & Eggert           Expires November 20, 2011               [Page 6]

Internet-Draft      Maintaining the Timezone Database           May 2011

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, 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.

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.

   [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",

   [1]  <>

Appendix A.  Changes

   RFC-EDITOR: Please remove this section prior to publication.

   o  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.
   o  02: Separate out from RFC5226 a bit; Simplify language around
      submissions; host list to IANA; spelling corrections; clarify here
      and there.

Lear & Eggert           Expires November 20, 2011               [Page 7]

Internet-Draft      Maintaining the Timezone Database           May 2011

   o  01: Proper reference to RFC5226, add acknowledgments, several
   o  Initial Revision

Authors' Addresses

   Eliot Lear
   Cisco Systems GmbH
   Richtistrasse 7
   Wallisellen, ZH  CH-8304

   Phone: +41 1 878 9200

   Paul Eggert
   Computer Science Department
   4532J Boelter Hall
   Los Angeles, CA  90095

   Phone: +1 310 267 2254

Lear & Eggert           Expires November 20, 2011               [Page 8]