[kea-dev] Client classification design

[Tomek Mrugalski]

Thanks a lot for all your comments. The documents are now updated. Here
are the major changes:

- Former Requirements document (that was lacking proper requirements
  definition) has been renamed to ClientClassificationDiscussion
- New Requirements document written
- Classes are now global only. Trying to define classes on per subnet
  basis was a mistake. Classification is (and should be) done before
  the subnet is selected.
- substring operator is now MUST for phase 1
- added explicit requirement for the evaluation code to be a
  stand-alone library with minimal set of dependencies.
- Added a number of new expressions for phase 2 (E.7 - E.13)
- case 1 (substring(option vendor-class-identifier, 0, 3) = "APC") is
  now phase 1
- added a list of expected tickets
- updated E.1 requirement to cover vendor-class-identifier(60)
- clarified examples
- Added G.8 (code must be located in separate lib)
- Added G.9 (must use its own dedicated logger)
- Added G.10 (number of classes must not be limited.

Two (related) things that remain unsolved are:
- which configuration syntax to use (we have a tie, one vote for
proposal 1 and one for proposal 2)
- what order to use

Currently we do:

1. classify packet
2. select subnet (we use class information here)

We need 2. to for cable networks (separate modems and other devices into
distinct subnets). If we stick with it, we won't be able to define per
subnet classes (or at least not use them to select subnets). This would
also force us to use proposal 1.

The list of expected tickets just for phase 1 is whopping 16. Even
ridiculously underestimating the tasks as 2 days/task (good luck with
implementing Bison grammar in two days), this gives us 32 days (or more
than 6 weeks) of engineering time. I leave it up to you to decide
whether it's realistic to shove this into 1.0.

Tomek