[kea-dev] Decline support requirements in Kea 1.0
Tomek Mrugalski
tomasz at isc.org
Mon Jul 13 13:23:19 UTC 2015
Ok, I finally got round back to the decline stuff. See my comments below.
On 25.06.2015 18:37, Thomas Markwalder wrote:
> 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"
Reworded as suggested.
>
> 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.
It is necessary. Let me give you an example. We do support rapid commit.
It is not enabled by default, however (and that's fine for rapid
commit). Decline should be supported out of the box, without any knobs
necessary.
> C3 - Remove the parenthetical suggestion of how-to. This belongs in a
> design document.
Removed.
> H1 and H2 - The word "new" is unnecessary.
Removed.
> S1 - Change "being declined" to "currently in the declined state"
Changed.
> S2 - Clarify that this value resets upon server restart. Otherwise it
> implies we must keep track across restarts forever.
Added a general note that statistics are considered runtime property and
as such, they're reset after server restart. On a related note, I'm sure
there will be people who'd like to keep their stats after restart. Until
they voice their needs, let's ignore this topic for now.
> S3 - As with S1, "being declined" to "currently in the declined state"
Updated.
Tomek
More information about the kea-dev
mailing list