[kea-dev] Extending client classification in Kea 1.1 - requirements/design

[Francis Dupont]

Tomek Mrugalski writes:
> Q1: We do have boolean (and, or, not) operators designed and planned for
> 1.1. Do we also want arithmetic comparison (>, <, >=, <=) operators?

=> IMHO we need boolean (and parentheses) but I am less convinced about
arithmetic.

> Q2: Do we want find(string, what) operator?

=> perhaps but "what" needs to be defined.

> Q3: Do we want len(string) operator?

=> only if we have arithmetic.

> Q4: Do we want option[123].len specifier?

=> useless if we have Q3. BTW the option[123].exists is useful as
an option can be empty.

> Q5: Do we want to have an ability to specify that if packet is matched
> to a class, the packet is immediately dropped?

=> I like the idea but perhaps we need something more general for
dropping packets. Note the "immediately" term suggests more control
on the classification order.

There are some other missing items:
 - a way to specify address binary constants using standard address syntax

 - suboptions

 - access to packet parameters like the remote address

Thanks

Francis Dupont <fdupont at isc.org>