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: Design for Kea Host Reservation (Thomas Markwalder)
----------------------------------------------------------------------
Message: 1
Date: Fri, 03 Oct 2014 06:47:04 -0400
From: Thomas Markwalder <[email protected]>
To: [email protected]
Subject: Re: [kea-dev] Design for Kea Host Reservation
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
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
> [email protected]
> https://lists.isc.org/mailman/listinfo/kea-dev
Marcin:
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.
Thomas
PS (I dig the pictures!)
------------------------------
_______________________________________________
kea-dev mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/kea-dev
End of kea-dev Digest, Vol 7, Issue 3
*************************************
