Subject: [dhcwg] Timezones again.

From: "David W. Hankins" <[email-masked]>
Date: Mon, 10 Apr 2006 15:28:57 -0700

First, on the subject of "imagined clients."

In the past week and change, I've been talking on this subject with
anyone who will listen.  I've been told I'm out of touch with users
needs by at least one individual, and that's not an acceptable thing
to even question.  Certainly, I am not unbiased on the subject.

I've talked with Jason Vas Dias who works on DHCP software distribution
stuff at Redhat (but his views aren't necessarily those of his
employer's).  He imparted to me a story that, in his corner of the
world, the TZ database did not have what he needed.  To get the correct,
current wall-clock time on their DHCP-connected systems, they actually
did use the time offset option (code 2) (hacking ISC "dhclient-script"
to do so) to set the wall clock.  This was done combining a fixed offset
from UTC TZ database entry, and using the time-offset field as a server-
supplied means of determining what he called "the political timezone."
This worked, because the DHCP server could be reconfigured with the
correct political time offset when the correct time to do so transpires
...and lease expiration timers could be reduced in advance so that
clients renewed their bindings shortly thereafter.

I've also talked with Mark Andrews, who after returning to Australia
after IETF 65 found himself in a taxi cab on the way home.  His
cell phone, his taxi driver, and his wife all disagreed on what the
correct local time was.  All because DST had been delayed a week due
to a game (cricket, I think).  The TZ database on his laptop would
also have had the wrong local wall-clock time, and that this would
have been an undesirable third false indicator.

I've also talked with a few Unix systems administrators, and no, they
don't all work at ISC.  One, Majdi Abbas at salesforce.com (whose
opinions are also not those of his employer's), refused to discuss this
option at all until I had entertained a lengthy rant from him on the
subject of the stupidity of DST and politicizing timezones.  A rant I
can't disagree with, and if we could simply do away with timezones
entirely and all live happily in UTC, I'd be for that.

But last I checked, we don't yet have that kind of power.  Yet.

I was just thinking to myself that this crossection of individuals
rather well represents our, that is ISC's, DHCP users, from vendors
who redistribute our products to actual end-users in the trenches...
which is who I was out to ask about this subject.  It doesn't really
slice into the area of experts in the field of network time, who might
be privvy to some secret knowledge the rest of us are ignorant to.

Then, while I was still editing this very email, I found myself lucky
enough to be sharing a table at lunch with Harlan Stenn, whose work on
the NTP Public Services Project might not need introduction.  I think
he qualifies as an expert in the field.

We were trying to have a technical conversation shouting at each other
over the dinn at a Red Robin (tm), and the conversation was audible...
that is not digital eg email or similar, so I don't have any notes to
quote directly.

It also may simply have been his desire to return to his burger and
get me out of his face, but he emitted nothing short of fundamental
agreement.  Certainly, I got no hint that some knowledge hidden to us
about time and history makes current correct wall-clock time undesirable
in comparison.

And if any of us weren't in on Time's Terrible Secret, certainly he
would be.

The consensus of these encounters, is: servers care about historic
time, but it's a 50/50 toss-up as to wether current wall-clock time is
more important or not.  It might be in some cases, isn't in others.
They are also generally not DHCP configured, but rather most sysadmins
favor statically configuring each server.  One less element of the
network to fail.  Desktops?  Laptops?  Historic time is irrelevant
compared to having the desktop clock emit the correct local wall-clock
time.

So, upon these reflections, I reaffirm that for most DHCP configured
devices, correct current local "wall clock" time is more important
than complete historic record of correct wall clock time.  What time
it is now is substantially more important than what time it was
yesterday to the vast majority of devices using DHCP to configure.

The way you get that is by picking one of TZ or POSIX formats, and
preferring it...but not to the exclusion of the other if only one
of the two is available.

And I reject any statement that the needs presented by these
'imaginary' clients don't exist.  Quite the contrary, they will
be the primary consumer.

So.

We have one thing, the local timezone, and three different ways of
digesting it.

We have clients that will happily digest multiple encodings, taking
the 'best' of what is offered.  I measure these to be the majority
of clients.  A subset of these may wish to actually receive multiple
encodings in order to compare them to determine which is best, but
we can't tell how many; probably not a lot as it is fairly hard
to compare two different encodings meaningfully.

We have clients that will only digest a single encoding, making
transmission of the others a waste of DHCP payload space, and
'sub-options' extra overhead.  I measure these to be the minority
of clients, but in those places where the need is real it is
crippling (eg, a phone or similar 'small' embedded device, despite
the fact that no phone DHCP stack implementors have yet to speak
up on this topic on this list referring to their needs).

We judge that it is a waste of space to send these option contents
if the client doesn't support the encoding method.  We must also
judge that it is a waste of space to send these option contents if
the client supports more than one encoding method but it will only
select one to use.

The former is obviously problematic, even rediculous.  But, it
represents a corner case, entered into by the minority of clients
that support only one of the three formats without supporting a
fallback for the POSIX string.

The latter, however, is what I perceive to be the general case.

So if solving the problematic corner case is so important we must
elide from suboptions to individual options, then how important is
the general case to solve?

Substantially more important I think.

So in summary, without typing too much more (I think I'm over quota
already), I think that if we resolve that this waste of space is
unacceptably high, we must solve the general form of the identical
waste before solving the corner case form.

With a brief footnote that the 'compatible-request-list' I floated
last message isn't the way to do that, with the format of the
options we have today (note the subset of clients that desire more
than one format to compare).

More on this after I feel I haven't typed enough re: where do we go
from here.

-- 
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: Mon, 10 Apr 2006 15:56:04 -0700

Forgive me for giving you a pithy one-paragraph response, David, but it sounds 
llike the status quo (time zone offset) is actually perfectly fine for you, 
and that you do not need this new option we're discussing.  I realize, 
though, that that's not what you actually said.   Is there any truth to this 
conjecture of mine?

---

From: "David W. Hankins" <[email-masked]>
Date: Mon, 10 Apr 2006 16:35:53 -0700

> though, that that's not what you actually said.   Is there any truth to this 

The status quo is actually perfectly fine for Jason Vas Dias, in DHCPv4
(he even said that).

I think the options suggested by Elliot provide some utility for people
who are not Jason but would also cover his needs and also be more
complete (rather than merely being the hammer he happened to have in his
toolbox at the time, and has now grown inseparable from).

You see, any new option, no matter what we do, will be work for him to
adopt.  He's busy enough as it is.

So the lack of status quo in DHCPv6 is again defined as the primary
problem.

But, hypothetically, if we were designing protocol for Jason's set of
problems as being representative of the majority of clients needs, then
Ralph's original draft is provably an adequate solution.

I think Elliot explicitly stipulates that there is a larger problem
set to solve for, that we can do better than merely adequate, and
that's where we're getting hung up.

---

From: John Schnizlein <[email-masked]>
Date: Mon, 10 Apr 2006 19:59:35 -0400

> though, that that's not what you actually said.   Is there any truth 

Although I will not presume to speak for David about his lack of need, 
I will note that he described different needs and objected to the 
suggestion that his clients are imaginary.

There are at least 3 issues that seem to be entangled tangled here.  
(1) The existing time offset (RFC 2131, option 2) lacks automatic 
changes at occasional times for the (horrible) Daylight Saving 
adjustment.  (2) The TZ database provides lots of historical 
information for hosts that have it (up to date) and lack only the name 
of the entry for where they are.  (3) Different options or sub-options 
of a new multi-purpose option could address issues 1 & 2.

IMHO assertions that all hosts need the name of the time-zone, either 
daylight-saving or otherwise overstates the requirement.  David 
provided examples where clients need just correct wall-clock time.  Of 
all the computers in my house (or pocket), only those with 
general-purpose operating systems bother with this - those with just 
radios, CD players, and/or telephone functions present just the time, 
including the one that "listens" to WWV just display the time.  For 
this set of IP hosts, computers embedded in all sorts of things, simply 
fixing the lack of offset transitions is adequate and appropriated.  
Two new options with 32-bit time values for NextOffset and 
TimeOfNextOffset would satisfy that.

The devotion displayed for the TZ (aka Olsen) database suggests that 
some hosts really want to be given the name (index into the database) 
of their time-zone, and prefer to rely on the entries in that database 
for which offset and display time-zone to display when.  A single new 
option for the name of a Zone entry in the database referred to as the 
TZ (or Olson) database string would satisfy that.

Because which of these kinds of information are useful is different for 
different clients, they should be separate options so that clients can 
choose which to request.

John

---

From: Ted Lemon <[email-masked]>
Date: Mon, 10 Apr 2006 17:39:07 -0700

> suggestion that his clients are imaginary.

I won't quote your whole summary, but I think I agree completely both with the 
conclusion you've come to, and the reasons you stated for coming to it.   It 
does indeed sounds like David's needs are fully addressed by the POSIX 
option, and that, based on the needs expressed, he would never need to 
implement the TZ option.

---

From: "David W. Hankins" <[email-masked]>
Date: Tue, 11 Apr 2006 02:20:11 +0000

> option, and that, based on the needs expressed, he would never need to 

I thought I typed 'in the absence of'.  I can't include the entire
discussion from each of them, I tried to cover the highlights, the gist
of the spectrum, and then summarize the consensus of all parties.  The
compromise that meets all their needs.

So:

- Some clients will exist for which, when POSIX is available but TZ is not,
  would prefer to use POSIX rather than nothing at all (but normally would
  prefer TZ).  Think North America, although less so these days, or any
  environment where 'political time zone' is not at the whim of some
  uncontrollable, chaotic, random event: TZ will generally be correct, and
  preferred, POSIX in the absence of TZ (or in the case where it is somehow
  provably inaccurate for wall clock time) is a desirable fall-back position.

- Some clients will exist for which, when TZ is available but POSIX is not,
  would prefer to use TZ rather than nothing at all (but normally would
  prefer to use POSIX because TZ is almost never correct).  I don't actually
  know what geopolitical sphere Jason is operating in, but I imagine he is
  not alone.  Mark Andrews, for example, lives in an environment where
  'political time zone' was decided by wether or not a game had finished.
  TZ in the absence of POSIX is a desirable fall-back position.

I suspect the above two sets will comprise the largest portion of consumers
of these two options.

Our own client will need to fill both needs since our users span both
sides:  Whichever one is present, with a preference applied to one if both
are, that preference being user-selectable.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 10 Apr 2006 20:57:53 -0700

> are, that preference being user-selectable.

Then I suggest you design your client to request both options.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 10 Apr 2006 21:23:36 -0700

> are, that preference being user-selectable.

To expand on my previous one-liner, let me suggest an alternative:  for those 
implementers, such as you, who want the client to be flexible enough to take 
whatever is configured on the server, in the case where a server has not been 
configured to provide every possible option, configure your client to request 
all three, in the order that you prefer.

This has the disadvantage of consuming more packet space, although I think not 
much.   If you want to mitigate that problem, then implement the following 
heuristic in your server: if it sees that all three options have been 
requested, it responds with the first one listed for which data is available, 
and doesn't send the other two, even if data is available.   This could be a 
MAY in the protocol specification.

What I specifically want to avoid is:

1. Sending options the client didn't ask for.
2. Using a suboption encapsulation in a case where at most we need to send 
only two options.
3. Defining and requiring the implementation of a protocol for negotiating 
which suboptions to send.

I think there is a better solution than this, which we could pursue in a 
separate draft if there was demand for it.   I think a general case can be 
made for it - an option request option with preference chunks, basically.   
It would look like this:

ORO length hunk-count-1 first-choice-1 second-choice-1 third-choice-1 
hunk-count-2 first-choice-2 second-choice-2 hunk-count-3 first-choice-3 
second-choice-3 ...

You'd have one hunk for each set of alternatives; each hunk would contain 
simply a list of option codes, in order of preference.   The server would 
respond with at most one of the alternatives listed, and would send the first 
such alternative that matched, which would be the one the client most 
preferred of the choices available.

This would be general, not specific to the timezone options.   It would be 
relatively cheap to implement, because really it's just an enhancement of the 
existing option request option (or parameter request list).   The client 
would have to send two OROs, because it couldn't count on the server 
understanding both of them.   This would be a minimal problem, because 
packets coming *from* the client generally aren't crammed with options - it's 
packets coming *from* the server that are.

But I would like to separate that issue from the issue of these timezone 
options, because they are really two separate issues.   This preference-based 
option negotiation is not something that Eliot volunteered to work on.   I 
think that we get substantial value out of Eliot's work whether we do the 
best-choice ORO or not.   So tying the two together, or even really debating 
about the second in the same conversation as the first, seems (a) unnecessary 
and (b) delay-inducing.

And this is the underlying reason why I keep debating you and asking you for 
real use cases.   So there you have the question: would you be willing to 
split this debate into two?

---

From: Shane Kerr <[email-masked]>
Date: Tue, 11 Apr 2006 12:09:13 +0200

Ted,

> hunk-count-2 first-choice-2 second-choice-2 hunk-count-3 first-choice-3 

<snip/>

> split this debate into two?

I like this approach. The combination of the existing TZ draft and a
mechanism for expressing option preferences would address all of my
concerns with the TZ options.

- --
Shane

---

From: "David W. Hankins" <[email-masked]>
Date: Tue, 11 Apr 2006 09:09:46 -0700

> 2. Using a suboption encapsulation in a case where at most we need to send 

At some point, I'd like to hear your reasoning for this, but perhaps
I should wait to hear this reasoning in the Introduction section of a
draft you appear set to write (?), rather than asking you to duplicate
that effort.

> preferred of the choices available.

Because when I compare these two solutions, they are very near in
function.

I tend to think of a sub-parameter-request-list as easier to implement,
but less general (it couldn't include the old time-offset option for this
set of timezone options for example, or indicate a preference for
domain-search over domain-name, or etc).

But it's possible I only have that bias because I've already implemented
sub-parameter-request: what you've already done always seems easier than
what you haven't entertained.

So, this is a new direction that deserves thought and analysis.

> packets coming *from* the server that are.

Parameter-requests are usually short anyway, shorter even than the POSIX
format presently being described here (the longest common one I'm
presently aware of in DHCPv4 is 18 codes long, commonly emitted by SuSe
9.1 [1]).  The worst case application of your proposed change would be to
consume these 20 bytes plus another 38, for a total of 58 bytes.  Still
pretty small, considering.

> So there you have the question: would you be willing to 

Yes, but this body needs to be agreed on how we're going to proceed.

Similiarly to my position on other draft controversy in recent memory, I
need to be sure we've selected a way forward before we run the work in
parallel.

But fundamentally:  You and I are in agreement on the problem set, if
not the solution, and that is measurable progress.

Thank you for your time.

[1] DHCP Listener (Java "DHCP Fingerprinting" applet)
    Author Unknown
    The University of Kansas
    Lawrence, KS, U.S.A.

    http://www.nts.ku.edu/downloads/

Derivative work:

    class "VendorIdent" {
            match option dhcp-parameter-request-list;
    }

    subclass "VendorIdent" 1:3:6:c:f:11:17:1c:1d:1f:21:28:29:2a:9:7:c8:2c {
            set os-ident = "Linux 2.6.5-7.108 Suse 9.1/Novell Desktop";
    }

---

From: Eliot Lear <[email-masked]>
Date: Tue, 11 Apr 2006 19:52:43 +0200

David,

Thank you for your note.  A few comments.

Regarding your example of a use of option 2, just because someone did
something with with it doesn't make it a good idea.  Quite the contrary
in my mind.  That person demonstrated its flaw.  Clearly POSIX is a far
better option in order to avoid synchronizing DHCP updates to DST changes.

Having said that I agree with your conclusion that while history is
nice, wall clock time is required.  My point is that the best way for a
client to get wall clock time is for it to receive something as close to
native as possible.  In MOST UNIX implementations the best approach is
the TZ database because that's what nearly all of them use.  This
requires no kernel changes and no tweaks to the environment, a hazardous
approach, always, IMHO.  Again, this makes history a side benefit.   
For Microsoft, I have a query out to the person responsible for
Microsoft DHCP and he has agreed to review the document soon, and so
I'll withhold comment.

As to Australia's problem (and the Brazil papal visit, for that matter),
one issue I've heard from SPs is that they really don't WANT to have to
provide the actual TZ definition, and would rather provide a reference
to something in the OS.  This makes the update "somebody else's
problem".  I personally don't like that approach, but if we split into
three options we get that for free IFF we say only "MUST implement" not
"MUST deploy" which is the line we usually draw, anyway.

This would also solve Ted's problem.

Regards,

Eliot