... | ... | @@ -12,6 +12,8 @@ This page documents status of client classification as of 1.5.0 (January 2019), |
|
|
|
|
|
1. With the increasing number of classes defined, kea performance drops. This can be mitigated with only-if-required flags. This, however, complicates the setup, because you need to specify in which subnets each class is required.
|
|
|
|
|
|
1. isc dhcp has a spawn client classes mechanism.
|
|
|
|
|
|
1. Whatever we choose to, it has to be documented and explained clearly. @sgoldlust reported several doc sections that are unclear and confusing.
|
|
|
|
|
|
# Goals
|
... | ... | @@ -20,7 +22,6 @@ This page documents status of client classification as of 1.5.0 (January 2019), |
|
|
|
|
|
1. Need to weigh pros and cons of keeping the options precedence or changing it. In any case, we need to explain our decision and clearly say that it's gonna stay that way.
|
|
|
|
|
|
|
|
|
# Possible actions
|
|
|
|
|
|
**Action A**: We could change the order to match ISC DHCP
|
... | ... | |