vendor-encapsulated-options and Scope

[David W. Hankins]

On Thu, Dec 11, 2008 at 03:40:04PM -0500, Jeffrey Hutzelman wrote:
> 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...).

We do warn if a host is present inside lower groups.  We should
probably have done so for other constructs.

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

Actually, there are some folks that use host structures enclosed
inside subnets or (more usually) shared networks to inherit the
options specific to that subnet, even when they're on another
network (ex: 'engineering' network gives 'engineering' blah-servers,
the host tie-in gives the same answer even if an 'engineering' machine
roams over to the 'sales' network).

Subnet in particular is a pretty strange place for host or classes
because of 'option routers'.

-- 
Ash bugud-gul durbatuluk agh burzum-ishi krimpatul.
Why settle for the lesser evil?	 https://secure.isc.org/store/t-shirt/
-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		     you'll just have to do it again."
Internet Systems Consortium, Inc.		-- Jack T. Hankins
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20081211/cfb9b344/attachment-0001.bin>