[kea-dev] kea-dev Digest, Vol 22, Issue 7
Ray Hunter (v6ops)
v6ops at globis.net
Thu Jan 28 12:22:33 UTC 2016
> 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
> 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 -
> 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  and design  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  document as it provides more background
> 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.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).
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.
> kea-dev mailing list
> kea-dev at lists.isc.org
> End of kea-dev Digest, Vol 22, Issue 7
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the kea-dev