One document matched: draft-lear-iana-timezone-database-05.xml

<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<!-- change this to yes to create a table of contents -->
<!-- change this to no to create a document with lots of whitespace -->
<?rfc symrefs="yes" compact="yes" strict="yes" rfcprocack="yes" ?>
<?rfc linkmailto="yes" ?>
<rfc ipr="trust200902" category="bcp"
     docName="draft-lear-iana-timezone-database-05" >

<front>
<title abbrev="Maintaining the Timezone Database">
Procedures for Maintaining the Timezone Database
</title>
    <author fullname="Eliot Lear" initials="E." surname="Lear">
      <organization>Cisco Systems GmbH</organization>
      <address>
        <postal>
          <street>Richtistrasse 7</street>
          <city>Wallisellen</city>
          <code>CH-8304</code>
          <region>ZH</region>
          <country>Switzerland</country>
        </postal>
        <phone>+41 1 878 9200</phone>
        <email>lear@cisco.com</email>
      </address>
     </author>
    <author fullname="Paul Eggert" initials="P" surname="Eggert">
      <organization>UCLA</organization>
      <address>
        <postal>
	  <street>Computer Science Department</street>
          <street>4532J Boelter Hall</street>
          <city>Los Angeles</city>
          <code>90095</code>
          <region>CA</region>
          <country>USA</country>
        </postal>
        <phone>+1 310 267 2254</phone>
        <email>eggert@cs.ucla.edu</email>
      </address>
    </author>
    <date year="2012" />

<abstract>
<t>
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 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 of the database maintainers.
</t>
</abstract>
</front>

<middle>
<section title="Introduction">
<t>
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 <xref target="RFC4833" />.  Timezone names can
appear in the TZID field of calendaring VEVENTs <xref target="RFC5545" />.  The
      normative reference for these values is
      the <xref target="TZDB">TZ Database</xref>.
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 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 and IEEE 1003.1 POSIX time functions that can be used
to convert time values.
</t>
<t>
The database was previously maintained by volunteers who participate in a
<eref target="mailto:tz@elsie.nci.nih.gov">mailing
list</eref> 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.
</t>
<t>
The Time Zone Community with the retirement of the volunteer experts
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.
</t>
<section title="Terminology">
      <t>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 <xref target="RFC2119"/>.</t>
<t>
<list style="hanging">
<t hangText="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 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 Registry, which was signed and
ratified in March of 2000<xref target="RFC2860"/>. 
</t>
<t hangText="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.
</t>
<t hangText="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 <xref target="RFC5226" />, except
as regards to appeals, as discussed in <xref target="appeals" />.
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.
</t>
<t hangText="TZ mailing list:">
The forum where matters relating to the TZ database and supporting
code are discussed.
</t>
</list>
</t>
<t>The rest of this document specifies the following:
</t>
<t>
<list style="numbers">
<t>Transferring and maintenance of the TZ mailing list;</t>
<t>Procedures for selecting a technical expert who will play 
  the role of TZ Coordinator and release  manager
  for the TZ database;
</t><t>Procedures for updating the TZ database; 
</t><t>Maintenance and ownership of reference code; and
</t><t>Ownership of the database.
</t>
</list>
</t>
</section>
</section>
<section title="The TZ Mailing List">
<t>
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.</t>
<t>
This list membership will be transitioned to the IANA mail server.
Its address, moving forward, is tz@iana.org.  Subscriptions are
processed at <eref target="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.
</t>
<t>
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.
</t>
</section>
<section title="Making Updates to the TZ Database">
<t>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.</t>
<t>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.</t>
<t>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.
</t>
<t>The criteria for updates to the database include the following:
</t>
<t>
<list style="numbers">
<t>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.
</t>
<t>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.
</t>
<t>Changes to existing entries SHALL reflect the consensus on the
  ground in the region covered by that entry.
</t>
</list>
</t>
<t>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.
</t>
</section>
<section title="Selecting or Replacing a TZ Coordinator">
<t>From time to time it will be necessary to appoint a new TZ
  Coordinator.  This could occur for a number of reasons:
</t>
<t>
<list style="symbols">
<t>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;</t>
<t>The TZ Coordinator is missing, has become incapacitated, or has died; or</t>
<t>The TZ Coordinator is not performing the function in accordance with
  community wishes.</t>
</list>
</t>
<t>
   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.
</t>
</section>
<section title="Appealing Database Decisions" anchor="appeals" >
<t>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:
</t>
<t>
<list style="numbers">
<t>Attempt to resolve the concern directly with the TZ Coordinator.
</t>
<t>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.
</t>
<t>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.
</t>
</list>
</t>
</section>
<section title="Maintenance and Distribution of Reference Code">
<t>
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.
</t>
</section>
<section title="Database Ownership">
<t>
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 TZ Database,
the organization that is providing the IANA Considerations defined in
this RFC, under the MOU 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.
</t>

</section>
<section title="IANA Considerations">
<t>
This section documents the following IANA actions:
</t>
<t>
<list style="symbols">
<t>Assistance on request of the IESG in selection of the TZ
  Coordinator, based on the procedures set forth above.
</t>
<t>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.
</t>
<t>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.  
</t>
<t>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.
</t>
<t>Maintenance of a cryptographic private key that is used to sign
  the database, and that will survive a change of TZ Coordinator.
</t>
</list>
</t>
</section>
<section title="Security Considerations">
<t>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.
</t>
</section>
<section title="Acknowledgments">
<t>
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.
</t>
</section>
<!-- THIS is essentially the end of the document. -->
</middle>
<back>

<references title="Normative References">
<?rfc include="reference.RFC.2119" ?>
<?rfc include="reference.RFC.2860" ?>
<?rfc include="reference.RFC.5226" ?>
<reference anchor="TZDB" target="http://www.iana.org/time-zones">
<front>
<title>Sources for Time Zone and Daylight Saving Time Data</title>
    <author fullname="Paul Eggert" initials="P" surname="Eggert">
      <organization>UCLA</organization>
    </author>
    <author fullname="Arthur David Olson" initials="A.D."
    surname="Olson">
    <organization>National Institutes of Health</organization>
    </author>
    <date year="1987" />
    <abstract>
      <t />
    </abstract>
</front>
</reference>
</references>
<references title="Informational References">
<?rfc include="reference.RFC.4833" ?>
<?rfc include="reference.RFC.5545" ?>
</references>

<section title="Changes">
<t>
RFC-EDITOR: Please remove this section prior to publication.
</t>
<t>
<list style="symbols">
<t>05: Edits to address IANA considerations.</t>
<t>04: Additional edits based on IESG review.</t>
<t>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.</t>
<t>02: Separate out from RFC5226 a bit; Simplify language around
  submissions; host list to IANA;
  spelling corrections; clarify here and there.</t>
<t>01: Proper reference to RFC5226, add acknowledgments, several
  rewordings.</t>
<t>Initial Revision</t>
</list>
</t>
</section>
</back>
</rfc>