Hi Tony, Thank you for your comments. On 4/12/11 2:47 PM, Tony Finch wrote: > 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? Added. > 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. Changed. > 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. Thank you. That term "scope" does make things considerably clearer. I've adjusted the text as follows: > New TZ names (e.g. locations) are only to be created when the > scope of the region a name was envisioned to cover is no longer accurate. > Is it worth documenting the naming scheme here, or would that be unhelpful? I think that probably goes too far, but could be convinced otherwise. > 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? I believe the rules are clear, but others should comment. > 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? I am leaving that for IANA to decide. Right now there's nothing, so anything would be better ;-) Thanks again, Eliot _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf