Thoughts on DHCP Option Definition

[Stephen Morris]

After discussing the option definition issue with Marcin today, I
thought that I'd put down my thoughts on how it would work:

All option definitions - both pre-defined ones and user/vendor-defined
ones - would be in the configuration database.  The pre-defined
options definition area would be populated from a .spec file, the
other two areas would be empty.  Although pre-defined options could be
defined in the code, it seems to me that defining everything in the
.spec file would mean just one code path for all options.  It would
also make it easier to add new pre-defined options - just update the
.spec file.

However, the pre-defined option definitions should not be able to be
altered by the user: I don't know whether this is possible with the
current configuration system, I suspect not.

When reading the options, user option definitions would override
vendor-option definitions, which would in turn override pre-defined
option definitions (any overriding being marked by a warning message
written to the log file).  At the end of the configuration process,
the option definitions would be stored in some form of option
interpreter object.

The option definitions are the first part of the configuration to be
processed.  During the rest of the configuration processing, when the
setting of an option is encountered, the option name and its value is
passed to the interpreter: the return value is a vector of bytes
representing the wire format of the option.

I suppose the main question are:

* Having the user being alter pre-defined option definitions -
possibly unsuspectingly - may prove awkward.  If, for example, they
change the definition of an option that holds a four-byte integer
value to one that holds a two-byte value, then unless the code
registered an overflow when setting it, the problem would not be
discovered until the data were received at the client.

* Do we want to allow user and vendor-defined options to override
pre-defined ones?


Stephen