[kea-dev] Design for Kea Host Reservation

Thomas Markwalder tmark at isc.org
Fri Oct 3 10:47:04 UTC 2014

On 9/30/14, 7:20 AM, Marcin Siodelski wrote:
> All,
> I have created a new design document on Kea wiki:
> http://kea.isc.org/wiki/HostReservationDesign for Host Reservation. It
> summarizes the discussions that we conducted on a mailing list and
> during the Kea hackathon.
> The document introduces detailed layout of the database for host
> reservations. It also presents relations between the old and new C++
> classes and some other details.
> At present, the document doesn't cover the design of a management tool
> for updating and adding new host reservations to the database. I think
> this tool is out of scope for now.
> The Trac ticket for creating a HR design is #3559. This ticket is now in
> the review queue and the regular review should be conducted by one of
> ISC engineers. I also encourage mail list subscribers to have a look and
> comment.
> Marcin
> _______________________________________________
> kea-dev mailing list
> kea-dev at lists.isc.org
> https://lists.isc.org/mailman/listinfo/kea-dev

I'm sending this out to the email list to share our jabber-chat
yesterday.   I applaud your effort, as a stand-alone component your
document is coherent and the design is complete enough to implement. 
Your design describes host reservation "persistence" but not how this
will be put to use within Kea.   Without reviewing it within the larger
context of a how it will integrate into Kea, reaching a full opinion on
its viability is impossible.

I believe what is needed is a high level design as a prerequisite to
your design so one can see how host reservation use cases will flow
through Kea.    It should cover configuration use cases as well as DHCP
client use cases.     

It is my impression that there was a lot of discussion and perhaps
emails regarding the overall design, and if so codifying should not be
too grate an effort, however  email chains do-not-a-design make ;) 
Without an overall design document I think there is too great a risk for
stumbling into unaccounted for situations or needs.


PS (I dig the pictures!)

More information about the kea-dev mailing list