[kea-dev] kea-dev Digest, Vol 22, Issue 7

[Ray Hunter (v6ops)]

> kea-dev-request at lists.isc.org <mailto:kea-dev-request at lists.isc.org>
> 20 Jan 2016 13:00
> Send kea-dev mailing list submissions to
> kea-dev at lists.isc.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.isc.org/mailman/listinfo/kea-dev
> or, via email, send a message with subject or body 'help' to
> kea-dev-request at lists.isc.org
>
> You can reach the person managing the list at
> kea-dev-owner at lists.isc.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of kea-dev digest..."
>
>
> Today's Topics:
>
> 1. Extending client classification in Kea 1.1 -
> requirements/design (Tomek Mrugalski)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 19 Jan 2016 20:36:15 +0100
> From: Tomek Mrugalski <tomasz at isc.org>
> To: "kea-dev at lists.isc.org" <kea-dev at lists.isc.org>
> Subject: [kea-dev] Extending client classification in Kea 1.1 -
> requirements/design
> Message-ID: <569E902F.80803 at isc.org>
> Content-Type: text/plain; charset=utf-8
>
> Hello everyone,
>
> We have implemented a somewhat basic client classification in Kea 1.0.
> It is working for some scenarios, but currently lacks fancier features.
> We do have a plan to extend it in Kea 1.1. I have updated the
> requirements [1] and design [2] documents. It would be great if you
> could read and comment on them.
>
> The existing stuff from Kea 1.0 is referred to as phase 1. Plans for Kea
> 1.1 are referred to as phase 2. Phase 3 are things that we'd like to get
> one day, but decided not to do them in the Kea 1.1 timeframe.
>
> In particular, there are couple ideas in the Open Questions section that
> require comments from developers and users. I list the questions here,
> but please do read the [1] document as it provides more background 
> reasons:
>
> Q1: We do have boolean (and, or, not) operators designed and planned for
> 1.1. Do we also want arithmetic comparison (>, <, >=, <=) operators?
>
> Q2: Do we want find(string, what) operator?
>
> Q3: Do we want len(string) operator?
>
> Q4: Do we want option[123].len specifier?
>
> Q5: Do we want to have an ability to specify that if packet is matched
> to a class, the packet is immediately dropped?
>
> The links are:
> 1. http://kea.isc.org/wiki/ClientClassificationRequirements
> 2. http://kea.isc.org/wiki/ClientClassificationDesign
>
> We would like to get going with the implementation, so please send your
> comments no later than 2016-01-26 (the next Wednesday).
>
> Thanks,
> Tomek

I missed the feedback deadline but FWIW I think creating too complex a 
classification syntax risks leading you into the maintenance rathole 
that you were trying to avoid when writing KEA: you are in danger of 
recreating a high level language (in the configuration).

I humbly suggest that your time might be more productively spent on 
providing a set of (tested) libraries and example hooks that would allow 
others to quickly develop specific hooks directly in c++ that can be 
loaded into the DHCP server. Packet and options parsing, packet and 
options construction for outbound packets, config parsing, and database 
lookups to file/mysql etc., are all reasonably painful operations and 
could benefit for a standard and well-documented API.

regards,
>
>
> ------------------------------
>
> _______________________________________________
> kea-dev mailing list
> kea-dev at lists.isc.org
> https://lists.isc.org/mailman/listinfo/kea-dev
>
> End of kea-dev Digest, Vol 22, Issue 7
> **************************************

-- 
regards,
RayH
<https://www.postbox-inc.com/?utm_source=email&utm_medium=siglink&utm_campaign=reach>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/kea-dev/attachments/20160128/788637ff/attachment.html>