Re: Last Call: <draft-lear-iana-timezone-database-03.txt> (IANA Procedures for Maintaining the Timezone Database) to BCP

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

 



This document is ready to go, modulo some nits.

Herein, my list of nits:



General
Because you define the terms, you should use them consistently.
Please check for "Coordinator" (replace with "TZ Coordinator") and "TZ
list" (replace with "TZ mailing list").

Sec 1.0
OLD
   The TZ mailing list would fit nicely just as such a list.
NEW
   The TZ mailing list would fit nicely as just such a list.

Sec 1.1
OLD
   The TZ Coordinator also has responsibility
   for maintaining the TZ mailing list.
NEW
   The TZ Coordinator also has responsibility
   for managing the TZ mailing list.

OLD
   2.  Procedures for selecting a technical expert for the technical
       expert who will play the role of TZ Coordinator and release
       manager for the TZ database;
NEW
   2.  Procedures for selecting a technical expert who will play the
       role of TZ Coordinator and release manager for the TZ database;

Sec 2
OLD
   The list will be used just as it has been, to learn of, discuss, and
   confirm TZ definition changes, as well as an announcement list for
   new versions of the database.
NEW
   The list will be used just as it has been: to learn of, discuss, and
   confirm TZ definition changes, as well to serve as an announcement
   list for new versions of the database.

Sec 3
OLD
   Moving forward, the TZ database and supporting code SHOULD be signed
   prior to release using a well known key, along with any appropriate
   supporting information and distributed from a well known location
   that is advertised by IANA in a manner of its choosing.
NEW
   Moving forward, the TZ database, supporting code, and any appropriate
   supporting information SHOULD be signed prior to release using a well
   known key and distributed from a well known location that is
   advertised by IANA in a manner of its choosing.

OLD
   1.  New keys are only to be created when the region a key was
       envisioned to cover is not accurately reflected by an existing
       key.
COMMENT
Because you just mentioned "key", meaning "cryptographic key", in the
previous paragraph, it needs to be clear that these are not those.

OLD
   To be clear, the TZ Coordinator SHALL NOT set timezone policy policy
   for a region
NEW
   To be clear, the TZ Coordinator SHALL NOT set timezone policy
   for a region

OLD
   actually is, or in case of historical corrections, was.
NEW
   actually is (or, in case of historical corrections, was).

Sec 4
OLD
   The IESG will
   use rough consensus of the TZ mailing list as their primary guide to
   further action, when it exists, and whatever other means they have at
   their disposal, when rough consensus cannot be found.
NEW
   The IESG will
   use rough consensus of the TZ mailing list, when such consensus exists,
   as their primary guide to further action.  When rough consensus cannot
   be found, they will use whatever other means they have at their disposal.

Sec 5
OLD
   apellants MUST show material harm from the decision
NEW
   appellants MUST show material harm from the decision

Sec 8
OLD
   The IANA SHALL assist the IESG, as required, in filling of the TZ
   Coordinator, based on the procedures set forth above.
NEW
   The IANA SHALL assist the IESG, as required, in selection of the TZ
   Coordinator, based on the procedures set forth above.

--
Barry
_______________________________________________
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]