[kea-dev] Client classification design

Tomek Mrugalski tomasz at isc.org
Fri Oct 23 12:42:41 UTC 2015


Points I agree with that were implemented completely were removed for
clarity.

On 16.10.2015 13:39, Thomas Markwalder wrote:
> First, let me commend Tomek for all the effort he has put into this
> and harassment he has endured for it ;).
Thanks. IMHO the amount of harassment is somewhat disproportionate to
the amount of time we have in 1.0 timeframe, but we can continue this
discussion as long as necessary.

> REQUIREMENTS:
> 
> You have two paragraphs which begin with "Client classification can
> be a very complex feature. Due to scheduling constraints...". I don't
> think you need em both ;)
Removed.

> G3. I think this should be expanded similar to what Stephen had in
> the discussion document, where he stated the search path:
> 
> "The search path for an option value is then:
> 
> Subnet class-option-data matching the client class Subnet
> option-data Global class-option-data matching the client class Global
> option-data"
Added a new section about options precedence.

> We also need to state what happens if a client matches more than one 
> class and they both specify the same option.  Even if we say it is 
> arbitrary.
Added clarification for that. Since we'll need to evaluate each class
anyway, we'll likely to go through their list iteratively. That means
that the options will keep the order they were specified in the config.
That also makes intuitive sense. The last one specified "wins".

> G10. Requirements should be stated as positives not negatives.
Why?

> "The system MUST support an arbitrary number of class defintions."
Ok, updated as suggested.

> I think we do want the ability to specify alternate or additional
> class options for a given class on a per subnet basis, which both
> options 1 and 3 provide.
> 
> I tried both #1 and #3  in a test configuration and #1 was a bit
> uglier to read and write than #3, and I think #3 will be less effort
> to implement. Here's what the hybrid might look like:
Good proposal. I used it almost as is.

> I believe the tokens should be stateless. But rather than pass in a
> fixed number of tokens into evaluate(), I believe we should pass in a
> "value" stack.  Each evaluate() implemenation pops off as many values
> from the stack as it requires to calculate its result.  If there are
> not enough on the stack that's an error.
This should be caught at the configuration parsing stage. The tokens are
now stateless, so we actually have 2 stacks. One constant with tokens
and another (variable) stack with token values.

Tomek


More information about the kea-dev mailing list