Thoughts on DHCP Option Definition

[Marcin Siodelski]

On 09/28/2012 01:45 PM, Stephen Morris wrote:
> 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.

For some standard options server will set the contents in flight
(depending on what client sends). This means that option contents is set
in the code while format is defined elsewhere. I would like to have
contents and format of the option coming from the same place.

I am also not clear if I understand the difference between "altering"
the option and "overriding" the option. I presume that by "altering" you
mean that standard option definition may be changed in the .spec file
(in the standard options space) and by "overriding" you mean creating
new option in the user option space that has the same code and name as
the standard option?

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

Shawn pointed out that in some cases users may want to override the
standard options definitions in case they are incomplete (or have bugs),
e.g. extend standard option with the list of suboptions. Possibly some
warning message could be issued if user overrides them.

Another interesting case was pointed by Tomek. If new RFC is issued that
defines "standard option" users may want to start using this option
immediatelly but it is not supported as "standard" option in our server.
If later on we start to support this option the option user definition
of this option conflicts with the same option that is now defined in
standard options area. What do you think, is it the issue?

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

Agree.

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

And this interpreter should be responsible for validating the data
against the format specified. If validation fails, the information
should be somehow conveyed to the user.

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

Ok. But if I override the option through the config manager shouldn't I
set the value for this option too? In my previous email I claimed that
once option has been defined (or redefined) by the user "he must set
value for it". Tomek opposed to this saying that "Debian package
maintainer wants to set the format for the option that has been just
defined in new RFC but it does not mean that everybody now wants to use
this option".
For this reason I think that it is fine that user does not specify the
option data at once but if the server is supposed to send it to the
client than setting its data through the config manager is obligatory.

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

There are at least two cases that I gave above when it makes sense.


Marcin