[kea-dev] Client classification design

[Marcin Siodelski]

On 14.10.2015 16:44, Thomas Markwalder wrote:
> 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.
> 


I am with you here. But, I think it is a result of altering the course
in rush and simply lack of time to organize this in a right way.

Marcin