idnits 2.17.1 draft-lear-iana-timezone-database-05.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 == Line 126 has weird spacing: '...release manag...' -- The document date (February 14, 2012) is 4427 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) -- Looks like a reference, but probably isn't: '1' on line 74 -- Looks like a reference, but probably isn't: '2' on line 144 ** Downref: Normative reference to an Informational RFC: RFC 2860 ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) -- Possible downref: Non-RFC (?) normative reference: ref. 'TZDB' Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 4 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: Best Current Practice P. Eggert 5 Expires: August 15, 2012 UCLA 6 February 14, 2012 8 Procedures for Maintaining the Timezone Database 9 draft-lear-iana-timezone-database-05 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 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 of the database maintainers. 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 August 15, 2012. 44 Copyright Notice 46 Copyright (c) 2012 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 (http://trustee.ietf.org/ 51 license-info) in effect on the date of publication of this document. 52 Please review these documents carefully, as they describe your rights 53 and restrictions with respect to this document. Code Components 54 extracted from this document must include Simplified BSD License text 55 as described in Section 4.e of the Trust Legal Provisions and are 56 provided without warranty as described in the Simplified BSD License. 58 1. Introduction 60 The IETF has specified several standards that make use of timezone 61 information. Timezone names are used in DHCP to configure devices 62 with correct local time [RFC4833]. Timezone names can appear in the 63 TZID field of calendaring VEVENTs [RFC5545]. The normative reference 64 for these values is the TZ Database [TZDB]. Since the early 1980s, 65 that database, which has been in use on nearly all UNIX systems, Java 66 systems, and other sorts of systems has been hosted at the U.S. 67 National Institutes of Health (NIH). The database consists of both 68 historic and current entries for geographies throughout the world. 69 Associated with the database is a reference implementation of ISO/IEC 70 9899 C and IEEE 1003.1 POSIX time functions that can be used to 71 convert time values. 73 The database was previously maintained by volunteers who participate 74 in a mailing list [1] that is also hosted at the NIH. The database 75 itself is updated approximately twenty times per year, depending on 76 the year, based on information these experts provide to the 77 maintainer. Arthur David Olson has maintained the database, 78 coordinated the mailing list, and provided a release platform since 79 the database's inception. With his retirement now approaching it is 80 necessary to provide a means for this good work to continue. 82 The Time Zone Community with the retirement of the volunteer experts 83 has requested that the IETF adopt the ongoing maintenance of the Time 84 Zone Database. The Time Zone community would like the IETF to 85 maintain it in a consistent fashion to its administration of the 86 Internet protocol parameters and values. 88 1.1. Terminology 90 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 91 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 92 document are to be interpreted as described in RFC 2119 [RFC2119]. 94 IANA (Internet Assigned Numbers Authority): For purposes of this RFC, 95 IANA is a role, not an organization. The IANA Considerations 96 defined in this RFC will be provided by Internet Corporation for 97 Assigned Names and Numbers (ICANN) in accordance with the IETF- 98 ICANN Memorandum of Understanding Concerning Technical Work of the 99 Internet Assigned Numbers Registry, which was signed and ratified 100 in March of 2000[RFC2860]. 102 TZ Database: The TimeZone Database, sometimes referred to as the 103 Olson Database. This database consists of information about 104 offsets from UTC for different localities, including daylight 105 saving time (DST) transition information. 107 TZ Coordinator: The person or people who maintain and manage release 108 of the TZ Database. The TZ Coordinator also has responsibility 109 for managing the TZ mailing list. The TZ Coordinator is an IANA 110 Designated Expert, as defined in Section 3.2 of [RFC5226], except 111 as regards to appeals, as discussed in Section 5. Roughly 112 speaking, this means that the IESG will choose one or more experts 113 to manage the TZ database, code, and mailing list. The TZ 114 Coordinator will also lead work to develop appropriate service 115 metrics. There SHALL be a single lead individual and at least one 116 backup individual for this function. 118 TZ mailing list: The forum where matters relating to the TZ database 119 and supporting code are discussed. 121 The rest of this document specifies the following: 123 1. Transferring and maintenance of the TZ mailing list; 125 2. Procedures for selecting a technical expert who will play the 126 role of TZ Coordinator and release manager for the TZ database; 128 3. Procedures for updating the TZ database; 130 4. Maintenance and ownership of reference code; and 132 5. Ownership of the database. 134 2. The TZ Mailing List 136 For many years the TZ mailing list at the National Institutes of 137 Health (NIH) has been the forum where discussion of changes to the TZ 138 database and support files would take place. In addition, the TZ 139 mailing list is used to announce releases of the database. Currently 140 the TZ mailing list is administered by the TZ Coordinator. 142 This list membership will be transitioned to the IANA mail server. 143 Its address, moving forward, is tz@iana.org. Subscriptions are 144 processed at [2]. The TZ Coordinator will continue to manage the 145 list. While the TZ Coordinator may establish other rules of 146 governance for the list, members of that list will be informed that a 147 condition of participating on the list is that all contributions to 148 the list are released to the public domain, and that by placing their 149 contribution in the public domain, contributors waive forever any 150 intellectual property claims. 152 The list will be used just as it has been: to learn of, discuss, and 153 confirm TZ definition changes, as well as to serve as an announcement 154 list for new versions of the database. 156 3. Making Updates to the TZ Database 158 Updates to the TZ database are made by the TZ Coordinator in 159 consultation with the TZ mailing list. TZ Coordinator is empowered 160 to decide, as the designated expert, appropriate changes, but SHOULD 161 take into account views expressed on the mailing list. 163 The TZ Coordinator will also decide the timing of database releases. 164 The release itself today consists of several archive files that are 165 downloaded from a well known location. 167 Moving forward, the TZ database, supporting code, and any appropriate 168 supporting information SHOULD be cryptographically signed prior to 169 release using well known public keys, along with any appropriate 170 supporting information and distributed from http://www.iana.org/time- 171 zones. 173 The criteria for updates to the database include the following: 175 1. New TZ names (e.g. locations) are only to be created when the 176 scope of the region a name was envisioned to cover is no longer 177 accurate. 179 2. In order to correct historical inaccuracies, a new TZ name MAY be 180 added when it is necessary to indicate what was the consensus 181 view at a given time and location. Such TZ names are usually not 182 added when the inaccuracy was prior to 1970. 184 3. Changes to existing entries SHALL reflect the consensus on the 185 ground in the region covered by that entry. 187 To be clear, the TZ Coordinator SHALL NOT set timezone policy for a 188 region but use judgment and whatever available sources exist to 189 assess what the average person on street would think the time 190 actually is, or in case of historical corrections, was. 192 4. Selecting or Replacing a TZ Coordinator 194 From time to time it will be necessary to appoint a new TZ 195 Coordinator. This could occur for a number of reasons: 197 o The TZ Coordinator is retiring (as Arthur Olson is) or has 198 announced that he or she will be unable to continue to perform the 199 function; 201 o The TZ Coordinator is missing, has become incapacitated, or has 202 died; or 204 o The TZ Coordinator is not performing the function in accordance 205 with community wishes. 207 In any of these cases, members of the community should raise the 208 issue on the TZ mailing list and attempt to reach consensus on a new 209 candidate to fulfill the role of TZ Coordinator. If rough consensus 210 cannot be reached easily, the Area Directors of the IETF Applications 211 Area should attempt to guide the members of the community to rough 212 consensus. The candidate that is agreed upon by the community 213 through rough consensus shall be presented to the IESG for 214 confirmation. If rough consensus cannot be reached even with 215 guidance from the Applications Area Directors, the IESG shall use 216 whatever means it has at its disposal to choose a candidate who in 217 its best judgment will be able to fulfill the role of TZ Coordinator. 219 5. Appealing Database Decisions 221 The TZ Coordinator makes decisions based on expertise, as well as 222 with guidance from the TZ mailing list. If a member of the community 223 has a concern with an individual decision made by the TZ Coordinator 224 with regard to the TZ database, the individual shall proceed as 225 follows: 227 1. Attempt to resolve the concern directly with the TZ Coordinator. 229 2. If a resolution cannot be reached directly with the TZ 230 Coordinator, express the concern to the community and attempt to 231 achieve rough consensus regarding a resolution on the TZ mailing 232 list. The Area Directors of the IETF Applications Area may at 233 their discretion attempt to guide the members of the community to 234 rough consensus. 236 3. As a last resort if a resolution cannot be reached on the TZ 237 mailing list, appeal to the IESG for a resolution. The appellant 238 must show that the decision made by the TZ Coordinator (a) was 239 materially in error and (b) has caused material harm. In its 240 deliberations regarding an appeal, the IESG shall weigh all the 241 evidence presented to it and use its best judgment in determining 242 a resolution. 244 6. Maintenance and Distribution of Reference Code 246 Currently the maintainer of the TZ database also maintains reference 247 code, most of which is public domain. The reference implementation 248 shall be distributed along with an associated cryptographic signature 249 verifiable by a public key. Several files from this software are 250 currently distributed under license. Where they exist, licenses 251 SHALL NOT be changed. 253 7. Database Ownership 255 The TZ database itself is not an IETF Contribution or an IETF 256 Document. Rather it is a pre-existing and regularly updated work 257 that is in the public domain, and is intended to remain in the public 258 domain. Therefore, BCP 78 and BCP 79 do not apply to the TZ Database 259 or contributions that individuals make to it. Should any claims be 260 made and substantiated against the TZ Database, the organization that 261 is providing the IANA Considerations defined in this RFC, under the 262 MOU with the IETF, currently ICANN, may act in accordance with all 263 competent court orders. No ownership claims will be made by ICANN or 264 the IETF Trust on the database or the code. Any person making a 265 contribution to the database or code waives all rights to future 266 claims in that contribution or in the TZ Database. 268 8. IANA Considerations 270 This section documents the following IANA actions: 272 o Assistance on request of the IESG in selection of the TZ 273 Coordinator, based on the procedures set forth above. 275 o Maintenance of a repository for the TZ database and associated 276 reference code. The TZ Coordinator SHALL be named by the IESG as 277 described above, and will act as the maintainer of the database 278 and code, as described above. 280 o Creation of appropriate access for the TZ Coordinator to maintain 281 the database, as well as necessary tooling that may be required, 282 so long as no direct software costs are incurred. 284 o Establishment of security of the system upon which the database 285 resides. Both current and historical versions of the database 286 will be stored and distributed via HTTP/HTTPS. 288 o Maintenance of a cryptographic private key that is used to sign 289 the database, and that will survive a change of TZ Coordinator. 291 9. Security Considerations 293 The distribution of the database is currently not secured. This memo 294 states that moving forward the TZ database SHOULD be distributed with 295 a valid cryptographic signature. 297 10. Acknowledgments 299 The authors would like to thank the TZ mailing list for their 300 remarkable achievements over the many years. Thanks also to Marshall 301 Eubanks, S. Moonesamy, Peter Saint-Andre, Alexey Melenkov, Tony 302 Finch, Elwyn Davies, Alfred Hoenes, Ted Hardie, Barry Leiba, Russ 303 Housley, Pete Resnick, and Elise Gerich for the improvements they 304 made to this document. A special acknowledgment should be given to 305 Arthur David Olson for his excellent stewardship, to Rob Elz for 306 continuing that stewardship, and to the team at ICANN for their good 307 efforts, moving forward. 309 11. References 311 11.1. Normative References 313 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 314 Requirement Levels", BCP 14, RFC 2119, March 1997. 316 [RFC2860] Carpenter, B., Baker, F. and M. Roberts, "Memorandum of 317 Understanding Concerning the Technical Work of the 318 Internet Assigned Numbers Authority", RFC 2860, June 2000. 320 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 321 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 322 May 2008. 324 [TZDB] Eggert, P. and A.D. Olson, "Sources for Time Zone and 325 Daylight Saving Time Data", 1987, . 328 11.2. Informational References 330 [RFC4833] Lear, E. and P. Eggert, "Timezone Options for DHCP", RFC 331 4833, April 2007. 333 [RFC5545] Desruisseaux, B., "Internet Calendaring and Scheduling 334 Core Object Specification (iCalendar)", RFC 5545, 335 September 2009. 337 Appendix A. Changes 339 RFC-EDITOR: Please remove this section prior to publication. 341 o 05: Edits to address IANA considerations. 343 o 04: Additional edits based on IESG review. 345 o 03: Reviewer comments. Take out ATTENTION: comment. Add backup 346 coordinator. editorial nits. Add discussion of metrics. Modify 347 both TZ Coordinator selection process and appeal process per 348 Adrian's comments. Clarify process rules per Russ' comments. 349 Clarify that the criteria are not an exhaustive list. 351 o 02: Separate out from RFC5226 a bit; Simplify language around 352 submissions; host list to IANA; spelling corrections; clarify here 353 and there. 355 o 01: Proper reference to RFC5226, add acknowledgments, several 356 rewordings. 358 o Initial Revision 360 Authors' Addresses 362 Eliot Lear 363 Cisco Systems GmbH 364 Richtistrasse 7 365 Wallisellen, ZH CH-8304 366 Switzerland 368 Phone: +41 1 878 9200 369 Email: lear@cisco.com 371 Paul Eggert 372 UCLA 373 Computer Science Department 374 4532J Boelter Hall 375 Los Angeles, CA 90095 376 USA 378 Phone: +1 310 267 2254 379 Email: eggert@cs.ucla.edu