[kea-dev] Decline support requirements in Kea 1.0

[Marcin Siodelski]

Francis,

The Host object reflects the structure of the host reservation entries
in the database. The declined address may well be an address from the
dynamic pool for which nobody has a reservation, therefore it doesn't
logically belong to the Host object. In other words, if the specific
property is not a part of the host reservation information and will not
be stored in the database for host reservation it MUST NOT be a part of
the Host object.

If you want to utilize the Host class for something unrelated to the
host reservation (e.g. Decline, not sure about secure-DHCPv6) you should
derive from the Host class and then you can extend your derivation in a
way that is convenient for you.

I don't want the Host class to be a collection of various properties
used for diverse purposes, as it messes up the code structure and goes
against the host reservation design. For example: the Host class has a
toText function. It prints data in the context of Host Reservation.
Adding properties to this class implies that the toText function is also
updated to print these properties. One can argue that this mix of
various properties and host reservation data is not a problem for
toText, because if certain properties are not set for the Host, they are
not printed. In that case for the host reservation we don't print any
unrelated data. Yes. But, for the purpose of solely printing the
properties like declined address or secure DHCPv6 timestamps how do you
choose what is printed with the toText function and what is not? You
don't want to print all properties together with the host reservation
details, which are just a trash in the particular context in which the
properties are important.

Please remove any extraneous information, i.e. properties from the Host
class and implement it on the derivation of the Host object.

Marcin

On 25.06.2015 20:19, Francis Dupont wrote:
> I have implemented a temporary state in the host (reservation) class,
> it can be used for decline (I use it for secure DHCPv6 to store two
> timestamps). This state is mutable (the setter is declared const)
> and its extend/lifetime is the same than the host object, i.e.,
> it is reset at restart or config reload. IMHO it is perfect for
> keeping the (transient) fact an address is already in use.
> 
> Regards
> 
> Francis Dupont <fdupont at isc.org>
> 
> PS: from memory: #3915
> 
> Tomek Mrugalski writes:
>> 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
>>
> _______________________________________________
> kea-dev mailing list
> kea-dev at lists.isc.org
> https://lists.isc.org/mailman/listinfo/kea-dev
>