[kea-dev] Client classification - discussion summary (?)

Marcin Siodelski marcin at isc.org
Tue Oct 27 12:33:07 UTC 2015



On 23.10.2015 14:46, Tomek Mrugalski wrote:
> Hopefully this summarizes the discussion about the client classification
> design. I responded to hopefully all comments.
> Here's a brief summary of those changes:
> 
> - clarified option order (global, subnet, global class, subnet class,
> host). The last one will not make it into 1.0. The one before it (subnet
> class) may or may not make it into 1.0.
> 
> - explained what to do when client belongs to multiple classes and each
> has the same option defined (only one will be sent, which class wins
> will be determined by the implementation, but it will most likely be the
> class that defined later in the config file.
> 
> - class configuration syntax agreed on (accepted Tom's proposal as is)
> 
> - evaluation process clarified. The Token stack is now stateless.
> 
> - renumbered the requirements, so the assigned numbers are continuous
> 
> - make it clear that the parser will be flex/bison based
> 
> - many smaller clarifications and corrections
> 
> If you really think that the design is not good enough and we have more
> time to dedicate to further refinement, feel free to continue the
> discussion. If not, let's move on to the ticket estimates.
> 
> Tomek
> 

I tried to make my pick on the estimates and had some comments for the
task list

#10, #11 - Implement class information storage including configuration
parsers
This should be split into the "storage" and "parsers" tickets, rather
than combine both in a single ticket. They are really independent tasks
and can be carried in parallel. I'd also think that class information
storage/parsers tickets don't need to be v4 and v6 specific.

#12, #13 - Per subnet information - if this is something that we're not
going to support in 1.0 it should rather be of a low priority.

#14, #15
How is that different than #10 and #11? If this is just hooking the
parser to the server code it is a trivial change. Perhaps, there is no
need to split it between v4 and v6 server too.

Marcin




More information about the kea-dev mailing list