I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Please resolve these comments along with any other Last Call comments you may receive. 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/. _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf