[kea-dev] Decline support requirements in Kea 1.0

[Marcin Siodelski]

I have added the reference to this discussion in the #3915.

Marcin

On 26.06.2015 12:24, Francis Dupont wrote:
> Can I put a summary of this in #3915?
>
> Thanks
>
> Francis Dupont <fdupont at isc.org>
> Marcin Siodelski writes:
> > 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.