Skip to main content

Procedures for Maintaining the Time Zone Database
draft-lear-iana-timezone-database-05

Revision differences

Document history

Date Rev. By Action
2012-08-22
05 (System) post-migration administrative database adjustment to the No Objection position for Adrian Farrel
2012-08-22
05 (System) post-migration administrative database adjustment to the Yes position for David Harrington
2012-08-22
05 (System) post-migration administrative database adjustment to the Yes position for Russ Housley
2012-02-16
05 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2012-02-16
05 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2012-02-14
05 (System) New version available: draft-lear-iana-timezone-database-05.txt
2011-05-31
05 Cindy Morgan State changed to RFC Ed Queue from Approved-announcement sent.
2011-05-19
05 (System) IANA Action state changed to In Progress
2011-05-19
05 Amy Vezza IESG state changed to Approved-announcement sent
2011-05-19
05 Amy Vezza IESG has approved the document
2011-05-19
05 Amy Vezza Closed "Approve" ballot
2011-05-19
05 Amy Vezza Approval announcement text regenerated
2011-05-19
05 Adrian Farrel [Ballot Position Update] Position for Adrian Farrel has been changed to No Objection from Discuss
2011-05-19
05 Russ Housley
[Ballot discuss]
I believe that the changes proposed below resolve the concerns raised
  by Dave Harrington.  The IETF Trust had a hand in preparing …
[Ballot discuss]
I believe that the changes proposed below resolve the concerns raised
  by Dave Harrington.  The IETF Trust had a hand in preparing them,
  although I made a few final edits on my own.  I intend to change my
  ballot position to YES once the spirit of these proposed changes to
  Section 7 are included in the document.

  Section 7 should be expanded to make it clear that contributions to
  the TZ database are not IETF Contributions.  I suggest:
  >
  > The TZ Database is not an IETF Contribution or an IETF Document,
  > rather it is a pre-existing and regularly updated work that is
  > intended to be kept in the pubic domain.
  >
  > With respect to the TZ database, IANA does not act on behalf of
  > the IETF or the IETF Trust, and accordingly, BCP 78 and 79 do not
  > apply to the TZ Database or contributions that individuals make
  > to it.
2011-05-19
05 Russ Housley [Ballot Position Update] Position for Russ Housley has been changed to Yes from Discuss
2011-05-18
05 (System) Sub state has been changed to AD Follow up from New Id Needed
2011-05-18
04 (System) New version available: draft-lear-iana-timezone-database-04.txt
2011-05-18
05 Peter Saint-Andre State changed to IESG Evaluation::Revised ID Needed from IESG Evaluation::AD Followup.
2011-05-12
05 Amy Vezza Removed from agenda for telechat
2011-05-12
05 Amy Vezza State changed to IESG Evaluation::AD Followup from Waiting for AD Go-Ahead.
2011-05-12
05 Adrian Farrel
[Ballot discuss]
I completely support the idea of moving this database to IANA
supervision, but I have some strong process concerns that I wish to …
[Ballot discuss]
I completely support the idea of moving this database to IANA
supervision, but I have some strong process concerns that I wish to
discuss with other members of the IESG. At this stage, I recommend
that the authors take no action (maybe not even read my Discuss!).
I will update my Discuss with actionable points after the IESG
telechat.

---

If the intention is to bring the registry into IANA stewardship but not
place the registry under IETF control, this may be a fine idea. But in
that case, this document should not be brought through the IETF process.
Indeed, it seems to me from much of the text (e.g., the mailing list is
run on the IANA mail server) that this document is in the wrong place
with the wrong audience. It is not the IETF community asking IANA to do
something; it is the TZ community asking IANA to do things.

On the ther hand, there are a number of actions required of the IESG in
this document that bypass IETF consensus in favor of TZ community
consensus.

Specific details of this issue show in my next two Discuss point.

---

This document specifically makes the IESG responsible for appointing the
TZ Coordinator and requires that consensus on the TZ mail list be the
primary parameter in selection and potential removal of such a
coordinator. While consensus support from the list will clearly be
important, this does not sit at all well with the appointment of other
designated experts or list admins.

This sort of sentiment might be more acceptable if it was phrased as the
responsiblity of ADs for a specific area to work to gain consensus on
the list.                               

I think this comes down to a discussion of whether this function is
being brought into the IETF or not. The whole fact that "contributions
to the TZ database are not IETF contributions" seems to suggest that
all of this work should be taken to IANA outside the IETF process.

---

I am very unhappy with the description of the appeals process in
section 5.

>5.  Appealing Database Decisions                     
>
> The TZ Coordinator makes decisions based on expertise,
> as well as with guidance from the TZ mailing lists. 
> While individual decisions MAY be appealed to the IESG,
> the IESG MUST give great deference to the designated
> expert in its considerations.  In particular, apellants
> MUST show material harm from the decision, and that the
> decision is materially in error.  The IESG is not a
> normal avenue for appeals of specific decisions of the
> TZ Coordinator, but rather a last resort when a TZ
> Coordinator is thought not to be functioning in an
> appropriate way.

I am stunned that this text made it through community review. Either the IESG is on the appeal path or it is not. If the IESG is on the path, it is either before or after appeals to the TZ Coordinator and the TZ designated expert (hint: it is not helpful that these two roles are used interchangeably in this paragrpah when they are actually the same person).                                                                       

If the IESG is on the appeal path after appeals to the TZ Coordinator, then this paragraph MUST NOT constrain the IESG's processing of the appeal. In prticular, to say that the IESG "MUST give great deference" means that the IESG will not make appeals decisions, but will be goverened entirely by what the TZ Coordinator says.

Equally, rather than saying what is "not normal", this paragraph needs to set out the normal appeals process and sequence making suitable reference to standing appeals procedures.
2011-05-12
05 Adrian Farrel
[Ballot discuss]
I completely support the idea of moving this database to IANA
supervision, but I have some strong process concerns that I wish to …
[Ballot discuss]
I completely support the idea of moving this database to IANA
supervision, but I have some strong process concerns that I wish to
discuss with other members of the IESG. At this stage, I recommend
that the authors take no action (maybe not even read my Discuss!).
I will update my Discuss with actionable points after the IESG
telechat.

---

If the intention is to bring the registry into IANA stewardship but not
place the registry under IETF control, this may be a fine idea. But in
that case, this document should not be brought through the IETF process.
Indeed, it seems to me from much of the text (e.g., the mailing list is
run on the IANA mail server) that this document is in the wrong place
with the wrong audience. It is not the IETF community asking IANA to do
something; it is the TZ community asking IANA to do things.

On the ther hand, there are a number of actions required of the IESG in
this document that bypass IETF consensus in favor of TZ community
consensus.

Specific details of this issue show in my next two Discuss point.

---

This document specifically makes the IESG responsible for appointing the
TZ Coordinator and requires that consensus on the TZ mail list be the
primary parameter in selection and potential removal of such a
coordinator. While consensus support from the list will clearly be
important, this does not sit at all well with the appointment of other
designated experts or list admins.

This sort of sentiment might be more acceptable if it was phrased as the
responsiblity of ADs for a specific area to work to gain consensus on
the list.                               

I think this comes down to a discussion of whether this function is
being brought into the IETF or not. The whole fact that "contributions
to the TZ database are not IETF contributions" seems to suggest that
all of this work should be taken to IANA outside the IETF process.

---

I am very unhappy with the description of the appeals process in
section 5.

>5.  Appealing Database Decisions
>                                                                                           
> The TZ Coordinator makes decisions based on expertise,
> as well as with guidance from the TZ mailing lists.  While
> individual decisions MAY be appealed to the IESG, the
> IESG MUST give great deference to the designated expert
> in its considerations.  In particular, apellants MUST show
> material harm from the decision, and that the decision is
> materially in error.  The IESG is not a normal avenue for
> appeals of specific decisions of the TZ Coordinator, but
> rather a last resort when a TZ Coordinator is thought not
> to be functioning in an appropriate way.

I am stunned that this text made it through community review. Either the IESG is on the appeal path or it is not. If the IESG is on the path, it is either before or after appeals to the TZ Coordinator and the TZ designated expert (hint: it is not helpful that these two roles are used interchangeably in this paragrpah when they are actually the same person).                                                                       

If the IESG is on the appeal path after appeals to the TZ Coordinator, then this paragraph MUST NOT constrain the IESG's processing of the appeal. In prticular, to say that the IESG "MUST give great deference" means that the IESG will not make appeals decisions, but will be goverened entirely by what the TZ Coordinator says.

Equally, rather than saying what is "not normal", this paragraph needs to set out the normal appeals process and sequence making suitable reference to standing appeals procedures.
2011-05-12
05 Adrian Farrel
[Ballot discuss]
I completely support the idea of moving this database to IANA
supervision, but I have some strong process concerns that I wish to …
[Ballot discuss]
I completely support the idea of moving this database to IANA
supervision, but I have some strong process concerns that I wish to
discuss with other members of the IESG. At this stage, I recommend
that the authors take no action (maybe not even read my Discuss!).
I will update my Discuss with actionable points after the IESG
telechat.

---

If the intention is to bring the registry into IANA stewardship but not
place the registry under IETF control, this may be a fine idea. But in
that case, this document should not be brought through the IETF process.
Indeed, it seems to me from much of the text (e.g., the mailing list is
run on the IANA mail server) that this document is in the wrong place
with the wrong audience. It is not the IETF community asking IANA to do
something; it is the TZ community asking IANA to do things.

On the ther hand, there are a number of actions required of the IESG in
this document that bypass IETF consensus in favor of TZ community
consensus.

Specific details of this issue show in my next two Discuss point.

---

This document specifically makes the IESG responsible for appointing the
TZ Coordinator and requires that consensus on the TZ mail list be the
primary parameter in selection and potential removal of such a
coordinator. While consensus support from the list will clearly be
important, this does not sit at all well with the appointment of other
designated experts or list admins.

This sort of sentiment might be more acceptable if it was phrased as the
responsiblity of ADs for a specific area to work to gain consensus on
the list.                               

I think this comes down to a discussion of whether this function is
being brought into the IETF or not. The whole fact that "contributions
to the TZ database are not IETF contributions" seems to suggest that
all of this work should be taken to IANA outside the IETF process.

---

I am very unhappy with the description of the appeals process in
section 5.

>5.  Appealing Database Decisions
>                                                                                           
> The TZ Coordinator makes decisions based on expertise, as well as
> with guidance from the TZ mailing lists.  While individual decisions
> MAY be appealed to the IESG, the IESG MUST give great deference to
> the designated expert in its considerations.  In particular,
> apellants MUST show material harm from the decision, and that the
> decision is materially in error.  The IESG is not a normal avenue for
> appeals of specific decisions of the TZ Coordinator, but rather a
> last resort when a TZ Coordinator is thought not to be functioning in
> an appropriate way.

I am stunned that this text made it through community review. Either the IESG is on the appeal path or it is not. If the IESG is on the path, it is either before or after appeals to the TZ Coordinator and the TZ designated expert (hint: it is not helpful that these two roles are used interchangeably in this paragrpah when they are actually the same person).                                                                       

If the IESG is on the appeal path after appeals to the TZ Coordinator, then this paragraph MUST NOT constrain the IESG's processing of the appeal. In prticular, to say that the IESG "MUST give great deference" means that the IESG will not make appeals decisions, but will be goverened entirely by what the TZ Coordinator says.

Equally, rather than saying what is "not normal", this paragraph needs to set out the normal appeals process and sequence making suitable reference to standing appeals procedures.
2011-05-12
05 Dan Romascanu [Ballot Position Update] New position, No Objection, has been recorded
2011-05-12
05 Jari Arkko [Ballot Position Update] New position, No Objection, has been recorded
2011-05-12
05 Adrian Farrel [Ballot comment]
Abstract                               

s/semantic meanings/semantics/
2011-05-12
05 Adrian Farrel
[Ballot discuss]
I completely support the idea of moving this database to IANA
supervision, but I have some strong process concerns that I wish to …
[Ballot discuss]
I completely support the idea of moving this database to IANA
supervision, but I have some strong process concerns that I wish to
discuss with other members of the IESG. At this stage, I recommend
that the authors take no action (maybe not even read my Discuss!).
I will update my Discuss with actionable points after the IESG
telechat.

---

If the intention is to bring the registry into IANA stewardship but not
place the registry under IETF control, this may be a fine idea. But in
that case, this document should not be brought through the IETF process.
Indeed, it seems to me from much of the text (e.g., the mailing list is
run on the IANA mail server) that this document is in the wrong place
with the wrong audience. It is not the IETF community asking IANA to do
something; it is the TZ community asking IANA to do things.

On the ther hand, there are a number of actions required of the IESG in
this document that bypass IETF consensus in favor of TZ community
consensus.

Specific details of this issue show in my next two Discuss point.

---

This document specifically makes the IESG responsible for appointing the
TZ Coordinator and requires that consensus on the TZ mail list be the
primary parameter in selection and potential removal of such a
coordinator. While consensus support from the list will clearly be
important, this does not sit at all well with the appointment of other
designated experts or list admins.

This sort of sentiment might be more acceptable if it was phrased as the
responsiblity of ADs for a specific area to work to gain consensus on
the list.                               

I think this comes down to a discussion of whether this function is
being brought into the IETF or not. The whole fact that "contributions
to the TZ database are not IETF contributions" seems to suggest that
all of this work should be taken to IANA outside the IETF process.

---

I am very unhappy with the description of the appeals process in
section 5.

>5.  Appealing Database Decisions
>                                                                                           
>  The TZ Coordinator makes decisions based on expertise, as well as
>  with guidance from the TZ mailing lists.  While individual decisions
>  MAY be appealed to the IESG, the IESG MUST give great deference to
>  the designated expert in its considerations.  In particular,
>  apellants MUST show material harm from the decision, and that the
>  decision is materially in error.  The IESG is not a normal avenue for
>  appeals of specific decisions of the TZ Coordinator, but rather a
>  last resort when a TZ Coordinator is thought not to be functioning in
>  an appropriate way.

I am stunned that this text made it through community review. Either the
IESG is on the appeal path or it is not. If the IESG is on the path, it
is either before or after appeals to the TZ Coordinator and the TZ
designated expert (hint: it is not helpful that these two roles are used
interchangeably in this paragrpah when they are actually the same
person).                                                                       

If the IESG is on the appeal path after appeals to the TZ Coordinator,
then this paragraph MUST NOT constrain the IESG's processing of the
appeal. In prticular, to say that the IESG "MUST give great deference"
means that the IESG will not make appeals decisions, but will be
goverened entirely by what the TZ Coordinator says.

Equally, rather than saying what is "not normal", this paragraph needs               
to set out the normal appeals process and sequence making suitable
reference to standing appeals procedures.
2011-05-12
05 Adrian Farrel [Ballot Position Update] New position, Discuss, has been recorded
2011-05-12
05 Ralph Droms [Ballot Position Update] New position, Yes, has been recorded
2011-05-12
05 Gonzalo Camarillo [Ballot Position Update] New position, No Objection, has been recorded
2011-05-11
05 Russ Housley
[Ballot discuss]
I believe that the changes proposed below resolve the concerns raised
  by Dave Harrington.  The IETF Trust had a hand in preparing …
[Ballot discuss]
I believe that the changes proposed below resolve the concerns raised
  by Dave Harrington.  The IETF Trust had a hand in preparing them,
  although I made a few final edits on my own.  I intend to change my
  ballot position to YES once the spirit of these proposed changes to
  Section 7 are included in the document.

  Section 7 should be expanded to make it clear that contributions to
  the TZ database are not IETF Contributions.  I suggest:
  >
  > The TZ Database is not an IETF Contribution or an IETF Document,
  > rather it is a pre-existing and regularly updated work that is
  > intended to be kept in the pubic domain.
  >
  > With respect to the TZ database, IANA does not act on behalf of
  > the IETF or the IETF Trust, and accordingly, BCP 78 and 79 do not
  > apply to the TZ Database or contributions that individuals make
  > to it.
2011-05-11
05 Russ Housley [Ballot Position Update] New position, Discuss, has been recorded
2011-05-11
05 Ron Bonica [Ballot Position Update] New position, Yes, has been recorded
2011-05-11
05 Sean Turner [Ballot Position Update] New position, Yes, has been recorded
2011-05-11
05 David Harrington [Ballot discuss]
I strongly support this action, and am happy to see IANA and the IESG helping maintain this important database.
2011-05-11
05 David Harrington [Ballot Position Update] Position for David Harrington has been changed to Yes from Discuss
2011-05-11
05 Stewart Bryant [Ballot comment]
Just a couple of minor points:

NIH is used in the introduction but not defined.

"the TZ mailing list" is not defined
2011-05-11
05 Stewart Bryant [Ballot Position Update] New position, No Objection, has been recorded
2011-05-11
05 David Harrington
[Ballot discuss]
I strongly support this action, and am happy to see IANA and the IESG helping maintain this important database.

two discuss discusses
1) …
[Ballot discuss]
I strongly support this action, and am happy to see IANA and the IESG helping maintain this important database.

two discuss discusses
1) should the IETF Trust, or Jorge, or an IANA lawyer review this document before IESG approval, especially section 7?
2) is giving the coordinator mailing list admin rights a burden for IANA ML support?
2011-05-11
05 David Harrington [Ballot Position Update] New position, Discuss, has been recorded
2011-05-10
05 Pete Resnick
[Ballot comment]
I don't particularly see the point of the 2119 language in the document. It doesn't add anything for me. I wouldn't mind seeing …
[Ballot comment]
I don't particularly see the point of the 2119 language in the document. It doesn't add anything for me. I wouldn't mind seeing it go. Otherwise, I think the procedures defined here are spot on.
2011-05-10
05 Pete Resnick [Ballot Position Update] New position, Yes, has been recorded
2011-05-10
05 Robert Sparks [Ballot Position Update] New position, Yes, has been recorded
2011-05-10
05 Amanda Baber
IANA has been an active participant in the discussions surrounding the
IANA requirements for this document. Upon publication, IANA is prepared
to create and maintain …
IANA has been an active participant in the discussions surrounding the
IANA requirements for this document. Upon publication, IANA is prepared
to create and maintain the timezone database and supporting resources
required by this document. IANA intends to continue to be in close
collaboration with the authors and the IESG during the implementation of
the IANA Actions in this document.
2011-05-10
05 Stephen Farrell
[Ballot comment]
I like that the IETF & IANA are helping here.

Bunch of near-nits below.

(1) Maybe add pointers to the current and new …
[Ballot comment]
I like that the IETF & IANA are helping here.

Bunch of near-nits below.

(1) Maybe add pointers to the current and new TZ lists and archives?
It looks like this document also has consensus or at least no objections
on the current list btw - I took a quick peek:-)

(2) s/a well known key/well known public keys/ - there's an unfortunate
trend these days to use sign for MACs as well and I'm not sure you
want to say that the code and DB SHOULD use the same signing key

(3) Maybe add "key" to the terminology saying its sometimes a DB
key and sometimes (once?) a signing key and if you can't tell which,
then you should start reading RFCs somewhere else:-)

(4) "timezone policy policy" might be worth adding to the terminology
section since it could otherwise be seen as a typo

(5) s/signature of an identity/signature verifiable by a public key/

(6) I guess the TZ Coordinator won't want to be "filled" except maybe
with beer - I guess adding the word "role" there will fix that.

(7) s/maintain a cryptographic identity/securely maintain a cryptographic
private key/
2011-05-10
05 Stephen Farrell [Ballot Position Update] New position, Yes, has been recorded
2011-05-09
05 Wesley Eddy [Ballot Position Update] New position, No Objection, has been recorded
2011-05-09
05 Peter Saint-Andre [Ballot Position Update] New position, Yes, has been recorded for Peter Saint-Andre
2011-05-09
05 Peter Saint-Andre Ballot has been issued
2011-05-09
05 Peter Saint-Andre Created "Approve" ballot
2011-05-09
05 Peter Saint-Andre Ballot writeup text changed
2011-05-09
05 (System) State changed to Waiting for AD Go-Ahead from In Last Call.
2011-04-20
05 Peter Saint-Andre Placed on agenda for telechat - 2011-05-12
2011-04-14
05 Samuel Weiler Request for Last Call review by SECDIR is assigned to David McGrew
2011-04-14
05 Samuel Weiler Request for Last Call review by SECDIR is assigned to David McGrew
2011-04-11
05 Amy Vezza Last call sent
2011-04-11
05 Amy Vezza
State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
Reply-To: ietf@ietf.org …
State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
Reply-To: ietf@ietf.org
Subject: Last Call:  (IANA Procedures for Maintaining the Timezone Database) to BCP


The IESG has received a request from an individual submitter to consider
the following document:
- 'IANA Procedures for Maintaining the Timezone Database'
  as a BCP

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2011-05-09. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-lear-iana-timezone-database/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-lear-iana-timezone-database/

2011-04-11
05 Peter Saint-Andre Last Call was requested
2011-04-11
05 (System) Ballot writeup text was added
2011-04-11
05 (System) Last call text was added
2011-04-11
05 (System) Ballot approval text was added
2011-04-11
05 Peter Saint-Andre State changed to Last Call Requested from AD is watching.
2011-04-11
03 (System) New version available: draft-lear-iana-timezone-database-03.txt
2011-02-23
05 Peter Saint-Andre State changed to AD is watching from Publication Requested.
2011-02-23
05 Peter Saint-Andre Draft added in state Publication Requested
2011-01-27
02 (System) New version available: draft-lear-iana-timezone-database-02.txt
2010-12-17
01 (System) New version available: draft-lear-iana-timezone-database-01.txt
2010-10-18
00 (System) New version available: draft-lear-iana-timezone-database-00.txt