Last Call: draft-lear-iana-timezone-database

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxx>  http://dotat.at/
Viking, North Utsire: Northwest backing southwest 4 or 5, occasionally 6.
Moderate or rough. Mainly fair. Good.
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]