Subject: [dhcwg] new forthcoming dhc timezone draft

From: Eliot Lear <[email-masked]>
Date: Mon, 27 Mar 2006 10:07:41 +0200

Hi,

Based on feedback from the Dallas meeting we've made a small number of
modifications to draft-lear-dhc-timezone-option-00.txt.  They are as
follows:

    * Provide clarifying text about what a client should do when
      multiple suboptions are sent.
    * Remove unclarifying text about same ;-)

We've also added text about deprecation of the old time offset.  This
requires some discussion.  There are three reasons to deprecate:

    * At its mandatory minimum, the option is no more difficult to
      implement and deploy than the existing option;
    * Use of the new option for both IPv4 and IPv6 will make deployments
      both more consistent and easier; and
    * We *EVENTUALLY* (read: NOT NOW) free up an option.

If there is strong objection, we can remove this text.

The forthcoming draft does NOT split the three suboptions into separate
options.  I can do this in the next draft if there is consensus.  In the
room there seemed to be, but one issue was raised.  What to do about
mandatory to implement?  My concern is that if we implement three
separate options we'll have servers that only implement specific ones. 
I'm particularly concerned about vendor specific solutions.  If we can
say something like, "if you implement option X you MUST also implement
option Y" I guess I'm okay with still splitting.

Comments?

Eliot

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

---

From: Shane Kerr <[email-masked]>
Date: Mon, 27 Mar 2006 14:01:36 +0200

Eliot Lear wrote:
<snip/>
> option Y" I guess I'm okay with still splitting.

I would suggest going further and requiring that including either the TZ
Database or Microsoft TZ options in a packet would also require the
server to use the POSIX time zone option.

The downsides are an extra 40 bytes or so in the packet, and a bit of
extra code in the server. I am guessing this is a reasonable trade-off
to avoid situations where misconfigurations on the server cause either
clients to get no time zone information (bad) or different time zone
information depending on whether they understand the option (worse).
(Maybe SHOULD to let developers/admins make that choice for themselves?)

Is it important to mention possible issues with mismatched
configurations in the text? I can see cut & paste errors when a new
subnet is added where the TZ Database option is updated but the
Microsoft TZ option is not, for instance.

--
Shane

---

From: Ted Lemon <[email-masked]>
Date: Mon, 27 Mar 2006 11:42:48 -0700

There's no mechanism for removing option codes other than a working group 
action, so that's a fairly weak reason to give, but it's not untrue - we 
could at some point reclaim that code point.   But probably not for a really 
long time, particularly if it's being used e.g. by DOCSIS or something.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 27 Mar 2006 11:46:25 -0700

> information depending on whether they understand the option (worse).

So you're saying we should add a mandatory 40 bytes in a 312-byte buffer 
(that's all you've got for options in a DHCP packet) on the off-chance that 
someone does a bad implementation or makes an easily-correctable deployment 
mistake.    Are you proposing that we specify the algorithm that the client 
should follow to determine when to use the 40 bytes and when to use the other 
information, or should we leave that to the implementor?

---

From: Ted Lemon <[email-masked]>
Date: Mon, 27 Mar 2006 11:56:29 -0700

> server to use the POSIX time zone option.

Oh, one other point about this - it requires special-case code in the server 
to implement, because you're now requiring the server to make a decision to 
send two options instead of one.   Alternatively, you could require 
special-case code on the client to do this.   Either way, you're creating a 
significant implementation burden.

---

From: Shane Kerr <[email-masked]>
Date: Mon, 27 Mar 2006 21:29:02 +0200

> significant implementation burden.

I don't see how you can live without the POSIX time zone option. The
other two options require a database, which

- is not small, and
- must be updated, and so
- may be out of sync between client & server.

Also, given that one is Unix-oriented and the other is Windows-oriented,
any "minority" OS will probably have to live without time zone
information or understand both (I'm guessing that Windows will never use
another time zone database - otherwise Microsoft wouldn't have created one).

Maybe at the end I'm arguing that using a time zone database is bad,
because it doesn't make sense for all clients and there are multiple
standards. I was thinking that by supporting POSIX as a mandatory
fall-back, you could work around the drawbacks of the having a time zone
database and still get the benefits (not too sure what those are, but
still).

--
Shane

---

From: Ted Lemon <[email-masked]>
Date: Mon, 27 Mar 2006 12:57:41 -0700

POSIX _is_ the mandatory fallback.   So we already have that covered.   It 
seems to me that what you're suggesting is that it be mandatory for the 
clients as well.   It is on that point that I am questioning you.

The implication of your preference is that we're going to send 40 bytes of 
data to the client whether it wants it or not, and the client is going to be 
required to check the POSIX data against its internal database and discard 
the internal database information if it disagrees with POSIX.

A couple of other points - you said in your message that the TZ database is 
unix-specific, but it's not.   And you said that keeping a local copy of the 
timezone database up to date and relying on it is a mistake.   But it's not.   
It's what everybody does right now.

I think you are conflating two separate issues - how frequently and accurately 
the timezone database is updated, vs. how frequently a particular DHCP 
client's physical location changes.   In reality, the latter change is much 
more frequent than the former.   In practice, when the timezone database 
changes, it's not updated manually.   It's updated through an update manager 
of some sort, whether it's MacOS X software updates, Microsoft's software 
update system, Ubuntu's system, Redhat's system, or whatever.   These systems 
work well, and we depend on them all the time.

The fact is that POSIX timezone information isn't useful on a device that uses 
the TZ database or the Microsoft database.   Why?   Because the POSIX 
timezone doesn't give you enough information.   If you rely on the POSIX 
timezone option, you're going to experience a downgrading of service - you 
have no history of what the time was in this timezone a year ago, or a decade 
ago.   So you don't want to rely on this option, and indeed none of the 
operating systems I just mentioned relies on the current time offset option, 
nor do I expect them to rely on the POSIX timezone option.

What would be really nice, for virtually everyone running an operating system 
that has a timezone database, would be if there were some automatic way to 
tell which entry in the timezone database were valid in the current location 
of the DHCP client.   For such devices, the only thing that's going to do is 
the timezone name, expressed in one of the two formats mentioned here.   If 
you have a third format to propose, please do so.   But sending a 40-byte 
POSIX string to a Microsoft Windows device or a Linux device or a MacOS X 
device simply doesn't do any good.

---

From: Eliot Lear <[email-masked]>
Date: Tue, 28 Mar 2006 08:40:55 +0200

Hi Ted & Shane,

> clients as well.   It is on that point that I am questioning you.
I certainly believe that the only mandatory behavior in the spec for
clients is that they ignore stuff they don't understand.  I do wonder
about POSIX, given your other points.  It is a concern because in order
to make use of it it seems that it needs to end up in the environment on
a UNIX system, as opposed to in /etc/localtime.

Eliot

---

From: Shane Kerr <[email-masked]>
Date: Tue, 28 Mar 2006 12:22:44 +0200

Ted,

> the internal database information if it disagrees with POSIX.

I guess I don't understand completely. Say we have a server with the TZ
database:

Case 1:
- client requests TZ
- server replies with TZ (and maybe POSIX timezone?)

Case 2:
- client requests POSIX timezone
- server replies with POSIX timezone (and maybe TZ?)

Case 3:
- client requests MS Time
- server replies with ?

Case 4:
- client does not request any time information
- server replies with ?

AIUI, in Case 1 or Case 2, the server *could* include an unsolicited
option, right?

In Case 3 or Case 4, should the server reply with the TZ, or the POSIX
timezone, or both, or nothing?

Is it wrong to make any recommendations for these cases? (Developers &
administators will have to figure something out anyway.)

> It's what everybody does right now.

I guess the difference to me is that right now the TZ is set by someone
with adminstrative control of the machine. Either the user or the
sysadmin. If it's done with DHCP, then the TZ might be set by someone else.

I'm also considering the case where a small system either can't or
doesn't update its TZ database - something like a camera or cell phone.
Further, a device like this might exclude some esoteric time zones for
space or UI reasons (Chile/EasterIsland, Antarctica/*, and so on).

It's not a huge deal I suppose (these things don't change too often, and
being off by an hour for a week or so isn't the worst possible case).
Maybe it's worth noting in the text that the databases should be kept in
sync somehow?

--
Shane

---

From: Ted Lemon <[email-masked]>
Date: Tue, 28 Mar 2006 15:01:47 -0700

> administators will have to figure something out anyway.)

It is absolutely wrong, yes.   The way clients request options is in the 
parameter request list.   The way servers decide what options to send is to 
look at the parameter request list.   If you place any additional 
requirements on the server here, you are needlessly requiring special-case 
code in a situation where no special-case code is needed.

In case 1, if you reply with TZ, it's going to work.   If you reply with TZ 
and POSIX, what do you think is going to happen?   If you reply only with 
POSIX, what do you think is going to happen?

I'll tell you what I think is going to happen - I think it's going to get 
ignored.   My implementation will either ignore it, or possibly use it as way 
to *guess* the timezone by looking up timezones in the TZ database that have 
the same offset as that specified in the POSIX timezone information.   My 
client definitely isn't going to do anything more than that with the POSIX 
information, because it's incomplete, and there's no way in Linux or NetBSD 
(which are the two cases I particularly care about) to configure the timezone 
using something other than the TZ database.   Since POSIX doesn't specify the 
TZ value unambiguously, it's not very useful, other than for sorting the list 
of timezones to ask about in a pulldown menu somewhere.

In case 2, it's going to work fine, because you're giving the client what it 
asked for and, therefore, what it expects.

In case 3, I suspect you get the same result as in case 1 - if you send the 
POSIX timezone, it will be ignored, because there is no API in Windows for 
setting the timezone that way, and furthermore the POSIX timezone information 
doesn't specify the timezone unambiguously.

In case 4, there's no point in sending the option - if the client didn't ask 
for it, it's not going to do anything with it when it gets it.

Again, please let me call your attention back to the fact that we can't assume 
that we have lots of payload space to burn.   I don't know of a single 
example of a time when sending the POSIX option when it hasn't been requested 
is going to work.   So you are essentially just decreasing the available 
space in the DHCP packet by 40 bytes for no purpose at all.

---

From: "David W. Hankins" <[email-masked]>
Date: Tue, 28 Mar 2006 16:51:43 -0800

> option Y" I guess I'm okay with still splitting.

I'm for keeping it in suboptions.

Timezone information is cognitively a single 'thing'.  We're not
asking for three different things, it's just that there might be
three different formats.

The space argument is persuasive - out of 340 bytes for option space,
not counting file and sname overloads, 37 bytes is almost 11%.

My feeling is that it would be better if there were a single unified
format that everyone could use and be happy with.  Just as with all
the other 'multiple formats in suboptions' devices we have on the
table.

And if anyone has any thoughts on how that might be accomplished,
I encourage them to tell us all.  Ostensibly the POSIX format has
all the information you should ever need (right?), but if we agree
that we must produce multiple formats, then we've all already
accepted that asking implementors to convert from this format to
the other two is too much of a burden.

That 37 bytes is worth something already.

Or else we need to talk about that then instead of this.

Countering the space problem, and I realize there is no deployed
software to do this now, I'm going to suggest encoding in the
draft a 'client compatible formats' option list.  A sort of
sub-option-space parameter-request-list.  In this case it's
probably most optimal for the server to respond with the first
option on the list that it's configured to provide a response with,
and ignore the rest of the list.

Because to me, splitting this into separate options, and then
forcing a client to ask for let us imagine 3 options (including
the old offset option) because it doesn't know which ones the server
is configured to use, is as much of a waste of space as asking
the server to concatenate all three options into all responses to
clients, 2 of which a given client will never use.  There's really
only a 2 byte difference.

As Ted says, we really shouldn't create new server behaviour vis
a vis the parameter-request-list and create complicated matrices of
dependencies.  But per-each-suboption, we can absolutely define an
option-local style of parameter request list, which doesn't even need
to be supported today for adoption of this option, but later, with
code deployment, can serve to optimize how much space we use in
replies.

As for mandatory configuration...the server should reply with
whatever it has been configured to reply with.  Someone has to
think about the contents of these fields.  It should be mandatory
that there be a way to configure the contents of each suboption,
if you support configuring one you support them all, but no further
than that.

If someone automatically fills in one of the options contents, then
they still have to supply a means to configure a value for the other
two.

That would be as far as we should specify.

-- 
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: Tue, 28 Mar 2006 19:01:27 -0700

> asking for three different things, it's just that there might be

Protocols are spoken by computers, not humans.   There is no cognition 
involved.   This argument would make sense if we were designing a UI, but it 
has no place in a discussion about network protocols.

> the other 'multiple formats in suboptions' devices we have on the

There isn't.   This is why Eliot so kindly provided us with three 
alternatives.

> all the information you should ever need (right?),

Sorry, that's wrong.   POSIX only tells you about the present and the near 
future - it does not tell you about the past.   That is the sense in which it 
is obsolete.   It's not useless, but it's not complete, and it's not what a 
modern operating system wants.   On your linux box, type 
"ls /usr/share/zoneinfo" to see just how different POSIX timezone information 
is from what Linux and NetBSD use today.

> and ignore the rest of the list.

You contradict this later on when you say that we shouldn't require new server 
behavior.   In fact, this does require new server behavior.   Complicated new 
server behavior.

> only a 2 byte difference.

No, the client is never going to do that.   The client is going to ask for the 
option it supports.   If the server doesn't support that option, the client 
is not going to attempt to change its timezone configuration.   That's the 
reality of the situation.   Any other scenario requires substantial changes 
on BSD, Linux and Windows, changes that significantly reduce the utility of 
the date/time subsystem, all of which particularly make life difficult for 
people who live outside of the United States and Canada, and also for people 
who live in states like Indiana and Arizona.

> code deployment, can serve to optimize how much space we use in

This is new server behavior, requiring new code.

> That would be as far as we should specify.

You haven't made the case for using suboptions.   It's trivially easy to use 
the parameter request list, if we use options.   If we use suboptions, we 
have to change the server.   Using suboptions doesn't buy us anything.   So 
we should use options, not suboptions, and we should use the parameter 
request list to determine which option to send, and we should not send an 
option that wasn't requested, because if the client didn't ask for it, it 
can't use it.   And we should not try to hack together some heuristic by 
which the client can decide which option to use, if the values in the options 
disagree with each other.   There is no reason not to make this dirt simple.

This doesn't preclude someone implementing a client that requests both 
options.   It doesn't preclude a client doing some really clever heuristics.   
But as long as we don't specify those heuristics in the draft, we can't be 
blamed when they fall flat on their face, as they likely will.   And we don't 
force people who do not want to implement those heuristics to do so.

---

From: Eliot Lear <[email-masked]>
Date: Wed, 29 Mar 2006 06:39:48 +0200

Ted,

It is possible for any POSIX compliant system to make use of the 1003.1
string.  It requires, however, something along the lines of the following:

In /etc/profile:

if [ -f /etc/dhcp.tz ]
  . /etc/dhcp.tz
fi

It would *probably* require that running apps restart, and if they care
they would need to (carefully) import the environment variable prior to
tzset().  It's ugly.  Real ugly.

There are a few reasons why POSIX is in there, however.  First, it's the
ONLY standard that succinctly provides a complete definition and not
just an index.  This can be useful for special purpose devices such as
set tops or even smaller (802.11 watches, anyone?).

All this having been said, would you rather there were no mandatory?  In
which case I would go with separate options.

Eliot

---

From: Ted Lemon <[email-masked]>
Date: Tue, 28 Mar 2006 22:49:32 -0700

> which case I would go with separate options.

I don't mind making POSIX mandatory to implement in the server, because it's 
useful to have at least one thing that can be counted on.   And the case 
where it's most important is the one you've described - the case where you 
have some kind of embedded device like a set-top box that needs to get this 
information, and doesn't care about history, and isn't expected to update 
itself frequently with new timezone information. 

However, I think making it mandatory to implement on the client is pointless, 
for reasons that I think I've gone into in enough depth at this point.   The 
point of a DHCP option is not to place requirements on the client operating 
system - it's to fulfill the needs of the client operating system.   I think 
the only case where the POSIX option is going to be useful--and it's an 
important case--is the embedded case.

You've already got my vote for options instead of suboptions... :')

---

From: Eliot Lear <[email-masked]>
Date: Wed, 29 Mar 2006 08:23:11 +0200

Ted,
> important case--is the embedded case.
The intent was to not mandate anything on the client, other than perhaps
to ignore stuff it doesn't understand.
> You've already got my vote for options instead of suboptions... :')
The earlier question I had was whether it was reasonable to mandate a
particular option of others are implemented.  So, can we mandate POSIX
if either the TZ Database or Microsoft options are implemented?  Is that
reasonable?  Perhaps this is why David views these as cognitively the
same thing.  Also, I've still not received comment from anyone at
Microsoft.  If we split these into different options, should we
implement the Microsoft option without such comment?

Eliot

---

From: Ted Lemon <[email-masked]>
Date: Wed, 29 Mar 2006 00:49:51 -0700

> implement the Microsoft option without such comment?

If you think the Microsoft option will work, I'm in favor of specifying it.   
If you're not sure, it's probably a bad idea.   But it does show some attempt 
at being cross-vendor, and if they did implement it it would be good.   Also, 
I get the impression that they're extremely under the gun right now, so the 
silence on their part quite likely doesn't reflect disinterest so much as it 
reflects a lack of time to spare.

I think that POSIX should be mandatory on servers, because the basic option is 
pretty easy to do, and it's good to have something you can count on for 
embedded devices, and it's pretty easy for an embedded device to use.   The 
presence of the other two options doesn't change that.   I don't think it 
makes any practical difference to server vendors, because I am sure every 
vendor will implement all three.   What it does is to ensure embedded systems 
vendors that it's a reasonable thing for them to implement.   It's also 
something that a server could derive automatically, which isn't necessarily 
the case for the other two.

I think what you need to say is just that servers that implement any of these 
options MUST be configurable to send at least the POSIX option, but not 
require that the server automatically derive the POSIX option.   I think 
it'll be a good bit of value to add to a server to do POSIX automatically, 
because unlike the other two, it is possible for the contents of the POSIX 
option to be out of date.   But mandating that would be going too far.

---

From: Shane Kerr <[email-masked]>
Date: Wed, 29 Mar 2006 12:00:13 +0200

Ted,

> space in the DHCP packet by 40 bytes for no purpose at all.

Okay, so we don't have a lot of packet space. AIUI, the client has no
way to know what options the server supports. So, I would prefer to do:

client: request TZ
server: reply TZ

But if the server does not support TZ, you end up with:

client: request TZ
server: reply nothing

Since I actually care about the time zone information, I will *always*
have to do:

client: request TZ+POSIX
server: reply TZ+POSIX

I think not providing a POSIX "fallback" might actually consume more
option space on average. (I hope this example demonstrates what Hankins
was talking about.)

BTW, I also had a look at the Microsoft API:

http://tinyurl.com/mqojp
http://tinyurl.com/ejyf

A Windows box can easily use the POSIX string - the drawback is that the
name is an abbreviation in POSIX rather than the full name(s). Windows
also has no historical time zone information, as far as I can tell.

- --
Shane

---

From: Eliot Lear <[email-masked]>
Date: Wed, 29 Mar 2006 12:31:38 +0200

> also has no historical time zone information, as far as I can tell.

Somehow I missed this.  Different APIs, I guess.  As long as this
modifies system time beyond that of the current application, I no longer
see a need for additional Microsoft (sub)options.

Eliot

---

From: Ted Lemon <[email-masked]>
Date: Wed, 29 Mar 2006 09:26:55 -0700

> way to know what options the server supports. So, I would prefer to do:

Shane, you say "I" like you're planning to implement this, and you have a 
particular deployment in mind.   It might help if you could explain what that 
target is--where you actually intend to deploy code, when the code will be 
done, and why this is such a likely scenario for that particular deployment.

DHCP servers are highly configurable.   These options are not complicated.   
The only case I can think of where the DHCP server wouldn't give you a 
timezone option that's the one you want is the case where (a) the server 
administrator is ignorant and (b) the server administrator won't respond 
constructively to legitimate requests from users.

While this is not a completely uncommon situation, it is a people problem, not 
a protocol problem, and furthermore it is a self-correcting problem, and not 
a denial-of-service problem.   So I think it's a problem we don't need to 
solve.

---

From: "David W. Hankins" <[email-masked]>
Date: Wed, 29 Mar 2006 11:17:50 -0800

> has no place in a discussion about network protocols.

And yet, that's how we think about DHCP option codes.  If you want one
thing, is it correct for the client that supports all four formats to
ask 4 times?

You want one thing, you should only have to look in one place for it.

In this particular case, that one thing might take three different
forms (or more!).  The real trouble we're all dancing around here
is that once you find a single form of that content that you can
use, the purpose of the others vaporizes.  More than one you can use
is purposeless.

> modern operating system wants.   On your linux box, type 

You're advocating removing the POSIX string entirely then?

I think you need to suggest an alternative fallback format then.  As
an IETF group, I don't think we can progress an option whose contents
are only digestable by two types of client and whose content is magic
that would only be known by two types of server administrator...it's
my belief we need a "generic" third type so that all three groups can
come to a middle ground.

I thought the POSIX string was it.

But if I'm wrong, tell us what you think the generic third type should
be?

Should we scratch the POSIX string and go back to the offset format?

> behavior.

I'm sorry that I haven't been clear enough, as you seem to have
misunderstood my message.  I /am/ advocating new server behaviour, in
regards to this option's format and processign.  In the same way we
advocated new server behaviour for VIVSO, or the domain-search option.

Admittedly, I also think the inclusion of sub-parameter-request-lists
in the DHCPv4 protocol would be beneficial to the continued health and
longevity of the protocol.  In the same way I think the domain-search
and VIVSO option's new and unique formats are.

I am not advocating new server behaviour in regards to old protocol
standard (the dhcp-parameter-request-list option).  You've been a
consistent voice in the past speaking against this, and what I said, or
what I thought I said, is that I agree heartily with that subset of your
output.

We absolutely do not want to enter the game where the server selectively
removes options from the parameter-request-list because similar options
appear earlier on it, in order to make space for other options.

So, what I tried to say is that kind of change is just right-out.

So where does that leave us?  We can't use sub-options without
defining a new behaviour, and we can't use regular options without
doing the bad thing (or accepting protocol space waste).

>  Complicated new 

I have to disagree with you substantively there.

kaboom:~/proj/isc/DHCP:4$ cvs rdiff -r dhankins_request_subopt_experiment_base -r dhankins_request_subopt_experiment DHCP | wc -l
218

I'm sorry, but I don't count a 218 line patch (including context lines)
as complicated.

I guess I'm also not being genuine.  That patch would have to be slightly
longer.  That branch does the dhcp-parameter-request-list in sub-option
space thing.  It doesn't do the thing I just described (more of a
'compatibility list' thing).  To do both behaviours, I'd have to add
about 5-10 lines of code I guess, to different modules.

But in my opinion, speaking as someone who has, as I think I've just
pointed out, caused that functionality to come into existence in at
least one server software package's pre-release sources, it's actually
terribly simple.

It does require new server behaviour to optimize the data returned
by the server, but it does not require new server behaviour to function
(a client should still be prepared to deal with multiple options in
responses) out of the gate.

That's what I think our tenet should be.

It sort of requires this new behaviour for the new option to be deployed
properly, in the same sense that the VIVSO options do, the domain-search
option does, and so forth (but each of these, you'll note, can be
configured and used by at least one vendor's implementation at the time
they became standard without code changes...with some substantial
handwaving as to how difficult that task would be).

So it's also what I think our tenet has been.

But doing that means it kinda depends on your server too, and how long
you can get by without the new fancy behaviour, doing horrible manual
configuration things, the same way it does for those options.

Because, at least in ISC DHCP (3.0.x), I can do this today:

	option space timezone;
	option timezone.posix code 1 = text;
	option timezone.tzfile code 2 = text;
	option timezone.msthing code 3 = integer 32; # hey, was this signed?
	option timezone.request-list code 4 = array of integer 8;

	option timezone code TBD = encapsulate timezone;

	if (substring(option timezone.request-list, 0, 1) = 1) {
		option timezone.posix = "EST5EDT4 ...";
	} else if (substring(option timezone.request-list, 0, 1) = 2) {
		option timezone.tzfile = "US/Pacific";
	} else if (substring(option timezone.request-list, 0, 1) = 3) {
		# We don't know how to configure the msthing...it's an
		# index into some database we can't see.
		if (substring(option timezone.request-list, 1, 1) = 1) {
			option timezone.posix = "EST5EDT4 ...";
		} else if (substring(option timezone.request-list, 1, 1) = 2) {
			option timezone.tzfile = "US/Pacific";
		}
		# There's nothing we can do for this client. :~(
	} else {
		# In the absence of a sub-parameter-request-list, we
		# configure all sub-options we're able to and hope one is
		# useful.  The actual encapsulated option won't be sent on
		# the wire unless it's on the dhcp-parameter-request-list.
		option timezone.posix = "EST5EDT4 ...";
		option timezone.tzfile = "US/Pacific";
		#option timezone.msthing = ...dunno...;
	}

Or something like that.  It may not be perfect, but it's an approximation
of the correct result, and it's pretty complete.  It's also
_substantially_ easier than the kinds of conflagarations you'd have to
go through to support VIVSO in ISC DHCP 3.0.x, although substantially
harder than what you'd go through to support the domain-search option.

At some point, through slow upgrades of software, we hope the right
thing becomes automatic, and we can do this (3.1(?).x) for new options:

	option space timezone;
	option timezone.posix code 1 = text;
	option timezone.tzfile code 2 = text;
	option timezone.msthing code 3 = integer 32; # hey, was this signed?
	option timezone.request-list code 4 = compatible-request-list;

	option timezone code TBD = encapsulate timezone;

	option timezone.posix = "EST5EDT4 ...";
	option timezone.tzfile = "US/Pacific";
	#option timezone.msthing = ...dunno...;

Where you s/timezone/something-new/.

> option it supports.   If the server doesn't support that option, the client 

You presume it will only ask for one, and that there are no cases where
the POSIX string is a reasonable fallback position if the other is not
available.

Do you also presume the server will support this single option the
client desires because it will configure all three all the time?

I submit none of those presumptions are safe.

The problem being described is that we have no way of knowing where in
the matrix of these possibilities the client is going to land.

> can't use it.

If we use the parameter request list, the very thing you complain of will
be true in reverse.  Duplicate information will be transmitted to clients
that support more than one option format.  37 bytes will be wasted to
support a fallback position in the general case.

Suboptions are the only way forward, with a sub-parameter-request-list
to be adopted with future software development, which totally eliminates
this complaint.

Anything else is subjectively preferring one instantiation of option
space exhaustion over another.  "Wasting space because the client
supports both is better than wasting space because the server supports
both."

I might agree with that, but I'd rather not have to.  I'd rather the
real answer was that space wasn't wasted either way.

---

From: "David W. Hankins" <[email-masked]>
Date: Wed, 29 Mar 2006 11:27:54 -0800

Ted should feel free to make any responses he wishes (I don't want
"the last word"), but I'm not going to make any further replies on
this until next week.

I think we should all go back to our day jobs for a few days and
come back to this with a fresh start and cooler heads, but of course
none of you answer to me.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 29 Mar 2006 13:03:45 -0700

> none of you answer to me.

One of the easiest ways to win an argument is to imply that the person with 
whom you are debating has lost his cool.

I agree that we should stop discussing this.   I don't think either of us has 
said anything new recently.   To reiterate very briefly (rather than 
responding point by point to the long message that preceded this), I think 
that you are not talking about real-world clients.   You are talking about an 
abstract client, that you are imagining, that exists in a vaccuum.   This is 
entirely pardonable, since the client that you have to work with was designed 
to be as abstract as possible.

But one of the *huge* failings of the ISC DHCP client is how poorly it 
integrates into the operating environments on which it runs (I feel free to 
say this because it's my fault).   Compare it to the OS X client, the Windows 
client, or even the Solaris client.   It's all very well and good to talk 
about the protocol aspect of this, but you need to address the integration 
aspect as well.   I think your line of reasoning falls down there.