vendor-encapsulated-options and Scope
jhutz at cmu.edu
Thu Dec 11 20:40:04 UTC 2008
--On Thursday, December 11, 2008 12:21:17 PM -0800 "David W. Hankins"
<David_Hankins at isc.org> wrote:
> On Thu, Dec 11, 2008 at 01:22:46PM -0600, Martin McCormick wrote:
>> My thanks to all. I think I understand this better
>> especially after seeing what happened yesterday. Every access
>> point that fit the cryteria got hosed and it now makes perfect
>> sense as to why. It's kind of easy to start thinking everything
>> can be scoped and this was a great reminder that that is not
> It's not your fault, the configuration syntax creates this expectation
> and then fails to deliver on it.
> It adds insult to injury when scoping such parameters causes them to
> inherit the 'group' scoping of their parent; inheriting options from
> contexts that are normally inappropriate.
It seems like an awful lot of pain could be avoided by simply rejecting
configuration that contains host or class declarations inside a subnet or
shared-network (or a host inside a class, or...). I can't think of any
reason to want what results from doing so, and in any case the same effect
can always be had by adding an enclosing group and hoisting all of the
hosts, options, and executable statements into the group.
More information about the dhcp-users