vendor-encapsulated-options and Scope

[Jeffrey Hutzelman]

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

-- Jeff