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

Hi Ralph,

First, thanks for your comments.  Please see below.

Ralph Droms wrote:
> 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.
I propose to do this using the classic "related work" heading at the
bottom of the introduction.
>
> Here is some suggested text for the Abstract and Introduction:

Thank you for the suggested text.  The RFC Editor strongly objects to
text in the abstract that is simply copied from the introduction.  As
such I would prefer to leave the abstract unchanged, or I would accept
other alternate text.
>
> 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)?

Microsoft also has a database, but one can vary from it without grief
because POSIX provides sufficient information to populate the registry.

>
>    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?

Fixed.

>
>    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.

Fixed.

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

My argument remains as follows:

    * the offset is broken for the reasons described in the introduction;
    * the reason I'm writing this in the first place is to provide a
      correct approach;
    * having fewer ways to accomplish a task is better.

On that last point, it is quite possible to derive offset information
from the POSIX option without *too much* effort.
>
> Section 10: missing space after "Dusseault,"

Fixed.

>
> 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.
>

Added.

Thanks again,

Eliot

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