Subject: [dhcwg] timezone draft

From: Eliot Lear <[email-masked]>
Date: Tue, 07 Mar 2006 09:30:26 +0100

Draft now available.

Eliot 

New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: A Timezone Option for DHCP
	Author(s)	: P. Eggert, E. Lear
	Filename	: draft-lear-dhc-timezone-option-02.txt
	Pages		: 10
	Date		: 2006-3-6
	
DHCP defines an option for a server to deliver to a client offset
from UTC.  This information in and of itself is not sufficient for
devices to portray local time both accurately and consistently.  This
memo specifies a new option for both DHCPv4 and DHCPv6 to do so.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-lear-dhc-timezone-option-02.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request at ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-lear-dhc-timezone-option-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

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

---

From: John Schnizlein <[email-masked]>
Date: Wed, 8 Mar 2006 08:39:15 -0500

On Mar 7, 2006, at 3:30 AM, Eliot Lear wrote:

> ...	

The scholarship of documenting various encodings for the Daylight  
Saving time changes in this draft is impressive.  The argument that the  
static offset specified in RFC 2132 is inadequate is convincing.  
Although it might seem that changing the offset in the middle of the  
night twice a year is rare enough for a static configuration parameter,  
the synchronization of this event is a problem.

The TZ database appears to be overkill for solving the problem, and an  
entry of the form:

"EST5EDT4,M3.2.0/02:00,M11.1.0/02:00"

duplicates the function (in the "EST5EDT4" portion) of the existing  
DHCP option:

> 3.4. Time Offset
>
>    The time offset field specifies the offset of the client's subnet in
>    seconds from Coordinated Universal Time (UTC).  The offset is
>    expressed as a two's complement 32-bit integer.  A positive offset
>    indicates a location east of the zero meridian and a negative offset
>    indicates a location west of the zero meridian.
>
>    The code for the time offset option is 2, and its length is 4  
> octets.
>
>     Code   Len        Time Offset
>    +-----+-----+-----+-----+-----+-----+
>    |  2  |  4  |  n1 |  n2 |  n3 |  n4 |
>    +-----+-----+-----+-----+-----+-----+

A simpler approach would be an option that indicates at what time the  
offset should next change and to what value.  This enables a RENEW or  
INFORM message any time during the next time cycle to get the next  
change.  It also allows for changes such as the complex set for Indiana  
this April, and the legal change for the United States in March of next  
year. [http://en.wikipedia.org/wiki/Daylight_saving] Automatically  
configuring one change at a time avoids errors from (humans) failing to  
update the TZ database with new entries.  The time-to-change-offset and  
new-offset should be 32-bit two's complement integers for compatibility  
with the existing offset.

Defining multiple sub-options for different cases should be avoided  
when possible.  Defining different sub-options for different current  
operating systems is a bad idea.

John

---

From: Eliot Lear <[email-masked]>
Date: Thu, 09 Mar 2006 08:58:14 -0800

John,

Thanks for taking the time to review the draft.  Please see below.
> duplicates the function (in the "EST5EDT4" portion) of the existing
I think this is an argument for deprecating the old option.  There's
plenty more information (like when to change, and what to display) in
the above example.
> change.  It also allows for changes such as the complex set for
> Indiana this April, and the legal change for the United States in
> March of next year. [http://en.wikipedia.org/wiki/Daylight_saving]
> Automatically configuring one change at a time avoids errors from
> (humans) failing to update the TZ database with new entries.  The
> time-to-change-offset and new-offset should be 32-bit two's complement
> integers for compatibility with the existing offset.
>

For all of its scholarly descriptions ;-), I believe you've exposed a
deficiency in the current draft.  I have not fully stated the motivation
for why one would go to all the trouble of these suboptions.  I propose
the following addition somewhere in Section 1:

NEW:

    With just an offset or even just an offset with a time of next
    change, the device does not have sufficient information to display
    its current timezone.  Further, configuration tools often interpret
    the timezone based on one of the representations defined in this
    draft.  For these reasons the best representation of timezone
    information is either a form the client natively understands or a
    form that can be easily mapped to a form the client natively
    understands.

Thanks,

Eliot

---

From: Stig Venaas <[email-masked]>
Date: Wed, 15 Mar 2006 09:56:17 +0100

>     form that can be easily mapped to a form the client natively

Right, so how does the server decide which sub-options to include, does 
it necessarily know which version can be mapped to something the client 
natively understands? Or do you suggest it just includes multiple 
sub-options? I think there should be some text discussing this.

Stig

---

From: Eliot Lear <[email-masked]>
Date: Wed, 15 Mar 2006 09:35:12 -0800

Stig,
> Right, so how does the server decide which sub-options to include,
> does it necessarily know which version can be mapped to something the
> client natively understands? Or do you suggest it just includes
> multiple sub-options? I think there should be some text discussing this.
I've been evolving my thinking on this question for some time, but
haven't come to a conclusion.  Initially my thoughts were that the
server would need some flexibility here, but I'm not so sure.

I think there are two possible answers to your question:

   1. In a limited environment the server is configured to send what the
      clients will use.  For instance, a small office might just send
      POSIX and Microsoft.
   2. In a broader environment the DHCP server does a conversion from
      the TZ database to the other formats and sends those.  While there
      has been no mapping from TZ to Microsoft, it's probably not hard
      to do, and POSIX strings can be generated from TZ.  This only
      requires processing power when these values are changed.  An in
      memory table with a simple lookup can be done.

I prefer option two because it should involve less administrator
involvement.  But it does raise a question.  If everyone agrees that's
the best approach, should we go with a different format option that
doesn't make use of suboptions, but instead just provides three
elements, two of which are variable length.  I think this is a ripe
issue for discussion.

Eliot

---

From: Robert Elz <[email-masked]>
Date: Sat, 18 Mar 2006 05:36:36 +0700

Date:        Wed, 15 Mar 2006 09:35:12 -0800
    From:        Eliot Lear <[email-masked]>
    Message-ID:  <[email-masked]>

  | I think there are two possible answers to your question:
  | 
  |    1. In a limited environment the server is configured to send what the
  |       clients will use.  For instance, a small office might just send
  |       POSIX and Microsoft.
  |    2. In a broader environment the DHCP server does a conversion from
  |       the TZ database to the other formats and sends those.  While there
  |       has been no mapping from TZ to Microsoft, it's probably not hard
  |       to do, and POSIX strings can be generated from TZ.  This only
  |       requires processing power when these values are changed.  An in
  |       memory table with a simple lookup can be done.
  | 
  | I prefer option two because it should involve less administrator
  | involvement.

The downside of this is sending much more data, two thirds of which we
know must be a waste of space (because it is really all the same data,
expressed in 3 different ways).

The relevant point is that it is the client that knows what format it
wants (so sending everything and allowing the client to choose does work).
In some way, the ideal would be for there to be different options rather
than sub-options - then the client can simply request the format that
meets its needs by requesting the appropriate option.

Of course, the limited option space makes that an unattractive answer,
which is why we have all of this sub-option stuff at all.

Do we have a general way yet for a client to request a particular sub-option?

If not, this seems like the perfect excuse to add that ability to DHCP.
I can't see that this will be the only case where a client is going
to want to select one of a set of possible sub-options for a reply.

My suggestion (made with very little thought for the consequences, so
feel free to trash this completely) would be for the client to request
the option as now, but also send the option in its discover/request
with the value of the option containing the desired sub-option code,
but no other data.   The server seeing that combination would reply with
the particular sub-option requested.   An option request without the
additional sub-option indicator would cause the server to either send
all applicable sub-options in the reply, or whatever sub-options the
server admin has selected as most appropriate (either for the server as
a whole, per subnet, or for an individual client - that's just a server
confionfiguration issue).

kre

---

From: Ralph Droms <[email-masked]>
Date: Fri, 17 Mar 2006 21:50:50 -0500

We'r enot really pressed for option codes, now that the option code space
has been expanded.  If it's worth saving the extra bytes by sending back
only one timezone endocing, then we should define three separate options.
Mechanisms for requesting sub-options seem to me to add unnecessary
complexity.

- Ralph

---

From: Eliot Lear <[email-masked]>
Date: Fri, 17 Mar 2006 18:52:27 -0800

I'm happy either way.  Let's discuss it next week, but it's easy to
split suboptions into three separate options.

Eliot

---

From: Ted Lemon <[email-masked]>
Date: Fri, 17 Mar 2006 21:54:38 -0700

> which is why we have all of this sub-option stuff at all.

The option code space is not so limited that if we need three options and no 
more, we can't afford to spend them on this.

I think trying to standardize a way to request suboptions would be challenging 
at this point, and probably pointless.   Maybe I'm being shortsighted, but 
the reason we freed up all that option code address space a year or two ago 
was precisely so that we wouldn't be painted into a corner when we needed a 
couple of extra option codes.   We are barely adding any new options to 
DHCPv4, so there isn't a crisis here we need to painfully avoid.