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

[Ralph Droms <[e-mail]>]

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
[e-mail]
https://www1.ietf.org/mailman/listinfo/dhcwg