< draft-lear-iana-timezone-database-03.txt		draft-lear-iana-timezone-database-04.txt >
	Network Working Group E. Lear		Network Working Group E. Lear
	Internet-Draft Cisco Systems GmbH		Internet-Draft Cisco Systems GmbH
	Intended status: BCP P. Eggert		Intended status: BCP P. Eggert
	Expires: October 13, 2011 UCLA		Expires: November 20, 2011 UCLA
	April 11, 2011		May 19, 2011
	IANA Procedures for Maintaining the Timezone Database		IANA Procedures for Maintaining the Timezone Database
	draft-lear-iana-timezone-database-03		draft-lear-iana-timezone-database-04
	Abstract		Abstract
	Timezone information serves as a basic protocol element in protocols,		Timezone information serves as a basic protocol element in protocols,
	such as the calendaring suite and DHCP. The Timezone (TZ) Database		such as the calendaring suite and DHCP. The Timezone (TZ) Database
	specifies the indices used in various protocols, as well as their		specifies the indices used in various protocols, as well as their
	semantic meanings, for all localities throughout the world. This		semantic meanings, for all localities throughout the world. This
	database has been meticulously maintained and distributed free of		database has been meticulously maintained and distributed free of
	charge by a group of volunteers, coordinated by a single volunteer		charge by a group of volunteers, coordinated by a single volunteer
	who is now planning to retire. This memo specifies IANA procedures		who is now planning to retire. This memo specifies IANA procedures
	skipping to change at page 1, line 43 ¶		skipping to change at page 1, line 43 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on October 13, 2011.		This Internet-Draft will expire on November 20, 2011.
	Copyright Notice		Copyright Notice
	Copyright (c) 2011 IETF Trust and the persons identified as the		Copyright (c) 2011 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 26 ¶		skipping to change at page 2, line 26 ¶
	The IETF has specified several standards that make use of timezone		The IETF has specified several standards that make use of timezone
	information. Timezone names are used in DHCP to configure devices		information. Timezone names are used in DHCP to configure devices
	with correct local time [RFC4833]. Timezone names can appear in the		with correct local time [RFC4833]. Timezone names can appear in the
	TZID field of VEVENTs [RFC5545]. The normative reference for these		TZID field of VEVENTs [RFC5545]. The normative reference for these
	values is the TZ Database [TZDB]. Since the early 1980s, that		values is the TZ Database [TZDB]. Since the early 1980s, that
	database, which has been in use on nearly all UNIX systems, Java		database, which has been in use on nearly all UNIX systems, Java
	systems, and other sorts of systems has been hosted at the National		systems, and other sorts of systems has been hosted at the National
	Institutes of Health. The database consists of both historic and		Institutes of Health. The database consists of both historic and
	current entries for geographies throughout the world. Associated		current entries for geographies throughout the world. Associated
	with the database is a reference implementation of functions that can		with the database is a reference implementation of ISO/IEC 9899 C and
	be used to convert time values.		IEEE 1003.1 POSIX time functions that can be used to convert time
			values.
	The database has been maintained by volunteers who participate in a		The database has been maintained by volunteers who participate in a
	mailing list that is also hosted at the NIH. The database itself is		mailing list [1] that is also hosted at the NIH. The database itself
	updated approximately twenty times per year, depending on the year,		is updated approximately twenty times per year, depending on the
	based on information these experts provide to the maintainer. Arthur		year, based on information these experts provide to the maintainer.
	David Olson has maintained the database, coordinated the mailing		Arthur David Olson has maintained the database, coordinated the
	list, and provided a release platform since the database's inception.		mailing list, and provided a release platform since the database's
	With his retirement now approaching it is necessary to provide a		inception. With his retirement now approaching it is necessary to
	means for this good work to continue.		provide a means for this good work to continue.
	The IANA provides registry services to the Internet community. Those		The IANA provides registry services to the Internet community. Those
	registries are coordinated by technical experts who are designated by		registries are coordinated by technical experts who are designated by
	the Internet Engineering Steering Group (IESG). The IANA is also		the Internet Engineering Steering Group (IESG). The IANA is also
	well suited as a distribution platform for the TZ Database itself.		well suited as a distribution platform for the TZ Database itself.
	The IANA has for quite some time had the capability to maintain		The IANA has for quite some time had the capability to maintain
	designated expert mailing lists. The TZ mailing list would fit		designated expert mailing lists. The TZ mailing list would fit
	nicely just as such a list.		nicely as just such a list.
	1.1. Terminology		1.1. Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119 [RFC2119].		document are to be interpreted as described in RFC 2119 [RFC2119].
	TZ Database: The TimeZone Database, sometimes referred to as the		TZ Database: The TimeZone Database, sometimes referred to as the
	Olson Database. This database consists of information about		Olson Database. This database consists of information about
	offsets from UTC for different localities, including daylight		offsets from UTC for different localities, including daylight
	saving time (DST) transition information.		saving time (DST) transition information.
	TZ Coordinator: The person or people who maintain and manage release		TZ Coordinator: The person or people who maintain and manage release
	of the TZ Database. The TZ Coordinator also has responsibility		of the TZ Database. The TZ Coordinator also has responsibility
	for maintaining the TZ mailing list. The TZ Coordinator is an		for managing the TZ mailing list. The TZ Coordinator is an IANA
	IANA Designated Expert, as defined in Section 3.2 of [RFC5226].		Designated Expert, as defined in Section 3.2 of [RFC5226], except
	Roughly speaking, this means that the IESG will choose one or more		as regards to appeals, as discussed in Section 5. Roughly
	experts to manage the TZ database, code, and mailing list. The TZ		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 work with the IANA to develop appropriate		Coordinator will also work with the IANA to develop appropriate
	service metrics. There SHALL be a single lead individual and at		service metrics. There SHALL be a single lead individual and at
	least one backup individual for this function.		least one backup individual for this function.
	TZ mailing list: The forum where matters relating to the TZ database		TZ mailing list: The forum where matters relating to the TZ database
	and supporting code are discussed.		and supporting code are discussed.
	The rest of this document specifies the following:		The rest of this document specifies the following:
	1. Transferring and maintenance of the TZ mailing list;		1. Transferring and maintenance of the TZ mailing list;
	2. Procedures for selecting a technical expert for the technical		2. Procedures for selecting a technical expert who will play the
	expert who will play the role of TZ Coordinator and release		role of TZ Coordinator and release manager for the TZ database;
	manager for the TZ database;
	3. Procedures for updating the TZ database;		3. Procedures for updating the TZ database;
	4. Maintenance and ownership of reference code; and		4. Maintenance and ownership of reference code; and
	5. Ownership of the database.		5. Ownership of the database.
	2. The TZ Mailing List		2. The TZ Mailing List
	For many years the TZ mailing list at the NIH has been the forum		For many years the TZ mailing list at the National Institutes of
	where discussion of changes to the TZ database and support files		Health (NIH) has been the forum where discussion of changes to the TZ
	would take place. In addition, the TZ mailing list is used to		database and support files would take place. In addition, the TZ
	announce releases of the database. Currently the TZ mailing list is		mailing list is used to announce releases of the database. Currently
	administered by the TZ Coordinator.		the TZ mailing list is administered by the TZ Coordinator.
	This list membership will be transitioned to the IANA mail server.		This list membership will be transitioned to the IANA mail server.
	The TZ Coordinator will continue to manage the list. While the TZ		The TZ Coordinator will continue to manage the list. While the TZ
	Coordinator may establish other rules of governance for the list,		Coordinator may establish other rules of governance for the list,
	members of that list will be informed that a condition of		members of that list will be informed that a condition of
	participating on the list is that all contributions to the list are		participating on the list is that all contributions to the list are
	released to the public domain, and that by placing their contribution		released to the public domain, and that by placing their contribution
	in the public domain, contributors waive forever any intellectual		in the public domain, contributors waive forever any intellectual
	property claims.		property claims.
	The list will be used just as it has been, to learn of, discuss, and		The list will be used just as it has been: to learn of, discuss, and
	confirm TZ definition changes, as well as an announcement list for		confirm TZ definition changes, as well as to serve as an announcement
	new versions of the database.		list for new versions of the database.
	3. Making Updates to the TZ Database		3. Making Updates to the TZ Database
	Updates to the TZ database are made by the TZ Coordinator in		Updates to the TZ database are made by the TZ Coordinator in
	consultation with the TZ mailing list. TZ Coordinator is empowered		consultation with the TZ mailing list. TZ Coordinator is empowered
	to decide, as the designated expert, appropriate changes, but SHOULD		to decide, as the designated expert, appropriate changes, but SHOULD
	take into account views expressed on the mailing list.		take into account views expressed on the mailing list.
	The TZ Coordinator will also decide the timing of database releases.		The TZ Coordinator will also decide the timing of database releases.
	The release itself today consists of several archive files that are		The release itself today consists of several archive files that are
	downloaded from a well known location.		downloaded from a well known location.
	Moving forward, the TZ database and supporting code SHOULD be signed		Moving forward, the TZ database, supporting code, and any appropriate
	prior to release using a well known key, along with any appropriate		supporting information SHOULD be signed prior to release using well
	supporting information and distributed from a well known location		known public keys, along with any appropriate supporting information
	that is advertised by IANA in a manner of its choosing.		and distributed from a well known location that is advertised by IANA
			in a manner of its choosing.
	The criteria for updates to the database are as follows:		The criteria for updates to the database include the following:
	1. New keys are only to be created when the region a key was		1. New TZ names (e.g. locations) are only to be created when the
	envisioned to cover is not accurately reflected by an existing		scope of the region a name was envisioned to cover is no longer
	key.		accurate.
	2. In order to correct historical inaccuracies, a new key MAY be		2. In order to correct historical inaccuracies, a new TZ name MAY be
	added when it is necessary to indicate what was the consensus		added when it is necessary to indicate what was the consensus
	view at given time and location. Such keys are usually not added		view at a given time and location. Such TZ names are usually not
	when the inaccuracy was prior to 1970.		added when the inaccuracy was prior to 1970.
	3. Changes to existing entries SHALL reflect the consensus on the		3. Changes to existing entries SHALL reflect the consensus on the
	ground in the region covered by that entry.		ground in the region covered by that entry.
	To be clear, the TZ Coordinator SHALL NOT set timezone policy policy		To be clear, the TZ Coordinator SHALL NOT set timezone policy for a
	for a region but use judgment and whatever available sources exist to		region but use judgment and whatever available sources exist to
	assess what the average person on street would think the time		assess what the average person on street would think the time
	actually is, or in case of historical corrections, was.		actually is, or in case of historical corrections, was.
	4. Selecting or Replacing a TZ Coordinator		4. Selecting or Replacing a TZ Coordinator
	From time to time it will be necessary to appoint a new TZ		From time to time it will be necessary to appoint a new TZ
	Coordinator. This could occur for a number of reasons:		Coordinator. This could occur for a number of reasons:
	o The TZ Coordinator is retiring (as Arthur Olson is) or has		o The TZ Coordinator is retiring (as Arthur Olson is) or has
	announced that he or she will be unable to continue to perform the		announced that he or she will be unable to continue to perform the
	function;		function;
	o The Coordinator is missing, has become incapacitated, or has died;
	or		o The TZ Coordinator is missing, has become incapacitated, or has
	o The Coordinator is not performing the function in accordance with		died; or
	community wishes.		o The TZ Coordinator is not performing the function in accordance
			with community wishes.
	In any of these cases, members of the community should raise the		In any of these cases, members of the community should raise the
	issue on the TZ list. If a rough consensus can be formed easily, and		issue on the TZ mailing list and attempt to reach consensus on a new
	quickly, then the results should be presented to the IESG for comment		candidate to fulfill the role of TZ Coordinator. If rough consensus
	and review. The IESG selects the TZ Coordinator(s). The IESG will		cannot be reached easily, the Area Directors of the IETF Applications
	use rough consensus of the TZ mailing list as their primary guide to		Area should attempt to guide the members of the community to rough
	further action, when it exists, and whatever other means they have at		consensus. The candidate that is agreed upon by the community
	their disposal, when rough consensus cannot be found.		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.
	5. Appealing Database Decisions		5. Appealing Database Decisions
	The TZ Coordinator makes decisions based on expertise, as well as		The TZ Coordinator makes decisions based on expertise, as well as
	with guidance from the TZ mailing lists. While individual decisions		with guidance from the TZ mailing list. If a member of the community
	MAY be appealed to the IESG, the IESG MUST give great deference to		has a concern with an individual decision made by the TZ Coordinator
	the designated expert in its considerations. In particular,		with regard to the TZ database, the individual shall proceed as
	apellants MUST show material harm from the decision, and that the		follows:
	decision is materially in error. The IESG is not a normal avenue for
	appeals of specific decisions of the TZ Coordinator, but rather a		1. Attempt to resolve the concern directly with the TZ Coordinator.
	last resort when a TZ Coordinator is thought not to be functioning in		2. If a resolution cannot be reached directly with the TZ
	an appropriate way.		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.
			3. 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.
	6. Maintenance and Distribution of Reference Code		6. Maintenance and Distribution of Reference Code
	Currently the maintainer of the TZ database also maintains reference		Currently the maintainer of the TZ database also maintains reference
	code, most of which is public domain. Several files from this		code, most of which is public domain. Several files from this
	software are currently distributed under license. Where they exist,		software are currently distributed under license. Where they exist,
	licenses SHALL NOT be changed. IANA SHALL allow for the downloading		licenses SHALL NOT be changed. IANA SHALL allow for the downloading
	of this reference code. The reference implementation shall be		of this reference code. The reference implementation shall be
	distributed along with an associated cryptographic signature of an		distributed along with an associated cryptographic signature
	identity that IANA will publish.		verifiable by a public key that IANA will publish.
	7. Database Ownership		7. Database Ownership
	The database itself is public domain. Should claims be made and		The TZ database itself is not an IETF Contribution or an IETF
	substantiated against the database, the IANA will act in accordance		Document. Rather it is a pre-existing and regularly updated work
	with all competent court orders. No ownership claims will be made by		that is in the public domain, and is intended to remain in the public
	IANA or the IETF Trust on the database or the code. Any person		domain. Therefore, BCP 78 and BCP 79 do not apply to the TZ Database
	making a contribution to the database or code waives all rights to		or contributions that individuals make to it. Should any claims be
	future claims.		made and substantiated against the database, the IANA will act in
			accordance with all competent court orders. No ownership claims will
			be made by IANA 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.
	8. IANA Considerations		8. IANA Considerations
	The IANA SHALL assist the IESG, as required, in filling of the TZ		If requested to do so, the IANA SHALL assist the IESG in selection of
	Coordinator, based on the procedures set forth above. The IANA SHALL		the TZ Coordinator, based on the procedures set forth above. The
	act as a repository for the TZ database and associated reference		IANA SHALL act as a repository for the TZ database and associated
	code. The TZ Coordinator SHALL be named by the IESG as described		reference code. The TZ Coordinator SHALL be named by the IESG as
	above, and will act as the maintainer of the database and code, as		described above, and will act as the maintainer of the database and
	described above. The IANA SHALL provide the TZ Coordinator with		code, as described above. The IANA SHALL provide the TZ Coordinator
	appropriate access to maintain the database, as well as necessary		with appropriate access to maintain the database, as well as
	tooling that may be required, so long as no direct software costs are		necessary tooling that may be required, so long as no direct software
	incurred. Both current and historical versions of the database will		costs are incurred. Both current and historical versions of the
	be stored and distributed via HTTP/HTTPs. IANA will be operationally		database will be stored and distributed via HTTP/HTTPs. IANA will be
	responsible for the security of the system upon which the database		operationally responsible for the security of the system upon which
	resides.		the database resides.
	The IANA SHALL also maintain a cryptographic identity that is used to		The IANA SHALL also securely maintain a cryptographic private key
	sign the database, and that will survive a change of TZ Coordinators.		that is used to sign the database, and that will survive a change of
			TZ Coordinator.
	9. Security Considerations		9. Security Considerations
	The distribution of the database is currently not secured. This memo		The distribution of the database is currently not secured. This memo
	states that moving forward the TZ database SHOULD be distributed with		states that moving forward the TZ database SHOULD be distributed with
	a valid cryptographic signature.		a valid cryptographic signature.
	10. Acknowledgments		10. Acknowledgments
	The authors would like to thank the TZ mailing list for their		The authors would like to thank the TZ mailing list for their
	remarkable achievements over the many years. Thanks also to Marshall		remarkable achievements over the many years. Thanks also to Marshall
	Eubanks, S. Moonesamy, Peter Saint-Andre, Alexey Melenkov, Tony		Eubanks, S. Moonesamy, Peter Saint-Andre, Alexey Melenkov, Tony
	Finch, Elwin Davies, Alfred Hoenes, and Ted Hardie for the		Finch, Elwyn Davies, Alfred Hoenes, Ted Hardie, and Barry Leiba for
	improvements they made to this document. A special acknowledgment		the improvements they made to this document. A special
	should be given to Arthur David Olson for his excellent stewardship.		acknowledgment should be given to Arthur David Olson for his
			excellent stewardship.
	11. Normative References		11. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC4833] Lear, E. and P. Eggert, "Timezone Options for DHCP",		[RFC4833] Lear, E. and P. Eggert, "Timezone Options for DHCP",
	RFC 4833, April 2007.		RFC 4833, April 2007.
	[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an		[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
	skipping to change at page 7, line 6 ¶		skipping to change at page 7, line 35 ¶
	May 2008.		May 2008.
	[RFC5545] Desruisseaux, B., "Internet Calendaring and Scheduling		[RFC5545] Desruisseaux, B., "Internet Calendaring and Scheduling
	Core Object Specification (iCalendar)", RFC 5545,		Core Object Specification (iCalendar)", RFC 5545,
	September 2009.		September 2009.
	[TZDB] Eggert, P. and A. Olson, "Sources for Time Zone and		[TZDB] Eggert, P. and A. Olson, "Sources for Time Zone and
	Daylight Saving Time Data",		Daylight Saving Time Data",
	<http://www.twinsun.com/tz/tz-link.htm>.		<http://www.twinsun.com/tz/tz-link.htm>.
			[1] <mailto:tz@elsie.nci.nih.gov>
	Appendix A. Changes		Appendix A. Changes
	o 03: Take out ATTENTION: comment. Add backup coordinator.		RFC-EDITOR: Please remove this section prior to publication.
	editorial nits. Add discussion of metrics.
			o 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.
	o 02: Separate out from RFC5226 a bit; Simplify language around		o 02: Separate out from RFC5226 a bit; Simplify language around
	submissions; host list to IANA; spelling corrections; clarify here		submissions; host list to IANA; spelling corrections; clarify here
	and there.		and there.
	o 01: Proper reference to RFC5226, add acknowledgments, several		o 01: Proper reference to RFC5226, add acknowledgments, several
	rewordings.		rewordings.
	o Initial Revision		o Initial Revision
	Authors' Addresses		Authors' Addresses
	Eliot Lear		Eliot Lear
	Cisco Systems GmbH		Cisco Systems GmbH
	Richtistrasse 7		Richtistrasse 7
	Wallisellen, ZH CH-8304		Wallisellen, ZH CH-8304
End of changes. 26 change blocks.
	87 lines changed or deleted		119 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/