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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf