[kea-dev] Client classification design

[Thomas Markwalder]

On 10/13/15 11:31 AM, Tomek Mrugalski wrote:
> Folks,
> I took a first stab at the client classification design. See the
> document here: http://kea.isc.org/wiki/ClientClassificationDesign
>
> For the reference, we have the requirements more or less described here:
> http://kea.isc.org/wiki/ClientClassificationRequirements.
>
> We had some discussions about the syntax, but I did think about it a bit
> more and came up with three alternative proposals. Please comment on
> which one seems to be the best in your opinion (or reject all of them
> and propose a fourth one). I tried to be objective and not push for any
> specific one.
>
> Keep in mind that we're working under very tight schedule here and
> client classification is a broad and complex topic. There's a lot we
> could do, but due to the time constraints, we need to be very selective
> for phase 1 (aka Kea 1.0).
>
> Some parts of the design will likely be moved to the requirements page,
> but I want to keep it in the new doc for now, so you could review it
> more easily as one chunk.
>
> It would be great if you could provide your comments by end of this week
> (Oct. 16th), so we could start an implementation the next week.
>
> Thoughts? Comments? Tomatoes?
>
> Tomek
>
> _______________________________________________
> kea-dev mailing list
> kea-dev at lists.isc.org
> https://lists.isc.org/mailman/listinfo/kea-dev
We went from Stephen's initial draft of requirements to a design
document?  Did
I miss a step of reviewing the requirements?  The requirements document
itself,
while containing a wealth of good information, is more of a high level
design
than a set of software requirements.  In general, software requirements
describe a list of behaviors that system must provide, expressed as
statements
which can be verified by testing the system.

So which document are we reviewing?  We can't review design unless we've
reviewed the requirements.  Cart before the horse. Technically, a design
must be reviewed against the requirements driving it in order to ensure
the design fulfills them.

I do acknowledge that a lot of good thought/work has been done by Stephen
and Tomek, don't misunderstand.

I am going through both documents.

Thomas