[kea-dev] Call for comments about Lease Expiration requirements in Kea

[Thomas Markwalder]

On 6/24/15 8:27 AM, Marcin Siodelski wrote:
> All,
>
> As a part of the preparation for the Kea 1.0, I would like to ask the
> list participants to review and comment on a document presenting the
> requirements for the "Lease Expiration", which is available here:
>
> http://kea.isc.org/wiki/LeaseExpirationRequirements
>
> Note that this is an early version of the document. The goal of the
> early call for the review is to collect, discuss and incorporate all
> additional requirements before the design phase starts for real. This is
> to avoid unnecessary delays in designing the feature and making "last
> minute" changes affecting our productivity and then implementation process.
>
> Just for the record... we're planning to close the requirements and the
> design phase for "Lease Expiration" by the end of July, when we're
> planning to start the implementation work.
>
> Thanks,
>
> Marcin Siodelski
> DHCP Software Engineer, ISC
>
> _______________________________________________
> kea-dev mailing list
> kea-dev at lists.isc.org
> https://lists.isc.org/mailman/listinfo/kea-dev

I would suggest defining the term "lease reclamation" as "the process of
restoring an expired lease to a state where it is free to be assigned to
a client" and adding that to the Introduction.  Many documents have a brief
terms/definitions section to ease discussion. 

--------

G2 - The phrase "for which DNS record exists" implies that the system
knows this.
I think it might be better to say "if DNS updates are enabled".   If we
want to then
optimize the implementation to look at the expired lease FQDN info and
decide
what to do, it becomes a design decision.

--------

G3 -  Is a little confusing.  Can a lease an expired lease be left in the
database when expiration is configured?  Secondly, the requirement should
be that the lease is again available to be assigned.  That it be removed
from the database is really an implementation detail.

You could restate G1-3 something like this:

G1. When an expired lease is reclaimed the system shall: 
G1.1 MUST Execute any registered lease-expiration hooks
G1.2 MUST notify DNS of the expiration if DNS updates are enabled
G1.3 MUST render the lease free for assignment

--------

G4 -  I would suggest rewording this:

"The system MUST perform lease reclamation upon an expired lease before
reusing it."

But is this necessarily true?  If the lease is going to the same client
do we necessarily need or/want to execute the hook(s)?  Do we need to remove
it from the database rather than just update it? 

(An interesting question becomes if you're doing B, is the lease truly
free if DNS info hasn't updated yet?)

----------

G5 - Could use rewording.  As it is currently written it is untestable.
Is it attempting to describe what happens at startup or is it a general
statement
that says the system will process all leases which expire?  I think you
may be trying
to say more than thing here.

How can we expire all leases that were removed from the database? 
They're gone,
we cannot know they existed.

The e.g. of "during the server startup" implies several things.  First,
what server are
you talking about, Dhcpv4, Dhcpv6, or an Expiration Server?  Isn't that
a design issue?
If not that it should be stated as part of the Introduction.

If one assumes you mean the Dchp servers, it implies that the server
will first deal
with all expirations before it does other things.  This might mean a
substantial lag
before the server begins granting leases.

---------

P1 - should be a general requirement if we keep it.  I'm assuming this
one is based
on the notion that newer expirations might be reused by their former
owners?  Otherwise
I'm not certain we really care about the order.

---------

P2, P3, I1, and I2 are all design goals or decisions and not testable
requirements.

P2 - At what point is the impact minimal enough?
P3 - How many calls are too many?  
I1 - How do I write a test that verifies backend agnosticism?
I2 - At what point can you say that an implementation has reached the
maximum amount
of common code?

----------

The section on Concurrency is entirely design.  It is valuable
information but
belongs in a design discussion/document.