Thoughts on DHCP Option Definition

[Stephen Morris]

On 28/09/12 20:12, Shawn Routhier wrote:
> One general item I'm not sure is getting addressed - how will
> these definitions and the code handle encapsulated options?  I see
> lots of discussion about an option name and an option value and
> things seem to be moving along well there, but I don't see how it
> will generalize to sub option spaces (but maybe I just missed
> something?)

Hopefully that is being worked upon...



> In general I'm having difficulty understanding why we want to
> restrict what the user can do to "pre-defined" options.  In the
> current code we use different formats to describe pre-defined
> options and user-defined options. (Though in the end they all get
> squashed into the same format for processing.) In this case it
> makes sense to me to separate the two sets of options.
> 
> :
> 
> In our current code we (sort of anyway) require users to reproduce
> a bug with an unmodified copy of the source before we try to fix
> the problem.  I could imagine the same general style in this case -
> if the user or vendor have modified the options they need to either
> demonstrate the bug without the changes or demonstrate that the
> changes won't affect the bug.

In BIND 10, option definitions are set not in the source but in a
user-editable configuration file.

In the original suggestion (where "pre-defined" options were defined
in the configuration database), having a separate area for user
definitions allowed the user to delete the area with a single command
without affecting the "pre-defined" area.

However, if the "pre-defined" options are defined in the source code,
the need for separate areas disappears.

Stephen