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

[Ralph Droms <[e-mail]>]

Eliot - I'm not sure how to interpret your first two responses.  Will  
you move all the references to the existing DHCP offset and VTIMEZONE  
to the prior art section?  Will you add a reference to the Microsoft  
database (for completeness)?

Regarding the abstract, in my opinion, the Abstract I suggested is  
not simply copied from the Introduction.  BTW, I goofed in the  
Introduction and omitted the word "document" after "this" in the  
first sentence.  The text I suggested explains (a) what options are  
defined and (b) what those options are used for.

One additional followup to your response about the Microsoft database  
- the wording in the document suggests (at least to me) that there  
are only two ways to configure the timezone in a device.  My  
suggestion would be to reword as:

    These options use two well-known means to configure timezones:

    o  POSIX TZ strings
    o  Reference to the TZ Database

- Ralph

On Aug 14, 2006, at 2:40 AM, Eliot Lear wrote:

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