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. Host Reservation requirements for Kea 1.1.0 (Marcin Siodelski)
2. Re: Extending client classification in Kea 1.1 -
requirements/design (Francis Dupont)
3. Re: Extending client classification in Kea 1.1 -
requirements/design (Francis Dupont)
----------------------------------------------------------------------
Message: 1
Date: Wed, 20 Jan 2016 14:54:51 +0100
From: Marcin Siodelski <[email protected]>
To: Kea Dev List <[email protected]>
Subject: [kea-dev] Host Reservation requirements for Kea 1.1.0
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Hi All,
Kea team is planning to extend Host Reservation implementation in Kea
1.1.0 release. As part of this effort I have created requirements
document on wiki:
http://kea.isc.org/wiki/HostReservationRequirements
It includes requirements for both existing and planned features. Please
review and share your comments.
The companion design document is available here:
http://kea.isc.org/wiki/HostReservationDesign
However, the design document is still pending an update according to
listed requirements.
Marcin Siodelski
ISC
------------------------------
Message: 2
Date: Wed, 20 Jan 2016 15:09:42 +0000
From: Francis Dupont <[email protected]>
To: Tomek Mrugalski <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [kea-dev] Extending client classification in Kea 1.1 -
requirements/design
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
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 <[email protected]>
------------------------------
Message: 3
Date: Thu, 21 Jan 2016 09:59:21 +0000
From: Francis Dupont <[email protected]>
To: Francis Dupont <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [kea-dev] Extending client classification in Kea 1.1 -
requirements/design
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
It is not strictly necessary but it will be fine to have a concat function
to concatenate two strings too.
Francis Dupont <[email protected]>
------------------------------
_______________________________________________
kea-dev mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/kea-dev
End of kea-dev Digest, Vol 22, Issue 8
**************************************
