The Time Zone Information Format (TZif)
draft-murchison-rfc8536bis-15

Repeating Vincent Roca's SecDir review comment:
----------------------
I just have a minor comment regarding Section 6 "Security Considerations" and 7
"Privacy Considerations". The current draft briefly mentions RFC 7808 whereas
this RFC has very detailed security and privacy sections and is a MUST READ. I
suggest the authors refer to RFC 7808 in both sections for further security or
privacy information in a convincing manner.
------------------------

I would recommend referencing RFC 7808 for both Security Considerations as well as Privacy Considerations (done already).

Section 6, paragraph 3
>    TZif provides no confidentiality or integrity protection.  Time zone
>    information is normally public and does not call for confidentiality
>    protection.  Since time zone information is used in many critical
>    applications, integrity protection may be required and must be
>    provided externally.


I agree with the SECDIR writeup (thanks Vincent) that the draft should refer to Security Considerations section of RFC 7808 in this section, which it already does for the Privacy Considerations section of the document.

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

 * Term "man"; alternatives might be "individual", "people", "person"
 * Term "dummy"; alternatives might be "placeholder", "sample", "stand-in",
   "substitute"
 * Term "traditional"; alternatives might be "classic", "classical", "common",
   "conventional", "customary", "fixed", "habitual", "historic",
   "long-established", "popular", "prescribed", "regular", "rooted",
   "time-honored", "universal", "widely used", "widespread"
 * Term "native"; alternatives might be "built-in", "fundamental", "ingrained",
   "intrinsic", "original"

-------------------------------------------------------------------------------
NIT
-------------------------------------------------------------------------------

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Section 2, paragraph 6
> vil time for a particular location. Its offset from universal time can depen
>                                     ^^^
Did you mean "it's" (short for "it is" or "it has") instead of "its"
(possessive pronoun)?

Thank you to Roni Even for the GENART review.

** Section 5.1
   Time
   type 0 SHOULD be a placeholder indicating that local time is
   unspecified, so that the reader is unambiguously informed of
   truncation at the start.

Is there another use of Time type 0?  Is there another way to signal that the local is unspecified?  The use of SHOULD here is confusing.

** Section 5.1
   To this end,
   the time type of the last transition SHOULD be a placeholder
   indicating that local time is unspecified.

What if it isn’t used?  Why isn’t a mandatory? 

** Section 8.  Please provide guidance in this section that “This Document” should be replaced with the published RFC number.

Thank you for the work on this document.

Just to note that I marked the erratas (which were addressed by this doc) as Held for doc update, since they were still in Reported state.

Thanks for addressing my concerns in https://author-tools.ietf.org/iddiff?url2=draft-murchison-rfc8536bis-14

Thanks for addressing my discuss comments and adding the i18n consideration section.