Last Call: draft-lear-iana-timezone-database
Tony Finch <dot@dotat.at> Tue, 12 April 2011 12:47 UTC
Return-Path: <fanf2@hermes.cam.ac.uk>
X-Original-To: ietf@ietfc.amsl.com
Delivered-To: ietf@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id DE191E06BD for <ietf@ietfc.amsl.com>; Tue, 12 Apr 2011 05:47:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.516
X-Spam-Level:
X-Spam-Status: No, score=-4.516 tagged_above=-999 required=5 tests=[AWL=2.083, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TSNc718LCNxx for <ietf@ietfc.amsl.com>; Tue, 12 Apr 2011 05:47:12 -0700 (PDT)
Received: from ppsw-41.csi.cam.ac.uk (ppsw-41.csi.cam.ac.uk [131.111.8.141]) by ietfc.amsl.com (Postfix) with ESMTP id 0BF95E0699 for <ietf@ietf.org>; Tue, 12 Apr 2011 05:47:11 -0700 (PDT)
X-Cam-AntiVirus: no malware found
X-Cam-SpamDetails: not scanned
X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/
Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:34138) by ppsw-41.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:25) with esmtpa (EXTERNAL:fanf2) id 1Q9czu-00010p-Rh (Exim 4.72) (return-path <fanf2@hermes.cam.ac.uk>); Tue, 12 Apr 2011 13:47:10 +0100
Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1Q9czu-0001nj-IZ (Exim 4.67) (return-path <fanf2@hermes.cam.ac.uk>); Tue, 12 Apr 2011 13:47:10 +0100
Date: Tue, 12 Apr 2011 13:47:10 +0100
From: Tony Finch <dot@dotat.at>
X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk
To: ietf@ietf.org, lear@cisco.com, lear@cisco.com
Subject: Last Call: draft-lear-iana-timezone-database
Message-ID: <alpine.LSU.2.00.1104121309180.3124@hermes-1.csi.cam.ac.uk>
User-Agent: Alpine 2.00 (LSU 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
Sender: Tony Finch <fanf2@hermes.cam.ac.uk>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 12 Apr 2011 12:47:13 -0000
I support this document. I have a few suggestions: Section 1: Is it worth mentioning that the reference code includes an implementation of the ISO/IEC 9899 C and IEEE 1003.1 POSIX time functions? Section 3: The term "TZ name" should be used instead of "key" in the update criteria, to avoid confusion with the cryptographic key mentioned earlier in the section. Criterion 1 could perhaps be clearer. Do I understand correctly that the intent is something like "New keys are only to be created when it is found that the region a TZ name was envisioned to cover does not all follow the same set of timezone rules between 1970 and the present day." That is, the thing that must be "accurately reflected" is the scope of the TZ rule, not its name or anything else. Is it worth documenting the naming scheme here, or would that be unhelpful? Typo: "policy policy". Section 5: Should the document explicitly mention that rough consensus of the TZ list should also be used when considering an appeal to the IESG? Section 6 and 8: The term "identity" appears whereas section 3 used "well known key". Is "identity" supposed to imply something more complicated than a key, such as an x.509 certificate? Tony. -- f.anthony.n.finch <dot@dotat.at> http://dotat.at/ Viking, North Utsire: Northwest backing southwest 4 or 5, occasionally 6. Moderate or rough. Mainly fair. Good.
- Last Call: draft-lear-iana-timezone-database Tony Finch
- Re: Last Call: draft-lear-iana-timezone-database Eliot Lear