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

From: Ralph Droms <[email-masked]>
Date: Wed, 9 Aug 2006 12:09:14 -0400

This message announces a WG last call on "A Timezone Option for DHCP"
<draft-ietf-dhc-timezone-option-02.txt>.  The last call will conclude
at 1700EDT on Wed, 2006-08-16.

Please respond to this WG last call.  If you support acceptance of the
document without change, respond with a simple acknowledgment, so that
support for the document can be assessed.  Lack of discussion does not
represent positive support.  If there is no expression of support for
acceptance during the WG last call, the document will not be advanced
to the IESG.

draft-ietf-dhc-timezone-option-02.txt specifies new options for both
DHCPv4 and DHCPv6 to provide hosts with accurate timezone
information, using the following two means to configure timezones:
    o  POSIX TZ strings
    o  Reference to the TZ Database.
This draft is available as
http://www.ietf.org/internet-drafts/draft-ietf-dhc-timezone- 
option-02.txt

- Ralph Droms

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: "David W. Hankins" <[email-masked]>
Date: Wed, 9 Aug 2006 09:10:53 -0700

> support for the document can be assessed.  Lack of discussion does not

I support acceptance of the document without change.

-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		you'll just have to do it again."
Internet Systems Consortium, Inc.	-- Jack T. Hankins
_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Ted Lemon <[email-masked]>
Date: Wed, 9 Aug 2006 16:51:21 -0700

I support acceptance of the document with or without Shane's proposed  
change.

---

From: Shane Kerr <[email-masked]>
Date: Thu, 10 Aug 2006 14:35:10 +0200

Ralph Droms wrote:
> support for the document can be assessed.  

I support the document with the changes noted on the mailing list.

- --
Shane

---

From: Mark Stapp <[email-masked]>
Date: Thu, 10 Aug 2006 09:54:39 -0400

I have a couple of questions about the text.

in section 2:

  "The following three options ..."

there are only two options now.

and further on in section 2:

   "Len is the two-octet value of the length ..."

is that correct? these are 16-bit length v4 options? the accompanying 
picture looks like regular 8-bit lengths are intended.

in section 7.1, should there be a sentence guiding clients? section 7 
only discusses server behavior or configuration right now. should it 
include something to the effect that clients should ask for the new 
options along with the deprecated one? or that they should prefer the 
new options over the deprecated one if they receive both from their server?

other than those three questions, I support advancement of this draft.

Thanks,
Mark

Ralph Droms wrote:
> http://www.ietf.org/internet-drafts/draft-ietf-dhc-timezone-option-02.txt
> 
> - Ralph Droms
>

---

From: "H. Peter Anvin" <[email-masked]>
Date: Thu, 10 Aug 2006 08:21:46 -0700

> picture looks like regular 8-bit lengths are intended.

16-bit options in DHCPv4 would break a lot of existing clients.

	-hpa

---

From: Eliot Lear <[email-masked]>
Date: Thu, 10 Aug 2006 18:22:34 +0200

> there are only two options now.

Right.  To be fixed.

> picture looks like regular 8-bit lengths are intended.
The intent is 16 bits.  How can I improve the diagram?
> new options over the deprecated one if they receive both from their

If you think it needs to be said, okay.  Shane Kerr has proposed
language to clean this up a bit:
> "Current implementations that support the time offset IPv4 option SHOULD
> implement this option also. Other implementations SHOULD implement this
> option, and SHOULD NOT implement the time offset IPv4 option."

Would the following sentences appended to the above address your concerns?

"As a matter of transition, clients that already use the time offset option MAY also request the timezone offset option."

> other than those three questions, I support advancement of this draft.

Thanks, Mark!

Eliot

---

From: Mark Stapp <[email-masked]>
Date: Thu, 10 Aug 2006 14:19:09 -0400

Eliot,

[...]

> The intent is 16 bits.  How can I improve the diagram?

ummm - really? is there any other dhcpv4 option that specifies this? I 
think that these v4 options should not try to specify unique 'type' or 
'len' encodings. that'd be undesirable...

Thanks,
Mark

---

From: John Schnizlein <[email-masked]>
Date: Thu, 10 Aug 2006 14:32:30 -0400

Changing the size of the length field is not compatible with the 
definition in RFC 3121. Notice in this quoted excerpt that the length 
field is explicitly specified as "length octet".

John

2. BOOTP Extension/DHCP Option Field Format

    DHCP options have the same format as the BOOTP 'vendor extensions'
    defined in RFC 1497 [2].  Options may be fixed length or variable
    length.  All options begin with a tag octet, which uniquely
    identifies the option.  Fixed-length options without data consist of
    only a tag octet.  Only options 0 and 255 are fixed length.  All
    other options are variable-length with a length octet following the
    tag octet.

---

From: John Schnizlein <[email-masked]>
Date: Thu, 10 Aug 2006 14:37:24 -0400

Sorry for the typo.  The definition of options is, of course, in RFC 
2132, not 3121.

On Aug 10, 2006, at 2:32 PM, John Schnizlein wrote:

>> ummm - really? is there any other dhcpv4 option that specifies this? 
>> I think that these v4 options should not try to specify unique 'type' 
>> or 'len' encodings. that'd be undesirable...
>>
>> Thanks,
>> Mark
>>

---

From: Ted Lemon <[email-masked]>
Date: Thu, 10 Aug 2006 12:10:20 -0700

> The intent is 16 bits.  How can I improve the diagram?

Oh crap, my eyes went right over that.   It can't be two octets.    
There are no DHCPv4 options with two-octet length fields.   Eliot,  
you have to fix this.   Bear in mind that with the option  
concatenation standard (RFC3396), it's possible to express timezone  
info with more than 255 bytes, although in general we very much  
prefer to avoid info that's that large.

---

From: Eliot Lear <[email-masked]>
Date: Thu, 10 Aug 2006 21:19:49 +0200

> 'len' encodings. that'd be undesirable...

As I mentioned some time ago, I'm not a DHCP guy.  I am perfectly happy
with an 8 bit value.  I believe I transversed the requirement by
accident, thinking that it had to be 16 bits.  Without objection we'll
change that in the next round to a single octet.

Eliot

---

From: Ralph Droms <[email-masked]>
Date: Sun, 13 Aug 2006 07:11:05 -0400

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

---

From: Eliot Lear <[email-masked]>
Date: Mon, 14 Aug 2006 08:40:09 +0200

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

>    The so-called "TZ Database" [6] that is used in many operating

Fixed.

> note that the double quotes are not included in the data on-the-wire.

Fixed.

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

Added.

Thanks again,

Eliot

---

From: Ralph Droms <[email-masked]>
Date: Tue, 15 Aug 2006 07:01:46 -0400

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

- Ralph

---

From: Eliot Lear <[email-masked]>
Date: Tue, 15 Aug 2006 13:22:03 +0200

Hi Ralph,

> database (for completeness)?

Yes, yes, and see below.
>
> 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.

I'm sorry- to me it reads like the Introduction.  What is your objection
to the current abstract?
> - 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:
>
Ok, I understand your concern.  Barring objection I propose to use the
following wording:

This memo specifies a means to provide hosts with more accurate
timezone information than was previously available.  To do this we
make use of two commonly used methods to configure timezones:

Eliot