[bind10-dev] Option definition in BIND 10 DHCP

[Jelte Jansen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 12/23/2011 03:33 PM, Stephen Morris wrote:
> On 20/12/2011 17:39, Stephen Morris wrote:
>> All
>>
>> One of the things we are looking at for BIND 10 DHCP is replicating
>> the ability of DHCPv4 to have user-defined options.  The first drafts
>> of requirements and design documents have been published (covering
>> IPv4 only) and I would appreciate feedback - if nothing else, on the
>> suggested use of the BIND 10 configuration database to define the options.
>>
>> The documents can be found at:
>>
>> http://bind10.isc.org/wiki/DhcpOptionDefinitionRequirements
>> http://bind10.isc.org/wiki/DhcpOptionDefinition
> 
> The Option Definition document has now been updated to include IPv6
> options.  Feedback is requested.
> 

I have not looked into it too deeply (and must confess I don't know much
about the advanced features of current dhcp implementations), but one
thing that immediately came to mind is that this proposal uses a a
number of lists which all have a name (e.g. vendor, options). The
example taken from existing stuff is Xfrin/zones, which is also a list.

That may not be the best of examples, we have a better structure for
those now, the named set; Boss/components is one of the examples. (IMO
we should move config settings identified by their zone name to that as
well).

Assuming that vendor and option names are unique (don't know if that is
true for both), if you use a named_set, you can directly access them
without 'weird' indexes;
config add DhcpX/vendor ISC
config set DhcpX/vendor/ISC/enterprise_number 42

There are some known issues with named sets (in the above example, you
can't use config add DhcpX/vendor/ISC for instance, and there is a bug
where a failed update can result in the entire set being cleared). Then
again, there is one for lists too (tab completion currently breaks at
the list index) :p

But IMHO if the name is unique, it looks and interacts much better with
named sets than with lists.

And on a more general note, because of the user-definedness of this, it
looks like we are essentially redefining the specfile config definition
within a specfile config value. I wonder if we can do something smart
with that.

Jelte
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk70lTIACgkQ4nZCKsdOncVOAACgpcpTY1A1KVeMzJ4GBwTvuU/X
pDUAoKK3jnLf/tWe5o8rdYWJPO0iyBxz
=WqEk
-----END PGP SIGNATURE-----