idnits 2.17.1 draft-lear-iana-timezone-database-04.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 (May 19, 2011) is 4726 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' -- Possible downref: Non-RFC (?) normative reference: ref. '1' Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 3 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: November 20, 2011 UCLA 6 May 19, 2011 8 IANA Procedures for Maintaining the Timezone Database 9 draft-lear-iana-timezone-database-04 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 November 20, 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 ISO/IEC 9899 C and 71 IEEE 1003.1 POSIX time functions that can be used to convert time 72 values. 74 The database has been maintained by volunteers who participate in a 75 mailing list [1] that is also hosted at the NIH. The database itself 76 is updated approximately twenty times per year, depending on the 77 year, based on information these experts provide to the maintainer. 78 Arthur David Olson has maintained the database, coordinated the 79 mailing list, and provided a release platform since the database's 80 inception. With his retirement now approaching it is necessary to 81 provide a means for this good work to continue. 83 The IANA provides registry services to the Internet community. Those 84 registries are coordinated by technical experts who are designated by 85 the Internet Engineering Steering Group (IESG). The IANA is also 86 well suited as a distribution platform for the TZ Database itself. 88 The IANA has for quite some time had the capability to maintain 89 designated expert mailing lists. The TZ mailing list would fit 90 nicely as just such a list. 92 1.1. Terminology 94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 95 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 96 document are to be interpreted as described in RFC 2119 [RFC2119]. 98 TZ Database: The TimeZone Database, sometimes referred to as the 99 Olson Database. This database consists of information about 100 offsets from UTC for different localities, including daylight 101 saving time (DST) transition information. 102 TZ Coordinator: The person or people who maintain and manage release 103 of the TZ Database. The TZ Coordinator also has responsibility 104 for managing the TZ mailing list. The TZ Coordinator is an IANA 105 Designated Expert, as defined in Section 3.2 of [RFC5226], except 106 as regards to appeals, as discussed in Section 5. Roughly 107 speaking, this means that the IESG will choose one or more experts 108 to manage the TZ database, code, and mailing list. The TZ 109 Coordinator will also work with the IANA to develop appropriate 110 service metrics. There SHALL be a single lead individual and at 111 least one backup individual for this function. 112 TZ mailing list: The forum where matters relating to the TZ database 113 and supporting code are discussed. 115 The rest of this document specifies the following: 117 1. Transferring and maintenance of the TZ mailing list; 118 2. Procedures for selecting a technical expert who will play the 119 role of TZ Coordinator and release manager for the TZ database; 120 3. Procedures for updating the TZ database; 121 4. Maintenance and ownership of reference code; and 122 5. Ownership of the database. 124 2. The TZ Mailing List 126 For many years the TZ mailing list at the National Institutes of 127 Health (NIH) has been the forum where discussion of changes to the TZ 128 database and support files would take place. In addition, the TZ 129 mailing list is used to announce releases of the database. Currently 130 the TZ mailing list is administered by the TZ Coordinator. 132 This list membership will be transitioned to the IANA mail server. 133 The TZ Coordinator will continue to manage the list. While the TZ 134 Coordinator may establish other rules of governance for the list, 135 members of that list will be informed that a condition of 136 participating on the list is that all contributions to the list are 137 released to the public domain, and that by placing their contribution 138 in the public domain, contributors waive forever any intellectual 139 property claims. 141 The list will be used just as it has been: to learn of, discuss, and 142 confirm TZ definition changes, as well as to serve as an announcement 143 list for new versions of the database. 145 3. Making Updates to the TZ Database 147 Updates to the TZ database are made by the TZ Coordinator in 148 consultation with the TZ mailing list. TZ Coordinator is empowered 149 to decide, as the designated expert, appropriate changes, but SHOULD 150 take into account views expressed on the mailing list. 152 The TZ Coordinator will also decide the timing of database releases. 153 The release itself today consists of several archive files that are 154 downloaded from a well known location. 156 Moving forward, the TZ database, supporting code, and any appropriate 157 supporting information SHOULD be signed prior to release using well 158 known public keys, along with any appropriate supporting information 159 and distributed from a well known location that is advertised by IANA 160 in a manner of its choosing. 162 The criteria for updates to the database include the following: 164 1. New TZ names (e.g. locations) are only to be created when the 165 scope of the region a name was envisioned to cover is no longer 166 accurate. 167 2. In order to correct historical inaccuracies, a new TZ name MAY be 168 added when it is necessary to indicate what was the consensus 169 view at a given time and location. Such TZ names are usually not 170 added when the inaccuracy was prior to 1970. 171 3. Changes to existing entries SHALL reflect the consensus on the 172 ground in the region covered by that entry. 174 To be clear, the TZ Coordinator SHALL NOT set timezone policy for a 175 region but use judgment and whatever available sources exist to 176 assess what the average person on street would think the time 177 actually is, or in case of historical corrections, was. 179 4. Selecting or Replacing a TZ Coordinator 181 From time to time it will be necessary to appoint a new TZ 182 Coordinator. This could occur for a number of reasons: 184 o The TZ Coordinator is retiring (as Arthur Olson is) or has 185 announced that he or she will be unable to continue to perform the 186 function; 188 o The TZ Coordinator is missing, has become incapacitated, or has 189 died; or 190 o The TZ Coordinator is not performing the function in accordance 191 with community wishes. 193 In any of these cases, members of the community should raise the 194 issue on the TZ mailing list and attempt to reach consensus on a new 195 candidate to fulfill the role of TZ Coordinator. If rough consensus 196 cannot be reached easily, the Area Directors of the IETF Applications 197 Area should attempt to guide the members of the community to rough 198 consensus. The candidate that is agreed upon by the community 199 through rough consensus shall be presented to the IESG for 200 confirmation. If rough consensus cannot be reached even with 201 guidance from the Applications Area Directors, the IESG shall use 202 whatever means it has at its disposal to choose a candidate who in 203 its best judgment will be able to fulfill the role of TZ Coordinator. 205 5. Appealing Database Decisions 207 The TZ Coordinator makes decisions based on expertise, as well as 208 with guidance from the TZ mailing list. If a member of the community 209 has a concern with an individual decision made by the TZ Coordinator 210 with regard to the TZ database, the individual shall proceed as 211 follows: 213 1. Attempt to resolve the concern directly with the TZ Coordinator. 214 2. If a resolution cannot be reached directly with the TZ 215 Coordinator, express the concern to the community and attempt to 216 achieve rough consensus regarding a resolution on the TZ mailing 217 list. The Area Directors of the IETF Applications Area may at 218 their discretion attempt to guide the members of the community to 219 rough consensus. 220 3. As a last resort if a resolution cannot be reached on the TZ 221 mailing list, appeal to the IESG for a resolution. The appellant 222 must show that the decision made by the TZ Coordinator (a) was 223 materially in error and (b) has caused material harm. In its 224 deliberations regarding an appeal, the IESG shall weigh all the 225 evidence presented to it and use its best judgment in determining 226 a resolution. 228 6. Maintenance and Distribution of Reference Code 230 Currently the maintainer of the TZ database also maintains reference 231 code, most of which is public domain. Several files from this 232 software are currently distributed under license. Where they exist, 233 licenses SHALL NOT be changed. IANA SHALL allow for the downloading 234 of this reference code. The reference implementation shall be 235 distributed along with an associated cryptographic signature 236 verifiable by a public key that IANA will publish. 238 7. Database Ownership 240 The TZ database itself is not an IETF Contribution or an IETF 241 Document. Rather it is a pre-existing and regularly updated work 242 that is in the public domain, and is intended to remain in the public 243 domain. Therefore, BCP 78 and BCP 79 do not apply to the TZ Database 244 or contributions that individuals make to it. Should any claims be 245 made and substantiated against the database, the IANA will act in 246 accordance with all competent court orders. No ownership claims will 247 be made by IANA or the IETF Trust on the database or the code. Any 248 person making a contribution to the database or code waives all 249 rights to future claims. 251 8. IANA Considerations 253 If requested to do so, the IANA SHALL assist the IESG in selection of 254 the TZ Coordinator, based on the procedures set forth above. The 255 IANA SHALL act as a repository for the TZ database and associated 256 reference code. The TZ Coordinator SHALL be named by the IESG as 257 described above, and will act as the maintainer of the database and 258 code, as described above. The IANA SHALL provide the TZ Coordinator 259 with appropriate access to maintain the database, as well as 260 necessary tooling that may be required, so long as no direct software 261 costs are incurred. Both current and historical versions of the 262 database will be stored and distributed via HTTP/HTTPs. IANA will be 263 operationally responsible for the security of the system upon which 264 the database resides. 266 The IANA SHALL also securely maintain a cryptographic private key 267 that is used to sign the database, and that will survive a change of 268 TZ Coordinator. 270 9. Security Considerations 272 The distribution of the database is currently not secured. This memo 273 states that moving forward the TZ database SHOULD be distributed with 274 a valid cryptographic signature. 276 10. Acknowledgments 278 The authors would like to thank the TZ mailing list for their 279 remarkable achievements over the many years. Thanks also to Marshall 280 Eubanks, S. Moonesamy, Peter Saint-Andre, Alexey Melenkov, Tony 281 Finch, Elwyn Davies, Alfred Hoenes, Ted Hardie, and Barry Leiba for 282 the improvements they made to this document. A special 283 acknowledgment should be given to Arthur David Olson for his 284 excellent stewardship. 286 11. Normative References 288 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 289 Requirement Levels", BCP 14, RFC 2119, March 1997. 291 [RFC4833] Lear, E. and P. Eggert, "Timezone Options for DHCP", 292 RFC 4833, April 2007. 294 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 295 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 296 May 2008. 298 [RFC5545] Desruisseaux, B., "Internet Calendaring and Scheduling 299 Core Object Specification (iCalendar)", RFC 5545, 300 September 2009. 302 [TZDB] Eggert, P. and A. Olson, "Sources for Time Zone and 303 Daylight Saving Time Data", 304 . 306 [1] 308 Appendix A. Changes 310 RFC-EDITOR: Please remove this section prior to publication. 312 o 03: Reviewer comments. Take out ATTENTION: comment. Add backup 313 coordinator. editorial nits. Add discussion of metrics. Modify 314 both TZ Coordinator selection process and appeal process per 315 Adrian's comments. Clarify process rules per Russ' comments. 316 Clarify that the criteria are not an exhaustive list. 317 o 02: Separate out from RFC5226 a bit; Simplify language around 318 submissions; host list to IANA; spelling corrections; clarify here 319 and there. 321 o 01: Proper reference to RFC5226, add acknowledgments, several 322 rewordings. 323 o Initial Revision 325 Authors' Addresses 327 Eliot Lear 328 Cisco Systems GmbH 329 Richtistrasse 7 330 Wallisellen, ZH CH-8304 331 Switzerland 333 Phone: +41 1 878 9200 334 Email: lear@cisco.com 336 Paul Eggert 337 UCLA 338 Computer Science Department 339 4532J Boelter Hall 340 Los Angeles, CA 90095 341 USA 343 Phone: +1 310 267 2254 344 Email: eggert@cs.ucla.edu