Send kea-dev mailing list submissions to
[email protected]
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
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of kea-dev digest..."
Today's Topics:
1. Re: kea-dev Digest, Vol 22, Issue 7 (Ray Hunter (v6ops))
2. Re: kea-dev Digest, Vol 22, Issue 7 (Tomek Mrugalski)
----------------------------------------------------------------------
Message: 1
Date: Thu, 28 Jan 2016 13:22:33 +0100
From: "Ray Hunter (v6ops)" <[email protected]>
To: [email protected]
Subject: Re: [kea-dev] kea-dev Digest, Vol 22, Issue 7
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
> [email protected] <mailto:[email protected]>
> 20 Jan 2016 13:00
> Send kea-dev mailing list submissions to
> [email protected]
>
> 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
> [email protected]
>
> You can reach the person managing the list at
> [email protected]
>
> 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 <[email protected]>
> To: "[email protected]" <[email protected]>
> Subject: [kea-dev] Extending client classification in Kea 1.1 -
> requirements/design
> Message-ID: <[email protected]>
> 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
> [email protected]
> 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-0001.html>
------------------------------
Message: 2
Date: Thu, 28 Jan 2016 16:12:00 +0100
From: Tomek Mrugalski <[email protected]>
To: [email protected]
Subject: Re: [kea-dev] kea-dev Digest, Vol 22, Issue 7
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
On 28.01.2016 13:22, Ray Hunter (v6ops) wrote:
>> 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).
Ack. That's a fair point. We talked about this internally and we think
that while is may have some of the drawbacks of the old implementation,
we are confident that we'll be able to avoid most of them.
One of the major annoyances of the old code is that there's a lot of
interconnected pieces of code that is hard to debug, test and rewrite if
necessary. Our new implementation is written in C++ with each token
(representing an option, a field, an operator etc) is separated into its
own class. Each class has its own unit-tests that checks its proper
operation. Those tests are run on a daily basis on many (around 20)
different systems. This gives us a high confidence that, while there may
be bugs, it should be working well in most cases.
As with most other features in Kea, this one is also well documented.
If the whole Kea team joins first SpaceX expedition to Mars tomorrow,
whoever takes over would have reasonable chance to understand the code
and continue its development.
The configuration language of the old ISC DHCP has many issues, but many
people like it a lot and depend on it heavily. Kea does different things
differently and people seem to be willing to try something new, but in
some cases the barrier of learning a bit of C++ is a problem. It will
get easier when the number of examples available will get bigger.
> 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.
This is the long term plan. We will get there eventually, but this road
has its own problems. The major problem here is testing. With the number
of example libraries we provide, the number of test cases grows
exponentially (for N libraries you have at least 2^N combinations, or
even more if you want to load them in different order). And that's just
assuming that each hook library doesn't have any configuration knobs.
There's another aspect here. Kea is a new software than still needs to
earn its reputation. Saying that upcoming Kea 1.1 will have improved
client classification and reservations storage in PostgreSQL and MySQL
sounds better than "hey, we've added a bunch of extra hook examples".
At least we think it does. :)
I'm secretly hoping that in the not so distant future there will be
people who will be writing their own hooks and would be willing to share
their code. But I get your point - we, the Kea developers, have to help
to bootstrap the process. I'll see what I can do about that.
Thanks a lot for sharing your thoughts on this one.
Tomek
------------------------------
_______________________________________________
kea-dev mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/kea-dev
End of kea-dev Digest, Vol 22, Issue 11
***************************************
