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

Re: [dhcwg] dhc WG last call on draft-ietf-dhc-timezone-option-02.txt

Comments (with WG chair hat off) on draft-ietf-dhc-timezone- option-02.txt:

I think the references to "prior art", including the existing DHCP
offset option and VTIMEZONE, should be moved to a separate section at
the end of the document.  I also think text marketing this option as
an improvement to the existing DHCP offset option in the body of the
document are unnecessary.  A simple sentence outlining the problems
with the offset option in the "prior art" section should suffice.
Here is some suggested text for the Abstract and Introduction:

Abstract

   This document defines new options for DHCPv4 and DHCPv6 through
   which a DHCP server can indicate what timezone a DHCP client should
   use in determining its local time.  The timezone information is
   used to determine the offset between UTC and local time for the
   client.

1.  Introduction

   This defines new options for DHCPv4 and DHCPv6 through which DHCP
   hosts can be provided with accurate timezone information.  There
   are currently two well known means to configure timezones:

   o  POSIX TZ strings
   o  Reference to the TZ Database
Are these the only two well known means to configure timezones?  What
about the Microsoft option (which has been removed from this document)?

   POSIX [1] provides a standard for how to express timezone
   information in a character string.  Use of such a string can
   provide accuracy for at least one transition into and out of
   daylight saving time (DST), and possibly for more transitions if
   the transitions are regular enough (e.g., "second Sunday in March
   at 02:00 local time").  However, for accuracy over longer periods,
   that involve daylight-saving rule changes or other irregular
   changes, a more detailed mechanism is necessary.

   The so-called "TZ Database" [6] that is used in many operating
       ^^^^^^^^^^^^^^^^^^^^^^^
Why use "so-called", which (to my mind, anyway) diminishes the
credibility?

   systems provides backwards consistency and accuracy for almost all
   real-world locations since 1970.  The TZ database also attempts to
   provide a stable set of human readable timezone identifiers.  In
   addition, many systems already make use of the TZ database, and so
   the names used are a defacto standard.

Sections 4 and 5: eliminate double quotes from example or specifically
note that the double quotes are not included in the data on-the-wire.

Section 7.1: I don't see any need or advantage to deprecate the
previous time offset option.

Section 10: missing space after "Dusseault,"

Mention that configuration of the TZ database is explicitly out-of- scope of this document, in conjunction with this sentence in section 5:

   In order for this option to be useful, the client must already have
   a copy of the database.

- Ralph


_______________________________________________
dhcwg mailing list
dhcwg at ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg