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