[tz] Response to informal TZ database appeal

[Murray S. Kucherawy]

Colleagues,

I am an IETF Area Director currently appointed to the Applications and Real
Time (ART) area. On June 21, 2021, the ART Area Directors (ADs) received a
request from Mr. Stephen Colebourne for intervention regarding a change
made to the time zone database.

I apologize for the delay in this response. The management of the time zone
database is new to me and I wanted to ensure I had done a proper review
with as much context as I could discover. Despite what I've learned, I may
get some terminology below wrong; apologies if so, and I'm happy to be
corrected.

I take this to have been an informal appeal under the second step of RFC
6557 Section 5, which prescribes a public discussion with the participation
of the ART ADs. As this was our first contact about this matter, I did not
interpret the second step as having been completed, and thus this was not
an appeal under the third step, which is a formal appeal to the full IESG
with prescriptive results. That step, or indeed action under Section 4,
remains available to you.

This is a shortened version of a much longer discussion document that I
have forwarded to the IESG for its reference should further appeals be
lodged. Note that since this is being taken under the informal second step,
nothing I say here is prescriptive.

For context, RFC 6557 (also known as BCP 175) is the only normative
document in force. The "theory.html" document is relevant but not
normative; it has recorded an evolving set of guiding principles for the
time zone database for decades, and they are maintained in the same
repository as the data now in dispute. That document has been visible, and
subject to discussion and proposed revisions by the community.

In summary, I do not believe there is relief to be found for the instant
complaint in RFC 6557.

There appear to be three points comprising the complaint. Taking them in
turn and citing from the message Mr. Colbourne posted to the list on June 3:

(a) I contend that to date, the TZ coordinator has not actively shown any
serious willingness to accept that the proposed changes are unacceptable to
a significant segment of tzdb users.  As such, the coordinator has not
taken into account the views of the mailing list.

I disagree.  The TZ mailing list archive is testimonial to the contrary:
The TZ Coordinator has engaged in good faith in several subsequent threads
on the topic after the change was made, and has proposed other workarounds
to accomplish the original goal while attempting to address the objections
raised.

RFC 6557 says, “... but SHOULD take into account views expressed on the
mailing list.”  ("SHOULD" is defined in RFC 2119.) This compels the TZ
Coordinator to follow the community’s consensus, unless she/he fully
understands the implications of not doing so.  It is evident to me that in
this case, that understanding exists.  Therefore it is within the TZ
Coordinator’s discretion to proceed.


(b) I also contend that the "cleanup" being proposed is not within the
charter of the project. Point 1 refers to new zones, thus is not
applicable. Point 2 refers to correcting historical inaccuracies, yet it is
clear that the proposed change *adds* historical inaccuracies. Point 3
refers to changes, but only in terms that reflect what people in the
relevant location would have considered the time zone to have been, yet
clearly the proposed change does not do that. No part of the charter
permits the coordinator to willfully harm the database, nor to merge
timezone regions, nor to increase the number of historical inaccuracies.


Again, I disagree.


It is worth noting at this point that RFC 6557 is over ten years old. As I
reviewed it I became convinced that it, for better or worse, was written in
the context of believing that the primary thing that needed to be sustained
by the database is accurate time zone calculations as of 1970; aesthetics
and "geopolitical" matters were a secondary consideration (if they were
considered important at all).


While I am sympathetic to the notion that this change may be disruptive to
software or other agents that consume only the basic time zone data rather
than the alternative representations also available, or may aggravate
consumers on a personal level, I do not believe RFC 6557 provides a basis
for demanding the change be reverted given my observation above.


(c) Justifications for the proposed change based on "consistency" or
"politics" are not rooted in the charter of tzdb and should be considered
null and void.


I disagree. I found no evidence of "political" motivation. If "consistency"
is not an acceptable justification, I find it curious that the theory
document has not been challenged in the years since the relevant guidelines
in it became stable.


I have some recommendations for additional paths forward to consider, apart
from further action under Sections 4 and 5 of RFC 6557:


On the topic of consensus, the IETF published RFC 7282 some years ago,
which describes its view of what “consensus” means in our context.  It is
not a governing document, but may be informative for future discussions or
operation of the TZ mailing list.


It is clear that in the years since RFC 6557 was published, consumers of
this database have come to rely on it for particular local representations
of time zones.  Mr. Colebourne refers to this as an important
“geopolitical” aspect of the database and asserts that the removal of the
data implemented by this change will be disruptive to these consumers, so
much so that he predicts this will necessitate a forking of the database,
with that set of consumers following the fork.  This is far from an ideal
outcome, and naturally I strongly recommend that this not be how this
matter is resolved by those dissatisfied with this (or any other) outcome.
Experience has shown that a forked software or data project will always
diverge, even with well-intentioned management of the fork to avoid such a
delta from forming.  Thus, such action could be enormously disruptive to
the community.  It is furthermore unlikely that the fork will enjoy the
same level of oversight, meticulous curation of the data, resolution of
disputes, vetting of proposed changes, etc., with any assured longevity.  I
therefore struggle to see how such action serves anyone in the long term.


In any event, and perhaps most importantly, there is the matter of the
tension between what the database was originally meant to be for and how
people are now consuming it.  This clearly cannot be ignored.  I propose
the community review both RFC 6557 and the “theory” document, giving
careful consideration to the principles in each and their respective
impacts, and also careful consideration to how the use of this database has
evolved, and propose revising either or both to reflect current usage or
desired management principles.  The IETF has a procedure for revising its
process documents (i.e., BCPs) from time to time when the community needs
something different, and it would seem that may be the case here.  I will
be happy to initiate that process within the IETF if a critical mass exists
to take up that work.

Of note, there are points in the “theory” document that appear to lack
supporting language.  For example, “annoyingly large” appears to be a
subjective criterion, not a technical one.  That is, it is unclear what
technical or process degradation, if any, is caused by these extra records,
so the relevance of this point is not obvious, and therefore it is not
clear why this is an important guideline to have in a technical
specification.


Also of note, I find the “consensus on the ground” requirement of RFC 6557
is probably in need of revision or, at a minimum, clarification.  It is
apparent that the intent there is to assure quality service to the local
communities affected by change, but it includes no practical guidance as to
how to do so.


Finally, I believe your next formal steps under RFC 6557, should you wish
to press the issue, will be one or both of the following:

(a) A formal appeal under step 3 of Section 5, which should be addressed to
iesg at ietf.org stating clearly that this is the formal appeal; or

(b) An informal request for the assistance of the ART Area Directors to
reach consensus on a candidate under Section 4, which can be addressed to
art-ads at ietf.org or to me directly.


-MSK, ART Area Director
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/tz/attachments/20210922/e32cda0c/attachment-0001.html>