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