Document: draft-lear-iana-timezone-database-01.txt
Reviewer: Elwyn Davies
Review Date: 11 January 2010
IETF LC End Date: 11 January 2011
IESG Telechat date: (if known)

Summary:
This document is not quite ready for the IESG.  The appeals process (if
there is to be one) needs to clarified as it currently points indirectly
to a hole in RFC 5226. As explained below, I have a feeling that it
would be wise to avoid tying the processes in this document to the
Designated Expert processes in RFC 5226 despite the similarities.
Making it clear what does apply and what doesn't is probably more work
than doing it from scratch in this document, especially given the hole
in RFC 5226.

Major(ish) issue:
s4: 
> > As RFC-5226 states, the IESG is not a
> >    normal avenue for appeals of specific decisions of the coordinator,
> >    but rather a last resort when a coordinator is thought not to be
> >    functioning in an appropriate way.
I think the draft should make it explicit that it is referring to the
'Designated Expert' sections in RFC 5226 here if it continues to
reference RFC 5226 - although there is a clear relationship with
Designated Experts, the differences between the selection process and
the operations of the TZ Coordinator and generic Deisgnated Experts may
mean that citing RFC 5226 might lead to legalistic disputes about which
set of rules applies.  Also, I am unable to find statements in RFC 5226
backing up the sentence above.  Regrettably, RFC 5226 appears
effectively to have a 'dsngling reference' in this area. Section 3.2,
para 3 of RFC 5226 points at Section 5.2 which (allegedly) discusses
'disputes and appeals in more detail'.  However s5.2 is titled 'Updating
Registrations' and says nothing about appeals and disputes.  Section 7
of RFC 5226 covers appeals of IANA decisions but says nothing specific
about appealing designated expert rulings.  I think this area may need a
little more work.  Overall, my inclination would be to make this a
standalone document that does not try to partially modify the RFC 5226
Designated Expert process and operations.  Appeals... >*sigh*<.  

Minor Issue:
s3, para 3: Is it intended that that the supporting info should also be
signed?  If so the order of the phrases should be reversed.


Nits/Editorial:
s3:  'tar files' is jargon. s/tar files/archive files/ maybe adding "in
the format used by the 'tar' program".

s4, last para: s/may/MAY/
s4, last para: 'OR MORE' - this isn't RFC 2119 language - is there any
real need for capitalization?

s5: The three instances of 'shall' ought to to be RFC 2119 terms:
s/No change shall be made to licenses, where they exist./Licenses, where
they exist SHALL NOT be changed./
s/IANA shall allow for the downloading of this reference code.  The
reference implementation shall be distributed/IANA SHALL allow for the
downloading of this reference code.  The reference implementation SHALL
be distributed.../

s7: Arguably the various 'will's and 'may' in the later part of the
section (from 'The IANA will provide' onwards) should be capitalised as
RFC 2119 requirements: s/will/SHALL/ (5 places) and s/may/MAY/.