idnits 2.17.1 draft-lear-iana-timezone-database-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 11, 2011) is 4757 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) -- Possible downref: Non-RFC (?) normative reference: ref. 'TZDB' Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Lear 3 Internet-Draft Cisco Systems GmbH 4 Intended status: BCP P. Eggert 5 Expires: October 13, 2011 UCLA 6 April 11, 2011 8 IANA Procedures for Maintaining the Timezone Database 9 draft-lear-iana-timezone-database-03 11 Abstract 13 Timezone information serves as a basic protocol element in protocols, 14 such as the calendaring suite and DHCP. The Timezone (TZ) Database 15 specifies the indices used in various protocols, as well as their 16 semantic meanings, for all localities throughout the world. This 17 database has been meticulously maintained and distributed free of 18 charge by a group of volunteers, coordinated by a single volunteer 19 who is now planning to retire. This memo specifies IANA procedures 20 involved with maintenance of the TZ database and associated code, 21 including how to submit proposed updates, how decisions for inclusion 22 of those updates are made, and the selection of a designated expert 23 BY AND FOR the timezone community. The intent of this memo is, to 24 the extent possible, document existing practice and provide a means 25 to ease succession. 27 Status of this Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on October 13, 2011. 44 Copyright Notice 46 Copyright (c) 2011 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 1. Introduction 61 The IETF has specified several standards that make use of timezone 62 information. Timezone names are used in DHCP to configure devices 63 with correct local time [RFC4833]. Timezone names can appear in the 64 TZID field of VEVENTs [RFC5545]. The normative reference for these 65 values is the TZ Database [TZDB]. Since the early 1980s, that 66 database, which has been in use on nearly all UNIX systems, Java 67 systems, and other sorts of systems has been hosted at the National 68 Institutes of Health. The database consists of both historic and 69 current entries for geographies throughout the world. Associated 70 with the database is a reference implementation of functions that can 71 be used to convert time values. 73 The database has been maintained by volunteers who participate in a 74 mailing list that is also hosted at the NIH. The database itself is 75 updated approximately twenty times per year, depending on the year, 76 based on information these experts provide to the maintainer. Arthur 77 David Olson has maintained the database, coordinated the mailing 78 list, and provided a release platform since the database's inception. 79 With his retirement now approaching it is necessary to provide a 80 means for this good work to continue. 82 The IANA provides registry services to the Internet community. Those 83 registries are coordinated by technical experts who are designated by 84 the Internet Engineering Steering Group (IESG). The IANA is also 85 well suited as a distribution platform for the TZ Database itself. 87 The IANA has for quite some time had the capability to maintain 88 designated expert mailing lists. The TZ mailing list would fit 89 nicely just as such a list. 91 1.1. Terminology 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 95 document are to be interpreted as described in RFC 2119 [RFC2119]. 97 TZ Database: The TimeZone Database, sometimes referred to as the 98 Olson Database. This database consists of information about 99 offsets from UTC for different localities, including daylight 100 saving time (DST) transition information. 101 TZ Coordinator: The person or people who maintain and manage release 102 of the TZ Database. The TZ Coordinator also has responsibility 103 for maintaining the TZ mailing list. The TZ Coordinator is an 104 IANA Designated Expert, as defined in Section 3.2 of [RFC5226]. 105 Roughly speaking, this means that the IESG will choose one or more 106 experts to manage the TZ database, code, and mailing list. The TZ 107 Coordinator will also work with the IANA to develop appropriate 108 service metrics. There SHALL be a single lead individual and at 109 least one backup individual for this function. 110 TZ mailing list: The forum where matters relating to the TZ database 111 and supporting code are discussed. 113 The rest of this document specifies the following: 115 1. Transferring and maintenance of the TZ mailing list; 116 2. Procedures for selecting a technical expert for the technical 117 expert who will play the role of TZ Coordinator and release 118 manager for the TZ database; 119 3. Procedures for updating the TZ database; 120 4. Maintenance and ownership of reference code; and 121 5. Ownership of the database. 123 2. The TZ Mailing List 125 For many years the TZ mailing list at the NIH has been the forum 126 where discussion of changes to the TZ database and support files 127 would take place. In addition, the TZ mailing list is used to 128 announce releases of the database. Currently the TZ mailing list is 129 administered by the TZ Coordinator. 131 This list membership will be transitioned to the IANA mail server. 132 The TZ Coordinator will continue to manage the list. While the TZ 133 Coordinator may establish other rules of governance for the list, 134 members of that list will be informed that a condition of 135 participating on the list is that all contributions to the list are 136 released to the public domain, and that by placing their contribution 137 in the public domain, contributors waive forever any intellectual 138 property claims. 140 The list will be used just as it has been, to learn of, discuss, and 141 confirm TZ definition changes, as well as an announcement list for 142 new versions of the database. 144 3. Making Updates to the TZ Database 146 Updates to the TZ database are made by the TZ Coordinator in 147 consultation with the TZ mailing list. TZ Coordinator is empowered 148 to decide, as the designated expert, appropriate changes, but SHOULD 149 take into account views expressed on the mailing list. 151 The TZ Coordinator will also decide the timing of database releases. 152 The release itself today consists of several archive files that are 153 downloaded from a well known location. 155 Moving forward, the TZ database and supporting code SHOULD be signed 156 prior to release using a well known key, along with any appropriate 157 supporting information and distributed from a well known location 158 that is advertised by IANA in a manner of its choosing. 160 The criteria for updates to the database are as follows: 162 1. New keys are only to be created when the region a key was 163 envisioned to cover is not accurately reflected by an existing 164 key. 165 2. In order to correct historical inaccuracies, a new key MAY be 166 added when it is necessary to indicate what was the consensus 167 view at given time and location. Such keys are usually not added 168 when the inaccuracy was prior to 1970. 169 3. Changes to existing entries SHALL reflect the consensus on the 170 ground in the region covered by that entry. 172 To be clear, the TZ Coordinator SHALL NOT set timezone policy policy 173 for a region but use judgment and whatever available sources exist to 174 assess what the average person on street would think the time 175 actually is, or in case of historical corrections, was. 177 4. Selecting or Replacing a TZ Coordinator 179 From time to time it will be necessary to appoint a new TZ 180 Coordinator. This could occur for a number of reasons: 182 o The TZ Coordinator is retiring (as Arthur Olson is) or has 183 announced that he or she will be unable to continue to perform the 184 function; 185 o The Coordinator is missing, has become incapacitated, or has died; 186 or 187 o The Coordinator is not performing the function in accordance with 188 community wishes. 190 In any of these cases, members of the community should raise the 191 issue on the TZ list. If a rough consensus can be formed easily, and 192 quickly, then the results should be presented to the IESG for comment 193 and review. The IESG selects the TZ Coordinator(s). The IESG will 194 use rough consensus of the TZ mailing list as their primary guide to 195 further action, when it exists, and whatever other means they have at 196 their disposal, when rough consensus cannot be found. 198 5. Appealing Database Decisions 200 The TZ Coordinator makes decisions based on expertise, as well as 201 with guidance from the TZ mailing lists. While individual decisions 202 MAY be appealed to the IESG, the IESG MUST give great deference to 203 the designated expert in its considerations. In particular, 204 apellants MUST show material harm from the decision, and that the 205 decision is materially in error. The IESG is not a normal avenue for 206 appeals of specific decisions of the TZ Coordinator, but rather a 207 last resort when a TZ Coordinator is thought not to be functioning in 208 an appropriate way. 210 6. Maintenance and Distribution of Reference Code 212 Currently the maintainer of the TZ database also maintains reference 213 code, most of which is public domain. Several files from this 214 software are currently distributed under license. Where they exist, 215 licenses SHALL NOT be changed. IANA SHALL allow for the downloading 216 of this reference code. The reference implementation shall be 217 distributed along with an associated cryptographic signature of an 218 identity that IANA will publish. 220 7. Database Ownership 222 The database itself is public domain. Should claims be made and 223 substantiated against the database, the IANA will act in accordance 224 with all competent court orders. No ownership claims will be made by 225 IANA or the IETF Trust on the database or the code. Any person 226 making a contribution to the database or code waives all rights to 227 future claims. 229 8. IANA Considerations 231 The IANA SHALL assist the IESG, as required, in filling of the TZ 232 Coordinator, based on the procedures set forth above. The IANA SHALL 233 act as a repository for the TZ database and associated reference 234 code. The TZ Coordinator SHALL be named by the IESG as described 235 above, and will act as the maintainer of the database and code, as 236 described above. The IANA SHALL provide the TZ Coordinator with 237 appropriate access to maintain the database, as well as necessary 238 tooling that may be required, so long as no direct software costs are 239 incurred. Both current and historical versions of the database will 240 be stored and distributed via HTTP/HTTPs. IANA will be operationally 241 responsible for the security of the system upon which the database 242 resides. 244 The IANA SHALL also maintain a cryptographic identity that is used to 245 sign the database, and that will survive a change of TZ Coordinators. 247 9. Security Considerations 249 The distribution of the database is currently not secured. This memo 250 states that moving forward the TZ database SHOULD be distributed with 251 a valid cryptographic signature. 253 10. Acknowledgments 255 The authors would like to thank the TZ mailing list for their 256 remarkable achievements over the many years. Thanks also to Marshall 257 Eubanks, S. Moonesamy, Peter Saint-Andre, Alexey Melenkov, Tony 258 Finch, Elwin Davies, Alfred Hoenes, and Ted Hardie for the 259 improvements they made to this document. A special acknowledgment 260 should be given to Arthur David Olson for his excellent stewardship. 262 11. Normative References 264 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 265 Requirement Levels", BCP 14, RFC 2119, March 1997. 267 [RFC4833] Lear, E. and P. Eggert, "Timezone Options for DHCP", 268 RFC 4833, April 2007. 270 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 271 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 272 May 2008. 274 [RFC5545] Desruisseaux, B., "Internet Calendaring and Scheduling 275 Core Object Specification (iCalendar)", RFC 5545, 276 September 2009. 278 [TZDB] Eggert, P. and A. Olson, "Sources for Time Zone and 279 Daylight Saving Time Data", 280 . 282 Appendix A. Changes 284 o 03: Take out ATTENTION: comment. Add backup coordinator. 285 editorial nits. Add discussion of metrics. 286 o 02: Separate out from RFC5226 a bit; Simplify language around 287 submissions; host list to IANA; spelling corrections; clarify here 288 and there. 289 o 01: Proper reference to RFC5226, add acknowledgments, several 290 rewordings. 291 o Initial Revision 293 Authors' Addresses 295 Eliot Lear 296 Cisco Systems GmbH 297 Richtistrasse 7 298 Wallisellen, ZH CH-8304 299 Switzerland 301 Phone: +41 1 878 9200 302 Email: lear@cisco.com 304 Paul Eggert 305 UCLA 306 Computer Science Department 307 4532J Boelter Hall 308 Los Angeles, CA 90095 309 USA 311 Phone: +1 310 267 2254 312 Email: eggert@cs.ucla.edu