host statement scope rules (ISC DHCP 3.0.5b1)

[Simon Hobson]

David W. Hankins wrote:

>The subnet {} clause is implicitly also a group {} clause.  So all
>host statements within the subnet {} clause share a group that is
>anchored at the subnet's curly braces.  The same is true of the
>shared-network {} clause, it is also implicitly a group {}.
>
>
>What's left for this thread is to decide consensus about how best
>to illustrate these two pieces of information to novice users.
>
>Currently, 3.1.0 as it exists on our release branch will produce
>a single-line warning (no matter how many host records you have)
>with the following text:
>
>		log_error("WARNING: Host declarations are "
>			  "global.  They are not limited to "
>			  "the scope you declared them in.");
>
>There aren't enough cycles between now and 3.1.0's release to
>add an option to remove this warning, as has been requested.
>
>Our options for 3.1.0's schedule are to go ahead as it is, to
>reword it, or to remove this 'feature' entirely.
>
>Please provide some feedback on what you'd like to see in 3.1.0.

Is there any real reason to need the inheritance of putting a host 
declaration within a subnet ? I guess it comes down to, will the host 
inherit anything that it wouldn't have inherited anyway by virtue of 
being 'put there' as the server allocates it to a subnet for lease 
allocation purposes ?

I believe the answer is no to both of these (unless someone knows 
differently), and if that is the case then I suggest keeping the 
warning as-is. Perhaps it might be worth a couple of lines in the man 
page along the lines of :

"Whilst host statements may be placed within a subnet or 
shared-network declaration, this was not an intentional capability 
and its use is deprecated."


Also, if the host inherits something from one subnet (by the host 
declaration being within it), and a different value for the same 
option when the server puts a client in a different subnet, which 
takes precedence ? It strikes me that having a host that can be given 
options relevant for a different subnet is a tad dangerous - I wonder 
if it's been responsible for some of the "the client got the wrong 
value" queries on the list ?

Simon