Procedures for Maintaining the Time Zone Database
RFC 6557

[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.

[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.

[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.

[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.

[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.

[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.

[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?

[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.

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.

[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/

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/