GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:bcp:bcp175

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]

/data/webs/external/dokuwiki/data/pages/rfc/bcp/bcp175.txt · Last modified: 2012/02/29 18:37 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki