[Tzdist-bis] Benjamin Kaduk's No Objection on draft-murchison-tzdist-tzif-15: (with COMMENT)

Benjamin Kaduk <kaduk@mit.edu> Thu, 25 October 2018 14:23 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: tzdist-bis@ietf.org
Delivered-To: tzdist-bis@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DA8E9128CF3; Thu, 25 Oct 2018 07:23:41 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Benjamin Kaduk <kaduk@mit.edu>
To: The IESG <iesg@ietf.org>
Cc: draft-murchison-tzdist-tzif@ietf.org, tzdist-bis@ietf.org, lear@ofcourseimright.com
X-Test-IDTracker: no
X-IETF-IDTracker: 6.87.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <154047742188.16315.11198947516223337349.idtracker@ietfa.amsl.com>
Date: Thu, 25 Oct 2018 07:23:41 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/tzdist-bis/ZXja646zigntpdYZOdT06E-YoBE>
Subject: [Tzdist-bis] Benjamin Kaduk's No Objection on draft-murchison-tzdist-tzif-15: (with COMMENT)
X-BeenThere: tzdist-bis@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Extensions to Time Zone Data Distribution Service <tzdist-bis.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tzdist-bis>, <mailto:tzdist-bis-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tzdist-bis/>
List-Post: <mailto:tzdist-bis@ietf.org>
List-Help: <mailto:tzdist-bis-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tzdist-bis>, <mailto:tzdist-bis-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Oct 2018 14:23:42 -0000

Benjamin Kaduk 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:
----------------------------------------------------------------------

Updating to remove my Discuss position, as I am confident that it can be
resolved (e.g., via an RFC Editor note).  The original point was:

This is a very boring, almost-trivial discuss point, but the document seems to have
an internal inconsistency to resolve before publication:

Section 3.1 says that the typecnt "MUST NOT be zero", but Section 3.2 says:

   A TZif data block consists of seven variable-length elements, each of
   which is series of zero or more items.  [...]

This is in conflict with the above "MUST NOT be zero" for typecnt.
I don't have a better suggestion than adding a parenthetical "(except for
the local time records, which as mentioned above cannot have zero items)",
even though I acknowledge that it is pretty awkward.

Original COMMENT section:

Section 2

   Coordinated Universal Time (UTC):  The basis for civil time since
      1960.  It is approximately equal to mean solar time at the prime
      meridian (0 degrees longitude).

Usually when "approximately" is used I ask for some quantification/bounds,
but I guess we can skip that for this well-known case.

Section 3.2

   transition types:  A series of one-octet unsigned integers specifying
      the type of local time of the corresponding transition time.
      These values serve as indices into the array of local time type
      records.  The number of type indices is specified by the 'timecnt'
      field in the header.  Each type index MUST be in the range [0,
      'typecnt' -1].

Please specify that the array accesses are zero-indexed.  (Also for
(desig)idx.)

      (is)dst:  A one-octet value indicating whether local time should
         be considered Daylight Savings Time (DST).  The value MUST be 0

nit: just "Daylight Saving"

Section 5.1

nit(?): some readers might interpret the "truncation range" to be "the
range that is truncated, i.e., omitted, from the file" as opposed to "the
range after truncation".  I guess one could make the same claim about the
phrase "truncated range" as well, so maybe no action is the best plan,
here.

Section 7

I also agree with Adam about the privacy considerations -- while the
contents of the file are not the concern, the metadata surrounding which
files go where have privacy implications worth mentioning.