[kea-dev] Decline support requirements in Kea 1.0

[Marcin Siodelski]

On 25.06.2015 18:37, Thomas Markwalder wrote:
> 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"
> 
> _______________________________________________
> kea-dev mailing list
> kea-dev at lists.isc.org
> https://lists.isc.org/mailman/listinfo/kea-dev
> 


I agree with Thomas's suggestions above and have the following
additional comments.

"Declined address" in the terminology - suggest replacing "unknown
entity" with a "different entity", as "unknown" is ambiguous.

"Declined state":  - suggest to reword to "a state in which an address
is marked by the server as unavailable for the assignment"

G4 - rather than adding the explanation what it means to "recover an
address", it would be better to add a new term in the terminology and
use it here:

"Declined address recovery (or Address Recovery)" - a process by which
the server marks an address in the declined state as available for
assignment again, i.e. moves it out of the declined state.

G6 - I think it is too much for the requirements to imply that the
declined addresses must be kept in the database. It would be sufficient
to say that "The information about currently declined addresses MUST not
be lost after system restart or crash". Plus another requirement which
would say: "There must be a mechanism by which the system administrator
can inspect currently declined addresses".

G7 - I suggest updating this requirement to say that the log message
emitted, when the address is marked declined, includes the duration of
time for which the address will remain in the declined state.

C2 - I suggest rewording it slightly to use the terminology: "The amount
of time an address remains in the declined state MUST be configurable"

C3 - Similarly to C2 - It MUST be possible to configure the server to
keep an address in the declined state until sysadmin intervention.

Marcin