Subject: [Tzdist-bis] Spencer Dawkins' No Objection on draft-murchison-tzdist-tzif-15: (with COMMENT)

From: Spencer Dawkins <[email-masked]>
Date: Tue, 23 Oct 2018 20:42:13 -0700

Spencer Dawkins has entered the following ballot position for
draft-murchison-tzdist-tzif-15: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-murchison-tzdist-tzif/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I'm a little confused on one high-level point. In this text,

   This document defines the Time Zone Information Format (TZif).  It is
   a binary format used by most UNIX systems to calculate local time.
   There is a wide variety of interoperable software [tz-link] capable
   of generating and reading files in this format.

is it correct to say that you're documenting the existing format, or are you
also defining aspects that are not currently deployed (which would obviously be
"defining")?

---

From: Eliot Lear <[email-masked]>
Date: Wed, 24 Oct 2018 10:32:06 +0200

Hi Spencer, Adam, and Ben,

Alexey asked me to shepherd this doc.  Here is my view on the comments
received thus far:

  * On Adams suggestion for an including an example, within the bounds
    of readability, it should be included as an appendix.  Paul and Ken
    are looking for something suitable (they found an error in a zone in
    the process!).
  * On Spencer's point on “define”, The authors are documenting an
    existing format, but are also defining a code point.  I propose the
    use of the word “specifies”.  Covers all evils.
  * On Adam's point on privacy considerations, I tend to agree, and
    would suggest that the authors update accordingly to indicate the
    risk, and that appropriate protections be considered, with perhaps
    an informational reference to Sections 8 and 9 of RFC 7808.  It is
    not possible to list all mitigations, of course, because this is a
    file format and not a protocol.

Eliot

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 24 Oct 2018 22:15:43 -0500

Hi, Eliot,
On Wed, Oct 24, 2018 at 3:32 AM Eliot Lear <[email-masked]> wrote:

>    - On Adams suggestion for an including an example, within the bounds
>    of readability, it should be included as an appendix.  Paul and Ken are
>    looking for something suitable (they found an error in a zone in the
>    process!).
>    - On Spencer's point on “define”, The authors are documenting an
>    existing format, but are also defining a code point.  I propose the use of
>    the word “specifies”.  Covers all evils.
>
> I wondered (at the non-blocking Comment level) whether the relationship
between what's being documented here and what's deployed in Unix
implementations would be clear to most readers - it was not obvious to me.
ISTM that it would be useful to say "this stuff is currently deployed as
specified in this document" or "this stuff is currently deployed as
specified in this document, except that section NN is new, and section OO
is a significant change from today's deployed implementations".

But I know you'll do the right thing :-)

Spencer

>
>    -
>    - On Adam's point on privacy considerations, I tend to agree, and
>    would suggest that the authors update accordingly to indicate the risk, and
>    that appropriate protections be considered, with perhaps an informational
>    reference to Sections 8 and 9 of RFC 7808.  It is not possible to list all
>    mitigations, of course, because this is a file format and not a protocol.
>
> Eliot
>
> The document, along with other ballot positions, can be found here:https://datatracker.ietf.org/doc/draft-murchison-tzdist-tzif/
>
>
>