[dhcwg] parameter-request

Ted recently suggested;

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

For full context,

  http://www1.ietf.org/mail-archive/web/dhcwg/current/msg06118.html

Let us remember the example 18 octect parameter request list known to
be emitted by some versions of SuSe (seen here in hexadecimal, each
octet spearated by a colon):

	1:3:6:c:f:11:17:1c:1d:1f:21:28:29:2a:9:7:c8:2c

It makes the most sense for the new option proposed to replace the
old parameter request list (eventually).  This is because in addition
to parameter request, it also introduces a priority.  We can't put the
new option ahead of the old, nor can we put the old option ahead of
the new...you have to send both, and both have to include all options.

Although hopefully at some point we could stop sending the old
parameter request list, that would be many years in the future.

So directly applying your suggested 'count, choices, count, choices'
method, that literally creates a 36 byte string (18 hunks each of 1
option), and we must also supply the 18 byte parameter-request in the
event the server doesn't support the new option.  So, 58 bytes in total,
plus let us imagine at most 3+4 bytes for the timzeone options (to do
TZ, POSIX, time-offset in both options, but only 'one of those three'
in the new option).

That quickly becomes a lot of bytes.  Slightly more than triple.  That
seems big.

My knee-jerk reaction is to suggest encoding it as:

	ORO LEN		type hunk-len [ hunk-len choices ]  \
			type hunk-len [ hunk-len choices ]  \
			...

You iterate different 'type' values to infer you want all of the
choices, or one of the choices.

But this looks dangerously similar to encapsulated options, and that
may lead people to make...unfortunate mistakes.

At any rate, in so doing, we are now at 18 + (18+2), merely 42 bytes
in total, again modulo our +3/+5 when we involve the timezones.  That's
not that big of an improvement relatively, and it still 'feels' big
(slightly more than double).

But if we, instead of allocating one option code for a new option to
contain parameter request, allocate two option codes (as Ralph says,
now that we have plenty) and use them to "mark up" the existing
parameter request option, then we can reduce this to a nominal
increase (a small percentage).

So, assuming you replaced the text "all-of" and "one-of" with the
actual option codes assigned, our strawman single, standard
parameter-request list option now looks like:

  1:3:6:c:f:11:17:1c:1d:1f:21:one-of:tz:posix:2:all-of:28:29:2a:9:7:c8:2c

Essentially, the start of the list defaults as an 'all of' section,
and may continue that way up until the end of the option.  If either
the 'one-of' or 'all-of' options are present, then you start a new
section (under the rules specific to one of those two) until you reach
the next 'one-of' or 'all-of' options (or the end of the list).

We would never actually use those options to encode option contents
in DHCP packets (but if someone accidentally did, it would be harmless).
If the DHCP server doesn't support the markup, then it just skips over
them (or at worst case, supplies a value for that option if for some
inexplicable reason it thinks it needs to supply one).

In this case our 18 byte parameter request list remains...18.  With a
+5 when we consider the timezone options.

That's a pretty small increase in the size used for parameter request.

Is there interest in the WG for a document describing something like
this?

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