idnits 2.17.1 draft-lear-iana-timezone-database-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 (December 17, 2010) is 4878 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: 2 errors (**), 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: June 20, 2011 UCLA 6 December 17, 2010 8 IANA Procedures for Maintaining the Timezone Database 9 draft-lear-iana-timezone-database-01 11 Abstract 13 ATTENTION: This memo contains a DRAFT proposal for the IANA to assume 14 operational responsibilities relating to the management of the 15 Timezone (TZ) Database. The authors seek comment and review of this 16 proposal. No action will be taken without rough consensus of the TZ 17 community. 19 The Timezone (TZ) Database consists of timezone information for all 20 localities throughout the world. This database has been meticulously 21 maintained and distributed free of charge by a group of volunteers, 22 coordinated by a single volunteer who is now planning to retire. 23 This memo specifies a DRAFT PROPOSAL for the IANA procedures involved 24 with maintenance of the TZ database and associated code, including 25 how to submit proposed updates, how decisions for inclusion of those 26 updates are made, and the selection of a designated expert BY AND FOR 27 the timezone community. The intent of this memo is, to the extent 28 possible, document existing practice and provide a means to ease 29 succession. 31 Status of this Memo 33 This Internet-Draft is submitted to IETF in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF), its areas, and its working groups. Note that 38 other groups may also distribute working documents as Internet- 39 Drafts. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 The list of current Internet-Drafts can be accessed at 47 http://www.ietf.org/ietf/1id-abstracts.txt. 49 The list of Internet-Draft Shadow Directories can be accessed at 50 http://www.ietf.org/shadow.html. 52 This Internet-Draft will expire on June 20, 2011. 54 Copyright Notice 56 Copyright (c) 2010 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (http://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the BSD License. 69 1. Introduction 71 ATTENTION: This memo contains a DRAFT proposal for the IANA to assume 72 operational responsibilities relating to the management of the 73 Timezone (TZ) Database. The authors seek comment and review of this 74 proposal. No action will be taken without rough consensus of the TZ 75 community. 77 Since the early 1980s, a database that is in use on nearly all UNIX 78 systems, Java systems, and other sorts of systems has been hosted at 79 the National Institutes of Health. [TZDB] The database consists of 80 both historic and current entries for geographies throughout the 81 world. Associated with the database is a reference implementation of 82 functions that can be used to convert time values. 84 The database has been maintained by volunteers that participate in a 85 mailing list that is also hosted at the NIH. The database itself is 86 updated approximately twenty times per year, depending on the year, 87 based on information these experts provide to the maintainer. Arthur 88 David Olson has maintained the database, coordinated the mailing 89 list, and provided a release platform since the database's inception. 90 With his retirement now approaching it is necessary to provide a 91 means for this good work to continue. The Internet community owes 92 Arthur Olson and the volunteers on the tz mailing list a debt of 93 gratitude. 95 The IANA provides registry services to the Internet community. Those 96 registries are coordinated by technical experts who are designated by 97 the Internet Engineering Steering Group (IESG). The IANA is also 98 well suited as a distribution platform for the TZ database itself. 100 The IETF has for quite some time had the capability to maintain non- 101 working group mailing lists. The TZ mailing list would fit nicely 102 just as such a list. 104 1.1. Terminology 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 108 document are to be interpreted as described in RFC 2119 [RFC2119]. 110 TZ Database The TimeZone Database, sometimes referred to as the 111 Olson Database. This database consists of information about 112 offsets from UTC for different localities, including daylight 113 savings time (DST) transition information. 114 TZ Coordinator The person or people who maintain and manage release 115 of the TZ Database. The TZ coordinator also has responsibility 116 for maintaining the TZ mailing list. The TZ coordinatior is a 117 Designated Expert, as defined in [RFC5226]. Roughly speaking, it 118 means that the IESG will choose one or more experts to manage the 119 TZ database, code, and mailing list. 120 TZ mailing list The forum where matters relating to the TZ database 121 and supporting code are discussed. 123 The rest of this document specifies the following: 125 1. Transferring and maintenance of the TZ mailing list; 126 2. Procedures for selecting a technical expert for the technical 127 expert who will play the role of coordinator, as well as release 128 manager for the TZ database; 129 3. Procedures for updating the TZ database; 130 4. Maintenance and ownership of reference code; and 131 5. Ownership of the database. 133 2. The TZ Mailing List 135 For many years the TZ mailing list at the NIH has been the forum 136 where discussion of changes to the TZ database and support files 137 would take place. In addition, the TZ mailing list is used to 138 announce releases of the database. Currently the TZ mailing list is 139 administered by the TZ coordinator. 141 This list membership will be transitioned to the IETF mail server. 142 The TZ coordinator will continue to manage the list, in accordance 143 with rules of governance for non-WG mailing lists, with the following 144 exception: instead of the normal "Note Well" statement, the following 145 statement shall apply in its place: 147 The Contributor, each named co-Contributor, and the organizations 148 represented above irrevocably and in perpetuity grant the rights 149 listed below to the Internet Community: 151 1. to prepare or allow the preparation of translations of the TZ 152 database into languages other than English, 153 2. to prepare derivative works (other than translations) that are 154 based on or incorporate all or part of the TZ Contribution, or 155 comment upon it. The license to such derivative works shall not 156 grant the IETF Trust, the IETF, or other party preparing a 157 derivative work any more rights than the license to the original 158 TZ Contribution, and 159 3. to reproduce any trademarks, service marks, or trade names that 160 are included in the TZ Contribution solely in connection with the 161 reproduction, distribution, or publication of the TZ Contribution 162 and derivative works. 164 The list will be used just as it has been, to learn of, discuss, and 165 confirm TZ definition changes, as well as an announcement list for 166 new versions of the database. The TZ coordinator will continue to 167 manage the list. 169 3. Making Updates to the TZ Database 171 Updates to the TZ database are made by the TZ coordinator in 172 consultation with the TZ mailing list. TZ coordinator is empowered 173 to decide, as the designated expert, appropriate changes, but SHOULD 174 take into account views expressed on the mailing list. 176 The TZ coordinator will also decide the timing of database releases. 177 The release itself today consists of several tar files that are 178 downloaded from a well known location. 180 Moving forward, the TZ database SHOULD be signed prior to release 181 using a well known key, along with any appropriate supporting 182 information and distributed from a well known location that is 183 advertised by IANA in a manner of its choosing. 185 4. Selecting or Replacing a TZ Coordinator 187 From time to time it will be necessary to appoint a TZ Coordinator. 188 This could occur for a number of reasons: 190 o The coordinator is retiring (as Arthur Olson is) or has announced 191 that he or she will be unable to continue to perform the function; 192 o The coordinator is missing or has died; 193 o The coordinator is not performing the function in accordance with 194 community wishes. 196 In any of these cases, members of the community should raise the 197 issue on the TZ list. If a rough consensus can be formed easily, and 198 quickly, then the results should be presented to the IESG for comment 199 and review. In keeping with [RFC5226], the IESG selects the TZ 200 coordinator(s). The IESG will use rough consensus of the TZ mailing 201 list as their primary guide to further action, when it exists, and 202 whatever other means they have at their disposal, when rough 203 consensus cannot be found. As RFC-5226 states, the IESG is not a 204 normal avenue for appeals of specific decisions of the coordinator, 205 but rather a last resort when a coordinator is thought not to be 206 functioning in an appropriate way. 208 N.B., the coordinator is a function, and may be filled by one OR MORE 209 people, as the community sees fit. 211 5. Maintenance and Distribution of Reference Code 213 Currently the maintainer of the TZ database also maintains reference 214 code, most of which is public domain. Several files from this 215 software are currently distributed under license. No change shall be 216 made to licenses, where they exist. IANA shall allow for the 217 downloading of this reference code. The reference implementation 218 shall be distributed along with an associated cryptographic signature 219 of an identity that IANA will publish. 221 6. Database Ownership 223 The database itself is public domain. Should claims be made and 224 substantiated against the database, the IANA will act in accordance 225 with all competent court orders. No ownership claims will be made by 226 IANA, the IETF Trust, or ISOC on the database or the code. 228 7. IANA Considerations 230 The IANA will assist the IESG, as required, in filling of the TZ 231 Coordinator, based on the procedures set forth above. The IANA will 232 act as a repository for the TZ database and associated reference 233 code. The database coordinator will be named by the IESG as 234 described above, and will act as the maintainer of the database and 235 code, as described above. The IANA will provide the TZ coordinator 236 with appropriate access to maintain the database, as well as 237 necessary tooling that may be required, so long as no direct software 238 costs are incurred. Both current and historical versions of the 239 database will be stored and distributed via HTTP/HTTPs. IANA will be 240 operationally responsible for the security of the system upon which 241 the database resides. 243 The IANA will also maintain a cryptographic identity that is used to 244 sign the database, and that will survive a change of coordinators. 246 8. Security Considerations 248 The distribution of the database is currently not secured. This memo 249 states that moving forward the TZ database SHOULD be distributed with 250 a valid cryptographic signature. 252 9. Acknowledgments 254 The authors would like to thank the TZ mailing list for their 255 remarkable achievements over the many years. Thanks also to Marshall 256 Eubanks, S. Moonesamy, Peter Saint-Andre, Alexey Melenkov, and Tony 257 Finch for the improvements they made to this document. A special 258 acknowledgment should be given to Arthur David Olson for his 259 excellent stewardship. 261 10. Normative References 263 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 264 Requirement Levels", BCP 14, RFC 2119, March 1997. 266 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 267 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 268 May 2008. 270 [TZDB] Eggert, P. and A. Olson, "Sources for Time Zone and 271 Daylight Saving Time Data", 272 . 274 Appendix A. Changes 276 o 01: Proper reference to RFC5226, add acknowledgments, several 277 rewordings. 279 o Initial Revision 281 Authors' Addresses 283 Eliot Lear 284 Cisco Systems GmbH 285 Richtistrasse 7 286 Wallisellen, ZH CH-8304 287 Switzerland 289 Phone: +41 1 878 9200 290 Email: lear@cisco.com 292 Paul Eggert 293 UCLA 294 Computer Science Department 295 4532J Boelter Hall 296 Los Angeles, CA 90095 297 USA 299 Phone: +1 310 267 2254 300 Email: eggert@cs.ucla.edu