[kea-dev] Decline support requirements in Kea 1.0

Tomek Mrugalski tomasz at isc.org
Mon Jul 13 13:31:35 UTC 2015


On 26.06.2015 12:34, Thomas Markwalder wrote:
>> 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".
> 
> This one could lead us down a rabbit hole:
You don't like rabbits, do you? ;)

>>  Plus another requirement which
>> would say: "There must be a mechanism by which the system administrator
>> can inspect currently declined addresses".
> Unless it is sufficient to accept the requirement as met by us documenting
> how the information can be understood by examination of the persisted
> data.   At first blush it implies we will provide some sort of tool or
> interface
> for reporting or retrieving this information.   We also made no such
> requirement
> for any other persisted information.   I would suggest we simply drop it.
Dropped as suggested. Declined addresses are somewhat different, because
there's high chance that they require manual sysadmin intervention - at
least an investigation why the duplicate address was discovered and
occasionally a witch hunt. While the server will recover from the
situation automatically, the issue will reappear if the underlying
problem (unknown device using an address without permission) is not solved.

We'll probably have this conversation in the design phase, but I agree
that dropping such a requirement would give us more design flexibility.

Tomek



More information about the kea-dev mailing list