[kea-dev] Decline support requirements in Kea 1.0

[Thomas Markwalder]

On 6/25/15 10:35 AM, Tomek Mrugalski wrote:
> All,
>
> Here's another requirements documents written as a preparation for Kea
> 1.0. This one covers DECLINE messages support:
>
> http://kea.isc.org/wiki/DeclineRequirements
>
> There is one topic that's not covered by the requirements yet: how to
> handle declined addresses in the host reservation context. One
> reasonable approach is to maintain consistency with what is already
> coded. Right now when the server discovers that the reserved address is
> used by someone else (there's a lease for someone else), it treats the
> reservation as unusable, prints a warning and continues as if there were
> no reservation. I'd like to handle the decline case in similar way.
> I'm not sure if that requires to be codified in the requirements page,
> though.
>
> Similar to lease expiration discussion, we want to close this discussion
> by end of July.
>
> Comments? Thoughts? Tomatoes?
>
> Tomek
>
> _______________________________________________
> kea-dev mailing list
> kea-dev at lists.isc.org
> https://lists.isc.org/mailman/listinfo/kea-dev
G3 - Stating that a declined address must be removed from the managed
pool is a
design/implementation detail.  You might reword this a "A declined
address MUST not
be assigned to a client"

C1 - I do not think this requirement is necessary.  G1 and G2 already
require it be
supported.  I'm not sure you gain anything by having this.

C3 - Remove the parenthetical suggestion of how-to.  This belongs in a
design document.


H1 and H2 - The word "new" is unnecessary.


S1 - Change "being declined" to "currently in the declined state"


S2 - Clarify that this value resets upon server restart.  Otherwise it
implies we must
keep track across restarts forever.


S3 - As with S1, "being declined" to "currently in the declined state"